Graham McNicoll

Software teams get measured on delivery speed. It's an easy thing to track, it fits neatly into a sprint review, and it makes the leaders feel like things are moving. The problem is that you can move very fast in the wrong direction. I spent thirteen years watching teams hit targets and still ship products that didn't move a single metric. On-time delivery is fine. It just doesn't tell you whether what you built was worth building. The metric that actually matters is learning rate. How quickly can your team go from an idea to evidence? How quickly can you learn where you should invest your time? How many experiments do you run in a quarter? And when one loses, what do you do with this information? Every idea should become a falsifiable hypothesis before anyone writes a line of code. Agree on the metric that would indicate success or failure. Build the smallest thing that tests it. Then go into the results genuinely curious about what you find, because a test that loses often tells you something more useful than one that wins. That's experimentation-driven development. The goal is to shrink the loop between idea and evidence as fast as possible, and to keep learning from every result regardless of the outcome. If your team is shipping a lot and learning a little, DM me.

Only one snapshot so far — the engagement-over-time curve appears once the daily scrape has captured this post at least twice.