Individual engineers write code far faster. No organisational number moved that anyone could attribute to it. This is about the gap between those two sentences.
Sangeethkumar · engineering leader, AI platform
It deserves a real answer, and the honest one is uncomfortable: a great deal changed for individuals, and very little changed for the organisation.
Both halves of that are true at once, and holding them together is the entire leadership problem.
We failed all three — while the individual gains were completely real.
Automated review adoption went from a few per cent to most changes in two months — on one codebase.
First review feedback in minutes, where waiting for a human took most of a day.
Code written roughly three times faster.
The same tool, on another codebase, stayed near zero.
The difference was not the tool. On one codebase it ran on its own; on the other it was triggered by hand, with each person's own rules and context.
The gain leaks out before it reaches delivery.
An engineer writes code three times faster. Then it is validated line by line and waits for review. Everything downstream of writing got harder.
Speeding up a step that wasn't the constraint produces a happier engineer and an unchanged organisation.
One person, one workflow, no owner, no measurement, no obligation on anyone else. Valuable — and it stays where it started.
Owned. Measured. Documented. On by default. Something a new engineer inherits without being told.
Every engineer had individual practices, and none of them were systematised. That is not an adoption problem. It's a distribution problem — and distribution was the thing we did worst.
Agents propose. Evidence gates. Humans promote.
The same sentence governs the technical systems and the organisational ones, which is why I trust it. An experiment becomes a default when someone owns it, evidence supports it, and a person decides to promote it — not when it goes well for one engineer.
This ran through a period of turnover on the team.
Transformation programmes are run by the same people absorbing everything else. Any plan that assumes otherwise is fiction.
I built a capacity model projecting when the backlog would break. Two months later I checked it against what happened. The bug projection was over-pessimistic by more than twice over — the broader forecast, by about 30%.
The interesting part was why: the bug backlog improved because fewer bugs came in, not because throughput rose.
Had I only looked at the outcome, I'd have congratulated the team for something they didn't do.
Same thirty people. Different work?
That's the only question worth answering, and it needs a number rather than a story. If the same people are doing the same work slightly faster, we bought tooling. If they're doing different work, we changed something.
I'd genuinely like to know how other organisations are measuring this — because adoption dashboards answer a different question than the one leadership is actually asking.
shipscale.org · sangeethcloud@gmail.com