The Project
I started with one systems team and a scope that kept widening. Over time I grew that single team into dedicated DevOps, systems engineering, database, and SRE teams. The part I care most about isn’t the boxes on the chart. It’s that every one of those teams started with a lead, hired or promoted alongside it, so ownership never had to route through me.
Structure follows the work
The splits weren’t an org-design exercise. Each one happened because a kind of work had become distinct enough to deserve its own owners, and because responsibilities across our engineering groups no longer matched where the strengths were. So I reshaped the boundaries until they did.
An SRE team built around responders
The SRE team is the clearest example. I didn’t start from a job description. The strongest incident responders were already visible in how they handled real events, so I formed the team around them and made the role official. That gave incident response a home, and it gave those engineers a path that valued what they were already good at.
Developing the people, not just the structure
Structure only holds if the people in it keep growing. Engineers I’ve managed have grown into leads, managers, and architects. That growth happens in the steady work: weekly 1:1s, coaching, career development, and working through interpersonal and cross-team conflict when it comes up. The payoff is execution that stays team-owned rather than manager-driven.
Wrap Up
The test I hold myself to is whether the teams run without me in the middle. Structure that matches the work, leads who own delivery, and people who keep growing into bigger roles: that’s what lets me spend my attention on direction instead of dispatch.