Centralising the Right Things
summary
Claim: centralise knowledge and coordination but not ownership. uSwitch moves from a three-week release cycle to continuous deployment, creates a small central team that builds shared patterns and self-service tooling (introspection APIs, deployment pipelines and migration helpers), preserves each service team’s architecture ownership, and measures success by fewer duplicate fixes (the same DB bug cost two teams a one-week duplicate outage). The result: faster feature flow, less repeated engineering, clearer company-wide visibility without taking ops from teams.
AI-written summary · about
chapters (18)
- 0:00Intro
- 0:11Centralising the right things Tom Booth
- 0:41Build a central team to empower and support others
- 1:45We weren't one business, we were competing functions
- 2:49Protectionism built through competition
- 3:46Operations would get the blame for developer problems
- 4:18Why did their change break my code?
- 4:57Getting features to our users was slow
- 5:22One team needs to own the whole service
- 6:01You have to embrace change
- 6:12Deploying continuously is better for users
- 6:24A team should own its own architecture and infrastructure
- 6:46Every team with their own direction, little shared
- 6:57Solving the same problems, in the same way with different implementations
- 7:56Change is complex because of poor architecture
- 8:43Retain ownership in the service teams
- 9:19Support common patterns with great tooling
- 10:01Give teams room to experiment, do what's best for them
related talks
21mTeam Ownership - Who Owns Production
34mYou only have to change one thing to do the DevOps
01h 01mRip It Up And Start Again?
58mMicroservices and the Inverse Conway Manoeuvre
18mManaging Change
26mThe Rise and Fall of Feature Teams
32mBalancing Service Centralisation &Team Autonomy in DevOps Organisation Anna McDougall, Andreas Prang
45mPeople and Culture