Tag: engineering management

The Shift to Managing Managers

From managing work to managing context

Vancouver, Canada – Photo by Kevin Goldsmith – February 2026

One of the most abrupt transitions in a leadership career is the moment you stop managing a team and start managing managers.

It rarely happens gradually. One day, you lead a small group and their output. The next, you oversee an organization whose work you can’t directly touch. You can study, prepare, and talk to experienced peers, but most learning comes the hard way.

What makes this transition particularly tricky is that the behaviors that got you here often stop working once you arrive.

When you manage a team, being close to the work is an asset. When you manage managers, that same instinct quietly becomes a liability.

The real tension: leverage versus comfort

People often frame this as a choice between autonomy and control. That’s partly true, but not the core issue.

The deeper tension is leverage versus comfort.

Staying close to execution feels safe. You know what’s happening. You can catch issues early. You feel accountable in a very tangible way. When something goes wrong, you can point to where you were involved and how you tried to prevent it.

The problem is that this sense of responsibility doesn’t scale.

As your organization grows, your job requires a different orientation. You need to look outward and sideways, not just downward. You need to understand the business direction, align with peers, and identify organizational risks before they become visible problems. None of that happens if your attention is consumed by team-level decisions.

Managing managers isn’t really about getting closer to the work. It’s about being clearer about what the work actually is.

How over-involvement erodes ownership

When leaders stay too focused on the layer below them, the effects show up quickly.

The managers reporting to you lose ownership because you’re implicitly taking it away from them. If you’re paying more attention to their teams than to them, they stop behaving like leaders and start behaving like intermediaries. They wait. They escalate. They defer.

At the same time, you become a decision-making bottleneck. The fastest way to ensure decisions align with your thinking is to require approval. That works in the short term, and it feels responsible. But it trains the organization to route everything through you.

Once that happens, your leverage disappears.

You’re always busy, but the organization actually slows down because decisions wait for you instead of being made by those with the information.

Worse, your own growth stalls. You can’t take on a broader scope because you’re too essential to the current one.

Why context matters more than answers

Early in my management career, I was rewarded for being deeply involved. I worked hard to be a good manager, to support my team, and to fix problems directly. That approach produced results.

When I began managing larger groups, I kept using that approach, expecting it to work.

It didn’t.

My intent didn’t change, but the effect did. All the context lived with me: the business constraints, political realities, and broader trade-offs. My managers lacked that context. I failed to transfer my understanding.

Decisions slowed down. Some were simply wrong. And the surprises I got were coming from the wrong direction. Instead of hearing early warnings from teams, I was learning from peers that work had been duplicated, priorities had shifted, or entire initiatives had moved without us.

Managers don’t usually need more direction. They need better framing.

When people understand what their work means in the larger system, they make better decisions on their own. They know who to talk to. They know what to ignore. They don’t need you as a relay for every conversation.

If your managers need you for every decision, you don’t actually have a management team. You’ve built a relay where everything passes through you.

There is one relay role that is appropriate: translating senior leadership’s context into something your organization can act on. Being the relay for your own teams, or peer organizations, is not.

The shift in where your attention belongs

There are two directions mid-organization leaders can focus.

Looking down is about coaching, quality, consistency, and execution. You’re responsible for results, but no longer do the work. Your job is to ensure that your managers are capable and focused on the right things.

Looking around is about strategy, alignment, organizational dynamics, and external signals. This is where managers of managers add unique value. And this scope only increases as you move up.

At some point, your role shifts from decision-maker to context-setter, standard-setter, and sense-maker.

Autonomy doesn’t grow because someone has “earned it.” It grows because shared understanding exists.

Delegating decisions instead of tasks

One of the most common mistakes leaders make at this level is delegating tasks rather than decisions.

Task delegation keeps control with you. Decision delegation transfers ownership.

If managers bring you work to approve, you haven’t delegated. You’ve added a step. Permission makes you a bottleneck; reasoning makes you a coach.

A simple change helps: ask “why did you choose this?” instead of “what do you want to do?”

That question is neutral, non-confrontational, and incredibly revealing. It tells you how someone thinks, what information they used, and what trade-offs they considered. If their reasoning is weak, that’s a coaching moment. If it’s strong, you learn something.

Warning signs you’re overmanaging

Overmanagement has predictable symptoms.

Managers escalate decisions that clearly belong to them. You’re deeply involved in hiring, performance management, or prioritization well beyond what your role should require. People ask, “What should I do?” instead of “Here’s my thought.”

Work slows when you’re unavailable. Vacations create anxiety. Your calendar fills with internal reviews and status meetings. Teams schedule their work around your presence. When everything flows through you, things might work, but they only work while you’re there.

Feeling indispensable is not a success metric. It’s a warning sign.

If the system only works while you’re holding it together, you’ve capped both your organization’s growth and your own.

Resetting decision boundaries

If you recognize these patterns, the first step is acknowledging them. To yourself first, then explicitly with your managers.

Staying too close to execution limits their growth. It also quietly limits yours.

One tool I’ve found useful is making decision boundaries explicit. With each manager, define:

  • Decisions they should make without telling you.
  • Decisions they should make and inform you about.
  • Decisions they should consult you on before acting.
  • Decisions you will make together.

The specifics will vary by person and role. The important part is that expectations are clear at the decision level, not just the role level.

Over time, decisions should move steadily toward greater autonomy. That movement marks growth, builds trust, and reduces dependency.

Expect friction during the transition.

Stepping back doesn’t immediately make things better. It usually makes them messier first.

Decisions will be uneven. Managers will test boundaries. Two people will make different calls in similar situations. That inconsistency is uncomfortable, but it’s part of the calibration process.

Use one-on-ones to learn how decisions were made, not approve them. Ask about data, risks, and expected outcomes.

Sometimes you’ll realize they missed something important. Other times, you’ll realize they saw things you didn’t. Both outcomes are valuable.

Replace control with calibration.

What you’re actually building

Managers operate under pressure from their teams while lacking full information about the organization. New managers optimize for approval when leaders are hands-on. Experienced managers read close oversight as a lack of trust.

When context isn’t shared, people invent explanations for what they are seeing in the organization. Alignment drifts. Culture debt accumulates.

Prevent this by making the invisible visible. Share what you hear, explain trade-offs, talk about constraints, and show how decisions connect.

If you do this well, work won’t pause when you step away. Decisions will improve because they’re made closer to the work with better context than you could ever have alone.

Scaling leadership means building teams that make informed, independent decisions and create lasting impact beyond your presence. Transitioning from managing work to managing context is essential for real organizational growth.

To hear an extended discussion of this topic, please listen to my podcast episode: The Shift to Managing Managers.

Some helpful references and tools related to Managing Managers:

  • “Using Agile Techniques to Build a More Inclusive Team” – In this talk, I explain an exercise I use with the managers who report to me to help establish a mutually agreed-upon framework for who makes what decisions.

Originally published at https://kevingoldsmith.substack.com/p/the-shift-to-managing-managers

Leading What You’ve Never Done Before

What happens when your role outgrows your technical background

Tokyo, Japan – Photo by Kevin Goldsmith – January, 2026


One of the guarantees of career progression in technology leadership is that, eventually, you will outrun your own resume.

Most technology leaders start as specialists. Frontend, backend, SRE, QA, mobile, data. Your first leadership role is often managing a team you used to be on, doing work you understand deeply. That familiarity is comforting. It’s also temporary.

As your scope grows, you start owning work you’ve never done yourself. A backend lead suddenly finds themselves managing frontend teams. An application developer finds themselves responsible for mobile, infrastructure, data, or security. Eventually, the gap widens enough to feel genuinely uncomfortable.

That discomfort is normal. It’s also where many leaders get stuck.

Early in my management career, I felt that pressure acutely. I had spent years as a C++ application developer. That expertise was my credibility. When I found myself responsible for iOS clients, Ruby backends, and systems I didn’t know well, I worried that I was no longer qualified to make decisions or lead effectively.

My instinct was to compensate by trying to learn everything. I wanted to stay technically credible in every domain I owned.

That instinct turned out to be the wrong one.

The trap of technical credibility

As leaders, we often confuse credibility with expertise. We assume that to lead an area, we need to be the smartest person in the room about it. That might work when you’re leading a single team in a domain you know well. It breaks down quickly as your scope expands.

If you try to become an expert in every system your organization owns, you slow everything down. Worse, you undermine the people you hired to be experts. You become a bottleneck without realizing it.

The opposite mistake is just as damaging. Some leaders disengage entirely from unfamiliar domains. “I don’t know that area, so I’ll just trust the team and focus on what I know.” That signals disinterest, even if you don’t intend it to. Teams notice. Motivation drops. Accountability weakens. And you’re still responsible when things go wrong.

Neither extreme works.

The real challenge isn’t a lack of knowledge. It’s understanding how your role changes as your scope grows.

How leadership actually shifts

There’s a progression most leaders have to make, whether they realize it or not:

You start by doing the work.
Then you review the work.
Then you design how the work gets done.
Eventually, you design the system that produces good decisions.

When you’re leading areas you’ve never worked in, your role moves firmly into those last two stages. You are no longer there to solve problems directly. You’re there to make sure the right problems are being solved, in the right way, by the right people.

That shift is uncomfortable if your identity is still tied to being a strong individual contributor. But it’s unavoidable if you want to lead at scale.

Failures at senior levels rarely stem from a lack of subject-matter expertise. They come from unclear ownership, misaligned incentives, poor decision-making systems, and leaders who stop being curious about the parts of the organization they don’t personally understand.

What to focus on instead

You don’t need deep expertise in every domain you own. You do need a solid mental model.

That means understanding the vocabulary, incentives, constraints, and common failure modes. It means being able to follow the conversation, ask good questions, and recognize when something doesn’t quite add up.

The questions that matter at scale are remarkably consistent, regardless of domain:

  • What does “good” look like here, and who decides?
  • What happens if this fails?
  • What risks are we knowingly accepting?
  • Are we relying on heroics?
  • How do problems surface early?

Those questions don’t require you to know the implementation details. They require judgment, context, and experience. That’s the transferable part of your background.

Your job is to let specialists own the “how,” while you own the “why” and the “so what.” When you provide clear context and intent, good teams make better decisions on their own.

Things you have to stop doing

Leading unfamiliar domains also requires unlearning some habits.

You have to stop pretending to be the smartest person in the room. Your job is to hire people who are better than you at their craft and give them room to do it well.

You have to stop asking detailed technical questions just to mask uncertainty. People can tell when you’re doing it, and it erodes trust rather than building it.

You have to stop measuring success only through artifacts and dashboards. As you move up, outcomes matter more than outputs. Metrics are signals, not substitutes for understanding.

Trust without abdication

Trusting domain experts doesn’t mean stepping away. It means staying engaged without micromanaging.

You are still accountable. You still ask questions. You still challenge assumptions. But you don’t make decisions for teams in areas where they clearly know more than you do.

You also have to create space for people to disagree with you. Role power makes that harder than most leaders realize. When you suggest something, people often hear a decision. If you don’t actively invite dissent, you lose valuable signal.

That matters even more when you’re not the expert.

The long view

Over time, leading unfamiliar domains gets easier. Not because you become an expert in everything, but because you get better at learning just enough, asking better questions, and building trust with the people who know the details.

Progression doesn’t mean abandoning your technical background. It means extracting the lessons from it and applying them at a different level.

If you’re feeling exposed because you’re leading something you’ve never done before, that’s not a sign you’re failing. It’s usually a sign that your role has changed faster than your self-image has caught up.

That gap is uncomfortable. It’s also where real leadership growth tends to happen.

To hear an extended discussion of this topic, please listen to my podcast episode: Leading What You’ve Never Done Before.

Originally published in the It Depends: Lessons in Technology Leadership newsletter at https://kevingoldsmith.substack.com/p/leading-what-youve-never-done-before