Twice the delivery from the same engineering team
A B2B SaaS company growing 40% a year could not hire its way to faster delivery. We embedded a small senior team for 24 months, built the capability inside the client's squads and stepped back once an internal CoE owned it.
Hiring more engineers was not making delivery faster
Revenue was growing 40% a year and headcount grew with it, but feature delivery did not keep up. Each new hire took six months to become productive, and every architectural decision meant either a long debate or a vendor recommendation. The CTO could keep hiring and watch margins shrink, or accept that the platform could not keep pace with the roadmap.
A Tier-1 consultancy had already been tried. It produced a 90-page strategy, no operational change, and a follow-on quote larger than the year's engineering budget. Discovery showed the real issue: eight squads with eight service patterns, no platform team, and operational knowledge held by three people.
The brief: build the company's own capacity to deliver, so the partner that helped would not become a permanent line item.
Releases depended on three people
Three senior engineers held most of the operational knowledge. When one of them was on holiday, some releases simply did not ship.
Cross-cutting changes took three weeks
A change touching several services needed weeks of coordination. Weekly architecture reviews produced few binding decisions.
Key hires stalled for nine months
Two senior platform roles stayed open for nine months. The market was tight, and the roles had no clear scope of authority.
.avif)
Four decisions that built capacity the client keeps
One service standard instead of eight
We codified the diverging patterns into one standard for APIs, errors, eventing, persistence and observability, each choice backed by an Architecture Decision Record. New services are generated from templates, so squads cannot easily drift apart again.
Grow the platform team from inside
Rather than wait on external hires, we formed the platform team from two existing senior engineers. Together we built a self-service deployment flow on Kubernetes with GitOps, a service catalog and a paved road for new services.
Named decision owners instead of review meetings
Squads were reshaped around stable product domains, with WIP limits and priorities tied to business outcomes. Weekly architecture meetings gave way to asynchronous ADR reviews with a named owner for each decision, which also gave the open senior roles a clear scope.
Train the CoE, don't staff it
We helped design the company's engineering Centre of Excellence and assembled it from the client's own senior engineers, which made it credible internally. The exit date was set at kickoff, and every milestone was measured by what the team could do without us.
Months 1–11 · Co-execution
We led standards and the first platform version. Client engineers paired on every change.
Month 11 · Co-leads
Two client engineers co-lead the platform.
Months 12–20 · Transition
Client leads platform and forum. CoE formed.
Months 21–24 · Self-sufficiency
The internal CoE owns all standards and decisions.
After exit · Counsel
Monthly check-ins and ad-hoc strategic advice.
The client's own CoE now owns the roadmap
Every standard, ADR, runbook and playbook lived in the client's own repos and wiki from day one, and each capability had a named internal owner on a skills matrix. When MetaProject stepped back, nothing important left with us.
The CoE runs independently with its own architectural roadmap. The weekly tech talks we started became a practice the team kept. MetaProject's role is now monthly check-ins and occasional strategic counsel.
24 mo
from co-execution to a fully independent CoE
5
client engineers rotating through the CoE
2
client engineers co-leading the platform by month 11
4 mo
to fill senior roles open for nine months
2.1×
feature delivery capacity at the same team size
4×
deployment frequency, with no rise in change-failure rate
−62%
lead time from idea to production
−45%
annual external consulting and contractor spend
4 wks
onboarding for new engineers, down from six months
+28pp
senior engineer retention, measured 18 months after the transition
Five capability layers, each handed to the internal team before the next: architecture standards, an internal developer platform, the delivery operating model, the engineering CoE and knowledge transfer systems.
AWS multi-region, multi-account · EKS, Lambda, Fargate · PostgreSQL (RDS, Aurora) · DynamoDB · Kafka (MSK) · ArgoCD · Backstage · Terraform / Crossplane · GitHub Actions · OpenTelemetry · Grafana, Prometheus, Loki
Questions about this project
How do you double delivery capacity without doubling headcount?
By removing what slows the existing team down rather than adding people. Here that meant one service standard instead of eight, a self-service platform built by the client's own engineers, and named decision owners instead of review meetings. Delivery capacity rose 2.1× at the same team size.
How long does a capability expansion engagement take?
This one ran 24 months from co-execution to a fully independent internal Centre of Excellence, with an exit date set at kickoff. The pace depends on how much the client's team needs to take on, and every milestone is measured by what the team can do without us.
What does the client own at the end?
Everything. Standards, Architecture Decision Records, runbooks and playbooks lived in the client's repositories and wiki from day one, and each capability had a named internal owner. After the exit our role is monthly check-ins and occasional strategic counsel.
How quickly do new engineers become productive?
Onboarding went from six months to four weeks, because new engineers start on a paved road with templates, a service catalog and documented decisions instead of tribal knowledge.
Can you share the client name?
The client name is withheld under NDA. Get in touch if you'd like to discuss the engagement in more detail under a mutual NDA. We can walk through the architecture and operational decisions at a level not appropriate for public material.
See more cases
Is your team growing faster than its delivery?
Tell us what you are building. We will come back with an honest view of how we would approach it.