Hey there,
Before I break down exactly what you need to do to prevent your platform initiative from failing, the community has recently launched the surveys for the State of Platform Engineering report (Vol. 3 already!). Here are the links if you want to help out and fill them in. The data will be shared in the report when it’s finished.
Alright, let’s dive in with the biggest shift in platform engineering I see right now.
While 2 years ago many platform engineering initiatives failed to ever get off the ground, now most are starting with Minimum Viable Platforms (MVPs).
Teams have now realized that endless planning of a large scale IDP that covers every edge case does not lead to success. The risk that you can’t demonstrate any value within the next 3 years and you do not get any funding for your platform engineering initiative is just too high.
And that’s not the only thing you have to be careful about. Other core drivers of failure of platform engineering initiatives in this context are:
- Lack of adoption
- Never getting anything workable
- Unclear Return on Investment.
Because of that, many teams started to follow a Platform as a Product approach and as one of the first steps, build a Minimum Viable Product (MVP) based on reference architectures, aiming to show value quickly.
But even following this approach, many teams still fail. Why? As in most cases, it is not about the tech itself, but about execution, communication, and interaction with other stakeholders.
After having observed this many many times, this is the advice I give to our teams and the teams we serve:
Keep the momentum at all costs: the platform engineering team needs to be in front of the wave and control the situation. Execution needs to be fast and flawless. Timelines you communicate need to be chosen conservatively and expectations have to be exceeded continuously. Why? Because platform endeavors will often be subject to challenges by other parts of the organization that might feel threatened, or are worried about the impact of your platform. Momentum and especially reality are hard to fight.
Choose the right first team: I cannot stress enough how important this is. If you need to create reality that means you need to have usage. To have usage you need to get a developer team to buy in. But that’s easier said than done. Because in most cases developers do not want change. They are, after all, human. While everybody will tell you that they are in general eager to join your platform initiative, when things get concrete nobody wants to jump first.
The second point is so vital that I want to spend more time on this. Here’s my hack on how to do this:
Setting expectations
What does “Onboard App 1” actually mean? It doesn’t imply the development team has decided to switch to your platform fully. They lack sufficient information, and your platform isn’t fully ready yet.In concrete terms, it means they are open to testing the development of one of their services or applications on your platform. The setup will use their real container, but the infrastructure will only mimic their actual environment.
How to get buy-in from developers for testing
Don’t overestimate your abilities—you need proper training to deliver platform demos. First, create a long list of potential app teams to approach. At this stage, do not engage with the teams yet.
Criteria for selecting teams
- Representative application: The app should represent other apps, showing developers that your platform can support their other services.
- Manageable scope: Limit the test to 1-3 services with 4-10 dependencies.
- On your “standard tech stack”: Make sure this is as close to your “blueprint” app that your platform is designed for.
Approaching teams:
Once you’ve identified 1-3 suitable teams, reach out with this message:
---
Subject: Internal Developer Platform Testing Opportunity
Message:
Hi TEAM,
We’re building a modern Internal Developer Platform aimed at reducing wait times and enabling PR environments. Would you be interested in testing it using one of your services or a test service? This won’t require your time or impact your current services or infrastructure.
We’ll handle all setup and onboarding with dummy infrastructure.
Once everything’s ready, we’ll provide a demo and instructions for you to test. If the trial is successful, you can decide whether to fully onboard. Here's a demo video showing the target state. Let us know if you have any questions!
Best regards, Â
Your Platform Team
---
This approach keeps the initial ask low-effort for the team and outlines the process clearly.
How to Choose the Right Service/App
Here’s a force-ranked approach to selecting the right service for testing:
- Best case: Ask the development team if they have a dummy app used for testing new things.
- Second option: Inquire if they’re starting a new service and offer to set it up as a test.
- Third option: Request 1-3 independent services that are representative of their broader architecture.
Once the app is selected:
Ask the development team for the following materials:
- Deployment artefacts
- Pipelines (if available)
- Network diagrams (if available)
- Other relevant documentation
Prepare the platform for the test app:
Focus all the energy you put into developing your platform on this one app. Get the end to end experience optimal for this one case. This will feel like your wasting energy as you are not building things for scale but this does not matter. Because if you don’t keep momentum going there will be no scale.
Prepare for the developer test
Training: Do not overestimate your readiness - practice the demo thoroughly and dry run the test day.
Running the developer test
- Begin with a presentation and then demo the platform using their selected app.
- Provide access to the platform and let them run a developer tutorial independently.
Collect feedback and secure buy-in
Let them know you’ll now build the production-grade version and consider them for onboarding. Inform them that the onboarding process would require 1 hour per day from a developer for 1-2 weeks, but should take no more than a day.
Ask: “Would you be open to testing this flow in your actual development environment and, if successful, switching to the platform entirely?” If they hesitate, ask: “What would you need to see to make this switch?”
That’s a lot to swallow but look, platform engineering initiatives aren’t easy. There’s no silver bullet, there’s just excellent execution and hard work.
You’ll prevail!
Kaspar
P.S. don’t forget to help out the platform engineering community and fill in these surveys.
