"Nobody asks the question that matters, which is: velocity toward what, exactly?"

"Every system has exactly one constraint. One bottleneck. The throughput of your entire system is determined by the throughput of that bottleneck. Nothing else matters until you fix the bottleneck. That's the part most people get. Here's the part they don't, and it's the part that should scare you: When you optimise a step that is not the bottleneck, you don't get a faster system. You get a more broken one. […] You didn't speed anything up. You created a traffic jam and called it productivity."

"I bet some of you are already living this. I've lived it. It sucked. Your developers are producing PRs faster than ever. Great. Wonderful. Gold star. Someone get the confetti cannon. Now those PRs hit the review queue, and your reviewers haven't tripled. Nobody tripled the reviewers. Nobody even thought about the reviewers, because the reviewers weren't in the vendor's slide deck."

"Reviews start getting rubber-stamped because there are simply too damn many of them to review properly. Someone approves a PR they didn't really read. We've all done it (don't look at me like that). It merges. CI takes 45 minutes, fails on a flaky test, gets re-run, passes on the second attempt (the flaky test is fine, it's always fine, until it isn't and you're debugging production at 2am on a Saturday in your underwear wondering where your life went wrong. Ask me how I know... actually,…“ 1/

„… don't). The deploy pipeline requires a manual approval from someone who's in a meeting about meetings. The feature sits in staging for three days because nobody owns the "get it to production" step with any urgency. Meanwhile, the developer has already shipped two more PRs. The queue grows. WIP goes through the roof. Everyone has six things in flight and nothing actually done. Cycle time (the thing that actually measures how fast you deliver value to users) gets worse.“ /2

"You are producing more code and shipping less software. You have made your situation measurably, demonstrably worse, and you have a dashboard that says productivity is up 40%. Congratulations. You've built a factory that's world-class at producing inventory that sits on the floor and rots. Someone's getting promoted for this."

"And here's the bit that really keeps me up at night: a lot of this AI-generated code? Nobody fully understands it. The person who "wrote" it didn't really write it. They prompted it, skimmed it, maybe ran it once. When it breaks in production at 2am, the person on-call didn't write it and the person who prompted it can't explain it. You've just increased the surface area for incidents while decreasing the number of humans who can reason about the system."

"So where's the actual bottleneck? If it's not writing code (and it almost never is), then where should you be looking? Walk the value stream. Follow a feature from "someone had an idea" to "a user got value from it." I promise the bottleneck will jump out and wave at you - it might even flip you off because you've been ignoring it."

"This is the one nobody wants to talk about because it's embarrassing. Your PM hasn't talked to a real user in two months. Your requirements arrive as a Jira ticket with three sentences and a Figma link to a design that was approved by someone who's never used the product. Your engineers are making fifty micro-decisions a day about behaviour, edge cases, and error handling that nobody specified, because nobody thought about them. And they're guessing."

"I once watched a team spend six weeks building a feature based on a Slack message from a sales rep who paraphrased what a prospect maybe said on a call. Six weeks. The prospect didn't even end up buying. The feature got used by eleven people, and nine of them were internal QA. That's not a delivery problem. That's an "oh fuck, what are we even doing" problem. And writing code faster just means you arrive at "oh fuck" sooner."

"When you speed up code output in this environment, you are speeding up the rate at which you build the wrong thing. You have automated the guessing. You will build the wrong feature faster, ship it, watch it fail, and then do a retro where someone says "we need to talk to users more" and everyone nods solemnly and then absolutely nothing changes. The bottleneck is understanding the problem. No amount of faster typing fixes that."

"The bottleneck is understanding the problem. No amount of faster typing fixes that."

"If you've ever seen a "quick fix" take nine days to reach production and lost the will to live somewhere around day six... yeah, that. The code was done ages ago. Everything after it was the bottleneck. If you want to ship faster, look at where things are waiting. Count the hours of actual work versus the hours of sitting in a queue. I guarantee the ratio will make you want to put your head through a wall."

"I can't count the number of teams I've worked with that were scared to deploy. Tests are flaky, observability is a mess, nobody trusts the canary process, and the last time someone deployed on a Thursday it ruined everyone's weekend. So what do they do? They batch changes into bigger releases. Which are riskier. Which makes deploys scarier. Which makes everyone batch more. Congratulations, you've built a fear spiral. Now add faster code output to this environment. More code, same…“ 1/

„… terrified deploy culture. The batches get bigger. The risk gets higher. The releases get less frequent. You have given a team that was already scared of shipping even more reasons to not ship.“ /2

"These are coordination problems. Human problems. Messy, political, nobody-wants-to-own-them problems. Writing code faster does precisely nothing for any of this. Zero. Your bottleneck is the org chart, and no amount of Copilot is going to refactor that."