Image source: Nano Banana Pro

When I first became a manager, like so many, I had no training for it. I was a solutions architect at the time and my boss resigned. Company leadership said, “Chris, we like what you’re doing, we’re not going to backfill the leadership role, we want you to do it.”

Um. Ok.

Suddenly faced with a daunting new role, I did what I always do \- a heck of a lot of research. At the time that primarily involved reading many books on leadership. What I hadn’t realized was that people had written books that closely aligned with how I felt things should be done when it came to leadership. The most influential books in that moment for me were Radical Candor by Kim Scott and Drive by Daniel Pink. In both cases, these were people who were explaining concepts that I had in my head but hadn’t put words to.

Drive, in particular, focuses on autonomy for teams. It’s a vital concept because the highest performing teams have a high level of autonomy. That’s something that many people agree with at a philosophical level but in practice it can be a lot more challenging. When people think of autonomy for teams, they often put it in contrast to micromanagement.

Over the years, micromanagement has been pretty much universally identified as bad. No one wants to work for a micromanager. The result of this assertion is that people often identify autonomy as the opposite end of the spectrum of micromanagement. If you don’t want to be a micromanager, then you give your team a ton of autonomy. That concept would look like this:

Image source: Nano Banana Pro

But this isn’t an accurate mental model. Micromanagement and autonomy aren’t opposites. The actual spectrum should be closer to:

Image source: Nano Banana Pro

The opposite of micromanagement isn’t autonomy, it’s absenteeism. This is an important distinction. Autonomy comes from a place of trust. Absenteeism comes from a place of apathy or disinterest.

So what do I mean when I talk about absenteeism? An absentee leader is someone who is so disconnected from their team that they don’t know what is happening within the team. If someone outside the team were to ask this leader what is happening with their direct reports, they would have to resort to broad statements because they were incapable of providing any detail due to not being involved with their team in any meaningful way.

I would argue that absenteeism is potentially more limiting than micromanagement when it comes to the ability for an organization to perform at a high level and scale effectively. With micromanagement, at least everyone knows where you, as a leader, stand (even if they don’t like it). You have a particularly specific view on how things should be done, to an extreme and potentially harmful level. Contrast that with the absentee leader where no one knows what you care about.

Let’s break this down:

Micromanagement: This is often perceived to be based in a lack of trust. The micromanaging leader doesn’t believe that their team can succeed without their own direct influence. They are spending an inordinate amount of time in the details of the team’s work because they believe that without their oversight, the team will fail. They’re also less effective in their own role because they aren’t delegating the tasks that their teams can do.

Autonomy: This is often seen as a reflection of belief and support. The leader who gives their teams autonomy believes that those teams will be able to figure out what needs to be done, how to do it and how to do so in a way that delivers value. That’s not to say that they’re hands off. But they find a way to be kept involved without making the decisions for their teams unless they’re asked for help.

Absenteeism: This is often interpreted as a result of apathy or disinterest. The absentee leader simply doesn’t show up on any kind of consistent basis. That’s not to say that they’re completely oblivious but when they get involved, it’s usually because an external party (their boss, a peer) asks them a question that they should know the answer to and they don’t. It’s not until then that they become reactive and start asking questions about the work their team is doing.

The above is fairly abstract so let me give some examples from my own career to give some detail to what I’m talking about. The names in these examples have been changed as it’s not important as to who these individuals are so much as that they stand as archetypes.

  • Doyle was a micromanager. He had a very specific way that he expected things to be built and any deviation was wrong according to his preferences. What this looked like in practice was that I could build a new feature that met acceptance criteria and accomplished what the feature required. Yet if I didn’t do so according to Doyle’s specific expectations, it wouldn’t be good enough. When this happened, Doyle would call me into his office where he would have me sit next to him, for hours, while he walked through the code, line by line, and redid it according to his exacting specifications. There was no material change in the performance or quality of the code. But he didn’t seem to trust any work done how he would choose to do it. The general feeling was that the only way to do things right was Doyle’s way.

  • Leon gave his teams wide autonomy. His belief was that he couldn’t know each team’s domain as well as they did and he usually wasn’t interested in trying to force them to do something that contradicted what they felt was best. That’s not to say that Leon’s approach was perfect. He had so much faith in his teams that he felt it was necessary to get everyone’s input on every question and that it was important to build consensus whenever possible. This led to a lot of long meetings and we were sometimes slower to take action because of a lot of discussion. But we always knew that Leon believed we had the most informed opinions and that his job was to orchestrate so that we were all working in unison. The general feeling was that Leon allowed us to figure things out but he was there to support us if things went wrong.

  • Andy was an absentee leader. This showed up in a variety of ways. He rarely seemed to know, or asked about, what was going on in the department. The only times he had questions was when his boss or one of his peers asked him about something. He wouldn’t give his direct reports performance reviews unless specifically asked and then when he had those conversations, they generally boiled down to, “I haven’t heard anything negative so you must be doing a good job.” We would get questions from other departments along the lines of, “What exactly does Andy do?” and we wouldn’t have a good answer. The general feeling was that Andy simply didn’t care about anything that didn’t directly affect him.

“Micromanagement is bad”. That’s been the prevailing wisdom for years. It’s not always that cut and dry but that’s a blog post for a different day. That said, the same conventional wisdom hasn’t really covered the other side of the spectrum. Absenteeism is just as bad, if not worse. A leader who doesn’t care risks spreading that same debilitating attitude across the department. And if the people under the absentee leader are strong enough to continue to care, they become ripe for disenchantment and demoralization within the organization, knowing that their “leader” can’t be bothered to care about the work as much as they do. This is the sort of thing that can undermine a department’s ability to scale or innovate.

This isn't just about making team members feel good, it's about making sure an organization can scale its impact. Micromanagement is inefficient, yes, but absenteeism is a fundamental failure of leadership that actively prevents the ability to grow. The danger of an apathetic leader is the trickle-down effect \- their lack of enthusiasm often mirrors itself in the performance and attitude of their subordinates. Strong, caring team members under an absentee leader become disengaged. When your best people are checking out because their leader won't show up, you lose more than a headcount number, you lose the engine for innovation. True autonomy requires a present, engaged leader who believes in the team's ability to succeed, not one who is simply checked out and hoping things work out. Engineering excellence relies on that belief.

Keep Reading

No posts found