Delivery friction

Friction hides around the change

A pull request can look small while the work around it is expensive. An engineer may spend time finding a reliable environment, asking who can approve a change, rerunning a flaky check, or reconstructing an undocumented dependency. The repository records the eventual change but may not record the effort required to reach it.

Delivery friction can be technical, procedural, or social. Examples include slow builds, unclear service ownership, excessive approval paths, unstable environments, missing context, and handoffs between teams with different priorities. The same friction can affect new and experienced developers differently.

Measure a specific source of friction

Start with a boundary such as time to first review, build queue time, time waiting for an approval, or the number of times a change is reopened. Pair the measure with the outcome it is meant to improve. A faster approval is not useful if it increases escaped defects or creates more rework.

Use distributions and examples. Average waiting time can hide a small group of very old changes. Surveys and interviews can identify friction that event data cannot see, while event data can show whether a reported problem is isolated or recurring.

How Weave can help

Weave helps teams move from a delivery trend to the pull requests, reviews, quality signals, and work patterns behind it. That creates a better starting point for an improvement conversation without treating one friction measure as a judgment about an individual.