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 200 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 integration tax: "the cumulative cost, in time, money, and senior engineering attention" of moving from component selection to production reliability. 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 comes first: too many candidate projects for the time available to evaluate them, with no clear guidance on which combination works at your scale. Decisions get deferred, or get made and then revisited six months later. It's the "too many tools" challenge, seen from the inside.
Integration overhead follows. Open source projects rarely come integrated with each other, so getting Prometheus, cert-manager, Flux, a policy engine, a service mesh, and a developer portal to behave as one coherent platform takes months of glue work, then ongoing maintenance as each component evolves on its own release cycle. It's the "operational overload" challenge, viewed structurally.
Opportunity cost is the third, and often the largest: the senior engineers who could be building things that move the business forward are instead keeping the platform alive. It's the "no time for automation" and "hiring the right people" challenges, named from a different angle, and it's the cost that never shows up on a budget line.
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 often the most workable plan available, not a sign anyone's reasoning has gone wrong. 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 integration tax. None of them is the right answer for every team.
- 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.
- 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.
- 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 have plenty of options. What they lack is 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.
