The Enterocial need!!! Can we get Enterprises Ready?
Tuesday, 24 November 2009

So much of hype of Social Media, so much to speak about it.. but with the world turning its heads on Social Media, Social search , Social culture... are the enterprises ready to adapt any of the good that Social Media brings in? Well I am not sure how much of it will be debated or how much will be agreed... but the challenges in running big enterprises lets you think on the best ways to improve enterprises and interaction in enterprises.... and Social buzz can be of good help there...


Think about a few challenges that enterprises face, everyday...

1. Communication : Departments like Human Resources, Administration needs to co-ordinate with the employees on a daily basis, on a mass basis... every time , every other day... not only they have to depend on certain tradtional modes of communication but also on the speed that is not so very promising...Imagine HR department want to call for a fire drill emergency update? Or think of a memo to not let people smoke out of the building? Today everyone in big organizations definitely uses Mobile phones... lot of them web enabled too.... why not have a tool (not just micro blogging) like a corporate twitter or yammer to let that happen at ease...

2. Information Share : They build huge share point portals... they put processes, documents everything on that portal... they enforce everyone in the company to have the portal as a default homepage... they block general internet to make people forcibly use it...imagine a automated chat robot that works with the enterprise intranet again... ask a question and get an answer... from within the team, from the automated robot... yes an enterprise aardvark...

3. Sales , Business Development and prospect networks : There are several business units, each business unit has its own set of contacts , prospects and well wishers... however there is no way for a Business Development Manager who joined a year ago to know who are our contacts in the last 10 years since the organisation is running.... A Linked in? An internal linked in that doesnt just create profiles of your sales team but the list of your own prospects.. with references that can link to future business development. Enhance the Enterprise linked in to a step further and add cross department, cross domain feather lists...

4. Business Processes?
Each department has its own process, due to domain or work ... Enterprises always worry about getting in sync, however mergers , acquisitions don't let them do that.... now imagine having one tool that can let each unit define its own Business process yet have it integrated in a tool... A Google process manager?

But imagine all of this getting into one tool or a set of integrated tools that can help enterprises adapt social buzz in a way... Are they ready.. No... can they be prepared for it? Yes...

I would call this concept as Enterocial i.e. Enterprise + Social .. and thats what can make our lives easier.... what do you think?


Scribbled bySameer 0 comments Links to this post

What did you miss?
Monday, 23 November 2009

I got a call from a friend 15 minutes before I had to decide on writing this post... The conversation very short and simple, effect very long and lasting... To give a bit of a background my friend is leading a team of 50 Engineers, analysts, QA and Business Managers, A year ago while we were busy building our Team, he too had started to set a direction to his...


We had almost 8-9 chats on cultures and spirits and the values, bonding and emotions they generate...my friend today reckoned a statement we discussed...

"Build Teams, Don't form them"

He said he thinks using experts he just organized them and formed them to a working model... now that its a running vehicle, the moment one part mis works the vehicle stops.....So forming and Building what to choose? You may ask what difference it makes... I would say a huge..... in one of my previous posts last year.. Team Building , What does leadership need? I wrote a few points that were essential... today I speak about the steps that you may miss in Building Teams and some way chose to form them with issues that can kill in long run...

1. Culture
Usually building the teams we forget this point... Culture... We bring the best minds, attitudes , people ... do we bring a unique culture? well the answer is no... Leaders have to decide on what culture they want to have.... Do you want to be challenged? Do you want to have a flat scheme where people can ask each other questions that can lead to improvement of processes and profits? We usually assume that Best people can build Best cultures.. I think I reverse it... best cultures help build best peoples... If you dont have a culture , in spite of having a great set of individuals you may not have a great Team, or in spite of having a great Team you may end up not having a great organization...

2. Chose Diamond, Chose Gold , Chose Stone
Aint we the same people who Interview the people and decide whether they fit the job roles or not? In one of the previous posts a couple of years ago I wrote.. How to chose the right guy
eventually I also meant that lets hire those who just not fit the role, but beyond. We choose people, we dont choose Team members... If you go by Technical capabilities you need in your team, you may end up hiring a geek who stinks, doesnt speak to anyone but the screen and returns a scare for a smile... So its you who has to decide if you want a diamond that can work hard, Gold that can be sold well or a Stone that may not be as hard as a diamond, not as presentable as a stone, but can build a Great Wall of Chine when set with others as a group or Team and can compliment them too at the same time...

3. Empower them
We usually end up only coaching and coaxing our Team, we end up telling them what to do and how, they do that and they continue to do that... in process what they learn? forget if you are not looking them to learn anything... what do they teach you? Nothing????? What do they do when you are not around? How do they react when they are in a disastrous situation? We miss empowering our Teams in our attempt to build teams.

4. Trust them, Treat them
We either trust them too much or nothing... a Mantra for a successful Team is the amount of trust you put on them.... If a developer says 10 days for an effort, how many times do you ask him to justify it? If your developer is stuck in something bad, how many times you tell him that somebody else could have resolved this issue in 5 mins... Knowingly unknowingly we do this... often and more often....Trust Team , Trust them...

5. Throw them in the Sea and float them on a luke warm tub
Bring them into action in disastrous situation and let them work on best things otherwise, throw them into sucker bugs and throw them into challenges... try out all situations with them so they have a perspective of Team, Culture, Situation, Customer and Organizational goals...

Did you miss any of these while building your Team? If yes work on it now... its never late because you always have great people who work with you and they are learners....

Scribbled bySameer 0 comments Links to this post

Build fast, Break fast
Saturday, 21 November 2009

There is nothing in this world called quick solution. If something is going to be built quick , it is going to break quick. Our experience in building good quality softwares is a good example for this... I remember first time our interaction with our then Product Manager Karin.... we discussed on a feature where the estimate given by a developer to add a new feature was given to be a couple of weeks... a similar feature done earlier in couple of days...


Big Question come to the minds of Product Owners , Project Managers and even Developers when certain thing is going to take time... but the fact is that what takes time, comes with a certain level of quality... and we have to go by the fact that something built quickly can not necessarily be the best...

On our current project we faced a scenario where the framework we use gives a quick support on building JSON components...some engineers chose to go with it easy to use , easy to build.. quick to use and quick to build.. today I took time to read through the code base and that is what makes me write this today....

We in our past projects used JSON.. the only reason that the tool was supposed to be built and delivered quickly... we used it , it worked well initially.. the moment we started using it with our actual projects it started failing badly.. eccentric characters, complex data structures, variable hierarchy more predominantly the debug and maintainability headaches...for something that we delivered in 1 month took 4 months to fix in phases...

As Project Managers... we expect our teams to develop and deliver quickly... but is that worth? Is it what you are looking at in long and short term of your roadmap? the answer is and should be NO....So next time when your developer comes to you as says that he can build something very quick for you, or your estimate says that something is going to be built very quickly answer these questions....

1. What is the proportion of Build vs Maintenance
2. Can anyone in your team build the same thing that quickly?
3. Have you seen the design and are you Happy about it?
4. if your competitor says that same thing what would be your arguments to it?
5. Can it be maintained and / or rewritten that quickly?
6. Does the work reveal good quality? or just fast work?
7. Can the developer who built it stand up and say that its one of the best maintainable code?
8. Did you choose to do it because its easy to do?
9. Did you do it because there was no other better way to do it?
10. Did you think of other best practices that lay there?

So many more... but you begin with these.... As a developer however you have other more things to think...

1. Can I fix all bugs in it if it comes to me in future, as quickly as I built it?
2. Can I revert, upgrade , roll back and commit the fixes as confidently as I built it?
3. Can the weakest developer in your Team handle the bug fixes?
4. Is it quick because its a technology benefit or it is because its a way you have done it?
5. If you are out of the project mid way , can your counterpart do the same thing with same effort and have the same feeling about it as you?

Answer it.. and you may choose to do the same or other wise.....




Scribbled bySameer 0 comments Links to this post

Labels:

Lessons from the Recent Deadlock issues
Tuesday, 17 November 2009

I usually don't do this over this blog... on my private blog diary however I maintain my own lessons but thought it has become very critical and worth a share. The recent deadlock issues really really tested my patience... it started on 30th October and finally seems to have ended today. But before I loose track of what and how we did, what we should take care.. here are my lessons from the issue :

1. A bug should be treated as immutable - It should be removed or created never fixed.
Every time a bug is created in an application it causes a lot of issues. People say we fixed the bugs.. the truth is every time a bug is said to be fixed, there is either another created or the same one removed. Don't ever think of a fix actually fixing the actual problem.

2. List down the problems , don't fix them yet
We usually mistake by finding one problem and starting to fix it. A better approach is to generate a huge list of problems in 3 orders:
1. Actual Problems
2. Potential Problems
3. Past problems in the same area

Prioritize it with 3 different sets of people... QA, Dev and Project management.. generate a list and then start working on them. In the meantime you may get requests to hit each of these areas adhoc.. Do not move around, unless you have convincing inputs. Fix one and make sure the fix doesn't break anything else.

3. Pick up the one that you think is obvious and get deeper to the non obvious
When you start the investigation on tricky issues, you end up investigating or looking for problems.. more usual answer to bigger problems are very small fixes.. I remember one of the alerting issues we had in the past had a typo and 2 years 3 hard core developers could not get the fix working.
When you step into a problem area make sure you cover the linked non obvious area.. there maybe something very silly in there...

4. Never bring only experts on the issue
Experts tend to focus only on technical directions, many times experts have a rigid view of how things work and they dont want to move away from it and find problems... 3 times during this deadlock issue we found that non experts came very handy:
1st When they traced that downloads block.. by accident or by luck and by hawk eye
2nd When they found that uploads take time when done in parallel
3rd when somebody not even on the system gave an idea to look at areas that are used in conjunction and have less of a link
All 3 times we found good traces and inputs to move further and find out whats on.

5. Analyse, List , Analyse , Detail , Analyze , Fix , Analyze , Test, Analyze, Analyze the Analyzed
Follow it hard... anything you do , just analyze and re analyze.

6. Trust your Findings, Analysis, Team , Fix , Test and Release
Trust whatever you do. Stand by it. Make sure it succeeds.

7. Nothing can be found and fixed in 1 go
It can never be, make sure you find , remove and keep finding.

8. There is never an end to a problem.
It will come back. Very soon. Be prepared.

9. don't loose track of what you have done.
List them out. put it as a checklist and then tick them on and off. Revisit them.

10. Wiki your approach and the tools, technology you used to fix it
Document your approach.

11. Spend hours and hours on looking at whats going on, minutes looking at exact problem area
May help you give more ideas on where to look at the exact problems.

12. leverage the dependency factors, Isolate what is not common
Add up flexibility to your analysis

13. Make a Team to look at the issue not individuals.
Individuals focus on certain areas based on there likings and feelings. Bring a Team that can drive discussions to move in the right areas. Add Team that can value in discussions..

14. Group to find it, Individualize to analyze, Pair to fix, Group to Test
Bring groups to find the issues, helps when different people, Individuals to analyse them , brings developers to pair and fix them as they can be more effective.

15. Revisit what is done earlier
Go back and see what has being done so far and what has being done in the past.

16. Track everything you do to resolve
Keep it in a way you can refer to it later.

17. Buy a Lunch to those who fixed it
Finally !!!!

Scribbled bySameer 1 comments Links to this post

Technology , Outages , Bugs and Us
Friday, 13 November 2009

No matter what you do... there is nothing called as full automation...
One manual error and you are gone for life.... Over the last few weeks
some good effort from the Team we have successfully being able to get
rid of the eclipse to our code... Yes we got rid of conflicting ORM
technologies in our code, upgraded and migrated our self to the best
one that works...

However its not easy... technology is predictive and so are the bugs
it holds, in 2 spells we have had severe troubles. Locks , Lock
contentions , Dead locks... pulling of people from critical tasks to
let our customers use our systems, Sleepless nights debugging the
locks and the SQL behind them, debugging the code , 1 , 2, 3 several
times... , Seeking experts every now and then..

I am sure you face this, If you are a technology team every now and
then. We learn our lessons and we become more effective , more
precautionary...But is it enough?

Well No... you need to bring Caution and Precaution in the Team. Bring
a Pessimistic QA and an optimistic developer in your tasks and maybe
it will work.. Here are few things that can take you at ease when you
are in such situations...

1. Bring a Policeman in your Team, He should not be the tech Lead, Not
the Architect.. he should be one who knows a bit of technology and
asks you why a certain line of code is checked in.

2. When in troubles take Baby steps... You can change the whole world
in one day and You can change yourself to match the world in a day...
Dont try to do either.. slow down.. take step 1 watch , step 2 wait ,
step 3 snooze and step 4 wake up...

3. Relax... just hard work is not enough , you have to be creative in
finding problems

4. Do not listen to your Sales Team nor your developers.... Both go to
extremes... One wants to do everything with Technology and immediately
the other wants everything immediately...both hurt in problem
situations

5. Bring a Semi expert , Non Expert and one expert in a loop and see whats on

6. List down areas , check them out to find the issue...

while I write this I think about it... Am I going to go tomorrow and
follow this the next time we have trouble?

Hell Yes

Scribbled bySameer 0 comments Links to this post

Few ways to identify a Commited collegue
Monday, 9 November 2009

  • You have never see him out of office
  • The places he is most found is the work desk , meeting room , coffee macine
  • When he speaks about the project, he is at top of his voice
  • He is on every forum and community related to the domain you work on
  • When he is done he would sit at other desk and watch what they do, help them
  • The first and last email you get at work is from him
  • He is there in sun , rains and winter
  • You think you can sleep well because he is there to handle any emergencies
  • You get a chat message or an email in the middle of the night on how you can do something better

What else can you think of? I will add more when I get some sleep for this week.... I plan to sleep 15 hours this week ;)

Scribbled bySameer 0 comments Links to this post

Subscribe to: Posts (Atom)