Dictator paradox: Why micromanagement is so tempting

I firmly believe all creative people hate when others tell them what to do. When instead of problems to solve, they are handled solutions to implement or, even worse, isolated tasks to just complete.

Yet, the world is full of micromanagers.

Over my career, I’ve heard countless complaints about how managers do not give their reports enough context, enough trust, enough freedom. That they decide all on their own.

Why is that?

Because micromanagement gets the thing done faster.

Well, kind of. Let me explain.

Dictators and complex systems

Originally a dictator (a micromanager is a local dictator) was a role in Ancient Rome, giving almost unlimited power to a selected individual during wartime. The appointment was for emergencies only and it was time-limited.

The idea was that one person would hold all the important information in their head and, because of that, they will make educated decisions fast. And during the war, a good decision today trumps a better decision tomorrow.

Having a dictator was actually very smart.

At wartime.

You see, a war (or a company, or a software system) is an example of a complex system. One crucial property of a complex system is that nobody can have a mental model of it that is complete.

That is, there were things (probably loads of things) that the Roman dictator did not count with and which harmed the people later. But, again, during the war, all is sacrificed towards winning it. Obviously, losing the war would harm all the citizens much more.

In other words, a dictator is a reasonable solution if fixing a single problem is all that matters. A dictator heavily favors a short-term solution over a long-term solution.

That is never the case in the real world of software engineering. While there are strict deadlines, meeting them with an exhausted team that is unable to continue is not acceptable. Neither is sacrificing the quality and maintainability of the architecture.

The project you are working on, however important it seems, cannot jeopardize the ability of the team to continue tackling the next projects. This includes piling the technical debt.

Why is that a paradox?

What I write might seem clear and obvious (I hope it is!). So, where is the paradox?

I define the Dictator paradox as the following:

Given a set of projects, every single project alone will be finished faster with a dictator. However, to finish all of the projects, decentralization and coöperation will beat any dictator.

This is the reason why people talk about self-organized teams, incremental delivery, and emergent design.

This is why the industry has replaced Waterfall with Agile development.

This is also why when the pressure makes a manager forget the context and perspective, they will start to micromanage.

After all: A dictator is a reasonable solution if fixing a single problem is all that matters.

Latest posts

  • 2 min read

3 Mistakes That Give Microservices a Bad Name

I’m sad to see that microservices are falling in popularity among architects and developers. Some say they are unnecessarily complex or overengineered. That one needs to learn so many new tools and technologies. That they introduce problems we had already solved. However, many ‘do microservices’ (unintentionally) wrong…

Read More

  • 1 min read

Why Developers Should Stop Using ISO 8601 for Date-Time

When documenting APIs, developers often link to ISO 8601 as the standard for computer-readable date and date-time format. Dates and times (and time zones!) are complicated. There are so many edge cases and pitfalls. I’m sure every developer has a battle story about them. It’s good to delegate that hard work to somebody else. So when an international body that everybody knows and trusts publishes such a standard, it’s no surprise all the API designers start referring to it.

Read More