You have three platform engineers. Product has six squads shipping features. Every environment request, every pipeline change, every "can you quickly look at this deployment" goes through the same three people. They are good. They are also the bottleneck.
You know this. You have the hiring req open. You have been looking for a senior platform engineer for four months. The recruiter says the market is tough. It is — you are competing with Google, Adyen, Booking, and every well-funded startup in the Netherlands for the same small pool of people who understand Kubernetes, networking, and CI/CD at production scale.
Meanwhile, product is waiting. Your CTO title means you spend half your day unblocking infrastructure decisions nobody else can make. The architecture that got you to Series A will not get you to Series C. Something has to change.
Here is what actually works.
The pattern we see
We work with scaleups between 50 and 200 engineers across Europe. The pattern is remarkably consistent:
Stage 1: The founding team built it. Two or three people set up Kubernetes, wired CI/CD, configured monitoring. It worked. They moved fast because they carried the full context in their heads.
Stage 2: The company scaled. The platform did not. Headcount tripled. The infrastructure stayed the same. The founding engineers became the platform team by default, not by design. Every request still flows through them because they are the only ones who understand how things are connected.
Stage 3: The platform team becomes a ticket queue. Product teams cannot self-serve. They file requests. The platform team triages. Lead time for a new environment goes from minutes (when the founders did it) to days (when three people serve six squads). Everyone is frustrated.
If this sounds familiar, the instinct is to hire. More platform engineers, more capacity, problem solved. But hiring takes six months in this market, and adding headcount to a broken model just creates a bigger ticket queue.
The fix is not more people. It is a different model.
Three things that actually unblock
1. Self-service by default
The single highest-leverage change you can make: stop being the person who provisions environments, creates namespaces, or configures pipelines.
Build golden paths — opinionated, pre-configured workflows that let product teams deploy without asking the platform team. A developer pushes to a branch, a preview environment appears. They merge to main, it deploys to staging. They tag a release, it goes to production. No ticket. No waiting.
This is not theoretical. This is what a well-built Internal Developer Platform does. The tools exist: Backstage for a self-service portal, Flux for GitOps-based deployments, Crossplane for infrastructure provisioning. The investment is meaningful — weeks, not days — but the payback is immediate. Every environment that provisions itself is one fewer interruption for your platform team.
What this looks like in practice:
- New environment: developer clicks a button in Backstage, environment is ready in minutes
- Pipeline change: developer modifies a
.gitlab-ci.ymlin their repo, no platform team involvement - Scaling: autoscaling handles it, with guardrails the platform team defined once
What this does not mean:
- It does not mean no governance. Golden paths have guardrails — cost limits, security policies, naming conventions — baked in.
- It does not mean the platform team disappears. They shift from running tickets to building the platform that runs itself.
2. Pair, do not hand off
When your platform team does work with product teams — and they will, for anything non-standard — the model should be pairing, not handoff.
The handoff model: product team files a request, platform team does the work, hands it back. Product learns nothing. Next time, same request, same dependency.
The pairing model: platform engineer sits with the product engineer, they build it together. Product engineer learns how it works. Next time, they do it themselves — or at least they understand enough to modify what exists.
This is slower for the first engagement. It is dramatically faster for every engagement after that. Knowledge compounds. After three months of pairing, your product teams handle 80% of what used to be platform team tickets.
The rule we use: if a platform engineer is doing something a product engineer could learn to do, they should be doing it together.
3. Document decisions, not just systems
Most platform teams document what — runbooks, architecture diagrams, configuration references. Few document why.
Architecture Decision Records (ADRs) capture the reasoning behind significant technical choices: what was decided, why, what alternatives were considered, and what tradeoffs were accepted. They take 30 minutes to write. They save weeks of re-litigation.
When your CTO is the only person who knows why the platform is built a certain way, every architectural question routes through them. ADRs distribute that context. A new engineer reads the ADR and understands not just how the service mesh is configured, but why Cilium was chosen over Istio, what the alternatives were, and under what conditions the decision should be revisited.
This is not documentation for documentation's sake. It is removing the CTO from the critical path.
The capacity question
These changes take time to implement. Your platform team of three is already at capacity. This is where external help — done right — makes the difference.
The wrong model: bring in contractors who build things your team cannot maintain. You get a faster build phase and a longer dependency phase.
The right model: embed senior platform engineers with your team for a defined period. They build alongside your engineers, pair on every decision, document as they go, and leave your team able to run and extend everything independently.
What to look for:
- Engineers who pair, not engineers who disappear into a branch and come back with a pull request
- Architecture decisions documented as ADRs from day one
- A planned handoff — not "we'll figure it out at the end" but a structured knowledge transfer from week one
- A defined exit — the engagement succeeds when your team does not need them anymore
What to avoid:
- Firms that create proprietary abstractions your team cannot understand or modify
- Body shopping disguised as consulting — if they are just filling a seat, you could do that cheaper
- Anyone who cannot explain their Kubernetes opinions with specifics
The hiring problem is real — but it is not the only lever
Yes, you need to hire. You should keep that req open. But hiring is a 6-month lever, and your platform team is a bottleneck today.
The combination that works:
- Now (weeks 1–2): Assess your current state. Map the bottlenecks. Identify the top 3 things product teams need from the platform team that could be self-service.
- Short-term (weeks 3–12): Build the self-service layer. Embed external engineers if needed. Pair on everything. Document decisions.
- Medium-term (months 3–6): Your platform team shifts from ticket queue to platform builders. Product teams self-serve for 80% of needs. Your CTO is out of the critical path.
- Long-term (months 6+): Hire into a functioning platform team, not a firefighting squad. New hires are productive faster because the platform is documented and the golden paths exist.
The goal is not to eliminate the platform team. It is to change what they spend their time on — from answering requests to building the system that answers requests automatically.
What this looks like at the end
A year from now, if you do this well:
- Product teams deploy without asking anyone. Environments appear in minutes. Pipelines just work.
- Your platform team of three (now maybe five) spends their time on architecture, reliability, and cost optimisation — not tickets.
- You have ADRs for every significant decision. A new hire can understand why the system is built this way without asking the CTO.
- You can scale to 300 engineers without proportionally scaling the platform team.
The architecture that got you to Series A will not get you to Series C. But the answer is not just more people. It is a better platform.
Facing this exact situation? Start with a conversation about where you are and where you need to be. Or read about how we build platforms with your team.