Its rather aÂ practice that you will find in most of the organizations. This is a form of management in which you just hit a developerÂ with a command and then run away without looking back at what the consequences of the decision has been.
Normally senior managers are too busy to micro-manage every employee and that’s good. It’s hard to know or remember the details of every project or what every employee is doing specially in scenarios where you have hundreds ofÂ developers doing lot of different projects of varying sizes.
Then, all of a sudden something changes and youÂ stop by at the developer’s cubicle and start a discussion about whatever work they are doing.Â You get into micro level detail ofÂ a project whichÂ you were completely unaware of approximately 10 minutes earlier. 3 minutes into the discussion, you find yourself completing sentences for the developer. Fascinatingly, within 5 minutes (sometimes 2),Â you presume thatÂ you know all about that given task or projectÂ and thenÂ giveÂ yourÂ verdict of what needs to be doneÂ and by when. TheÂ developer simply have to follow that without questioning.
Why is this so bad?
1. The manager ventured into theÂ project for reasons that are important to him rather than project itself. So, any decision taken will be biased towardsÂ their own interest.
2. Are you a trained Programmer ? Designer ? Database architectÂ ? Project manager ? If not, you need to recognize your limitations and be aware of the fact that your decision will cause unwanted consequences. You might even don’t understand what’s involved in getting that piece of work done.
3. You are telling theÂ developersÂ that they are not smart enough, which in the long term will have negative effects. Pygmalion effect kicks in and the motivation goes down.
4. TheÂ developer gets a false perception from that point onwards, that you are controlling or watching the project. TheyÂ will avoid taking decisions (becauseÂ they feel that youÂ willÂ change it later!)Â while you are too busy with your actual job to follow-up with that project. The project will tail-spin and you will end up blaming the developer.
So what do to?
The fact from the other side of the table isÂ that you definitely have been tipped-offÂ or something has caught your attention or fancy, for which you are deciding to take the matters in your own hands. You don’t want to do this but it seems you have no other choice. Here is what you can do:
1. Try to empathize with the employee and understand the conditions under which they are working.
2. Try adopting a consultative approach rather than a dictatorial approach. Help the employee arrive at the decision rather than making it for them.
3. Make sure you communicate the parameters you are considering while making the decision. This will set the right context when theÂ person faces the same situation next time.
4. Communicate the degree of your involvement. Make sure that you tell the employee exactly what you areÂ expecting and when will you monitor the progress again.
5. Follow-up your decisions, to see if it worked. If it has, give the employee the credit forÂ making the right decision.
6. Avoid on-the-spot decisions when you are not sure, involve people who can give you broader perspective on what’s involved.