You wrote a 6-page Design Doc.
You architected a migration that will pay off 10 years of technical debt.
You present it to the team in the All-Hands meeting.
And then... nothing happens.
There is an uncomfortable silence. A Staff Engineer asks, “What about the legacy auth support?” The Product Lead asks, “Do we really have time for this during Q4?” The Manager says, “Let’s put a pin in this and circle back next quarter.”
Your brilliant idea dies in the conference room.
Why? Because you treated a political problem like a technical problem.
You assumed that if the Logic was sound, the Decision would follow. But in an organization, logic only validates the solution. Consensus ships it.
If you want to drive technical change, you cannot just be a Great Architect. You have to be a Coalition Builder.
The “Grand Rewrite” Trap
Early in my career, I watched a Principal Engineer try to move a monolithic Java app to Go. His technical argument was flawless. He had charts showing memory reduction, concurrency improvements, and faster build times. He spent two weeks writing a 20-page RFC.
He presented it to the VP of Engineering.
The VP asked one question: “Does this help us launch the Enterprise Tier by March?”
The Engineer said, “No, but it ensures we can scale in Q3.”
The VP killed the project immediately.
The Engineer was right about the technology. But he was politically naive. He hadn’t built a coalition with the Product leaders to understand their pressures before he pitched his solution.
The Alternative History
If he had spent one week talking to the Product Lead before writing the RFC, he would have discovered the pressure to launch the Enterprise Tier.
He could have framed his pitch differently: “I know we need to launch in March. If we carve out just the User Service to Go now, it will prevent the Enterprise Tier from crashing on Day 1. We can migrate the rest in Q3.”
That pitch would have been approved.
The “1,000 Coffees” of React
Contrast that with how React took over Facebook.
In 2011, when Jordan Walke introduced the prototype (FaxJS), he didn’t get a standing ovation. He got pushback.
Senior Engineers hated the idea of putting HTML inside JavaScript (JSX). It wasn’t just “fear of change.” It was a legitimate technical objection regarding the Separation of Concerns.
If the React team had tried to force a top-down rewrite of the News Feed, they would have failed. The “No” votes from the Staff Engineers would have buried them.
So they didn’t ask for a rewrite. They built a Coalition.
They found one team that was struggling with performance (Instagram). They helped them fix one specific problem using React. It worked.
Then they found the Ads team. They solved one complex form state issue.
They went desk by desk and solved individual pains for individual influencers.
By the time React was proposed as the standard for the main app, the “Separation of Concerns” debate didn’t matter anymore. The evidence was overwhelming, and more importantly, the voters were already convinced.
Nemawashi: The Art of the Pre-Meeting
What the React team instinctively understood is a concept Japanese business leaders have formalized as Nemawashi.
It literally means “digging around the roots.” In gardening you prepare the soil before you transplant a tree so it doesn’t go into shock. In business it means you never present a big idea in a meeting unless you have already won the votes.
The All-Hands meeting is not for Deciding. It is for Ratifying.
If you are hearing serious objections for the first time in the big meeting you have already failed.
The Hierarchy of “No”
Building a coalition isn’t just about getting your peers to like you. It is about navigating Power Dynamics. You need to identify who actually holds the Veto and tailor your conversation to them.
They are the technical authority. They can’t fire you but they can poison the team’s opinion.
- The Pitch: “I’m looking at this migration but I’m worried about how it impacts the legacy cache. You know that system better than anyone. How would you handle it?”
- The Follow-Up: If they say “It’s too complex,” you respond: “That is exactly the kind of concern I need to understand. Walk me through your worst-case scenario so I can protect against it.”
2. The “Resource Veto” (The Manager)
They agree with the idea but “can’t afford the time.”
- The Pitch: “If we don’t fix this tech debt the Q3 roadmap is at risk because build times will hit 45 minutes. This project buys us insurance for the launch.”
- The Follow-Up: If they say “We still can’t afford the time,” you respond: “What if we broke it into three phases and only did Phase 1 before the launch?”
3. The “Strategic Veto” (The VP/CTO)
They care about P&L and strategic alignment.
- The Strategy: Never pitch technology. Pitch enablement.
- The Pitch: “This migration isn’t just an infrastructure change. It directly enables the ‘Global Latency’ OKR you announced last month.”
- The Trap: If your project doesn’t align with their OKRs, do not pitch it. A “No” from a VP is often permanent because you have just signaled that you don’t understand the company’s priorities. They will remember that the next time your name appears in their inbox.
AI as a Red Team
We used to have to guess where the landmines were. Now we can simulate them.
Before I talk to a skeptic, I use AI to “Red Team” my proposal.
The Prompt:
“Act as a cynical Principal Engineer who believes in ‘If it ain’t broke, don’t fix it.’ I am proposing we switch from REST to GraphQL. Tear my argument apart. Focus on caching complexity and N+1 query risks.”
This isn’t about generating text. It’s about generating a strategy. It forces you to prep for the hard questions so you don’t freeze up in the real conversation.
When to Walk Away
Sometimes you do the Nemawashi, you build the coalition, and the answer is still “No.”
Maybe the business is running out of cash. Maybe there is a secret acquisition in the works. Maybe the “Cost of Consensus” (months of meetings) is higher than the value of the migration itself.
A Senior Engineer knows the difference between “I failed to persuade” and “The timing is wrong.”
If you have aligned the Logic and the Consensus and it still doesn’t ship don’t burn bridges. Document the trade-offs, commit to the current path, and wait. The constraint will change eventually.
Your Homework
Think about the next big proposal you want to make. Do not schedule the meeting.
Identify the one person who is most likely to block it (The Skeptic).
Schedule a 15-minute coffee chat.
Do not pitch your solution. Use this script:
“I’m exploring a few ways to solve [Problem X] and I know you have a lot of context on the risks here. Before I write anything up I wanted to get your take on what I should avoid. What are the landmines I’m not seeing?”
Listen. Take notes.
If you can solve their specific fear in your document, you have just turned a Veto into a Vote.
The irony is brutal. The code might take two weeks to write but the coalition might take two months to build. It feels like “overhead.”
But here is the truth I have learned after almost a decade in the trenches: The perfect solution that never ships is just a Notion doc. The 80% solution that everyone agrees to becomes the foundation for the next decade.
Write great code. But spend even more time making sure someone actually merges it.