Series
Why Engineering Teams Stop Shipping
Most teams do not fail because people stopped caring. They stall when complexity, process, and incentives quietly stop lining up.
- Part 1, The Complexity Tipping Point: when managing connections in the system crowds out the work of improving it.
- Part 2, Busy Is Not Shipping: the team keeps releasing features, but the problems people expected that work to solve are still there.
- Part 3, Where the Week Went: support, incidents, and other jobs fill the calendar, so planned changes barely move.
- Part 4, Who Reviews the Machine: AI coding tools move work faster, then more of it waits for the people who can check it.
- Part 5, The First 30 Days: how to bring those investigations together in the first month.
This series is complete. If the team has already stopped shipping, start with the landing page or Team Turnaround.
Parts in order
Part 1
The Complexity Tipping Point
Delivery rarely collapses overnight. Six months ago the team shipped in days. Now a small feature needs six meetings. Here is what a complexity tipping point looks like, and the first two weeks of work.
Part 2
Busy Is Not Shipping
The team keeps releasing features, but important customer and business problems remain. How small engineering teams can reconnect their work to the results people need.
Part 3
Where the Week Went
Six engineers, a full week, and very little progress on the work everyone agreed was important. How small teams account for support, incidents, and the other jobs that fill the calendar.
Part 4
Who Reviews the Machine
A small team starts using AI coding tools, and more work waits for review. Who has time to check the additional code, and what the first two weeks of that work look like.
Part 5
The First 30 Days
The first four pieces looked at different reasons a small team can struggle to ship. Here is how to bring those investigations together in the first month.