The Engineering Manager’s Guide to Establishing Platform Buy-In (Before You Build Anything)

Building an internal developer platform is not just a technical challenge; it is an organisational one. Across the industry, many platform engineering initiatives stall because developers resist adopting a system they had no hand in shaping. Most often, because they don’t trust or understand the platform. 

When building a platform, engineering leaders often focus on technology choices without first building a shared vision with developers, specialist teams and other stakeholders. This results in low adoption or, in the worst case, wasted investment.

There is a growing recognition that platform engineering is as much a social and cultural endeavour as it is a technical one. In a previous article, I highlighted how to enable collaboration across specialist teams in building platforms based on existing institutional knowledge. In this article, I will take a step back to provide a practical leadership framework for securing developer support before a single platform component is built.

Why platform buy-in matters more than technology

A few weeks ago, I wrote about why platform engineers need to think like product managers. In that article, I highlighted an example of an organisation that built its platform with just Backstage, and its team refused to use it because it was too complicated. This is the reality of countless teams. It might even be your reality reading this now. 

Platforms are products, and products succeed or fail as a result of adoption, not technical polish.

You remember Humane’s AI Pin? It was designed and marketed as the future of personal computing with a sleek wearable that could replace your phone. But despite its impressive design pedigree and cutting-edge technology, the product flopped almost immediately. 

Why? Because it didn’t align with how people actually wanted to use technology. It wasn’t integrated with their existing habits or ecosystems, and it required too much change without delivering sufficient value. 

That’s the same dynamic many internal developer platforms face.  

You can build something technically brilliant, but without buy-in and proof that it meets your users where they are, it risks becoming shelfware, no matter how innovative it appears on paper.

Understand developer pain points first through interactions

We can both agree that the ability to facilitate collaboration and build strong cross-team relationships is a core skill for anyone building a platform, and it is the foundation of gaining buy-in, whether from developers, specialist teams, or executives. 

Before a single line of YAML, Terraform or Kratix Promise is written, platform leaders need to step back and ask: What’s actually slowing our developers down? Not asking engineers in the platform team, but asking developers themselves. 

You can ask these questions by interviewing developers and other technical teams that interact with them, because in most cases, they have seen challenges (platform use cases) while working with developers. Another great source of hard (factual) data is repository issues and tickets raised by developers. 

With all that data gathered, the next step is to prioritise which challenge to solve first. As you’d have thought, the most painful challenge. With a product mindset, prioritising the use case to build can be as simple as analysing with frameworks like RICE, the Kano model, or the MoSCoW method, among others.

But you remember, we want to get buy-in before building anything and fast. I suggest a less analytical approach. 

Choosing the most recent pain with the highest frequency of occurrence. This can be easily gotten through recent conversations or the issues/tickets. 

Yes, it might not have the highest “ROI”, but it meets developers where they are at that time period and creates an emotional connection to what you will be building as opposed to solving a challenge with an existing workaround that has been in use for a couple of months. Yes, that can be standardised with the platform for compliance and governance needs, but not first. 

With the first challenge/problem/use case decided, how would you solve it? Make the solution as simple as possible to implement. Initially, it may be a framework, a documentation page with detailed steps, or a lightweight script that automates the process. The point isn’t to build the “perfect” platform feature on the first try; it’s to demonstrate responsiveness and value quickly.

By addressing a pain point that’s fresh in developers’ minds, you create an immediate win and show that the platform team is listening. With that, you earn trust. And once trust is established, you earn the right to tackle bigger, more complex problems that require deeper investment.

Co-create with developers, don’t dictate

Now you have the first component of the platform, developers are using it, and are excited about it. You are now using product thinking frameworks to build out other features based on impact, but the seeding buy-in doesn’t stop there because developers won’t just automatically use any new feature you build. 

How can you continue to co-create with developers without the workload of making them part of the platform team, or without feeling like they have to? There are so many ways, but here are two ideas you can implement:

Creating a platform sandbox environment 

I have seen several organisations set up what they call a platform sandbox environment. This sandbox is essentially a parallel space where developers can safely test new ideas and processes.

Here’s how it works: a developer who wants to try something new (maybe a deployment tool or a new observability agent) requests access to the sandbox.

They’re given credentials for a limited period (say, two weeks), along with clear boundaries around cost and security. Within that window, they’re free to explore, prototype, and see how their idea behaves in practice.

The key is what happens next: there’s a lightweight feedback loop back to the platform team. If the experiment proves valuable, for example, a tool improves performance for their service, there’s a path to add that idea into the platform itself. This creates an organic growth cycle where developers not only consume platform capabilities but also actively influence its roadmap.

The sandbox becomes more than just a playground; it’s a mechanism for innovation and buy-in. Developers recognise that their efforts can shape the future of the platform, while the platform team benefits from a steady pipeline of validated, developer-driven ideas. 

Developers' ideas being welcomed by the platform team 

Fixing platform bugs as they come

With developers using the platform, just like any product, there will be bugs, issues, or friction points that can be resolved or improved upon. The mistake many platform teams make is treating feature launch as the finish line for that capability, when in reality it’s the start of the feedback loop.

A simple way to keep co-creating is to establish lightweight mechanisms for ongoing feedback. Think “platform office hours,” check-ins with other teams, or even a dedicated Slack channel where developers can surface pain points in real time. 

The important thing isn’t to create more bureaucracy, but to show developers that their feedback directly shapes the platform.

When developers see bugs quickly fixed, friction removed, or a small improvement shipped in response to their input, it builds confidence that the platform team is listening. That responsiveness is what turns adoption into loyalty; co-creation in action.

Make it easy to do the right thing and hard to do the wrong thing

A significant worry for platform engineers in any organisation is that developers do not use the platform. As you’ve read so far in this article, obtaining developer buy-in isn’t a one-time activity; it is a lifelong commitment, spanning the platform's lifetime. 

In summary, the best way to sustain buy-in is to make it easy to do the right thing and hard to do the wrong thing. If one command or a few clicks provision a secure, compliant, production-ready database instance, as opposed to waiting days for approval, developers will naturally use the platform. 

When defining the “right thing”, it is essential to strike a balance between standardisation and flexibility. This is why we champion the idea of a platform being composable, which provides development teams the flexibility to move beyond the predefined “paved paths” when they encounter an edge case or a new use case.