The Problem
You have the right idea. You pitch it to the wrong person. Nothing happens.
Or worse: the right person hears it at the wrong time, from the wrong direction, and now the idea is dead for six months because it got associated with the wrong context.
Influence is not about what you say. It's about where you inject it into the system.
Two Vectors
TOP-DOWN
Start with the founder, CEO, CTO
Get strategic buy-in first
Mandate flows downward
Fast to decide, slow to land
Works when you need air cover
BOTTOM-UP
Start with the devs, IT pros, practitioners
Build grassroots adoption first
Demand flows upward
Slow to start, hard to stop
Works when you need real usage
Both are valid. Neither works everywhere. Choosing wrong burns time and credibility.
The Routing Table
Who to talk to based on what you're trying to move.
THE FOUNDER / CEO
When the change is existential or strategic
When the org needs permission to think differently
When nobody below will move without a signal from above
Speak in: outcomes, market position, risk, competitive edge. Not features.
THE CTO / VP ENGINEERING
When the change is architectural or platform-level
When you need technical authority behind the decision
When the real blocker is engineering culture, not strategy
Speak in: systems, trade-offs, technical debt, velocity, team capability. They know when you're hand-waving.
THE DEVS / IT PROS
When adoption depends on the people who actually build and run things
When top-down mandates have failed before (and they remember)
When the best proof is working code, not a slide deck
Speak in: concrete problems they have today, how it works, what it replaces, what it costs them to try. Zero abstraction.
THE BUSINESS / PRODUCT TEAMS
When the change affects revenue, customers, or go-to-market
When engineering needs business pull to justify investment
When the real decision-maker is commercial, not technical
Speak in: customer impact, revenue, speed to market, competitive differentiation. They don't care how it works. They care what it does.
When to Go Top-Down
The change requires budget or headcount
Existing teams have no incentive to adopt
The org needs a new narrative, not just a new tool
Political blockers exist at middle management
Speed of decision matters more than depth of adoption
Top-down gets you the decision. It does not get you the behaviour. If nobody on the ground changes what they do on Monday morning, the mandate was noise.
When to Go Bottom-Up
The change is tool-level or workflow-level
Practitioners already feel the pain
You need proof points before the business case
Leadership won't move without evidence
The best marketing is "their team already uses it"
Bottom-up gets you the behaviour. It does not get you the air cover. If leadership decides to go a different direction, grassroots adoption gets overwritten.
The Pincer
The most effective pattern is both simultaneously.
Bottom-up creates demand and proof
Top-down creates permission and budget
They meet in the middle at the decision point
The founder says "we should look at this." The devs say "we're already using it." The CTO says "let's make it official."
That's not luck. That's sequenced influence.
Failure Modes
Top-Down Only
Mandate without adoption. Shelfware. The org complies on paper and ignores in practice.
Bottom-Up Only
Shadow IT. No budget. No integration. Works until someone notices and kills it.
Wrong Audience
Technical pitch to commercial buyer. Business case to practitioners. Right message, wrong system. Dead on arrival.
The Diagnostic
Before you open your mouth, ask:
Who has to say yes? (the real approver, not the meeting organiser)
Who has to change behaviour? (the people on Monday morning)
What language do they think in? (outcomes / systems / code / revenue)
What's already been tried? (scar tissue determines receptivity)
Which direction creates the least resistance? (go with gravity, not against it)
The answers tell you the vector. Top-down, bottom-up, or both. Who first, who second, what language, what sequence.