One Secret to Free Yourself from the Overwhelm of Leadership Work

This is the January 2025 Pragmatic Manager Newsletter, from Johanna Rothman. The Unsubscribe link is at the bottom of this email.

Several of my leadership clients have this problem: they feel overwhelmed by all of their work. Here's how one technical leader, Peter, describes his problem:

“I'm in the middle of all the work. Because I've been here the longest, I'm the gating factor in everyone else's work:

• Everyone needs me to do the code reviews.
• Our standups have turned into serial status meetings. That's where I move the work to the done column.
• No one seems to have any initiative or motivation. I feel like I'm pulling teeth to get them to try new things.

What's wrong? Why don't they act like a team and show initiative? Where is their motivation?”

That's a too-typical explanation of leadership overwhelm. It's a little different for people who facilitate project-focused teams, but it feels the same way to many of my clients.

While Peter describes several symptoms of leadership overwhelm, there is one meta-problem that causes these symptoms. And he said it: He's in the middle of all their work, controlling what they do and when they do it. That's micromanagement.

Problems When Leaders Control Work (Micromanage)

The image above shows the reinforcing feedback loop that Peter finds himself in.

• Because Peter feels so much pressure, he's only doing the tactical work of building the product. He's not focused on the strategic problems of building each person's capabilities and building a team that can thrive. As a result, they don't have a team, and only Peter's problem-solving capabilities are growing.
• Because they don't have a team, they don't collaborate on anything. Their throughput decreases.
• Worse, everyone's WIP increases, because Peter is the only one with any answers. Every piece of work goes through him at least once. (Often, it's much more than once.)
• As a result, Peter feels he has to micromanage even more. No one exhibits any innovation or motivation because of all the micromanagement.

If leaders feel pressure, at some point, they realize they do not have a sustainable job. How did things get this way?

Because so many people still revere Fred Brooks and The Mythical Man-Month, especially the chief programmer model. However, that does not work if you want agility.

Agility Requires the Death of The Chief Programmer & the Rise of Team-Based Learning

In his classic book, The Mythical Man-Month, Fred Brooks publicized the idea of the Chief Programmer Model. In that model, The Chief Programmer held the entire architecture and system design in his head. Then, he parceled out tasks to the rest of us poor peons on the project, but only when we needed to know.

Unfortunately, even back in the 1960s and 1970s, very few people could keep the entire system design in their heads. And, those darn requirements—they kept changing! So the Chief Programmer still had to revisit the system design. That meant he had to change the tasks he assigned.

However, agility requires a collaborative cross-functional agile team. That means there can't be a Chief anything, especially not a Chief Programmer. That's because:

• Agile teams learn as they create the product. They learn about the requirements, architecture, design, and everything else. If they demo, they also learn a lot about what the customer wants and needs.
• That collaboration requires the team work on problems and their outcomes. Teams do not work on tasks.
• And since agile teams work through the architecture, not across it, no one ever has to work on a task.

Notice that I did not say that each member of an agile team is equal. Instead, it's that the product and the agility arise from the team's collaboration. The faster the feedback loops, the more agility the team has and the faster the team can learn together.

When technical leaders are supposed to do product development, they are not doing the strategic work of building the team. Worse, if they have pressure as Peter does, they do not take the time to grow each person's capabilities and support the team's collaboration growth.

That's why technical leaders must delegate problems and outcomes, never tasks.

The Big Secret: Delegate Problems and Outcomes, Not Tasks

Too many people think delegation means creating a long task list and parceling out work. And that's what Peter's “stories” looked like. It was common for each “story” to have 20 or more tasks, with each task as its own item in their tracking tool. In effect, each person worked as a silo, a component team.

But finishing tasks does not finish features.

That's when Peter decided to change how he worked.

1. First, he created a project charter with a product goal and release criteria. To acquire customers, they need to have several early releases. Now, everyone knows the overarching goal.
2. He conducted an “Agile” Hudson Bay Start on three features, so people understood what he meant by collaboration. The team mapped their value stream to see where they had bottlenecks. (Yes, Peter was still the main bottleneck.)
3. He stopped working alone. Instead, he (judiciously) chose when to pair, swarm, and mob. For example, he stopped doing code reviews one-on-one. Instead, he asked everyone to join him on every code review for a week. Then, he asked people to pair or triad their code reviews for another few weeks and ask him if they needed support. (This is not strict mobbing/teaming, but Peter no longer worked alone.)
4. In addition, he asked the people to collaborate. Would they be willing to pair or swarm on features?

After several demos and retros, the team learned how they could collaborate. And Peter felt a lot less pressure, because the team's throughput was so much higher. That changed Peter's problems.

Delegation Changes the System

Once the team learned how to be a team, they were able to move items across the board. They barely had standups because they collaborated more than they worked alone. And they looked motivated to Peter. Even better, now that Peter is no longer in the middle of the work, he can coach the team members to better performance. That allows the team to work better and faster.

If you are also in the middle of the work, choose alternatives so you can remove yourself from that middle. Most often, that's a function of delegating problems and outcomes to the team. Not tasks to a person. That overall delegation helps the team learn how to innovate and create their own motivation.

Remember, a lot of the fun in our work is the problem identification and solving every team member gets to do. If the technical leader does all of that, why would the people be motivated?

Everyone can learn to delegate. And the more you practice, the more you can free yourself from the overwhelm of leadership work.

(I focused on technical leaders in this newsletter. Would you like to see examples for project/product-oriented people? Or for middle managers? Let me know. Thanks.)

This newsletter touches on topics in these books:

• The Modern Management Made Easy books
• Project Lifecycles: How to Reduce Risks, Release Successful Products, and Increase Agility
• Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver