Archive

Archive for the ‘Project Mangement’ Category

An open letter to micromanagers – Another classic article from scott berkun

October 12th, 2009 Sarath Comments

In his recent article, Scott Berkun reloaded his shot gun against micromanagers. Here I am quoting some best part of his open letter to micromanagers. You may why should I post it here. Because I hate micromanagement, absolute waste of time, energy, full of desperation, de-motivation, unbalanced team, poor culture, more pressure… Even I’ve seen some managers spoiling good culture and harmony in the team by “pressurizing the team”. Nobody gains from this.

67295.strip[1]

Image courteously from dilbert.com

 

Owners of thoroughbreds never stop their horses during a race, every ten seconds, to remind  the horse and jockey how to run, where the finish line is, or that it’d be a good idea to finish first. Why? It would slow them down. Only an idiot would do this.

 

If you’re a manager, you must assume you have thoroughbreds working for you. Your job is to give them what they need to win their respective races, agreeing with them on the goal  and rewards, but then getting the hell out of the way. Until they start jumping fences or attacking other horses, you have to let them run their race.

Even if you are 30% better at a task than someone who works for you, the time it takes for you to check on them every few hours, and demand approvals over trivial decisions, costs more in lost morale, passion for work, and destruction of self-respect among your staff than the 30% you think you’re adding.  No one works well if they feel they are being treated like an idiot child. Having two people involved in work that should only require one wastes everyone’s time.

 

But if you are in fact a micromanager, you started over-managing the day you started. You have  no idea of the potential of the people who work for you

 

An easy test of micromanagement is to let your team know you are confident in their ability to do their job and offer, if they wish, that you will be less involved in their day to day work to give them more room to perform. Tell them you are available if they need you, but otherwise you will put some of your attention elsewhere. See what happens. Hold your tongue. Don’t demand to review that email. Don’t insist on regulating who can meet with who. Take one small step backward and see what happens.

Your best employees will be happier and more productive, giving you new energy to invest in the rest of your work or more afternoons where you can head home early. Some of your team might surprise you, and thrive with more autonomy. And for those who fail to improve or make mistakes, you’ve lost nothing, as you can step back in where it’s actually needed.

 

Perhaps you’re afraid to admit your people can function quite well without your approval or input on every stupid little thing. Or it could be you are proof of the peter principle, and would be happier and more useful if you stopped managing and worked solo.

 

Good managers are brave, and generous with trust in their people. The want them to mature in their judgment and grow in their skills, preferring to err on the side of trusting too much than trusting too little. They take pleasure in letting go and giving power away to their staff, accepting that when someone who works for them shines, they shine too.

And the best part

Hugs and kisses,

Signed,

The people you are micromanaging

How to keep your mouth shut – interesting article by Scott Berkun

October 3rd, 2009 Sarath Comments

keep-silence I am a hard fan of Scott Berkun especially because of great essays and his book “The Art of Project Management” (it has a new updated version called “Making things happen”) which is one of the best management books I’ve ever read. Trust me, it doesn’t contain any bullshits. It talking about the common stuffs in Project management with common sense.

This time I am really interest to quote about his new article in posted in his Blog “How to keep your mouth shut?” Why I am quoting this here because this is a common problem we face including myself  in our day to day life. At least I am experienced few things he mentioned in his blog post.

As a rule, if you insist on speaking your mind, you will inevitably find yourself in an environment where everyone hates you.  Most people can not handle the truth. And the more you shove it in their face, the easier it is for them to ignore you. You simply become the person who always complains, rendering any good ideas you have entirely impotent. Your ideas will be shot down simply because of the reputation of the mouth they come from.

When you’re working under good teams you will get applauded regardless of the senior audience. But he talks about the time where he worked in a team where no one spoke their mind in public.  Few people worked hard or asked tough questions. Quality of work, and morale, was low.

In this kind of situation people may consider your view points as wrong or arrogant.

If you don’t know the angle being played, anything you say might ruin the plan.

This is a great rule to follow before you raise objections or offer big ideas. No matter how right you are, if you care about effecting change, you should never open your mouth without some sense of who will agree with you and who won’t.  If you can anticipate the angles and responses, and judge, even by guessing, if there is a 80%, 20% or 0% percent chance anyone in good standing will follow your lead in support of what you say, you know whether it’s worth opening your mouth. It’s a world of difference of perception when someone respected says, after you speak, “he might be right” and when there’s only silence. And of course, in most cases your percentages go up if you raise your objections in private, rather than in a large meeting where egos are at stake.

We must have experienced situations where our words took in wrong sense. May be we’re talking or raising the hands when we are foreseeing some issues, dealing with BS management, poor tracking, planning, unrealistic estimations and schedule. But remember, someone more powerful than you should have to agree with what you’re saying, otherwise the situation comes like your words got misinterpreted. Trust me, it’s hard to convince your seniors and you will have to do your homework on how to convince them if you’re seeing some wrong or may we need to understand ourselves why such a decision has been made. For this Berkun has another interesting essay – How to survive bad managers?

If you’re saying something, just think twice whether it’s gonna be respected or agreed by your audience. If we’re feeling our ideas or opinions are great, we should have the convince the audience about your view point. Our actions and images are the core things behind these acceptance. If you’re having a bad track record it simply hard get proved unless you’re introducing something great to change the status quo.

On the other hand(receiving end), we’re not comfortable in changing the coziness we’ve, sometimes even if realize it’s a mistake. In the classic book code complete Steve McConnel says -

Any fool can defend his or her mistakes—and most fools do —Dale Carnegie

If a person refuses to admit a mistake, the only person she’ll fool is herself. Everyone else will learn that they’re working with a prideful programmer (person) who’s not completely honest. That’s a more damning fault than making a simple error. If you make a mistake, admit it quickly and emphatically.

If she refuses to admit a mistake, the only person she’ll fool is herself. Everyone
292 else will learn that they’re working with a prideful programmer who’s not
293 completely honest. That’s a more damning fault than making a simple error. If
294 you make a mistake, admit it quickly and emphatically.

The post is still incomplete because these kind of things may vary from people to situation. Some good related essays from Scott is here.

[Updated 2009-10-13 12.00 Noon JST]

Fixed typos. reduced the usage of BS :) (Sometimes I forgetting I am not an American :)

Managing your Managers

May 11th, 2009 Sarath Comments

If you’re a professional software developer, you might have faced various types of project managers. Some of them might be non technical project managers while some other are came from technical background who are 10 years behind the times. It’s hard to have technically competent and technically current managers.

Peter Principle also comes in the picture some times, In a hierarchy, every employee tends to rise to his level of incompetence.

There’s a short and interesting paragraph on “Managing your Managers” the classic book Code Complete 2.

Managing your manager means, telling your managers what’s the best thing we can do in the particular situation. At the same time you’ve to give him a feeling that you’re still being managed.

The book suggests following tips.

  • Plant your ideas for what you want to do and let’s wait for managers decide what you should do after having a brainstorm.
  • Educate your manager on the right way of doing things. It’s often happening because the managers are often promoted, transferred or sometimes fired J
  • Focus on your manager’s interests, what he really wants to do. Never distract him by talking too much on implementation details.
  • Refuse to do what your manager tells you and insist on doing your job in the right way.
  • Find another job

Those are the quick tips on the topic. I’m particularly interested in the 3rd topic. It’s frequently happening with every projects. In most of the cases your managers and project leads will not too much involved in your implementation details. Often the developers tend to have describing each and everything they’ve implemented as an answer for 10 marks essay to his manager. If your manager is ignorant about a particular technology or technique, never let their brain burn with confusions. Give high level details on the problems.

On the other side, I recommend the managers for not too much involve in the technical matters if they don’t have any grips in that. Because this will make the developers irritated and has to spend too much time for explaining things.

On the 4th point, it’s really hard to do. Refusing the things have said by your manager. But if you diplomatically handle that your good ideas will cherish and will do well for your project. You should not blindly refuse to do things, give appropriate reasons and provide solutions for the problems. Thus, don’t provide lame excuse, provide alternative better solution.

Finally everything depends upon the attitude of the managers to accept the inputs from juniors or developers. Some managers are too arrogant their pride will never allow them to accept good things. Such kind of managers are hard “manage”. Without power, human being is nothing. You will suffer especially if a fool get power and have control over you. So the last option is to find another job.

Think twice, give options for your managers for the good will of the project. Also don’t forget to give a feeling that you’re still being managed by him or her(even virtually you’re above).

Project Management and Program Management

April 21st, 2009 Sarath Comments

There are various discussions I heard recently on the responsibilities of Program Manager and Project Manager. In most of the discussions Program manager is much highlighted than project manager while it’s isn’t like that. But of course I believe it’s a glorified title of project management.

In 1980’s Jabe Blumenthal at Microsoft identified this special job to coordinate the engineering efforts with business and marketing side of each division. Program manager will be involved in project from the day one of planning and the last day of testing. It had to be someone who at least technically-respectable by programmers and also at the same time to involve in a broader participation in how the products were made.

An excellent project management book “The Art of Project management” by Scott Berkun has clearly distinguished what’s project management and program management and I think it’s the only book explained about this topic in such a nice way. He define program management as

He’ll be mostly involved in various tasks like writing specifications, reviewing market plans, generating project schedules, leading teams, doing strategy planning, tracking bugs, cultivating team morale and anything else that needed to be done that no one else was doing.

Not every member of the team would report directly to the program manager but he’ll be granted authority to lead and drive the project. In other ways, there will be functional and project reporting points for an individual programmer. I believe we’ve no doubt on the role of project manager.

Even the role Program manager is not defined in many companies, there are many managers doing both project management and program management. Large companies like Microsoft are clearly implemented and has scope for that particular role. But in small companies, dedicated program managers are rare and that role is handled by the project manager and his delegates.