Managing Sideways
Everyone Nodded, Then Nothing Happened
A quick note before this one. I’m taking some time off for the rest of the summer, so this is the last new piece for a little while. I’ll keep a few encores running while I’m away, and I plan to be back with new writing toward the end of August.
Before I go, I’d like to hear from you. If something here has stuck with you, or there’s a leadership problem you keep running into and want me to take on when I’m back, send it over. I’m collecting questions for a reader Q&A to run when I return. You can reach me at contact@itdependsbook.net or find me on Bluesky at @kevingoldsmith.com.
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.
To hear an extended discussion of this topic, please listen to my most recent podcast episode: Managing Sideways: Everyone Nodded, Then Nothing Happened.
Thanks again for reading! If you find it helpful, please share it with your friends.
Buy on Amazon | Buy on Bookshop.org | Buy on Audible | Other stores