8 platform engineering anti-patterns

Some say platform engineering has entered its trough of disillusionment phase. A combination of high cognitive load, lack of business alignment, and difficulty encouraging adoption of internal developer platforms (IDPs) has stalled one of yesteryear’s hottest technology trends.

Platform engineering initiatives fail for a variety of reasons, from lack of leadership or developer buy-in to an inadequate IDP implementation. Below, we’ll consider what not to do when it comes to platform engineering, looking at common traps teams fall into and the lessons learned.

Building the front end first

A big misconception in platform engineering is that the platform is the visual interface, i.e., that the platform and the developer portal are one and the same.

Naturally, it’s much more than that. “Platform implementation should begin with a solid back end, not the front end,” says Luca Galante, core contributor at Platform Engineering, a popular platform engineering community. “Focus on building a solid back end with APIs and orchestration before adding a UI,” he adds.

Front-end user interfaces like Backstage are a core element of platform engineering, but they aren’t the full picture. Developers may prefer interacting outside the GUI portal, through a CLI or an API, too.

“It’s important you don’t put logic in your portal—then you’re limiting yourself to one way of accessing your platform,” says Viktor Farcic, developer advocate at Upbound. Doing so locks you into one consumption mode, which can frustrate users who desire more flexibility.

Lacking a product mindset

Adopting a product mindset has almost become a cliché tip in the world of platform engineering. But it’s true—not treating the platform as a product is a surefire path toward minimal use.

“Even the best products don’t sell themselves,” shared Erica Hughberg, manager at Tetrate, at Kubecon North America in 2024. According to Hughberg, expecting engineers to drive adoption without a clear marketing approach is a recipe for disaster. Building a user base requires more than you might think: internal advocacy, storytelling, and sharing early-adopter success stories.

Establishing a product mindset also helps drive improvement of the platform over time. “Start with a minimum viable platform to iterate and adapt based on feedback while also considering the need to measure the platform’s impact,” says Platform Engineering’s Galante.

No shared ownership

Top-down mandates for new technologies can easily turn off developers, especially when they alter existing workflows. Without the ability to contribute and iterate, the platform drifts from developer needs, prompting workarounds.

“Give the teams some ownership—don’t push them to adopt,” recommends Tom Barkan-Benkler, director of product management at Spotify. To enable this, Spotify gives developers autonomy and the ability to write plugins for Backstage, their IDP.

One example is Soundcheck, a Spotify-made plugin to validate new code within a continuous development process. When engineers can build and customize the platform, they’re part of the process and more likely to use the platform, adds Barkan-Benkler.

This shared ownership model is proving successful. According to Pia Nilsson, Spotify’s senior director of engineering, 100% of employees use the company’s internal version of Backstage.

Others agree that too much top-down control can stunt a fledgling platform engineering initiative. “Strong governance is key, but it should empower, not restrict,” says Jay Jenkins, CTO of cloud computing at Akamai.

Not surveying users

On that note, not fully understanding your user base can result in scattered results.

“If you build something without knowing your target audience and how you can help them, you build something that will not be impacting engineering efficiency at all,” says Andreas Grabner, devops activist at Dynatrace and co-author of Platform Engineering for Architects. Instead, platform architects should seek to intimately understand end users and their pain points, he says.

This is tricky because every organization is different, with unique requirements for different user subsets. For example, the user experience a Java developer requires, says Grabner, is far different than what a quality assurance tester or site reliability engineer expects. This underscores the importance of gathering feedback for specific user subsets.

“The feeling of being heard and understood is very important,” says Zohar Einy, CEO at Port, provider of a developer portal. “Users are more receptive to the portal once they know it’s been built after someone asked about their problems.”

By performing user research and conducting developer surveys up front, platform engineers can discover the needs of all stakeholders and create platforms that mesh better with existing workflows and benefit productivity.

Tracking the wrong metrics

“Everything you build should be measurable,” says Dynatrace’s Grabner. Yet you must make decisions based on the right metrics. DORA metrics, Grabner says, are lagging indicators from a platform engineering perspective.

Similarly, a high percentage of onboarded developers using the platform may be only a surface-level indicator of success, and not necessarily an accurate reflection of ROI to the business.

“A successful platform should improve time to market, reduce costs, and increase innovation,” says Kaspar von Grünberg, founder and CEO at Humanitec, a provider of tools for building internal developer platforms. “The starting basis is a proper ROI calculation you should have before building the platform.”

Copying the platforms and approaches of others

Although platform engineering case studies from large companies, like Spotify, Expedia, or American Airlines, look impressive on paper, it doesn’t mean their strategies will transfer well to other organizations, especially those with mid-size or small-scale environments.

“The effort is the same no matter if you have one hundred or thousands of developers,” says Himanshu Mishra, who was previously part of the Backstage team at Spotify and now works as a staff product manager at Harness, the maker of a software delivery platform. “Think of the return on investment, and don’t just copy what bigger players are doing.”

IDP reference architectures can give you a general idea of what it takes to construct a platform. However, not all are convinced of their universal utility. As Camille Fournier, advisor, CTO, and author of O’Reilly’s Platform Engineering, shares:

“I don’t think [IDP reference architectures] solve the hardest problems of abstracting the infrastructure from the application teams, and leave the challenge of every team needing to understand how to scale and support their entire application stack; provisioning and even setting up observability are a small part of the overall lifetime cost here.”

Overengineering on day one

Some platform teams attempt to boil the ocean from day one. Instead, Harness’s Mishra recommends starting by streamlining basic, concrete developer touchpoints and CI/CD, then introducing additional complexity incrementally. “Always optimize for developer time, rather than platform engineering time,” Mishra says.

Others agree that incremental development is key for successful platform engineering rollouts. “Solve today’s problems, don’t focus too far into the future until you have established success,” says Fournier. She recommends first focusing on areas of shared software suffering from a lack of focused ownership.

“Complexity is the enemy,” says Akamai’s Jenkins. “If platform engineering is creating more toil than it’s reducing, something is off.” Platforms shouldn’t add layers of unnecessary tooling, rigid processes, or heavyweight templates that slow developers down. Instead, the best platforms are almost invisible, he says.

Rebranding the operations team

Platform engineering requires more energy beyond a simple rebrand. “I’ve seen teams simply being renamed from operations or infrastructure teams to platform engineering teams, with very little change or benefit to the organization,” says Paula Kennedy, co-founder and chief operating officer at Syntasso, creators of the internal developer platform Kratix.

Countless project failures can be attributed to poor direction or a lack of clear requirements, and platform engineering is no different.

Platform engineering requires a significant cultural shift that shouldn’t be underestimated, says Fournier. As such, organizations should avoid treating it as a traditional cost center, and instead view it as a novel approach to solving software engineering problems, she says.

Platform engineering is never done

Nowadays, many cloud-native organizations are well along in their platform engineering journey, and most developers are familiar with internal developer platforms like Backstage. “I’m hearing those basic questions less and less,” says Spotify’s Barkan-Benkler. “The sheer amount of companies and tools for platform engineers is a good sign.”

Great internal platforms meet developers where they are. They’re self-service, they automate toil, they provide a standard software catalog and templates for consistency, and they offer golden paths with extensibility and flexibility. The platform engineering initiative itself ideally has executive buy-in but embraces co-ownership as well.

This dream seems great, but if achieving all these seemingly contradictory goals sounds near impossible, you’re not alone in thinking that way.

Many organizations are finding mixed results with platform engineering in production. The 2024 DORA Report found that having a dedicated platform engineering team increased the productivity of software development teams by a mere 6%. Even less encouraging, it actually decreased throughput by 8% and decreased change stability by 14%.

As these organizations have discovered, there are countless moving parts in platform engineering, and mistakes early on can have many downstream consequences. This makes success a convoluted target.

For the most part, succeeding in platform engineering boils down to basic product fundamentals. As so many experts advise, approach your internal developer platform as a product—one that must be continuously improved to meet the evolving needs of your developers.

“Embracing a product manager mindset is key,” says Port’s Einy. Harness’s Mishra echoes that sentiment. “You need to think like a product manager in your company.”