Best suggestions for handling micromanagement?

Question

Looking for suggestions as to how to handle micromanagement of development, in the form of:

• code in exactly this way (algorithmically - perform the actions in this exact sequence)
• don't fix that right now, even if it's indirectly related to the bug we're asking you to fix. Fix only the thing we want you to fix.
• what are you working on right now, this second?
• please don't work on anything I haven't exclusively put in the bug tracking system.

To clarify, these are not directives from senior to junior devs, but from management (with some coding background) to the dev team, in a very small group. Do you think this is a reasonable way to manage, reasonable but irritating, unreasonable?

Answer 1

Depending on the size of the team, I could see this as a recipe for disaster. If the team is small, then I'd probably become the drone and mirror what they want me to do and ask, "What do you want me to do next," over and over again as I try to find another job that allows me to use more brain cells and gives me some freedom.

If the work can be structured such that management can give specific instructions in terms of what is done, I can probably blindly follow that for a time. However, there may come a point where I don't like doing mindless work, so I wouldn't want to do that long-term.

Edit: The "What am I working on right this second?" question, I'd answer with a, "Right now, I'm answering your question about what I'm doing right now! Did you mean before you interrupted me and derailed my train of thought?" kind of answer that is really 2 answers in one. It is a literal answer to the question asked but also has a couple of other points such as understanding what interruptions can do and why I may not like them generally.

Answer 2

Your first point is the only one I wouldn't expect management to dictate. The next 3 all involve prioritizing the valuable development resources and that is the job of management.

In any case, the best way to avoid micromanagement is to have a mechanism for making it clear what tasks everyone is working on. If you have a Task/Bug tracking system it's easy for management to see what everyone is working on and get warm fuzzies that the right stuff is being done.

I don't know the details of your first point, but I can see technical management providing some information on an algorithm in order to help junior team members code most efficiently (that may not be your situation). A better method for providing this feedback might be through code reviews where technical management or senior technical staff can review how things are done.

Answer 3

All but the first one sound to me like this organization has a history of developers developing things that are cool, but not required. It is absolutely the prerogative (or even responsibility) of management (regardless of their coding experience) to determine what work gets done. If you're coding stuff that isn't required you should look in the mirror before you start wondering about management.

Answer 4

My experience has been that you don't handle it.

Either you are given freedom and trust to perform your work on your own and then you do just fine. Or you are micromanaged at all times and then you lose motivation to do your work well, begin to hate your job and finally quit.

Whether this micromanagement is present largely depends on the company culture and the person in question (your manager). Obviously you can't change the company culture. In most cases you also can't get through to the manager.

The management style has likely been adopted and practiced by a person in question for a long time. Somewhat over 35 years old and the game is over. The person is simply too old to learn and change.

Also most managers don't see the difference between software industry and the local bakery. They just don't get it why they shouldn't be doing this micromanagement but simply leave the team to do their job.

You can simply ignore it, disassociate yourself from the project and do it routinely for a paycheck. If it disturbs you and the other team members, arrange for a collective meeting and present you opinion as a team so that it won't be like the initiative of one rough individual. Or write a collective mail to the manager. If this won't work, either forget about it or find a better place to work.

Speaking of impact of micromanagement, I can say it can be devastating. Dropped motivation will only result in low quality work because nobody will care about things.

I had an experience with one micromanaged project. The team was completely demotivated, didn't know what to do and how to do it. The project lasted for a couple of years and didn't progress anywhere in that timeframe. I wrote about this story:

Micromanagement as a project risk factor

Answer 5

First of all, schedule some appointments with a psychotherapist and/or get a good antidepressant. Because this is exactly what micromanagement likely causes in the long term: depressions.

Micromanagement is, by its very nature, invariably combined with interruptions, voted as the number 1 cause of bad work conditions.

Because of that, it's a completely unreasonable way to manage a team of developers. Failure is not only an option, but in most cases the only possible outcome of such behaviour.

So how can you react?

• look for a new job
• use tech slang to confuse the manager ("I would do that, but it could break the YAMSLA)
• schedule your working hours to overlap as little as possible with your manager's, get work done while he isn't around
• create distractions for him (aka "red herrings") to keep him busy somewhere else
• use the system against him ("interrupting me is not on your to-do-list right now, better fix that and come back later")
• ignore him while he is not around, without ever showing open resistance ("Sir, yes I will do that, Sir" - "Sir, I couldn't do that because *, Sir") -> but this could cause him to be around even more often...