5 parts
Why Engineering Teams Stop Shipping
A five-part series on the tipping points that freeze delivery, and the first month of work that restores cadence.
Open series →Journal
Featured series
5 parts
A five-part series on the tipping points that freeze delivery, and the first month of work that restores cadence.
Open series →Latest posts
The ERC-8427 repo now tests spend grants with Safe, ERC-4337 accounts, ERC-8004 agent identities, and ERC-7710 delegations, proposes a mapping for x402 payments, and an outside developer has built an order-amendment experiment on it. What each one does, and how far it has been tested.
Read essay →ERC-8427 lets an account owner register capped, revocable spending of ETH and tokens for a delegate, with per-payment, rolling, and lifetime caps. Where it helps and why.
Read essay →Canton's token standard can show a lock, but not a standard way to release on a condition. A draft interface, reference implementation, and ask for builders who need it across registries.
Read essay →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.
Read essay →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.
Read essay →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.
Read essay →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.
Read essay →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.
Read essay →