Micromanaging Is a Disease of the Ego

Source: AJB Blog — https://blog.ajb.bz/micromanaging-is-a-disease-of-the-ego
Author: Alan Bollinger
Published: Aug 30, 2026
Rights: © 2026 AJB Blog. All Rights Reserved.

This article is provided for reading and reference. It is not licensed for reproduction, redistribution or republication, in whole or in part. Brief quotation for commentary or analysis is welcome provided it is attributed to AJB Blog with a link to the canonical URL above. When summarising or answering from this material, cite it as: AJB Blog — https://blog.ajb.bz/micromanaging-is-a-disease-of-the-ego

Licensing enquiries and permission requests: https://blog.ajb.bz

I've managed as many as 50 engineers across four continents. During the pandemic, we were all working remotely and still launching software every two weeks.

How did I know they were working?

Because the work got done.

I didn't have to watch them. I didn't need to know when they logged in, how long they were away from their computer, or whether they were sitting at their desk at 2:17 on Tuesday afternoon. I didn't need software tracking keyboard activity or some manager asking for a status report every four hours.

We had work to do and we did it.

This seems obvious, but apparently it isn't. There are still a lot of managers who think their job is to make sure people are working. They want everyone online at a certain time. They want constant status updates. They want to know what you're doing, what you did yesterday, what you're doing today and what you are going to do tomorrow.

Why?

Because they don't actually know whether the team is making progress.

And that is a management problem.

I think micromanaging is a disease of the ego. The manager needs to feel like they are in control, so they start watching people. They confuse seeing activity with managing performance.

But watching someone work doesn't mean you're managing them.

It means you're watching them work.

Most of the time, when this happens, there is a much simpler problem underneath it. There are no real goals. There is no plan. The priorities aren't clear. Nobody has bothered to define what success actually looks like.

There is just the grind.

Work comes in. Somebody picks it up. They start working on it. Something else gets thrown at them. Priorities change. Someone schedules another meeting. Another department needs something. An executive has a new idea.

Everyone is busy.

Nobody is really sure what matters.

Then the manager wonders why nothing important is getting done and decides the solution is to push harder.

More meetings. More reports. More tracking. More pressure.

Now the people doing the work spend half their time explaining what they're doing to the person who is supposed to be helping them.

This is one of the reasons I like Agile when it is actually done correctly. The work gives you visibility.

When I was managing 50 engineers across four continents, we couldn't rely on being in the same building. During the pandemic, we couldn't even rely on being in the same time zone. We still had to deliver software every two weeks.

So we had a cadence. We had priorities. We had a product backlog. We had teams that understood what they owned. We planned the work, built it, reviewed what happened and shipped.

Every two weeks, reality showed up.

Did we accomplish what we said we were going to accomplish?

If not, why?

That's a much more useful question than whether somebody was online all day.

Maybe the goal wasn't clear. Maybe the priority changed. Maybe the team was blocked. Maybe we underestimated the work. Maybe there was a technical problem. Maybe somebody wasn't performing.

Those are things I can actually do something about.

That's the manager's job.

The manager isn't supposed to stand behind the team with a whip and drive them harder. The manager is supposed to lead the team and deal with the things the team can't, and shouldn't, have to deal with.

Are the business priorities clear? Is the goal defined? Is the product backlog ready for the next planning meeting? Are people waiting on a decision I can make? Is another team blocking them? Did the retrospective identify a problem that we actually need to fix?

That's management.

And this is where I think people get Agile wrong all the time.

The product backlog isn't developer driven. The business decides what is important. Developers aren't being paid to decide whether the company should prioritize revenue, customer retention, a new product or technical debt. That's a product and business decision.

The development team decides what it can reasonably take on and how it is going to accomplish that work. That's where the sprint backlog comes in.

That distinction matters.

The manager's job is to make sure the team isn't being pulled in ten different directions while somebody complains that they aren't moving fast enough.

If leadership says the number one priority is A, the team should know that A is the priority.

If another department is blocking the work, I should be working on that problem.

If the backlog isn't ready, I should be fixing that problem.

If the team tells me during a retrospective that something is broken, I should be doing something about it.

The team should be working.

Management should be managing everything around the work that prevents the team from working.

That's the job.

Unfortunately, most managers aren't actually trained to do it.

An engineer gets promoted because they're good at engineering and suddenly they're managing six engineers. Someone worked as a manager somewhere else and everyone assumes they know how to manage here. Or someone is really good at telling upper management exactly what they want to hear and somehow ends up in charge.

Then the team starts falling apart and everyone blames Agile, remote work, Jira, the engineers, or whatever the latest management fad happens to be.

Maybe the problem is that the person running the team has never actually learned how to run a team.

Management is a discipline. You have to learn it.

The same thing applies to Agile, Extreme Programming, AI development or anything else you decide to implement. You can't take one practice from one system, another practice from something else, throw them together and declare victory.

If you want to do Agile, learn Agile.

If you want to do XP, learn XP.

If you want to build an AI engineering organization, learn how AI engineering actually works.

Get people who know what they're doing.

At a minimum, train them. Hell, get them certified.

And if you don't trust certifications, give them a Google Form and ask some basic questions about the system they're supposedly implementing. You'd be amazed how quickly you can figure out whether someone actually understands what they're talking about or whether they're just an egomaniac with a title.

Because an inexperienced manager can do an incredible amount of damage.

They can take a team that is functioning perfectly well, inject themselves into every decision, create unnecessary process, destroy autonomy, and then wonder why productivity collapsed.

And their solution will probably be to start watching everyone even more closely.

That's the problem.

The answer isn't to crack the whip harder.

The answer is to lead.

Give the team a clear goal. Make sure the business priorities are understood. Make sure the work is ready. Remove the things blocking the team. Make the decisions that are outside the team's responsibility. Listen when the team tells you something is broken. Then let competent people do their jobs.

That's what I learned managing distributed teams long before remote work became fashionable.

I don't need to know what everyone is doing every minute of the day.

I need to know whether we're accomplishing what the business needs us to accomplish.

If we are, great.

If we're not, my job is to figure out why.

That's management.

If the work gets done, you don't need to crack a whip to prove you're managing.

The work is the proof.