What makes a platform team succeed while others struggle
How the way we build our platform teams determine the platform success.
Most platform teams don't fail at building the platform, they struggle at proving its value or solving user needs, which often leads to a long detour in the valley of pain and poor developer experience. This is a short recap of the presentation I gave at Navigate Kongress 2026, where I talk about some of the factors that tell apart the platform teams that succeed and those who struggle.
We need to remember that building platforms is a socio-technical problem, and it should be solved as such. Platforms must outpace the speed of change of the organization to justify their investments. The team building the platform needs to clearly map and understand the user needs the platform addresses.
Why are platform teams so special?
Platform teams build bridges across the organization to support teams in delivering business value
Platform teams need to listen to the needs of different teams and craft solutions that can highly impact the organization, both positively and negatively.
A bad platform can lead to big issues for the organization, as developer teams become stuck and are unable to deliver business value.
Defining success is critical. We want to avoid the "valley of pain and poor developer experience" as much as possible.
What makes a platform team succeed?
Focus on:
Leadership - clear guidance, clear backlog
Impact - deliver value fast, prove it works
Trust - build it, keep it, and get continuous feedback
The way you solve a problem is sometimes more important than solving it
What successful teams show:
Stable teams have established rituals, make it easier to onboard new colleagues, and have the capability to pivot faster.
High-performing teams have a strong product manager, the knowledge is spread across the team, and have a clear alignment on architecture
What teams that struggle show:
Stable teams might have existing internal frictions and negative communication patterns. Building platforms on those might be dangerous.
A team built around experts working in isolation - expert silos - results in communication overhead, high knowledge concentration (i.e. a low bus factor), architecture divergence, and eroded trust.
Dysfunctional teams are often subject to top-to-bottom mandates that cannot be challenged, difficult individuals pushing against change, or not having enough agency to change processes or infrastructure they would need to address user needs.
The references
A Miro template for your Internal Developer Platform kickoff workshop.
I asked the CNCF Platform Engineering community, platform architects, engineers and managers to answer the same question. Here are their answers.
What is the #1 thing that made your platform team succeed?
Having a good documentation
Automation and self-service
Support from management and freedom of decision
The focus on goals made us succeed!
Stability
People over technology/tools. Clear scope/purpose of the platform or sub-platform team. Use your own platform as a user regularly to understand the pain points.
Always think from both points of view
Communicating the needs of the users to the engineers
You can always hire someone to solve a technical challenge, but the inter-human one is the hardest and the one you shouldn't really outsource — it's a recurring theme
The person who is supposed to be "the expert" is not an expert
No clear goals or purpose, toxic management, reorgs, etc.
The platform team could not say no to requests
Unmanaged (not present in version control) Lambda functions can be one of the failures
Trying to do everything for the whole company at once
What would you like to share with the audience at NAVIGATE Kongress?
Having good documentation. Design future-proof platforms.
The best coworkers are the ones who like to jump in on new activities and learn the most out of them. A small team of 3 platform engineers can handle the needs of a 100+ employee company. Bad managers can be worse than no managers.
Implement a change in the mindset first, on all sides. Always answer What, Why, and How. Listen to feedback.
Everything can be done. The limit is not the tech — it's figuring out what we need, and to what degree we need it.
Run your platform as a small company (crossing the chasm).
The less crossing of team boundaries, the better.
Make policies mandatory, then people will adopt it.
The bigger the org, the more opinions you've got — focus on feedback.
You need version control; solutions built with team awareness in mind, not "school projects" where the wheel is reinvented.
Think customers, developer experience, maintenance, and reliability.
