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.
