Starting with the front end limits flexibility
Platform engineering isn’t about dashboards or polished UIs. That’s not where the leverage is. If your team builds the front end first, you’re prioritizing perception over performance. This is one of the most common, and avoidable, missteps in modern platform efforts.
Front-end interfaces are useful, yes. Tools like Backstage are widely adopted and provide value. But they’re only a shell. The real engine, what truly powers an internal developer platform, sits beneath the surface. It’s in the APIs, the automation layers, the infrastructure orchestration. That’s where developers get speed and reliability. If that foundation is fragile, even the most beautiful interface won’t save adoption.
Viktor Farcic, a developer advocate at Upbound, pointed out something essential: putting your platform’s logic inside the portal locks you into one way of interacting with it. That’s a limitation. Developers want flexibility. Some use GUIs. Others use CLIs or APIs. Ignoring that diversity pushes developers to circumvent your tooling entirely, which means you’ve lost them before you’ve even started.
Luca Galante, who contributes to the Platform Engineering community, said it plainly, start with a solid back end. Get the foundations right. You can always layer in a UI afterward. That’s a smarter route. It delivers scalability. It gives developers choice. And it keeps your platform adaptable in the long term, which is exactly what you want.
Embracing a product mindset is crucial for platform adoption
A platform without a product mindset is just code with no purpose. This is the difference between building a tool and building something people want to use. Internal platforms are no exception. Expecting developers to adopt something without storytelling, advocacy, or feedback loops is wishful thinking, it doesn’t work.
Erica Hughberg, a manager at Tetrate, explained this clearly during KubeCon 2024. She said relying on engineers to drive platform adoption alone is a “recipe for disaster.” That’s not an exaggeration. You might engineer something impressive, functionally speaking. But even the best products don’t sell themselves. They’re shaped, promoted, and constantly refined. Think like a product team, because you are one.
Get a minimum viable platform into the hands of developers early. Then listen. Iterate. Measure. This isn’t about perfection, it’s about relevance. Luca Galante from Platform Engineering recommends tracking impact over time. That’s what keeps the platform breathing. If you’re not improving constantly, you’re behind.
This product mindset isn’t fluff. It’s ROI. When you build with purpose and market it internally, adoption follows, organically and at scale.
Give your platform an identity. Show value before asking for commitment. Make this shift, and you’ll notice the difference. Teams don’t just use the platform, they rely on it.
Shared ownership and developer buy-in are vital for engagement
Top-down implementation kills trust. If you push a platform on developers without their input, they’ll either reject it or build their own workarounds. That’s time lost. Innovation lost. It’s a path to fragmentation, not adoption.
Shared ownership solves this. It turns platform engineering into something participatory. Tom Barkan-Benkler, Director of Product Management at Spotify, explained this well: give teams the freedom to contribute. Let them write plugins. Let them shape the platform around their workflows.
Spotify doesn’t just talk about this model, it operates by it. They built “Soundcheck” as a plugin inside Backstage, their internal developer portal, to support continuous delivery validation. More importantly, their open model means every engineer can extend the platform. That’s a force multiplier. Developers don’t need to ask permission to improve their tools, they just improve them.
The payoff? Pia Nilsson, Spotify’s Senior Director of Engineering, confirmed that 100% of employees use their internal Backstage instance. That’s not a result of mandates. That’s co-ownership driving embedded value.
Jay Jenkins, CTO of Cloud Computing at Akamai, put it best: governance should empower, not restrict. You need structure, but it should invite contribution, not limit it. Platforms succeed when developers feel it’s something they helped build. That’s when your platform becomes an ecosystem.
Thorough user research is essential to build relevant platforms
Engineering teams aren’t one-size-fits-all. Developers, QA engineers, site reliability teams, they operate differently, need different tools, and expect specific capabilities. Yet too many platform initiatives are launched on assumptions. That’s a risk you can’t afford to take.
Andreas Grabner, a DevOps advocate at Dynatrace, said this clearly: if you build a platform without knowing your users well, you build something that won’t move the needle in engineering efficiency. It may look good on paper, but it won’t drive adoption or solve actual bottlenecks.
Start by listening. Gather feedback before writing the first line of code. That gives you clear signals. What do your teams need? Which workflows are breaking? Where’s the wasted time?
Zohar Einy, CEO at Port, emphasized this human angle. When teams see their feedback reflected in platform outcomes, adoption increases. People support what they helped define. That’s not just sentiment, it’s strategy. It ensures the platform aligns with real, everyday work.
For executives, this is a straightforward move. Early research reduces waste, speeds up iteration, and delivers functionality where it’s needed most. It’s an investment in clarity, and long-term efficiency. Don’t skip it. It pays dividends.
Focusing on the wrong metrics can misguide platform investment
Looking at the wrong numbers leads to false signals. It’s easy to fall into the trap of reporting onboarding stats or tool usage as signs of success. But those are surface-level indicators. They don’t show how your platform is impacting the business.
Andreas Grabner from Dynatrace points out that many teams lean too heavily on DORA metrics, lead time, deployment frequency, change failure rate. Useful, yes, but they are trailing indicators from a platform engineering perspective. They don’t tell you whether your investments are increasing productivity or reducing friction in real time.
If you want to know whether your internal developer platform matters, focus on time-to-market reductions, lowered infrastructure costs, and whether your engineering teams are innovating faster. Kaspar von Grünberg, CEO at Humanitec, makes this direct: ROI must be defined before a single component is built. If you don’t know what “good” looks like, you can’t measure progress, and you can’t justify the spend.
For C-suite leaders, the takeaway is clear. Push for metrics that speak to business impact. Treat usage statistics like signals, not outcomes. Adoption means nothing if it doesn’t translate into strategic value. Metrics should connect your platform’s performance to goals you can present to the board.
Copying strategies from large companies can be counterproductive
Just because it worked at Spotify or Expedia doesn’t mean it will work for you. Large enterprises have unique advantages, scale, budget, engineering bandwidth, that don’t apply to every business. Adopting their internal platform models without adjustment often results in overbuilds and failed expectations.
Himanshu Mishra, staff product manager at Harness and formerly part of the Backstage team at Spotify, warns against exactly this. He says the return on effort matters more than matching capability. Smaller teams may spend the same effort as a large enterprise, but they often won’t see the same return. The misalignment burns time and resources.
Camille Fournier, seasoned advisor and author of O’Reilly’s Platform Engineering, isn’t impressed by reference architectures either. She points out that they don’t address the difficult parts, abstractions, scalability limitations, maintaining observability standards across varied application stacks. Templates are useful, but they don’t solve foundational complexity.
For executives, the guidance is simple: be strategic. Borrow ideas, but align every design choice with your actual business needs. Copying blindly won’t close capability gaps. Building from what your teams need right now will.
Overengineering in the early stages creates unnecessary complexity
Trying to address every possible use case up front leads to complexity that slows teams down. Many platform engineering efforts fail early because they focus on hypothetical futures instead of solving real problems today.
Himanshu Mishra from Harness advises a pragmatic approach: start with core developer workflows, especially CI/CD. Minimize the friction where it’s highest. When those areas are streamlined, you build trust and prove value early. Later, additional capabilities can be added based on clear demand, not overextended assumptions.
Camille Fournier, an experienced CTO and platform engineering author, supports this. She recommends focusing first on neglected areas that cause shared pain across teams. Adding complex features too soon creates bloat and clutters the experience.
Jay Jenkins, CTO of Cloud Computing at Akamai, draws a hard line here: if your platform adds more toil than it removes, you’re headed the wrong direction. Efficiency should increase. Complexity should be managed. A platform that consumes more developer time than it saves is fundamentally flawed.
Executives should prioritize outcomes over scope. Early wins create momentum. Stability comes from sequencing, not volume. If the platform isn’t making life easier within the first few releases, your foundation needs reevaluation, not expansion.
Rebranding operations teams without fundamental changes is ineffective
Renaming your infrastructure team to “platform engineering” doesn’t fix anything. It doesn’t change mindset, workflows, or outcomes. That’s a surface-level move that creates appearance without progress.
Paula Kennedy, COO and co-founder at Syntasso, has seen this firsthand. She’s observed organizations simply rename ops or infrastructure teams in hopes of aligning with current trends. But unless those teams adopt new practices, user engagement, product thinking, iterative development, nothing actually improves.
Camille Fournier is clear about what’s required: platform engineering demands culture shift. It requires viewing infrastructure not as cost containment, but as a product that helps software teams move faster, safer, and with more consistency. That’s a different operating model, and it needs different leadership priorities.
For C-level leaders, this is about commitment. You can’t assign new titles and expect results. You have to guide transformation deliberately: new vision, meaningful goals, measurable impact. If you skip that, you don’t get the gains. You get a new nameplate and the same bottlenecks.
Platform engineering is a continuous, evolving initiative
Platform engineering doesn’t end. It evolves. The idea that you can “complete” an internal developer platform is misleading and often leads to stagnation. What works today might not align with development needs six months from now. The most effective platforms adapt, constantly.
Zohar Einy, CEO at Port, and Himanshu Mishra from Harness both emphasize the importance of adopting a product manager’s mindset. That means treating your platform not as infrastructure to maintain, but as a product that must deliver outcomes. It must evolve based on usage, feedback, and measurable impact.
For internal platforms to succeed, they need to meet developers where they are. That means reducing repetitive tasks, standardizing workflows, and offering automation that saves real time. Done right, platforms become silent accelerators. But none of this happens automatically. It takes iteration. It takes feedback. It takes investment.
Tom Barkan-Benkler of Spotify highlighted what’s becoming a recognized principle, co-ownership matters. Developers must have a say in shaping the platform. Executive buy-in keeps it funded. Team buy-in keeps it useful.
But results take time. According to the 2024 DORA Report, having a dedicated platform engineering team increased developer productivity by only 6%. At the same time, it decreased throughput by 8% and reduced change stability by 14%. That data sends a clear message: the benefits of platform engineering don’t materialize without strategic, ongoing effort. You don’t just build it and win. You build, adapt, and improve, or you stall.
For executives, this requires long-term thinking. Allocate resources beyond the launch. Set goals measured in outcomes, not outputs. And push for systems that reflect real usage and enable faster innovation. That’s how platform engineering becomes a durable advantage, not a one-off project.
Concluding thoughts
If you want platform engineering to work, you can’t treat it like a side project or a title swap. It’s a strategic capability. It impacts speed, cost, innovation, and developer retention. Done right, it becomes infrastructure that actively amplifies your engineering efforts.
But it only works when built with intention. That means thinking like a product team. That means knowing your users inside out, measuring real impact, and iterating based on actionable feedback. Mandates from the top won’t deliver adoption. Co-ownership will.
Avoid overengineering, ignore vanity metrics, and stop copying what doesn’t fit. Build what your teams actually need. Then optimize over time.
For executives, platform engineering is a long game. But the return, when matched with discipline, vision, and the right inputs, is real. Make the investment count. Lead it with the same focus you’d apply to any product driving your bottom line.
