Tag: engineering management

Managing Sideways

Everyone Nodded, Then Nothing Happened

Vancouver, Canada – Photo by Kevin Goldsmith – June, 2026

Driving change across teams you don’t control.

You have been in this meeting. A group of managers gets together to fix something that is clearly broken, someone proposes a shared way of doing it, and the proposal is good. Everyone agrees. Heads nod around the table. This is obviously the better approach, and the room is unanimous. Then everyone goes back to their desks, and six months later, every team is still working exactly the way it did before.

The idea was sound, and the logic held up. Nothing happened anyway, because agreeing was free and changing was not, and nobody in that room actually had to do the changing.

Most of the work is sideways, not up.

This is one of the most common situations in technology leadership, and one we talk about the least: much of the work is sideways, not up. A lot of advice is about managing up, about getting the people above you to see things your way. Far more of the actual work is getting teams you don’t manage, and can’t tell what to do, to change how they operate. The skill that makes that possible is influence without authority, and it is one of the hardest things a leader learns to do well.

A change you impose lasts as long as the pressure behind it.

When a team won’t move, the instinct is to reach for authority. If you have formal power over them, you use it. If you don’t, you borrow it, usually by appealing to someone more senior who can force the issue. Both of those moves feel like progress, but both tend to backfire.

Start with the borrowing, because it is the more seductive one. Say you get your director or your VP to agree and announce that everyone should adopt your approach. People hear the message and comply. Then that executive moves on to the next fire, the pressure behind the announcement fades, and so does the compliance. The teams that never actually agreed go back to what they were doing the moment they no longer feel watched. Worse, you have taught the organization something about you. You have shown that you win by going over people’s heads, and the next time you try it, they will drag their feet, push back harder, or get to that senior leader first to argue against you before you arrive. Borrowed authority buys shallow agreement that lasts exactly as long as the pressure behind it.

Using your own authority, when you have it, runs into a quieter version of the same problem. I’m a CTO, which means I have real role power over the technology organization. I cannot use it on product, marketing, finance, or operations. For most of what matters across a company, I have to convince people rather than direct them, which is why this skill stays valuable all the way up. Even a CEO, who can in theory force almost anything, creates morale problems and erodes trust by leaning on that power too often. You have probably heard this framed as ‘telling’ versus ‘selling’. You need both, and the judgment to know when to use which. The trouble is that most of us reach for telling first, even when we don’t have the standing to make it stick.

Being right is the cheapest part.

There is a second reason force disappoints, and it is more fundamental. The strength of your idea and other people’s willingness to change how they work are almost entirely unrelated. You can be completely right and completely stuck at the same time. You feel the urgency because the problem is in front of you. The other team has its own list of urgent things, and your idea is not on it. Being right is the cheapest part of this whole exercise. Getting adopted is the part that costs you something.

The most successful version of this I have done was at Spotify, where I led the building of the technology career framework for the engineering organization. Spotify was known for autonomous teams, and that autonomy was real and strongly felt, so a framework imposed from the top would have failed immediately, even though I had the nominal authority to impose it. What worked instead was slower and far more durable.

For others facing similar challenges, here are the key steps in the coalition-building process that made this work:

  • Invite broad participation early. Pull in representatives from across the organization, not just the most senior or obvious choices. The more teams included from the beginning, the more invested they will be.
  • Co-create the solution. Involve these stakeholders in actually building the new approach, rather than simply seeking feedback after the fact. Let them shape the details.
  • Roll out gradually. Share the changes in stages, piloting with a few teams and making adjustments as you go based on real feedback, rather than launching the entire initiative at once.
  • Create space for questions and revisions. Make it clear that input is encouraged and will be seriously considered, not just collected and filed away.
  • Foster ownership. As teams contribute, highlight, and celebrate their input, so they feel responsible for the outcome rather than passive recipients of someone else’s decision.

It took much longer than writing it alone and announcing it would have. It also stuck because, by the time it arrived, people felt some ownership of it rather than having it handed down.

The counterexample came earlier, at Adobe. One of the first things I worked on there was a shared system that every product team was supposed to adopt. Leadership had already made the decision, so I had a mandate on my side. I went team to team, and most came along, but one product leader, someone more senior than me, pushed back hard. Their system worked, they had ship dates, and they were not going to tie their release to an unproven dependency. I didn’t escalate, but that leader knew as well as I did that I could force the issue if it came to that, and that the decision would land in my favor. So, once I reminded them of that fact, they adopted it. I got my compliance. I also made an adversary who stayed vocal about every problem we hit afterward, who came at us at every opportunity, and who, as far as I know, never liked me again (if he did before). The system shipped, and it worked, but I paid for that win for a long time. Compliance you extract that way is rented, not owned, and the lease ends the moment the leverage does.

Adoption without a mandate.

Out of those experiences, I have come to think of cross-team change as a sequence rather than an argument. I call it adoption without a mandate, and it has four moves, in order. That sequence is the thesis, and the order is the part people get wrong.

The first move is to recruit the first mover. Start with the team that already wants what you are offering, not the loudest skeptic. The skeptic feels like the obstacle to clear, so it is tempting to spend your best energy converting them first, but that is the lowest-probability conversion on the board. While you grind on it, the willing teams cool off or solve the problem themselves. Find the team with a problem your change already solves, and start there.

The second move is to frame adoption around the work it removes for the other team, not around your initiative or how much better your way is. Nobody changes how they work to make your life easier. They change it to make their own life easier. This is ordinary salesmanship, the same pattern you see in every vendor email that opens by naming a problem you actually have. Understand what the other team is measured on, and show them how your change helps them hit it rather than adding another item to their list.

The third move is to let the results recruit the next team. Once your first adopter has a real win, make it visible, and let them tell the story. A team hearing from a peer that something worked is far more persuasive than you advocating for your own work. Proof travels further than persuasion, and the second team asking to join is worth more than the second team being told to.

The fourth move is to settle ownership before the thing scales. Decide who maintains the shared work and who arbitrates when two teams want incompatible things, and do so before adoption spreads or the first real conflict turns the whole effort into a tragedy of the commons. The best example of this I saw at Adobe was an application UX library, which was managed as internal open source. Teams across the company contributed to and built against it, with clear ownership of the core, so when two groups needed different things, there was an actual process for resolving it rather than a standoff. That structure scaled in a way that ad hoc adoption never does.

If you want to go deeper on the idea itself, the clearest treatment I know is Influence Without Authority by Allan Cohen and David Bradford, which is built on the premise that you trade in things people actually value, not in being correct. Kotter’s Leading Change is where the coalition idea comes from, and it holds up.

Resistance is usually fear, not logic.

Underneath all four moves is the same fact about people. Resistance that gets framed as a technical objection is usually about something else: autonomy, job security, or a team protecting work it believes defines it. Treating that as a logic problem, when it is really a fear problem, is how good proposals die. The tricky part is that these concerns rarely come up directly. Leaders need practical ways to bring them to the surface so they can be addressed. Sometimes this means holding listening sessions where people are encouraged to share honestly, running anonymous surveys that ask what worries or challenges people see with the change, or just creating space in meetings for people to name what feels at risk. Sincerely inviting these conversations and being willing to sit with the discomfort they surface can reveal what is really standing in the way, and give you a chance to respond more effectively.

You can watch this happening right now as AI moves into engineering organizations. A lot of the resistance is not really about the tools. It is about developers who think of themselves as people who write code, being asked to work in a way that changes what their job is. The change that lands will be the one that respects what people are actually afraid of losing.

Sometimes the mandate is the right call.

None of this means authority is useless. There is a technique John Kotter describes, called the champion skeptic, where you deliberately bring in a respected doubter early, because if you win them over, they will carry others. I use it. I just don’t lead with it. I bring them in once there is some momentum to point to. And sometimes the honest answer is that pull is too slow. If the company needs something standardized by next quarter, that will usually come down as a mandate from leadership, and shallow buy-in may be a price worth paying for speed.

To make the right call between mandate and influence, leaders need to look at a few key criteria: urgency and timeline (how quickly change is needed), risk tolerance (whether mistakes or slower adoption are acceptable), the degree of alignment or resistance among teams, and organizational culture (whether top-down directives are the norm or if buy-in is valued more). If time is short, alignment is low, and the risk of failure is high, a mandate might be justified. On the other hand, if durable change, broader ownership, and morale matter most, influence and coalition-building will pay off over time.

Context decides. Proof recruits better than persuasion, but persuasion is faster than proof, and you pick the one your timeline can afford.

Start where the change is already wanted.

The mistake I made for a long time was believing the better idea would win on its own, and that my job was just to prove it clearly enough. The clearer my proof got, the more unreasonable the holdouts seemed, which made me push harder, which made them dig in deeper. Then I overcorrected and started going straight for the mandate because it was faster, and learned that lesson about rented compliance the hard way. What I do now is start somewhere else entirely. The first question is no longer how I convince them. It is where this change is already wanted, and how I begin there.

So when you can’t order a change, your job is to make the new way the easiest way and let that do the arguing for you. Even when you can order it, you will get a better result this way.

Here is something concrete to try. Take a cross-team change you have been pushing and name the team that would adopt it tomorrow with no convincing at all. Then ask whether you have been spending your time there or on the team that has been fighting you the hardest. If you can’t name a single team that already wants it, that is the real finding, and it is not an adoption problem yet. It means the change does not solve anyone’s actual problem, and that is what needs to be fixed first.

For an extended discussion of this topic, listen to my recent podcast episode: Managing Sideways: Everyone Nodded, Then Nothing Happened.

The Director to CTO Path: How to Follow It, or How to Mentor It

Why the leap from Director to CTO is really three distinct shifts, and how to start making them before you have the title

Montreal, Canada – Photo by Kevin Goldsmith – February 2026

If you want to move from Director to CTO, the real secret is this: you don’t make one giant leap. You make three distinct shifts: to your focus, your horizon, and your sense of what leadership means. This article will break down the three shifts so that you can see the real path ahead.

Before I get into this, I want to be clear. My path to CTO will not be your path. Every CTO I know got there in a different way. Most of us started as developers, then moved into engineering management and worked our way up. But the companies we worked for, the time we spent at each level, the opportunities we had, and the choices we made along the way vary wildly. There is no one true path.

My CTO experience is mainly with mid-sized startups (Series C-D, 150–a few hundred employees, engineering teams of 50–200). I’ve also worked at early-stage (places you’ve never heard of) and large companies (IBM, Microsoft, Adobe, Spotify), and I mentor leaders across company sizes, so I’ll bring those varied perspectives. But if you want to be CTO at a 10,000-person enterprise, someone who’s done that will be a better guide.

That said, the three key shifts I describe: broadening your focus, extending your strategic horizon, and evolving your definition of leadership, are still relevant in larger enterprise environments. The specifics may differ: for example, decision-making is slower, your “company-wide” focus as a technology leader can mean navigating far more complex org structures, and building cross-functional relationships requires even more intention because of the sheer number of stakeholders. You may be more specialized or work through more layers of management, but the same underlying transitions in how you think and lead still apply. Directors at large organizations may need an even greater emphasis on influence, coalition-building, and navigating ambiguity across business units, so as you read, consider how these shifts might scale in your context.

I’ll outline the key transitions on this path and what changes at each level. You need to broaden your focus from team to company and industry, extend your horizon from near-term delivery to long-term strategy, and adjust your definition of leadership as your scope grows. I’ll detail each shift so you’re ready for each step up.

What the roles actually look like

One important note before I describe these levels: I’m talking about a director of engineering, not a director of security, IT, data, or another domain. You can hold a director title in technology and manage a small team if you own a domain important to the company. In engineering at mid-sized or larger companies, a director usually manages managers and possibly a couple of very senior engineers.

A director of engineering is fundamentally execution-oriented. Your focus is your organization: are your teams delivering, what’s getting in the way, and how are your engineering managers doing? You were likely a line manager not long ago, and before that, perhaps a developer. Thus, your technical background remains focused, as your teams cover adjacent disciplines (e.g., Backend and Frontend). You’re thinking strategically, but mainly in the near term. Typically, your time horizon is six months to a year, since you are building on your manager’s strategy.

That’s not a criticism. The execution layer is essential. As a Director, you’re closer to the work than your manager. Organizations fall apart without people who are genuinely focused on delivery. But it does describe the ceiling of the role.

At the VP of engineering level, the shift is from looking down to looking around the company. You join the extended senior leadership team and work with cross-functional peers across the business. You now have visibility into the company’s longer-term direction. You’re expected to think at the system level, not just the team level. Your directors handle execution. Your job is to see how the pieces fit together and where they don’t. You have a wider technical scope because you are responsible for more disciplines. You’re thinking operationally, one to three years out.

Ask yourself: When was the last time you mapped dependencies across functions or business units? How often do you step back and assess how different teams’ plans might intersect or compete? Bringing this kind of diagnostic reflection into your routine helps you build the habits and perspective needed at the VP level.

The VP role also varies significantly depending on the company’s structure. In some organizations, a VPE reports to the CEO and effectively runs engineering day-to-day alongside a CTO co-founder who isn’t a management leader. In others, multiple VPs report to a CTO. The title means different things in different places, which is worth keeping in mind.

At the CTO level, your focus widens again, this time beyond the company. You think about how the company is executing and what technology can enable. You also watch the industry and your competitors, and track emerging trends that may matter in three to five years. You’re now a senior leadership team member. You contribute to the company strategy, not just align with it.

This outward focus is not just about scanning the horizon for interesting trends, but critically assessing risk and opportunity. For example, the emergence of generative AI has quickly expanded what is possible in product differentiation and introduced new security and ethical risks. Suddenly, companies face both the chance to leap ahead with innovative features and the risk of being disrupted by startups that build faster on these new technologies. Similarly, cybersecurity threats are evolving so rapidly today that your company’s market reputation and even core operations can be at stake if you are not looking ahead and shaping proactive responses. The CTO sees these shifts early and helps the company decide where to lean in, when to move cautiously, or when to double down.

When I moved into this level, I became responsible for areas I had never worked in directly: security, infrastructure, IT, data science, analytics, and internal finance and marketing systems. I had to learn enough about each area to lead well and make sure they had what they needed, even if I couldn’t do the work myself.

Across all three levels, your focus grows wider. You move from execution to operations, then strategy. Your technical scope grows broader, and your time horizon shifts from months to years.

How do you actually make the transition?

Here’s the thing about all of these transitions: you generally don’t get promoted to demonstrate them. You get promoted because you’ve already been demonstrating them. The title follows the behavior.

So, how do you start doing the next job before you have it?

Broadening your focus

If you’re an engineering manager or a director, your focus is naturally on your team. That’s appropriate. But if you want to move up, you need to start showing that you think beyond it.

Start by understanding how the people you work with daily actually do their jobs. How does product management decide what to include in the roadmap? How does UX approach a design problem? What does the QA team care about that your developers downplay? These are not just networking conversations. They give you real context for your decisions.

To put curiosity into action, turn this into a regular exercise. Set yourself a simple goal: once every week or two, schedule a lunch or coffee with someone outside of engineering: product, UX, QA, finance, or marketing; and ask them about their work and how it connects to the company’s goals. Treat it like an intentional challenge. Committing to scheduled conversations will build your understanding over time and help you develop a real cross-functional perspective, not just theoretical knowledge.

Then expand further. Take someone from finance to lunch and ask what accounts payable does and why it matters to the business. Ask a marketing person how they think about the customer. These conversations may seem unnecessary when you’re deep in delivery. But they help you build a picture of how the company works. That picture is what you need to help shape how it should work.

If there are cross-functional working groups or improvement efforts, volunteer for them. These tasks might feel like distractions, but they do two useful things. First, they give you exposure to people and processes you wouldn’t normally see. Second, they signal to your manager that you’re thinking beyond your own team. That signal matters.

The same goes for industry knowledge. Follow the trade press, podcasts, and industry blogs. It does not take long. If you want to join conversations about where the company fits in its market, you have to know what’s going on there. You need opinions you can back up.

Widening your orientation

Understanding your organization’s strategy is different from simply being aware of it. Most people hear the company’s goals at a town hall and think, “Okay, I understand the strategy.” That’s a start. But it’s not enough. Pause for a moment and ask yourself: how does my team’s work connect to that strategy? Does it connect cleanly? If not, how could it?

At Adobe, I led a team focused on heterogeneous computing, writing software to schedule signal-processing work across GPUs and CPUs. Our goal was to run as fast as possible on whatever hardware was available. This was deep, specialized work, very close to the metal. Then Adobe started moving to the cloud. Suddenly, that work was heading in a different direction from the company.

The easy move would have been to dig in. Cloud latency was terrible for our use case. Local hardware was better. I could have made that case. But instead, I asked: Could we treat the cloud as just another compute target? The latency was longer than the GPU bandwidth, but we controlled the cloud hardware. Maybe our scheduling system could be extended to handle it.

We started building a strategy around that alignment. People noticed. And I think one reason people started thinking of me as director-level was that I was actively considering the company’s direction, not just my team’s work.

You don’t need a perfectly polished strategy proposal every time. If you have an idea, bring it to your manager. If it’s not quite right, the conversation still helps. You learn why it doesn’t fit, which helps you develop better ideas. Having ideas and sharing them shows you’re thinking at that level.

Another part of broadening your orientation is understanding the system around you, not just the teams you manage. How does your team depend on other teams? What are the dependencies the other way? If you see two teams making heavy demands on a shared service team at the same time you need something, you can plan ahead. That kind of awareness: knowing constraints and relations between teams and using it to plan, is operational thinking. It’s VP-level thinking, even if you do it as a director.

Thinking longer term

Strategy is a skill, and like most skills, you get better at it by practicing it, not by reading about it.

Adobe had a training program for people on the cusp of the director level, and I was invited to join it. The whole program was focused on strategy because the leadership team understood that the gap between line managers and managers of managers is fundamentally about strategic thinking. Not technical skills, not management skills. Strategy.

If you want to develop that, start paying attention to what’s happening in your industry beyond your company. Not just as general awareness, but with opinions attached. Right now, everyone is having conversations about AI. What do you actually think about it? What are the constraints? What are the realistic applications for your company in the next six months? In the next two years? You don’t need to have it figured out. But if you can have a substantive, informed conversation with your manager about where you think things are headed and why, that demonstrates extended strategic thinking.

To put this into practice, try this assignment: This week, write a 200-word point of view on how AI might impact your product or your company. Consider the opportunities, risks, and whether you think it’s important for your team to start experimenting or learning now. Treat it as a draft and share your perspective with a peer or your manager to start a real conversation. The point is not to have the perfect answer, but to actively build the habit of strategic thinking by applying it to real, current topics. Over time, these bite-sized exercises will help expand your strategic thinking.

Broadening your technical knowledge

Your technical breadth expands naturally as you become responsible for more disciplines, whether you like it or not. The question is whether you engage with that expansion or manage it from a distance.

I’ve talked in previous articles about why you should lean into learning the technologies you become responsible for. You don’t have to become an expert. The goal is to understand them well enough to have a real conversation with the people who do them every day, to ask questions that aren’t too far off base, and to make them feel heard and understood. That trust matters a lot when you’re leading teams you didn’t come from.

One practical way to accelerate this process is to look for your own knowledge gaps actively. Start by asking yourself some basic self-reflection questions: Which technical areas do I find myself avoiding in meetings? Where do I rely most on others to summarize or interpret? Do I feel less confident discussing certain projects or systems in my team’s portfolio? Listing out these areas can help pinpoint blind spots that deserve attention.

You can also ask trusted peers or team leads for feedback: “Are there technical domains where you think my understanding is weaker?” or “What topics do you wish I engaged with more directly?” This can bring new perspectives to your self-assessment and highlight areas that may not be obvious to you. Knowing exactly where your knowledge is thin lets you focus your learning more efficiently and show your team you are committed to truly understanding their world.

A few other ways to do this: talk to peers who are responsible for disciplines you aren’t. Ask what it’s like to manage a data engineering team. What does that work look like? What are the common failure modes? If it’s possible to sit in on a planning meeting for a team outside your area, ask. Just say you’re interested and want to learn. They might say no, and that’s fine, but if they say yes, you learn something real.

Side projects are another way I’ve learned new things over the years. I’m not trying to become an expert. I’m trying to gain enough hands-on experience so I can follow a conversation with an expert, understand what they’re saying, and ask follow-up questions that make sense. That’s a reasonable bar, and it’s usually achievable with a few weekends of tinkering.

If you’re the mentor

Everything I’ve described above is also a set of things you can actively create for the people who work for you, if you’re a VP or CTO.

Start by identifying potential. The signals are usually pretty visible once you know what to look for. People who are curious about things beyond their immediate responsibilities. The people who are already thinking about how their work connects to the company’s direction. The people who volunteer for things, ask questions in cross-functional meetings, or come to you with ideas that go beyond their job description. Those are the people who are already thinking in the ways that lead to more senior leadership.

One practical way to make this potential-spotting more deliberate is to set aside 30 minutes each month for a quick review of your team. Ask yourself: who has shown these signals recently? Who has stepped up or shown interest in broader company goals? By making this a recurring part of your calendar, you turn talent recognition from an ad hoc practice into an ongoing development discipline. Over time, this habit will help you turn signals into real growth opportunities for the people ready to take the next step.

Once you’ve identified these folks in your team, delegate real work to them. Not just tasks, but ownership of things that require the kind of thinking you want them to develop.

The best example from my own career happened at Spotify. I was a VP reporting to the CTO when we decided the company needed an engineering career ladder. We’d never had one. The CTO delegated that project to me and supported me through it. I had to work across the entire technology organization, design something that would work for hundreds of engineers in very different specializations, get buy-in from leaders I’d never met, and partner heavily with HR, not just my HR business partner, but the CHRO, the compensation team, and the HRIS team. It was genuinely hard. And I learned more from it than from most of the work that was actually in my job description.

Did he delegate it because he wanted to develop me? Maybe. Did he delegate it because he didn’t want to deal with it himself? Also possible. Honestly, either way, it worked. I’ve built engineering career ladders at every company I’ve been at since then, and I delegate it every time.

The point is that there are many things you do as a leader that require exactly the kind of thinking you want to develop in your direct reports. Handing them ownership of those things, with your support, is one of the most effective ways to grow them.

Beyond delegation, explain your thinking. In your staff meetings, don’t just announce decisions; explain them. This matters for a few reasons. First, it helps people understand and support what you’re doing. But more importantly, it gives them the reasoning, not just the conclusion. A decision you announce in five minutes might represent thirty hours of meetings, months of context, and a dozen competing considerations. When you announce it, people get the output. When you explain it, they get the thinking. That’s what lets them make good decisions on their own when a similar problem comes up, instead of just pattern-matching on what you did. To make this easier, try using a straightforward lead-in like, “Here’s the trade-off I wrestled with…” or, “The key constraint I was weighing was…” This kind of sentence opener helps you quickly bring others into your thought process and gives your team a template for sharing their own reasoning when they make decisions.

Beyond explanation, be as transparent as you can. As you move into senior leadership, you accumulate a lot of information you can’t share. That creates a gravitational pull toward sharing less by default, because it’s easier to say nothing than to figure out what to share. I try to resist that. I stay careful about what I actually can’t share, and then I share everything else. The people who work for me make better decisions when they have context, and they understand my actions better when they know what I’m thinking. The alternative is that what I do looks random or arbitrary because I’ve withheld the information that would make it make sense.

Create opportunities for people to expand their thinking, separate from delegation. If someone volunteers for cross-functional work, support it. If that kind of work doesn’t exist yet, create it. Organizational improvement efforts, working groups, task forces, whatever form makes sense in your company. Don’t assume HR or someone else will generate these opportunities. You can create them yourself for your organization.

Give feedback that’s calibrated to the next level, not just the current one. If a director does good work, tell them. Then add what a VP would have done differently in that situation. Not as criticism, but as a way to help them see what growth looks like from where they’re standing. Most people don’t have a clear picture of what the next level actually expects of them. You can give them that picture through the feedback you provide over time.

For example, after a successful project delivery, you might say, “Great job keeping the team focused and delivering on time. At the VP level, I’d expect you also to anticipate cross-team dependencies earlier and proactively align timelines across groups to minimize bottlenecks. How would you approach that next time?” Or when they handle an incident well, you could note, “You communicated clearly with your team and resolved the immediate issue. A VP would also consider which system-wide process or coordination could help other teams avoid similar problems in the future. What broader fixes do you see here?” Specific feedback like this helps people step into the mindset of more senior roles before they get there.

Why this matters

When I look back at my career, the projects I’m proudest of aren’t the ones that lasted. The heterogeneous computing work at Adobe was genuinely interesting and technically hard, and it’s completely obsolete now. Technology moved on. You don’t need software to schedule GPU work the way we used to anymore. I’m proud of what that team built, but the work itself is gone.

What hasn’t faded is watching someone who worked for me post on LinkedIn that they’re starting a new role as a CTO or VPE. That lands differently. The idea that I played some part in helping that person get there, that’s a more direct and lasting impact than anything I’ve shipped.

And the thing about developing people is that it compounds. They’ll go on to support the next generation of leaders behind them. The influence extends well past the moment.

So if you’re on this path, that’s what’s on the other side of it. For the people following the path: keep going. It’s a hard job and a genuinely great one. For the people who are further along and mentoring, the most important work you do might not show up in a product release. It might show up years later in someone else’s announcement.

To hear an extended discussion of this topic, please listen to my recent podcast episode: The Director to CTO Path: How to Follow It, or How to Mentor It.

Originally published in my newsletter.

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