Stop Asking Your Manager for Permission to Try New Technology

Getting new technology adopted at work is not a permission problem — it's a demonstration problem. Engineers who build the demo, measure the outcome, and let the results do the pitching move faster, build more trust, and get promoted more often.

I've spent 9+ years as an engineering manager — Google, Capital One, startups. In that time, engineers have pitched me new languages, frameworks, build tools, databases, and at least four different state management libraries.

Here's what I've never once said: "Why didn't you ask me first?"

Here's what I've said more times than I can count: "Cool. What problem does it solve?"

Most engineers think getting new technology adopted is a permission problem. It isn't. It's a demonstration problem. And the engineers who understand that difference move faster, build more trust, and — not coincidentally — get promoted more often.

Here's the playbook.

1. Try things without asking anyone

Your manager should not be approving your experiments. Spiking a new tool on a branch, rebuilding a slow script, prototyping with a library your team doesn't use — just do it. That's not going rogue. That's the job.

But know the line between trying and committing:

• Trying = a spike, a prototype, a throwaway proof. Costs only your own time. Needs nobody's blessing.
• Committing = a new dependency your teammates maintain for years. A new language in the build. Something that shows up in on-call. That's a team decision — you're spending other people's future time, not just yours.

Get this wrong in one direction and you never try anything. Get it wrong in the other and you merge a new framework into prod and wonder why everyone's furious.

Try freely. Commit deliberately.

And if your manager genuinely requires sign-off before you're even allowed to experiment? You don't have a technology problem. You have a micromanagement problem — and that's a different blog post.

2. Build the demo before the argument

Eric Schmidt spent six years saying no to building a browser. Google was small, he'd survived the browser wars once, and he had zero appetite for a fight with Microsoft.

Larry Page and Sergey Brin eventually hired a few ex-Firefox developers and built one anyway. When Schmidt saw the prototype, his reaction — his own words — was that "it was so good that it essentially forced me to change my mind."

Six years of argument moved him nowhere. One working demo moved him in an afternoon.

You are not Larry Page, and neither am I. The founders could override their CEO; you can't override your VP. But the mechanics scale down perfectly: demos beat decks. Every single time.

3. Lead with the outcome, not the tool

Here's the pitch I watched fail over and over as a manager:

"We should use X. Better ergonomics, huge community, look at these benchmarks from their website."

And here's the one that works:

"Our integration tests take 40 minutes. I rebuilt the harness on a branch last week — same coverage, 9 minutes. Want to see it?"

Notice the technology isn't even named in the second one. That's not an accident. The outcome is the headline. The tool is a footnote. If the demo lands, people will ask what you used — and now they're pulling the technology toward themselves instead of you pushing it at them.

There's a name worth knowing here: Sundar Pichai. When he championed Chrome internally, he didn't tell executives browsers were interesting. He argued Microsoft could threaten a sizable chunk of Google's revenue. Business risk first, technology second. Seven years later he was running the company.

4. Bring numbers or don't bring it at all

"It's faster" is an opinion. "40 minutes to 9" is a fact.

Before you show anyone anything, measure the pain you're removing:

• Build minutes
• Flaky test rate
• Onboarding days
• Pages per on-call shift
• Files touched per simple change

If you can't quantify what it improves, you're not ready to bring it to anyone yet.

5. Quantify the old thing — never trash it

The clunky system you want to replace? Someone on your team built it, probably under constraints you know nothing about.

• ❌ "This codebase is a mess and we should rewrite it in X" — reads as an attack on your teammates, and recruits opponents before you've started.
• ✅ "Our current setup requires touching 10 files to make one change — here's the measurement" — makes the same case with zero collateral damage.

Numbers criticize nothing. They just sit there being true.

6. Make your tech lead your first audience

Before anything goes wide, show it to your tech lead. Not for permission — for pressure-testing. They know where the bodies are buried: the migration that failed in 2023, the maintenance cost you haven't considered, the reason the "obvious" approach was already rejected once.

Two outcomes, both good:

1. They poke holes in it → you found the weaknesses privately instead of publicly.
2. They're convinced → you now have the most technically credible person on the team behind you. Those proposals are approved before the meeting starts.

7. Save the lunch-and-learn for last

Once something's proven and adopted — that's when you teach it. Demos convince; teaching compounds.

But it comes last, not first. A lunch-and-learn about a tool nobody's committed to is just a sales pitch with sandwiches.

The real problem: nobody defined the boundary

One more thing, from the manager's side of the table.

A manager's job is not to approve technology choices. It's to define the boundary inside which the team chooses freely — what the team owns, what risk it can absorb, and what genuinely needs wider alignment (things that cross team lines, touch compliance, or create long-term platform commitments). Inside that boundary, the team decides. That's what owning a service means.

So if every library needs your manager's blessing, the real problem isn't that they said no to your library. It's that nobody has defined where the team's authority starts and ends — and that ambiguity defaults to "ask permission for everything," which is how teams go slow and engineers go numb.

That conversation — "what are we actually empowered to decide ourselves?" — is worth a 1:1 far more than any single tool pitch. And if you've stopped proposing things entirely because you got shot down once: this is probably why. It was never about your tool.

The playbook in one breath

• Try without asking. Commit with the team.
• Build the demo before the argument.
• Lead with the outcome — the tool is a footnote.
• Bring numbers or don't bring it.
• Quantify the old thing. Never trash it.
• Tech lead first, everyone else second.
• Teach only after it's adopted.

And if the walls keep appearing? Fix the boundary, not the pitch.

---

Nick is a Senior Engineering Manager with 22+ years in engineering and 9+ years managing engineers across Google, Capital One, and multiple startups, including a successful acquisition. He writes about the craft of engineering management at Engineering Manager++.