Ask a platform team to describe what's getting in the way of their work, and you'll usually hear about four things: hiring the right people, too many tools for the team size, operational overload, and not enough time for automation. Different teams put them in different orders, but the same four answers come back.
They sound like four separate problems. Looked at together, they're more connected than they appear.
The unspoken baseline, and the four tied challenges
This isn't only our impression. When we surveyed hundreds of practitioners at KubeCon EU in 2023 and again in 2026, those four answers landed almost exactly tied: each one around 29% to 32% of responses. Oliver wrote up the full year-on-year comparison, which is worth reading alongside this post. What stood out for us was what didn't appear on the challenges list.
Stability. In both years, when teams were asked to name their main platform objective, stability and reliability was the top answer. In 2023, 47.6% of respondents named it. In 2026, the same trend held. But stability never showed up as a challenge. Not once.
It's the unspoken baseline. Teams don't write "keep the platform running" on a list of problems. It's assumed. And the four challenges that do get named are the things that make that assumption hard to hold.
Naming the pattern
The CNCF landscape now contains over 1,500 projects. Most teams building a platform from open source are choosing from that surface. The tools are free, but choosing them, integrating them, and running them in production is not.
At Giant Swarm, after twelve years of running production Kubernetes for enterprises, we've been calling this the platform assembly tax: the cumulative cost, in time, money, and senior engineering attention, of getting from "we picked these projects" to "this platform runs reliably in production." The shape of that cost is consistent across the teams we work with:
- 6–12 months to assemble a working platform from components
- 8–15 specialists needed to keep it running well
- €1M–€2M annually in operating cost at typical enterprise scale
That's the shape of the work being absorbed somewhere on the team's calendar. The framework has three parts, and which part is biggest varies a lot from team to team.
The three components
Evaluation paralysis. Too many candidate projects for the time available to evaluate them. No clear guidance on which combination works at your scale. Decisions get deferred, or get made, then revisited six months later. This is the "too many tools" challenge, seen from the inside.
Integration overhead. Open source projects rarely come integrated. Getting Prometheus, cert-manager, Flux, a policy engine, a service mesh, and a developer portal to behave as one coherent platform is months of glue work, then ongoing maintenance as each component evolves on its own release cycle. This is the "operational overload" challenge, viewed structurally.
Opportunity cost. The senior engineers who could be building things that move the business forward are instead keeping the platform alive. This is the "no time for automation" and "hiring the right people" challenges, named from a different angle. It's the cost that doesn't appear on any budget line and is often the largest of the three.
Once you can name which component is biggest on your team, what to do about it becomes a clearer conversation.
The internal-staff default, in context
One of the more striking findings in the 2026 survey was about how teams plan to make improvements. Of 143 responses, 99 said: internal staff only.
That's a reasonable default. In-house capacity feels most controllable. Vendor relationships add coordination overhead. Platform teams often have strong, well-earned opinions about autonomy and about not handing critical infrastructure to outsiders. And the work is genuinely specific to each environment, which makes outside help feel harder to integrate than it sometimes is.
Reading that finding alongside the four tied challenges surfaces a question worth sitting with. The same teams describing their main constraints as hiring, tooling, operational load, and a lack of automation time are planning to make improvements using only the staff already absorbing those constraints. That's not a contradiction. It is, often, the most workable plan in the moment. But it's worth knowing that's the plan, and worth knowing what the other options actually look like.
Three legitimate responses
There are roughly three ways to respond to the assembly tax. None of them is the right answer for every team.
1. Build through it. Hire, train, and absorb the work in-house. This works when capacity exists or can be added, when the team's opinions about the architecture are strong enough to be worth the cost of expressing them, and when the platform is itself part of the business's competitive position.
2. Share the load. Bring in outside help on the parts of the work where outside experience gives the most return. This comes in different shapes, from fully managed setups that remove the operational layer to expert-supported models that keep the team in control but bring outside knowledge into the build.
3. Change the architectural approach. Choose a curated platform stack rather than assembling from raw components. Adopt capabilities progressively rather than aiming for a complete platform up front. Trade some optionality for less integration overhead.
Where to start
Most teams don't lack options. They lack a way of seeing what they're choosing between. The framework is a way to make those choices visible. The first useful move is locating where your team sits on it. Which of the three components is biggest right now: evaluation, integration, or opportunity cost? The answer often suggests which response will move the most.
If you're sitting with the question of which component is biggest on your team, and what to do about it, that's a conversation we have often. Book a discovery call and we'll work through it together.
