Bringing People Along

When you want to change something that involves other people, you have choices about how to go about it. As an IC, you can push ahead on your own and hope others adapt. As a leader, you can announce a decision and move on. Both can work in the short term. Over time, though, they burn trust, and once trust drops, everything gets harder. Process changes, architectural proposals, team restructures, ownership shifts. None of these will truly succeed without the people around you.

That dynamic shows up everywhere. Nobody builds anything meaningful in isolation. Even the "self-made" story depends on a system of people and infrastructure that already exists and keeps running. Software teams are no different.

There is a slower path, and it's stronger over time: bring people along. Float the idea before it's fully formed. Have the one-on-ones. Listen to what comes back and be willing to rework parts of the plan based on what you hear. Sometimes that feedback tells you to go back to the drawing board, or to stop altogether. I'd rather learn that early. Once an initiative rolls out with obvious gaps, people lose confidence in the whole thing, and it's hard to get that back.

But when the idea does move forward, it moves forward stronger. People who helped shape it become invested in making it succeed, and that investment is what turns skeptics into champions of the idea.

I've seen this pattern play out in process changes, architecture shifts, and org redesigns. One recurring example is moving service ownership between teams. Even when I trust the team and know they're capable of taking it on, it's usually a hard sell. They already have a full plate, and now they are inheriting code they did not write, plus bugs, pager load, and operational risk. Trusting them to handle it and telling them to handle it are very different things.

The telling version is familiar. An EM is told Team A will take over a service from Team B, then relays the decision to the team. People grumble, but it "works" because it is only one service this time.

The trusting version takes more effort. The EM and a senior engineer are brought in early because Team B needs to focus on a new 0-1 initiative. Team A is asked what a successful transition would require. They ask for a runbook, architecture docs, walkthroughs, and shared pager duty for a month. Now Team A has context, leverage, and some ownership of the transition plan.

The telling version is faster in the moment. The trusting version is healthier for the organization and usually better for the service. Repeat each approach three times over a year and the difference compounds.

The same dynamic plays out when proposing an architectural pattern or a new workflow. If people had a hand in shaping it, they defend it when things get hard. If it was handed to them, they're stuck with it, and that could breed resentment. People go along with it, but they lose the motivation to iterate on it and make it work long term, even if there are minor issues.

The hard part is letting go of exactly how the idea gets implemented. Sometimes there isn't time for a full socialization cycle. In those moments you're spending trust, and that's fine as long as it's deliberate. The problem is when it becomes the default and people stop noticing they're drawing down an account that takes a long time to refill.

In my experience, learning to let go tends to come with time. I've watched talented engineers grow over years and hit a point where their perspective moves from "how do I succeed" to "how do we succeed." When that happens, the teams around them get better, the work gets better, and their careers tend to follow. In healthy organizations, that shift is one of the most important inflection points in someone's trajectory. Once you're there, collaboration stops feeling like delay and starts feeling like durability.

I've written before about minimizing whiplash during change, which is about the pacing side of this. Buy-in is the adjacent problem. Whether people genuinely own the change once it lands.

I have become increasingly opinionated about this over time. Build trust in every direction. It doesn't require giving up authorship or ambition. It just means the work gets better when more people are invested in it. You may move slower at first, but if people see their input shaping the outcome and steady progress following, momentum tends to accelerate.