May 2026
I inherited two engineers who had never touched AWS.
Within 18 months, one was our primary coordinator with AWS engineering. The other had converted our company's flagship migration from a data center deployment model to GitOps on ECS/Fargate — a pattern that would become the reference architecture for every cloud migration that followed.
This is the part of the CCoE story that doesn't make it into the architecture diagrams.
The cloud industry has a talent problem. Everyone wants experienced SREs with Kubernetes certifications and production AWS experience. Nobody wants to build them. The math is simple: demand outpaces supply by a wide margin, and poaching only shifts the deficit around.
The CCoE model offered a different approach. Instead of hiring for SRE skills that didn't exist in the organization, we built a pipeline that turned infrastructure engineers and ops-focused developers into SREs — through pattern-based learning, production exposure, and a clear career path.
It wasn't formalized as a "program." It was three things that happened to work together:
Production exposure with safety rails. Mark and Victor didn't start with root access to 47 AWS accounts. They started with defined work items inside the CT migration — specific service migrations with documented patterns, paired with senior engineers for the first pass, then gradually given ownership of full workstreams. The safety net was the pattern itself: if you followed the maturity model assessment, the GitOps template, and the observability stack, you couldn't go far wrong.
Career visibility. I made sure both of them knew where they were going. We had explicit conversations about what Principal SRE looked like, what skills they needed to develop, and what work would get them there. This is table-stakes management, but it's surprisingly rare in practice — most organizations treat SRE as a destination you arrive at by surviving incidents, not a career path you can navigate intentionally.
Compensation advocacy. When Mark and Victor reached the level, I went to bat for their promotions and compensation adjustments. This matters more than most managers realize. If you ask people to develop scarce, high-demand skills and then pay them below-market rates, you're running a training program for your competitors.
The CCoE to SRE transition tested everything we built. When the organization forced CCoE resources into SRE roles aligned with product groups, we lost people — not because the model was wrong, but because the transition was framed as a reassignment rather than a promotion.
The people who stayed were the ones who saw the career path clearly. The ones who left were the ones who felt like they were being moved rather than developed.
The lesson: a pipeline is only as strong as the narrative that supports it. If you're asking people to develop new skills, take on new responsibilities, and operate in a higher-stakes environment, you need to make the "what's in it for me" explicit and credible. Promotions, compensation, and title changes are not perks — they are the infrastructure of a functioning people pipeline.
Every organization that adopts cloud at scale hits the same wall: you can buy tools, you can rent accounts, but you cannot buy experienced SRE teams. You have to build them.
The CCoE model works because it creates a natural training ground. Engineers get exposure to multiple product groups, multiple cloud patterns, and multiple operational contexts — all within a team structure that has explicit teaching and enablement as part of its mission. That's harder to replicate in a traditional siloed IT organization where every team is too busy fighting its own fires to develop anyone.
We built three SRE squads from that pipeline — led by Nurit, Sreehari, and Eyal — covering the full product portfolio. At peak, the team was ~15 people with 9 active openings, reflecting the demand that the pipeline couldn't keep up with.
That's a good problem to have.
A functioning people pipeline doesn't just fill your SRE openings. It changes what your organization believes is possible with the talent it already has.
*If this resonates, the full CCoE narrative — 47 AWS accounts, four failure modes, and the migration that almost didn't happen — starts [here](/blog/ccoe-blog-post.html).*
---
Built on a home lab, powered by local models, and owned by Andrew Katana.
Built on a home lab, powered by local models, and owned by Andrew Katana.