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:
- I explained to the team the results I wanted: as quickly as possible, but it had to be right. Right trumped shoddy.
- I explained that I needed information, and how often I needed it.
- I ran interference and kept the rest of the management team informed, daily. My goal was no surprises.
- 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?
