Friday, 2 February 2007

Success is in ????????????

The more of a Manager we be the more we loose on the leadership front… this I have noticed over a period of time while Project Managing…. While I think about all this I realize that this really has nothing to do with Manager or being a leader but rather with everyone be it a developer or QA or Manager… I think success is a radish that everyone really wants to achieve and for that they do anything and everything… I thought I would put up some points that can tell you where we fail in defining success:

Success is in:

1. Empowering the team to handle their tasks but not driving them to solutions….
2. Involving the Team into decision making and not defining what they have to do to achieve a solution…
3. Meeting as a Team to discuss problems and solutions not just taking it away…
4. Responding to queries and exploring solutions rather than waiting for them
5. Being Yourself rather than pretending to be someone else
6. Sharing the experience with everyone and not keeping things within fearing that everyone will be what you are….
7. Listening to what others want to say rather than pretending to know you know everything
8. Telling what you know and exploring the options within but not defining it to be the ultimate solution
9. Reflecting rather than being Opaque… so that other's can have a space to expand
10. Prompting rather than commanding so that everyone gets help wherever required… and still can balance themselves
11. Suggesting rather than dictating so that you learn what is in store with others
12. Connecting rather than isolating…. Like …How good it will be to involve the Developer while we discuss the requirement changes with the BA
13. Digging it rather than wrapping it with some make ups…. Like do you think that there is more of a problem in the solution?
14. Encouraging rather than hiding the credits… Like… This is something that was a problem since long… I am sure this solution will be liked by everyone
15. Focusing rather than deviating…. Like we discuss about all the issues in the company when doing a personal appraisal…
16. Being specific than generalizing like "Saket missed the bug which is causing the broken application" … rather than saying "QA missed the bug or dev did a faulty code to screw the app on a whole" (Sorry Saket that was just an example)
17. Marshalling rather than getting driven …. Like Agreed that this is a problem but for now our objective is to resolve XXX problem… lets come back to this when we have resolved it.
18. Challenging than accepting everything like "do you think that's the ultimate solution?"
19. Reading it to the bottom not just the heading

Information………………

Every morning for years, at about 11:30, the City MIC telephone operator in a small town received a call from a man asking the exact time. One day the operator summed up nerve enough to ask him why the regularity.
"I'm foreman of the local sawmill," he explained. "Every day I have to blow the whistle at noon so I call you to get the exact time."
The operator giggled, "That's really funny," she said. "All this time we've been setting our clock by your whistle.

The moral of the story is that sometimes we rely so much on a set of information that we really forget to testify the originality and reliability of it. You agree or you don’t I see it as a SIN in Project Management. If you want to be a Good Manager you need to make sure that what you have is correct and testified, if not you have to take the pain to do it before actions are performed on it. The added pain you take will also help you be a curious, inquisitive Manager who wants to learn more than pretending to know or giving Bookish answers…

There was a question raised in the SEO caferatti that happened 3 weeks ago at the KP Barista where SEO Manager of BigBytes raised a question saying “I am subscribed to several forums and websites and a part of Global SEO community, yet reading and implementing all the changes is not getting me to a highly trafficked website”. The answer was clear the information he was subscribed to was either not true/ bookish/ not relevant for what he was doing / not a solution and still he ended up spending 3 engineers work on a strategy which was uncertified…. Good Managers take a added step before provoking the team to move in the given direction so that they don’t end up in the debt of Fatal mistakes on irrelevant information.

Where do you think you stand while you use the information process in your team?