It's time to talk about micromanagement

In the early ’00s, I worked for a start-up in the education technology space. It isn’t important what we did (and the company no longer exists), but my experiences there shaped my view of what management should be like.

The worst manager

Early on, there were only about six of us: the founder and president, whom I’ll call “Paul;” the CEO, whom I’ll call “Bill;” and four tech folks including me. Paul had hired Bill to manage the operations of the business so that he could, ostensibly, focus on the sales and customer relations.

But Paul came around a lot, and he wanted to be very involved. He wanted to know what everyone was working on, he wanted to tell us what we should be doing. There was one day that I remember clearly:

Paul had come around to the office to see how a project was going for one of our newer customers. He also had meetings with other customers or prospects, at their locations, for the rest of the day. I remember him telling a colleague of mine, who was working on this new customer’s project, to email him every single hour with a status update while he was out of the office.

Every single hour.

Fortunately, Paul wasn’t like that all the time, I think he was particularly paranoid about this one customer. Still, we joked about that request for weeks; we all thought it was insane. If you need to know what’s happening each and every hour of the day, you obviously don’t trust the people doing the work.

Also fortunately, Paul wasn’t our manager. As the company grew, he became increasingly distant from the daily details. I’ve had this experience with other founders. It can be hard to let go.

The best manager

Years later, Bill left the company. Before he did, he helped Paul find his own replacement. We’ll call this new CEO “Richard.”

At this early point in my career, Richard was the best manager I had ever had, and he retained that title in my mind for years onward. What made him so great was his ability to understand what was important and when things needed to get done, to protect us all from the demands of our stakeholders, and to trust us to get our work done.

Richard would check in with us perhaps a couple of times a day. We could see each other from our desks, as mine was directly outside of his office, but he never tried to tell me how to break up my day.

Our little company was acquired by a national firm, and we thrived for a while, until the stresses of delivering larger and larger contracts overcame me and I had to leave. The company ultimately didn’t survive as a subsidiary of that larger firm, but I know that it was the firm’s mismanagement that led to its demise and not the way Richard ran it.

Micromanagement can be stifling

There is a reason that the top-rated managers take a hands-off approach to the work of individuals on their teams. People want to be led, guided, coached; they don’t want to be told exactly what to do.

That’s why the second principle of The Engineering Manager’s Charter is “Tell me the goal, not the steps to take.” So much of the learning, and the fun, is in figuring out the steps to take. Don’t rob your team of that experience.

But, I say that micromanagement can be stifling because there is always a time when a specific directive is useful. To understand how and when to apply different styles, I like the framing of Paul Hersey and Ken Blanchard’s “Situational Leadership Theory.”

In the Situational Leadership model, a team member is located at one of four “maturity levels” (which can vary by task), and those are:

Unable and insecure
Unable but confident
Capable but unwilling
Very capable

Based on where an individual is within that continuum, you adjust your leadership style accordingly, either “telling” or “delegating.”

In my experience, “telling” is only productive at the initial skill levels. Even novice engineers want the space to explore, make mistakes, and learn from them. Be deliberate about when you give someone an order versus when you give them a suggestion.

Leading, and managing, thoughtfully

You probably want some concrete tips or suggestions for leading effectively without stifling your team, so here they are.

Limit check-ins

Unless the deadline for the work is imminent, like within hours, don’t check in constantly. Even if it is, be careful not to distract the individual doing the work with requests for updates on the work.

I like agile methodologies that promote ongoing asynchronous updates (like comments on GitHub or Jira tickets or similar) and daily in-person updates (like stand-ups, either face-to-face or on video chat or in Slack).

Set SMART goals

As individuals become more self-sufficient and no longer need you to tell them exactly what steps to take, transition to providing more abstract goals, but make the SMART:

Specific
Measurable
Achievable
Relevant
Time-bound

Note that “specific” doesn’t mean telling someone exactly what to do, it means that the goal is focused on a single thing, a specific objective.

Transition toward coaching

Coaching is the opposite of micromanagement. When a micromanager wants to define each step in detail, a coach asks the question “what steps will you take?”

The goal is to reach a point where everyone in your team understands the goals and their purpose, is adequately skilled to do the work or to learn what they don’t know on their own, and needs your help only to guide and inspire them.

Using a coaching methodology, you can help people find their way through their own sticky problems, and provide a “north star” to navigate toward. Working for people who do this very well is joyful.