Understanding State vs. the Micromanagement Trap

Back when I was a Director of many things at one company, we had an urgent patch to go to a customer. My VP wanted it “yesterday.” Well, time only goes in one direction.

I gathered my continuing engineering team, explained the pickle we were in. “Everyone wants this patch right away. However the customer is truly pissed. I want to know that we have a fix that works. And, while you are working on it, I will need to know updates every morning and every afternoon. I will run interference for you, as well as I can.”

Everyone groaned. They knew what this meant. We had a small company. The corporate management was just down the hall from our offices. Even though I said I would run interference, nothing would prevent the VP of Engineering, the CEO, or the CTO from popping their heads in “to see what's going on.” Everyone wanted to make the customer happy, right now.

At the time, I didn't know about kanban boards. I knew about spreadsheets and email. I had four people working on this fix. I knew what they were all doing. So did they.

They managed themselves. Their offices were close to each other. Every day, about noon or so, they gathered in my office, so I would have the most up-to-date status. It wasn't quite a standup, because some of the work was what we would now call spikes. (At first, we had no idea what was causing the problem.)

As we identified the problem, I explained to management on behalf of the team how they narrowed down the problem and identified it. Then I explained to management on behalf of the team how they were debugging the problem. Then I explained to  management on behalf of the team how they were testing the fixes they proposed. Then I explained to management how they were packaging the fix they had decided on.

If we'd had a visual board, this might have been easier. I used email. It took close to a month. It was a very difficult fix.

Notice what I did:

  1. I explained to the team the results I wanted: as quickly as possible, but it had to be right. Right trumped shoddy.
  2. I explained that I needed information, and how often I needed it.
  3. I ran interference and kept the rest of the management team informed, daily. My goal was no surprises.
  4. I explained things on behalf of the team, so they got the credit. I was doing my management job, not technical work.

Because our management, and I could share the interim results with the customer, the customer was not happy during this month, but they were pleased to know we were working on the fix. By the time they got the patch, they were very pleased. It worked.

I did not micromanage my people. I understood their state. There is a big difference. And that is the topic of this month's management myth, Management Myth 26: It’s Fine to Micromanage.

If I had stood over their shoulders, and asked, “Is it done yet?” I suspect I would have had different results.

My team understood that I was doing my management job. I didn't prevent all other senior management interference. But, I prevented most of it. In return, they were free to work together to accomplish their goal: a fix that didn't upset the rest of the system and really fixed this customer's problem.

It's easy to fall into micromanagement. We, as technical people are terrific problem solvers. We excel at it. We want to help other people solve their problems. Micromanagement is inflicting help on other people. It's not helpful. It's irritating and prevents other people from doing their jobs.

Have you caught yourself micromanaging? If so, what made you stop?

4 Replies to “Understanding State vs. the Micromanagement Trap”

  1. An interesting article – as always – and I agree that what you did probably helped the team work on the problem more effectively.

    However, I started thinking about the giving credit part. I’ve had my share of project managers that “run interference” in other words insulate the team from higher management. In my opinion this always means that the project manager gets all the credit in the eyes of the higher management. This is not a immediate problem in a crisis like the situation you described.

    However, long term, running interference does lead to higher management thinking of the project manager as a rainmaker that is the only set of working brains in the team. I’m not really sure of how to fix this, but I definately think that a part of the solution is to not give all the upward communication of the team to a single person – even if the project manager is the most qualified person to speak “management”.

    1. Hi Pirkka, Thanks for your comment. Ah, I should have linked to this myth, People Don’t Need External Credit. I stressed that I was working on behalf of the team. I gave the team full credit. Management believed me. I did not get the credit, except for organizing the information, which is all I deserved credit for.

      You note a real problem. How do we help management see the real status, under normal circumstances, and under pressure? I like kanban boards for normal circumstances, because they provide more information than Scrum boards, especially if the stories are large in the iteration. Under pressure? That’s a different problem. I am open to other solutions.

  2. Hi Johanna,

    I think this article is right on the money, the team lead should take the responsibility for running interference and allowing the experts to work their magic outside of the tapping feet.

    Agreed on Pirkka’s concerns about poor leaders that absorb the limelight, but good organizations will flush this out pretty quickly. As a good leader, simply using ‘We’ instead of ‘I’ in upward (and downward) communication is picked up very quickly by those around the organization. ‘We’s build and empower the team, which in turn increases engagement and performance. Good cycle to maintain.


    1. Hi Kurt, this is my experience also.

      That’s why I italicized “on behalf of the team” in the post. My managers knew I wasn’t doing the work. I think they wanted me to wade in and write code. But I would have interfered if I had tried. Talk about micromanagement then!

      Of course, it does depend on the culture your organization has. Culture is these three things: how people are rewarded, what people can discuss, and how people are treated. Every culture is different.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.