When your pipeline is fast and your product still isn't

The last time I tuned a CI pipeline from twelve minutes down to five, I felt like I'd earned my paycheck for the quarter. Then a PM told me that the feature we were racing to ship had been in prioritization discussions since April. It was August. My five minutes suddenly felt smaller.

I thought about that conversation while reading Brad Nelson's piece on DevOps.com, "DevOps' Three Ways Were Never About Tooling." Nelson, who wrote "I Think, Therefore I Know: Scientific Thinking for Unscientific Organizations" and co-hosts The Agile for Agilists podcast, has a blunt argument. The community that reads a site like this one (and yes, I mean us) has been reducing DevOps maturity to a CI/CD scoreboard, and he thinks we are grading the wrong test.

The argument, in his words

Nelson walks through the original DevOps canon: Flow, Feedback, and Continual Learning. His claim is that each was written to apply to the whole system that turns an idea into revenue, and each has been quietly narrowed to the slice an engineer can see from their laptop.

On Flow, he asks a question I have been unable to shake: "what does the movement of value look like from aha to ka-ching?" His example, borrowed from Mik Kersten's "Project to Product," is a Nationwide analysis showing that only 2.5 percent of a 120-day end-to-end flow lived in development. If that number is anywhere near right for your org, adding engineers to speed up code is optimizing the least of it.

On Feedback, Nelson is stricter than most CI/CD writing I read. Value can only be judged by the customer, he argues, so an internal loop, however fast, is not the loop that matters. He cites the familiar research (Pendo, Standish Group, Microsoft, Google) that around 80 percent of shipped features are rarely or never used. Fast delivery of the wrong thing is a more efficient way to be wrong.

On Continual Learning, his framing is that feedback without a behavior change is a report, not learning. Every roadmap, he writes, is a stack of hypotheses until a user gets near it.

Where the DX crowd should sit with this

I want to defend our patch of ground for a moment. Faster pipelines are a component of Flow, not a distraction from it, and it is much easier to measure a build queue than a boardroom. But Nelson is landing a fair blow. Every deploy-frequency chart I have ever presented has treated "deploy" as the finish line. The customer meeting the change is the actual finish line. Deploy is a checkpoint on the way there.

Where I would push back a little: the CI/CD scoreboard is not only vanity. When my team's median PR-to-main dropped under an hour, product started proposing smaller experiments, because the cost of trying one had collapsed. Fast pipelines change what leadership dares to attempt. That is Flow too, even if it is downstream of the interesting decisions.

The verdict I'm sitting with

Nelson does not hand you a Monday morning to-do list, and I think that is honest, because the answer depends entirely on where your 120 days actually live. If most of your lead time is in a build queue or a flaky test suite, keep tuning. You will feel the difference on your next PR. If most of it is in a prioritization meeting that reconvenes every two weeks, no runner upgrade will save you. It is a product problem wearing a pipeline costume.

What I am watching next: whether the platform-engineering movement, which has spent a couple of years building golden paths for engineers, starts building the equivalent for the product-decision loop. That is the part of the pipeline no one has a Grafana dashboard for yet, and it is the part Nelson is asking us to look at.