At the end of The Wizard of Oz, Dorothy and company confront the wizard, and he threatens them with his wrath. When they pull the curtain, the wrath deflates instantly. There's just a man with a microphone.
Many engineering leaders feel like that wizard right now, except it’s AI pulling back the curtain. For decades, there was a clear dividing line between the technical and the non-technical. Business leaders might have made more money and had more sway over company direction, but engineering leaders held technical expertise that business leaders couldn't always parse. That gave them leverage.
AI has changed that. Engineering leaders are in a newly vulnerable position. Business leaders were skeptical of engineering leaders before AI; now they have more reason to doubt. Whether that's fair is beside the point. If you want executive buy-in for technical decisions, you have to meet those doubts directly — not avoid them or wait for them to pass.
The foundation of communicating effectively is knowing your position before you say a word. Think of it like a job negotiation: you wouldn't start talking salary before you knew your number.
Start by recognizing that AI devalued the engineering profession. There's no productive debate on that point right now.
That devaluation doesn't mean engineering isn't valuable. It means technical expertise is less scarce than it was, which weakens the leverage that came from it.
Engineering leaders have long understood that coding was never the real bottleneck for developer productivity or product innovation. But it dominated the conversation anyway. We never communicated alternate ways to think about productivity and value clearly enough, so we shouldn't be surprised that executives are reaching for AI as a speed solution first. With pressure from boards and investors, coding — and coders — can look expendable.
Can AI do everything engineers do? No. But the argument that AI makes everybody an engineer is like saying a scalpel makes everyone a surgeon: the choice of incision matters, and that comes from experience, knowledge, and judgment — not access to a blade.
We have to be willing to move upstream, feel the pressure against us, and keep swimming. The alternative is throwing Copilot licenses at the problem and watching the profession face steeper devaluation.
AI will reshape the relationship between business leaders and engineering leaders. This feels threatening, and it potentially is, but avoidance won't help.
Business leaders are not entirely wrong that AI will replace some human labor. The reality is more nuanced than laying off engineering and deploying agents, but it’s our job to emphasize the nuance, not dismiss the whole idea.
The truth is that most companies over-hired during ZIRP. The contraction now may not be a direct result of AI replacing developers, but the pressure to cut costs and reorganize is real. AI will be a significant part of newly rationalized engineering departments whether we like it or not.
Similarly, business leaders are not entirely wrong that some developers are falling behind. Many developers chose this line of work because it promised a reliable paycheck. Many of them don't think in terms of business value and just push code. Those developers are more replaceable than others.
Accept, too, that the communication gap between engineering and business didn't start with AI. It goes back much further — and it runs both ways.
Marketing, finance, sales, and product have long known how to talk to business leaders in a language they understand. Engineering leaders tend to talk about incident counts, remediation rates, and the complexity of a feature that required an upgrade of something the business leader doesn't understand.
At the same time, many engineering leaders have tried to have business-focused conversations and gotten waylaid. Conversations start with value and devolve into costs. That shift turns engineering from a profit center to be expanded into a cost center to be cut.
The specific gap is speaking in terms of value outcomes: revenue, NPS, market share. With AI in the picture, the absence of that conversation leaves engineering exposed. You don't want your primary value to be a commodity during a period of mass commodification.
Getting executive buy-in for technical decisions requires accepting one core reality: executives don't care about technical details, and they never will.
Skip the specifics and communicate in terms of business outcomes and tradeoffs. Once you've made that shift, these tactics will help you do it effectively.
As an engineering leader, you carry technical history that business leaders don't have. You have muscle memory from past failures. Use it — not as a pros/cons list, but as pattern and precedent.
As Bryan Finster explains, this typically means automating old processes rather than transforming them.
Bryan uses Material Requirements Planning in manufacturing, and Agile and cloud in software to hammer the point home. While some companies used new technologies to rebuild from first principles, most replaced clerks with computers, produced the same reports faster, declared the project a success, and kept doing exactly what they'd been doing at exactly the same cadence.
If you don’t learn history, you’re doomed to repeat it. Your job is to teach them history and make it relevant through an ROI narrative. Be honest: Do you communicate in ROI terms? If you do, do you revisit that calculation once a feature ships? Every time?
Which leads right to the next question: Do you pivot based on your regularly updated ROI learning? I’m not talking about the initial hypothesis that got the project underway. I’m talking about actual, realized value.
Organizations that can honestly say yes to those questions are rare. But it's never too late to start. A clear-eyed look at past efforts and their tangible results is the strongest ROI story you can build. Once you have it, you can fold it into broader technology trends — past and present — to situate your work within cycles executives already recognize.
Business leaders understand constraints. They live with hard choices. You don't need to explain technical details — abstract past them and focus on the problems behind the details.
If your microservices architecture is limiting AI productivity gains, don't explain microservices. Zoom out: explain how architecture shapes ownership boundaries, and why AI can't solve people problems. Show why the situation is complex without listing every detail that makes it so. Then show how one iteration after another leads toward microservices rationalization. The journey is long, but it starts with a single step — and that framing is one executives can follow.
Engineering leaders often react to executive cost-cutting instincts by pushing back with a technical perspective, as though the two views are in opposition. They don't have to be. Technical decisions made in a business context produce better outcomes than either side working alone.
The AI narrative most executives have absorbed is simple: code without coders, replace engineers with agents. As Kent Beck writes, "Labor replacement looks at value creation through a tiny pinhole." He offers four counternarratives:
The labor-replacement story is compelling because it's legible. The goal isn't to convince executives it's foolish — it's to make these other, more compelling stories equally clear.
When Dorothy pulls back the curtain in Oz, the wizard tells them to pay no attention to the man behind it.
I’m asking you to do the opposite. Many engineering leaders feel vulnerable, exposed, and weak, but your true strength was never technical wizardry. Instead, embrace the people problems, pursue systems thinking, and master the communication skills that shift engineering from a position of weakness to a position of strength.
You’re more equipped to do this than you might realize. Engineering leaders are, by nature, problem solvers. Lean into that instinct instead of flinching from business pressure. Engineering leaders are already great at finding ways to address constraints in a system – just zoom out to see that the system here is sociotechnical. Your organization is nested within others — to translate technical reality into business consequence — and learning to move between them is one of the most impactful skills you can learn.
It was never about the coding. Getting buy-in from executives starts with showing them you know that.