Micromanagement in Software Development… and its YOUR fault!

If you were attracted to the topic of this article, there is a strong chance that you’ve been subjected to micromanagement. You close your eyes to remember those moments of unnecessary, controlling supervision and immediately will feel the level of frustration and temperature rising with the very thought of constant interruption, distraction, and annoyance. A feeling so negative like ripping out your passion, drive, your soul.

How bad is it? Let’s be honest – pretty bad. Recent studies have shown that nearly 60% of people have experiences being micromanaged, and nearly 70% stated that this hurt their morale and 55% claiming that it hurt their productivity. So certainly, we’re preaching to the choir here… micromanagement == bad!

Then why does it still happen? Technical leaders, they definitely know better. Fully aware of themselves and being in a senior position requires a level of maturity and almost demands one to know how they function. And yet, micromanagement continues to occur and is quite pervasive. What most Software Engineering Team Members do not understand is it’s their fault!

It’s harsh, but it is true. Let me explain.

The Nature of Micromanagement

Micromanagement is a behavior of overtaking control and the reason someone wants to take over control is due to the lack of trust and fear. Imagine you’re teaching your teenager to drive. Will you grab the wheel should you observe a risk? Or will you trust young driver to adjust? Most parents grab the wheel, why? Because the risk is just too great – first the fear of well-being of a child and second – an expensive car.

Same rules apply at work. To eliminate micromanagement, the shortest path is to gain trust and eliminate fear. How do you accomplish this in Software Development? Trust is gained by understanding that the Software Engineering Team knows what to do and how to do it. It proved its ability to take on work and deal with it in a predictable and reliable way. And, if things do not go as planned, the Team has the discipline of bringing the concerns, failures, and raising important questions when the situation demands it. And most importantly, the Team has demonstrated a history of continuously performing in this professional way. Just like any relationship, trust is gained. It is earned, every single time! And just like relationships, it can be quickly lost. This is exactly where fear holds micromanagement in place.

“Trust but verify” is a common motto to suppress fear. But most Teams lack the instruments for verification. How do you verify that a Blocked work item is being timely handled to be unblocked? Or better yet, how does a leader even know that a work item was blocked and why in the first place? Do leaders only learn the details once a day, at regular meetings, or learn too late when there’s just no time to solve the challenge quickly? There seems to me a perpetual management fear of missing something, which again feeds the feeling of the loss of control.

Fixing it

Fixing micromanagement requires gaining trust and eliminating fear. Unfortunately, it’s an area where most engineers fail. Too many lack the discipline and courtesy of proper communication. In the example of a Blocked work item, wouldn’t it be great if everyone on the team always added a comment to explain the reason for something being blocked? What about regular updates of the blockage, so urgency is visible?

What about other scenarios? A bug in performance, it would be great to add an explanation of the cause when it is found. Working with others, requiring handoff – why not ensure to state when handoff would occur to allow the next person to be prepared to do their part? Or, a scenario where changes in requirements discussed verbally are not documented by anyone involved in the conversation?

On our Teams, we follow a few rules that solve that – first, an approach we call “Life Insurance”. When someone buys life insurance, they don’t buy it for themselves, but for the loved ones around them. That’s how work should be documented and communicated. It’s not for self but for the Team ( and obviously everyone else who needs it ). Of course it’s important to make sure it’s written in a way that anyone can clearly understand – no cutting corners of short ambiguous sentences loaded with tech jargon. Need a better way to explain? Capture a video, be creative!

Another approach we use is called “GPS”. It’s a technique for informing the Team Members where you are with your work. As if a GPS location, it indicates how much more work is needed to be done and when you plan on delivering it to the next person in line.

Surfacing this information helps establish trust and dismiss fear, but unfortunately it’s fragile. It only takes a few days to be away from the communication and the information overload again creates a vacuum that only micromanagement can fill. To hold trust and fear in contempt requires continuous visualization. This brings us to tooling.

Visualization Tools

We learned that most Project Management tools are actually very poor at demonstrating progress and organizing work in value streams that clearly show the progress of the Project. Even more so, when the Project spans multiple Teams it’s practically impossible to follow everyone’s progress. The closest to the solution are companies that connect BI tooling with their Project Management system and export the data that sums up visualization of progress across the board.

Unfortunately, there are still issues with this approach. First, BI tools are expensive and unless your company already bought them, that’s quite the price to pay to simply gauge the progress. BI tools also typically lack real-time visibility, and it’s not uncommon to see a snapshot with a 30 day delay. And finally, another issue – garbage in and garbage out. Should anyone not fill in the data properly, all bets of gaining desirable and accurate views are off.

There are no guardrails on the way Engineering Teams implement their development process either and Team Members lack the discipline to timely update their work when they should. Here’s a quick test – if you constantly chase engineers around to have them update statuses and estimates – you definitely understand the challenge.

Therefore to eliminate micromanagement requires a solution that can establish a disciplined development process for all Teams and then delivers a visualization of the progress in a way that makes it easy to follow, track, and detect problems. Merely with a simple look to see what needs to be addressed. Wouldn’t that be great? Here’s a plug, perhaps you should consider www.projectsimple.ai.

Exceptions to the Rule

Despite the huge benefits in working without micromanagement, we live in a real world and often, we’re forced to lead via micromanagement. Not by desire, but by necessity. An example is a code red customer support case – system down and the Team needs to come together to fix things real quick. It’s not uncommon for the technical leaders to jump in to organize the resources to address the issue by delegating assignments, or providing precise instructions.

This type of management is often necessary – to maintain the rhythm of the team and swarm them around the problem to the resolution. The key however, is not to run the Team entirely this way. Once everything’s restored, conduct a post-mortem and let the Team return to the normal cycle.

Conclusion

If you are part of the Team that is micromanaged, its time to reflect on the Team’s patterns. Does the Team communicate clearly? Does it provide timely documentation? Does it propagate information when needed and quickly? Is the Team keeping the progress statuses updated and reports impediments as soon as they are encountered? As long as Teams lack the discipline to document, notify where they are in terms of their work item progress, and lack the visualization necessary for leaders to ensure progress, the micromanagement will continue to prevail. Well, either that, or utter mediocrity if no one really cares.

So take responsibility, make your work and progress visible and freedom will be gained with confidence and trust!