Tag: managing up

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.

Talking to Executives: That’s Not a Derailment, That’s the Meeting

Why being understood matters more than being right

Seattle, USA – Photo by Kevin Goldsmith – February 2026

When I was starting out at Microsoft, I nearly derailed my first executive presentation over the word “avatar.”

We were building virtual world software, and I used “avatar” the way the industry did. The VP stopped me, insisting it wasn’t the right term based on its dictionary definition. I pushed back, stating it was accepted industry usage, and asked to move forward. He agreed, but became distant for the rest of the presentation.

Afterward, my boss’s boss pulled me aside. “If the VP wants to talk about a word, that’s what you talk about.” I was never invited to present to that VP again.

I was two years out of university. It was a painful lesson.

I’ve made a lot of mistakes in executive communication over the years, and I’ve been on both sides of that table long enough to understand why they happen. Before I was someone people presented to, I was terrified of the same thing. When I started at Adobe, my director was in San Jose while I was in Seattle. I’d see him present to the broader organization occasionally, but the first time he called me directly, I nearly froze. He just had a question about something, but I picked up the phone, heard his voice, and thought: “I’m talking to the director.” It felt enormous and scary.

I also know what it feels like to be on the receiving end of that anxiety. A few years later at Adobe, I was now a Director. A team that joined my organization set up a meeting to introduce themselves when I visited their office. I came to the conference room expecting to sit around the table and talk. Instead, I walked in to find a polished deck waiting for me, the whole team lined up, ready to present. It was the first time anyone had ever built a slide deck just for me. I felt guilty, honestly, because it was obvious they’d spent serious time on it, and I had just breezed in thinking we’d hang out. I understood immediately why they’d done it. But I also wanted to tell them: I’m just Kevin. You don’t have to do this.

The key: Executives are just people with different responsibilities. The anxiety you feel walking into that room is completely understandable, and mostly unnecessary.

What I learned the hard way from that Microsoft VP is that when you speak to executives, every word carries weight. The core tension is that you are closer to the work than they are. You’re the expert in your domain. But that doesn’t make you the expert in the room. You’re there because the thing you’re working on matters to them, not necessarily in the way it matters to you. Executives have the broader business context. You have the deeper technical context. They’re optimizing for risk, clarity, and decision making, not technical elegance.

Executives aren’t there to hear your whole presentation. They’re there to get something specific, and that something is usually part of a much larger set of conversations they’re having. If you give them a complete tour of your work and none of it is what they came for, they’ll interrupt you. Or they’ll check email. Or they’ll leave. Not out of disrespect, but because they have other things to do, and this meeting didn’t give them what they needed.

A framework: the four C’s

Before any executive communication, whether it’s a meeting, an email, or a Slack message, run through four questions.

Clarity. Are you using language that cannot be misinterpreted? Not your team’s language, not industry jargon. Plain language. Define terms the moment you use them, or don’t use them at all.

Context. Have you situated your topic inside the broader business picture, as best you understand it? You won’t have all their context. That’s fine. Show that you’re thinking past the narrow scope of your project. The executive you’re talking to is probably thinking about two other projects and how yours intersects with them. Meet them there as best as you can.

Consequence. Have you made it clear what happens if a decision is made or not made? Don’t assume the stakes are obvious. Say something like: “If we get the help we need, I’d put our odds of delivering on time at 70%. Without it, 30%.” That gives them something to act on. They’re not going to intuit the downstream implications of your team’s situation. You have to surface them.

Control. Are you demonstrating command of your subject, including its risks and trade-offs? Executives have usually been where you are. They can tell when someone is leaving something out, whether intentionally or because they haven’t thought it through. Either reading is bad for you.

If you skip answering one of these four questions, they’ll go hunting for the answer. That’s when the interruptions start and when you lose control of the room.

Calibrating your technical level

One common challenge in executive settings is explaining topics at the right level of technical detail for your audience. This challenge is called technical calibration: making sure your explanations match what your audience understands and needs, not just what is technically accurate.

Overexplaining occurs when you dive deeply into technical details with an audience that lacks the same technical background or expertise. For example, if you are a developer or a frontline engineering manager presenting to a mixed-background group, most will not be technical. If you go straight to implementation specifics without first gauging your audience’s familiarity, you risk losing them. I have seen this happen when I wanted to give team members exposure to the executive team. Despite my advice to focus on the business context, they presented too much technical detail. As a result, my peers disengaged—not out of disrespect, but because the level of information wasn’t appropriate for them. It can be tough to watch, especially knowing how much effort goes into preparing.

Under-explaining happens when you assume the audience shares your technical context and use unexplained terms or reference internal systems without clarification. Under-explaining can make your message opaque to executives, even if they don’t say so. Executives may not interrupt to ask, but will quietly disengage if they can’t follow the discussion. Clear technical calibration helps prevent this by defining terms and providing just enough context.

To technically calibrate, start by identifying your audience’s background and what matters to them. Focus your explanation on three areas: business impact, customer impact, and risk. These areas matter most to executives. Lead with what changes, who is affected, and what costs or risks are involved. Offer more technical details if requested, but always start with a clear context relevant to your audience’s familiarity.

Here’s something worth understanding about the translation problem. As a CTO, my job is to make complex technical realities legible to people who don’t live in technology. My peers on the executive team understand the broad strokes of engineering, but they’re not going to track a detailed architectural discussion, nor should they. I continuously hear fairly complicated things from people on my team, figure out what’s actually important in a business context, and translate them for my peers. That skill didn’t come naturally. I developed it by presenting to executives over the years and paying attention to what landed and what didn’t.

If you’re looking to move into senior technical leadership, this is not optional. The ability to translate your domain for non-technical peers is one of the most critical skills you can develop. In the first years of my career, I thought being technically correct was sufficient. What I eventually learned is that clarity and alignment matter more than precision. You can be right about everything and still fail to move anything if the people you’re talking to can’t follow you.

How to handle the room

A few more things worth knowing.

Lead with the conclusion. In written communication, especially, I see people bury the point. They walk me through everything that happened before telling me why they’re writing. Put the conclusion first. We have this problem. Here’s what I need. The background can follow, if I need it.

Plan to use half your time. If you’re given an hour, prepare for thirty minutes. You will get interrupted. Questions will go deep. Tangents will happen. If you’re done in half an hour and could have taken an hour, that’s a great outcome. It means you were clear and direct, leaving room for the conversation to go where it needed to. The executives you are presenting to will appreciate your brevity if it gives them time back in their day.

Say “I don’t know” when you don’t know. This is harder than it sounds. You’re in front of people who matter, and someone asks a question you can’t answer. The instinct is to approximate, to say it’s going pretty well, to give them something. Resist that. If you guess and you’re wrong, the next time they hear about your project from someone with the real information, they’ll wonder whether you were confused or covering something up. It’s more important for you to protect your credibility than your ego. If you don’t have an answer, commit to providing one as soon as possible after the meeting.

Treat interruptions as signals. If someone goes deep on something you considered minor, or starts a side conversation with the person next to them, that’s not a sign things are going badly. Something you said connected to a concern you’re not aware of. Stay with it. Follow it. Don’t try to reroute back to your slides. I’ve made this mistake. The executives started talking among themselves because something I’d said triggered a prior discussion. At a certain point, I was just standing at the front of the room waiting. I tried to bring them back because I was worried about running out of time. They didn’t have it. We ran out of time anyway. The deck got a “just send it over, sorry we ran out of time.” That is a common outcome from one of these meetings. Remember: your job in the room isn’t to get through your material at all costs—it’s to meet executives where they are and help them move things forward. If you do that, you’ve succeeded, even if the meeting doesn’t go as planned.

Executive brevity isn’t disinterest. Senior leaders in large companies can spend eight hours in meetings a day. They get direct because directness is how you survive that schedule. If they’re short with you, it probably just means they’re operating efficiently. Don’t confuse it with dismissal.

The view from the other side

Now that I’m regularly on the other side of these conversations, I recognize pretty quickly when someone is protecting their ego instead of informing me. When they get defensive about a challenge, when they oversell, when they’re more focused on how they look than on what I actually need to understand. And I recognize the opposite, too. When someone says, “I don’t know, but I’ll find out,” I trust them more, not less. When someone slows down and clarifies rather than powering through, I appreciate it.

What executives want from anyone presenting to them is to help them understand something so they can make a good decision. That’s it. You are not there to demonstrate your expertise. They already assume you have it. That’s why you’re in the room. You’re there to enable good decisions for the people you’re talking to.

Every word should either reduce ambiguity, increase alignment, or surface risk. Remember, every executive conversation is a chance to build trust and influence outcomes. Treat each as an opportunity to connect, learn, and shape direction.

Ask yourself one question before every executive interaction: Am I optimizing to be right, or am I optimizing to be understood?

The answer should always be the latter.

To hear an extended discussion of this topic, please listen to my recent podcast episode: Talking to Executives: That’s Not a Derailment, That’s the Meeting.

Originally published in my newsletter