What Is the First Way of DevOps? Optimise the Flow

The first way to introduce DevOps is to optimise the value flow from development, through operations, all the way to the customer. This is the First Way in Gene Kim’s Three Ways framework — and it is where every transformation should start.

Value Lives at the Customer

#

The thing to internalise is this: value only exists when the customer can use the feature. Code on a developer laptop is not value. A merged pull request is not value. A binary in an artifact registry is not value. The full distance from “we had an idea” to “the customer is using it” is the value flow, and the goal of the First Way is to make that flow as fast and predictable as possible.

If a feature takes six months to travel that distance, you have a flow problem. The fix is not to push developers harder. It is to look at the entire pipeline — handoffs, queues, approvals, environment provisioning, deployments — and remove what slows the flow down.

Make the Work Visible

#

You cannot improve what you cannot see. The first concrete move is to make work visible across the whole value stream. Every piece of work in flight, in every stage, on a board everyone can look at. Not just dev tickets — also ops tickets, deployment requests, change approvals, security reviews. The moment you see it all in one place, the bottlenecks become obvious. There is always a column where cards pile up.

This is also where the cultural shift starts. When dev and ops see the same board, they stop optimising their local queue and start thinking about the system.

Shrink the Batch Size

#

Big batches are slow batches. A release that bundles 80 features takes longer to test, longer to deploy, longer to debug when something goes wrong, and longer to roll back. A release that contains one feature is fast on every one of those dimensions.

Shrinking batch size is the single most powerful flow lever you have. Smaller commits, smaller pull requests, smaller deployments, smaller releases. As batch size goes down, lead time goes down, quality goes up, and the team’s confidence goes up — because each change is small enough to reason about.

Shorten the Work Intervals

#

Alongside batch size, look at work intervals. How often do you deploy? How often do you release? How often do you run the test suite? If the answer is “weekly” or “monthly”, every interval is a queue where work waits. Shortening the interval — daily deployments, continuous test runs, on-demand releases — converts those queues into flow.

This is what makes deployment a non-event. When you deploy ten times a day, deployment becomes routine. When you deploy once a quarter, deployment becomes a high-stakes ceremony with a war room and a rollback plan.

Quality at the Source

#

Optimising flow does not mean cutting corners. It means putting quality where it belongs — at the source. Automated tests, code review, static analysis, security scans on every commit. The cost of catching a defect at commit time is minutes. The cost of catching it in production is days, plus the customer cost, plus the trust cost. Flow gets faster precisely because quality is built in from the start, not bolted on at the end.

Key Takeaways

#

1. Value lives at the customer, not in the repo. Optimise the whole distance from idea to customer use.
2. Make work visible across the entire value stream. Bottlenecks hide until everything is on one board.
3. Shrink batch size aggressively. Smaller commits, smaller deployments, smaller releases — every dimension wins.
4. Shorten the intervals. Frequent deployments make deployment routine. Rare deployments make it dangerous.
5. Build quality in at the source. Faster flow only works if defects do not flow with it.
6. The First Way prepares the Second. You cannot have meaningful feedback (Second Way) until value actually flows.