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.
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.
Since the very first moment I learned about TypeScript, I knew there’s always goona be this one thing I’ll hate on: Enums. So un-elegant, so old-school, and so why-do-you-polute-my-runtime. Well, I was wrong. I use Enums now. At least some of them. Let me show you.
Recently I was re-reading one of my favorite engineering articles The Trident Model of Career Development. The sentence that caught my eye this time was a note about the role of a Tech Lead: ‘They should have good but not necessarily the best tech skills in the team they are leading.’ How does this apply to an Engineering Manager?