When should a manager step in?

Not a single sentence of this article has been written by AI.

Most management questions can be answered by "it depends" and "I know it when I see it". A couple of weeks ago a peer asked me "how do you know when to step in and give directions as a manager?" My first hunch was to reply "based on my experience (and many mistakes)".

We had a good back and forth on this question, so I thought this would make a good blog post. Here it is.

Introduction

Managers are here to... manage. One would be right to question the value of managers who do not make any decision or never step in to help their team. Some organizations do confine managers to pure people management activities (hiring, performance management, administrative tasks such as PTO approval), but those are rarely the best-in-class, most effective organizations.

The other extreme is not any better. A manager who's always intervening and making every single decision will soon be left on their own. No knowledge worker wants to be confined to pure execution. The best employees want agency and autonomy. Micro-management is the surest way to create attrition within your team.

One of my favorite management books of all time is Turn the Ship Around! by former Navy captain David Marquet. Most management books are repetitive and boring to read - this is not one of them. Its main thesis might seem common-sense nowadays: replacing the leader-follower model with a leader-leader model leads to a more effective team. It also offers many useful techniques to empower your team. If you're looking for a more systematic treatment of this topic, I highly encourage you to read it.

This is a very nuanced topic, I'll provide you with a few ideas and models that can help you think about whether and how to step in.

Having to step in is a form of management failure

None of this article should be construed as a one-sided justification for manager's intervention.

One of my previous managers told me he would postmortem every time he had to step in to make a call for his team. That's a pretty good idea:

What competency do we lack as a team? Should we grow it internally (coaching, training, documentation, etc.)? Externally (hiring)?
What piece of context was my team lacking?
Was the "why" behind this project clear?

You need to be able to trust your team to scale your impact.

The what: "below the waterline" mistakes

There is a corollary to providing your reports with agency: you must let them make mistakes, which is - as all parents know - the best way to grow and build competency.

We can make a first distinction. A ship's hull can be divided in two parts. Any hole "below the waterline" will surely lead to the ship's demise. "Above the waterline" holes are not as impactful.

So, when considering a team decision you disagree with, ask yourself: "if it's a mistake, will lead to a hole 'below the waterline'?". If so, it's a good sign you should intervene to save your team/employee from a fatal, potentially career-limiting mistake. The same goes with one-way decisions that are very costly to reverse.

The what: disagree & commit to difference in taste

You also need to distinguish between potential mistakes and stylistic details. Most decisions involve a nuanced understanding of tradeoff, for which taste matters (especially when it comes to system design). For instance, when reviewing code, you should approve liberally if your only feedback is about style¹1. For instance, if you're passionate about Functional Programming, you probably don't need to ask your reviewee to rewrite all their code to follow those patterns..

If you have a strong opinion about how things should be done (most managers do), then it's worth at least spending the time with the individual contributor in charge of the project to pitch your idea. You're only trying to convince them while acknowledging that they're in charge of the final decision.

Depending on the importance of this decision, and the tradeoff horizon involved, it might be a good idea to capture how you're thinking about the same problem in writing, so that you can reference it later. The goal is not to be able to say "I told you so!", but to ensure the team as a whole extract all the learnings from that past decision.

The what: the vision is usually a single person's responsibility

The strongest visions are the most consistent ones. Consistency almost definitionally requires a single origin. The manager is usually uniquely positioned to provide that vision, because they have the most business context, and the most credibility given their differentiated role.

Note that it does not follow that this vision solely comes from the manager. Quite the contrary. Sometimes, the team is relatively aligned on a technical topic (e.g., "we need better observability", or "we have too many micro-services", or "we need to invest in reliability") and all it needs is a manager who reinforces that vision with some key design ideas.

"When" to step in: seizing the moment

Choosing the right moment to intervene as a manager requires a lot of judgment. Here are a few guardrails:

Lots of ambiguity: good managers step in to help their team escape analysis-paralysis by providing design constraints. At one point in my career I made the mistake to let the team design a completely new service with carte blanche. They quickly got lost and spent two weeks challenging every single part of the infrastructure we had built so far. Once I stepped in to provide some constraints (a soft deadline, and coached them to reuse the existing stack, focusing on the differentiating features of this new service), the situation unblocked itself.
Design conflict: a good manager won't let a design disagreement block a project's progress for too long. That's another mistake I've made: an engineer was driving a new system project, and would change their mind based on their interlocutor (they wanted to follow approach A, a senior tech lead convinced them to do solution B, and during RFC review another team's senior IC drove them towards solution C). While all three solutions had different tradeoffs, I let the situation linger for too long before stepping in to clarify that this was their project, and that their solution A was a perfectly reasonable one if they believed in it.

"With whom": the TRM (task-relevant maturity)

Andy Grove coined the TRM (task-relevant maturity) acronym in High Output Management: your amount of involvement will range from full delegation (high TRM) to close direction (low TRM).

While it usually correlates with the individual's seniority, it's a good idea to challenge that bias. For instance, some very senior folks have much less experience with public speaking than others, and in that case, it makes sense for you to review the presentation material, ask for a rehearsal, etc. beforehand.

I find this concept to be useful for a-posteriori reviews too: when you review your level of engagement, you should verify that it was appropriate for the individual's particular TRM at the time.

The "how": different ways to intervene

There are many ways for a manager to intervene and picking the right way evidently depends on the situation:

Providing a constraint or a pattern: for instance, all new features must be behind feature flags.
Changing the project staffing
Killing or redirecting a project
Influencing direction by encouraging a direct report to double down on their chosen path, or re-stating a clear vision, providing a target metric.
Making a direct decision, overriding past directions. (should be postmortem'd)

A principled "how"

A good manager intervention will ensure that the team learns so that next time, it can be self-sufficient:

Principled: if you need to step in, you'll have to explain why you're doing so and what principles are helping you make a decision that your reports weren't able or willing to make. For instance, you should be able to pinpoint the missing aspects of a tradeoff analysis.
Contextualized: perhaps your report were missing a critical piece of context that you're providing (in which case, it's a good idea to reflect on why you/it wasn't clear in the first place).
Empowering: it's not always trivial to do, but a good manager intervention strikes a good balance between "unblocking clarity" & "leaving the employee at the helm".

Further resources

This is such a deep topic. I could only provide some high-level thoughts. Here are some resources to go further (as always, check out my engineering-management repository for more.

About Decisions: