How should one manage developers?
What is micromanagement? Well, it can be explained in several ways.
micromanage — to try to control or manage all the small parts of a development process in a way that is usually not wanted or that causes problems, especially with excessive control or attention to details.
micromanagement — management style whereby a manager closely observes or controls the work of developers.
It’s easy for a boss to fall into the micromanagement trap, especially for a project which is starting to slip away from control. It’s hard to resist the urge to keep an eye on every part of it then.
A software house is not a manufacture
In the so-called software factory, the employees are specialists. They sit at their place in the assembly line, fastening Ruby components together or rounding the rough edges of a Rails application on their software lathes. Software components move down the line, and they test and stamp them, in the same way, each day. Web designers design web applications. JavaScript coders code in JavaScript. The world is very clean and compartmentalized.
It’s no surprise that managers want software development to be like manufacturing.
Unfortunately, the manufacturing analogy doesn’t work. A software is at
least as malleable as software requirements. Things change in business,
and business people know that software is soft and can be changed to
meet those requirements. This means architecture, designs, code, and
tests must all be created and revised in a fashion more agile than the leanest manufacturing processes can provide.
How to micromanage?
- Propose unachievable deadlines. Make sure you don’t give your team enough time to do the work, and then blame them for not getting it done on time.
- Introduce “priority” tasks. Routinely ask people to stop working on whatever they’re doing right now to take care of urgent emergency work. Preferably in other projects.
- Request breaking changes. Often switch concepts of a project, rename domain components, replace business rules and later ask developers why they are doing the same work twice. Mind you it has been working already.
- Don’t specify requirements enough. Make sure you prepare tasks with lots of vague and poorly thought-out concepts — and also make sure you don’t give any extra time to precise them.
- Get to know what one is working on. Don’t look into Jira, Asana or Trello but just ask each developer “what are you working on currently?”. Maybe they are doing some other tasks than assigned to.
- Constantly ask for an update. Your team needs continuous attention! If it’s been more than two hours since you’ve talked to someone on your team, drop by and ask “what’s the status here”.
- Assign unambitious tasks to skilled developers. If you have great programmers in your company, make sure they do also some WordPress fixes. They cannot still build great things, they have to take a rest.
- Organize ad-hoc meetings. Developers don’t have more important things to do than random meetings. So hold a couple of two-hour-long calls every week, talk about a weather and waste their time. Then complain about missing deadlines.
- Talk about implementation-related things. Even if you are a manager and you don’t have any idea about database details, MVC flow or architecture design, pretend you know what’s going on. Suggest some improvements to an API or deployment process. Often use words like “microservice”, “read model”, “dump” and “staging”.
- Ask to reuse solutions. You probably manage a couple of similar projects. You have done almost the same feature somewhere else already. Payments are implemented in the other project as well. Ask developers to reuse that code instead of writing it from scratch, just make sure they rename corresponding concepts.
- Estimate development work. How hard can be implementing login? Isn’t it just email and password input? Many projects have already that. It must be a very simple solution that developers can get from ready libraries. It can’t take no more than 4 hours then.
Nobody is ever allowed to make mistakes!
If a developer makes a mistake, it reflects badly on you, and the whole team suffers. Never admit that you were wrong about anything. If you said it once, it’s now the law and should never be questioned.
If you follow this simple advice, then your team will be demoralized in no time. Also, they’ll hate you. Oddly, though, there’s a good chance that they won’t get their resumes together and start looking for new jobs. I have a theory about this: when you micromanage a team, it drains their will to such an extent that they no longer care.
Why micromanagement fails?
Every manager craves control.
They want to know what they are getting in return for those expensive developer salaries. They want to be able to accurately estimate the time taken to deliver a system in order to do an effective cost-value analysis and to give the client an accurate forecast of delivery.
The problem with this approach is that it fundamentally misunderstands the nature of software development. It is a creative and experimental process. Software development is a complex system of loops and interactions. It is a process of trial and error, false starts, experiments and monumental cock-ups.
As developers we need to be free to try things out, see how they evolve, back away from bad decisions, maybe use several different things before we find one that works. Very often we want to try this or that approach or stop in the middle of this task and throw away everything we’ve done. We can’t really justify all our decisions, many of them are wrong.
What about estimations?
If you ask me how long a feature is going to take, my honest answer is that I really have no idea. I may have a ball-park idea, but there’s a long-tail of lower-probability possibilities, that mean that I could easily be out by a factor of 10.
I’m not just the implementer of this software. What if we discover a better way half way through the estimated time? What if I suddenly stumble on a technology or a technique that could make a big difference to the business? What if it’s not on the road map?
As soon as you ask a developer to tell you exactly what he’s going to do over the next 8 days (or worse weeks or months), you kill much of the creativity and serendipity. You may say that he is free to change the estimates or the tasks at any time, but he will still feel that he has to at least justify the changes. The more finely grained the tasks, the more you kill autonomy and creativity. No matter how much you say it doesn’t matter if he doesn’t meet his estimates, he’ll still feel bad about it. His response to being asked for estimates is twofold: first, he will learn to put a big offset, just in case one of those rabbit-holes crosses his path; second, he will look for the quick fix, the hack that just gets the job done. Screw technical debt, I must meet my estimate. Good developers are used to doing necessary, but hard to justify work ‘under the radar’.
Wrapping up
To be clear, I’m not speaking for everyone here. Not all developers dislike micromanagement. Some are more attracted to the paycheck than the art. For them, micromanagement can be very attractive. As long as you know how the system works, you can happily submit inflated estimates, just do what you’re told, and check in the feature. If users are unhappy and the system is buggy and late, you are not to blame, you just did what you were told.
The people who live software will leave — they usually have few problems getting jobs elsewhere. The people who don’t like to take decisions will stay. You will find yourself with a compliant team that just carries out your instructions, doesn’t argue about the utility of features, fills Trello correctly, meets their estimates, and produces very poor quality software.
So how to manage developers then?
Give them freedom of work. It sounds terrifying, but finely grained management is poisonous for software development.
It’s far better to give high-level requirements and allow your developers to split them as they feel. Sometimes they will fail and you need to take it into consideration. But don’t react to failure by putting in more process and control. Work on building a great team that you can trust and that can contribute to success rather than employing rooms full of passive code monkeys.
References: