Fast Feedback

When thinking about improving effectivness, I look for suboptimal feedback processes. These are processes that take longer than necessary to make their outcome knowable. The motivation is not speed for speed’s sake, but speed to inform sooner and in smaller chunks. A feedback loop that returns quickly, loops more regularly, meaning it can provide value more often, but also in smaller, more understandable increments.

A clear example is the CI build for a software project. Used properly, these provide a single source of truth for the latest state of the application code. Does it build? Which areas have regressed? Where are there performance and security issues? All this information is extremely informative for development teams because it allows them to catch issues introduced sooner, typically before the build is even deployed to a shared environment. The sooner this information is known, the better, and it is even better if an individual build represents a single change to the codebase only (i.e. that builds are not batched) because this ensures there is a smoking gun should the build fail for any reason. The end result is feedback about regressions sooner than waiting for a deployment and feedback about what produced the regression more clearly than if changes were grouped. The CI build provides value more often, in smaller, more understandable increments.

This rapid cycle creates a flywheel effect whereby faster feedback encourages faster amendments, producing fast feedback, and so on, ad infinitum. Keeping up a high cadence leads to confidence in the feedback mechanism (because it executes so often), improved responsiveness to change and greater understanding of the forces in play driving such changes. These are never not good things. Some feedback loops must necessarily be slow, but wherever you find them it is worth looking at whether they could be feeding information back sooner than they are.