I just got off a board call where we presented our platform engineering initiative—18 months in, $2.4M invested, and we’ve hit some genuinely impressive technical milestones. Our internal developer platform reduced deployment times from days to hours, cut infrastructure incidents by 60%, and automated away thousands of manual tickets.
The board’s response? “That’s nice. But what does this mean for our business?”
And honestly? I didn’t have a great answer ready. I talked about developer productivity and reduced friction, but I could see their eyes glazing over. They wanted to know about revenue impact, customer acquisition costs, and competitive positioning—and I was speaking a different language.
This wasn’t a surprise. The research is pretty clear: organizations with strong leadership alignment in platform engineering reduce time-to-market by 70% and improve developer productivity by 40% compared to peers with weaker executive support (source). The distinction between high-performing and underperforming platform teams increasingly comes down to leadership decisions rather than technological capabilities.
But here’s what’s bothering me: we built the right thing technically, but I failed to build the right organizational alignment. Our CEO doesn’t understand what a platform team does. Our CFO sees it as a cost center. Our COO thinks DevOps already handles this. Meanwhile, I’m fighting for headcount to scale a team that’s delivering real value—but only to people who already understand platforms.
The Goldman Sachs Example I Keep Thinking About
Goldman Sachs’ Developer Experience (DX) platform achieved 90% adoption in 24 months because they had a dedicated executive sponsor (their CIO) who explicitly aligned the platform with business goals (source). Without that top-down alignment, platforms risk becoming “shelfware”—technically sound but organizationally unused.
We have 35% adoption after 18 months. We’re not shelfware, but we’re not Goldman either. And the gap isn’t technical—it’s organizational.
The Translation Problem
I keep reading that we need to “translate platform benefits into business outcomes.” Stop saying “we deployed a Kubernetes operator” and start saying “we reduced on-call incidents by 60%” (source).
But even when I do that translation, I’m not sure it lands. Here’s what I mean:
What I said to the board:
- “We reduced deployment time from 3 days to 4 hours”
- “We cut infrastructure incidents by 60%”
- “We automated 1,500 manual tickets annually”
What they heard:
- “Engineers are happier” (nice-to-have)
- “Things break less often” (isn’t that just doing your job?)
- “You automated work that maybe shouldn’t have existed in the first place”
What I should have said (maybe):
- “We can now ship customer-requested features 75% faster, directly impacting our win rate against competitors”
- “Reducing incidents by 60% freed up 3 engineering FTEs to work on revenue-generating features instead of firefighting”
- “Platform automation let us onboard 15 new engineers in Q4 without proportionally scaling our DevOps team, reducing our cost-per-engineer by 30%”
But here’s my concern: am I just putting a business-friendly spin on the same work? Or is the work itself not actually aligned with what the business needs?
The Real Question
When your CEO doesn’t “get” platforms, is that:
A) A communication problem — You built the right thing but failed to explain its value in business terms
B) A prioritization problem — You optimized for developer experience when the business needed you to optimize for something else (faster feature delivery, lower cloud costs, better security posture, etc.)
C) A maturity problem — The company isn’t ready for platform engineering and you’re trying to force organizational change before the pain is acute enough
D) A structural problem — Platform engineering requires a level of executive sophistication and long-term thinking that most companies simply don’t have
I’m genuinely not sure which one it is for us. And I suspect the answer might be “all of the above.”
What I’m Wrestling With
-
Should I have gotten executive buy-in before building the platform? We started as a grassroots initiative—engineers were frustrated, we saw a clear need, we built incrementally. But now we’re hitting a ceiling because we don’t have organizational air cover.
-
How do you translate developer experience into business metrics when the connection is indirect? Yes, faster deployments can lead to faster feature delivery which can impact revenue—but there are so many variables in between that it feels intellectually dishonest to claim direct causation.
-
What happens when the ROI timeline doesn’t match board expectations? Platforms are investments that pay off over quarters or years, not weeks. How do you justify that when the board wants to see results this quarter?
-
Is 35% adoption actually a problem, or am I measuring the wrong thing? Maybe the right 35% are using it and that’s enough. Or maybe 35% means we built something the organization doesn’t actually want.
The Uncomfortable Truth
I think the uncomfortable truth is this: Platform engineering is as much an organizational change management challenge as it is a technical one—and CTOs like me are often better at the technical part than the organizational part.
We know how to build platforms. We’re less practiced at building the coalitions, telling the stories, and translating the work into the language that CEOs, CFOs, and boards actually care about.
And when we fail at that translation, we risk building technically excellent platforms that die from organizational neglect.
So here’s my question: How do you build platform engineering when your CEO doesn’t get platforms? Do you invest in education and organizational change first? Do you start small and prove value incrementally? Do you wait for the pain to get worse until leadership demands a solution? Or do you accept that some organizations just aren’t ready and focus your energy elsewhere?
I’d especially love to hear from folks who’ve successfully navigated this—or who tried and failed. What worked? What didn’t? And how do you know when to push harder vs. when to pivot?