Squeezing the Feedback Loop

How many cups of coffee have you made while waiting for code to compile? While waiting on team members to complete reviews; changes to deploy; user analytics to start rolling in?

I love coffee as much as the next developer. Maybe even a little more. But I’d rather enjoy it in the morning, on the weekend, at a sun-touched cafe with a friend. Coffee at the cost of a flow state has always been bitter to my tastes.

Atlassian’s Rajeev Rajan feels similarly, offering up “joy” as the watchword for more productive developers:

If you constantly have to work around sub-optimal systems and missing information as you code, productivity and creativity suffer. Conversely, being in a state of frictionless flow sets up a virtuous cycle. You’re working quickly, you feel good about what you’re building, and you’re happier as a person. This allows you to pour more energy into the creative aspects of development, as opposed to being frustrated by speed bumps.

And nobody likes speed bumps. The challenge with eliminating them, though, is that they often exist for good reasons.

• Blocking code review may be a required step for compliance
• Deployments subjected to layers of vulnerability scans will take longer than a git pull from an ad-hoc SSH session
• And customer data may not be flowing because a still-in-progress feature hasn’t been flagged for release in production

These matter less for a pre-product startup than an enterprise in an intensely regulated industry, but the point is that collaborative enterprises will always have their checks and gates. A completely frictionless experience is out of reach. But there is a principle we can adopt to maximize the time and energy directed into Rajeev’s virtuous cycle.

One system design principle

Good decision-making depends on adequate information (rarely complete, but always more than none at all), and the information available while waiting on a feedback loop is by definition outdated. Any actors waiting to integrate new information into their work must now wait until it becomes available. They’ve now entered a blocked state–the worst sort of speed bump–until the loop returns and their work can proceed.

Keep feedback loops as tight as possible. That’s the principle. Whether feedback comes in from a compiler, test suite, teammate, or third party, the closer it is, the happier everyone will be. The principle holds whether you’re measuring distance in time (when will our vendor have the integration ready for test?) or space (do I have the tools/knowledge/access I need?), and hints at a neat basis for diagramming, understanding, and optimizing feedback loops of all sorts.

Consider, for example, how the frictions sampled above are also inputs to concentric feedback loops within a typical development lifecycle:

• Does the code meet team standards? (change is accepted by team)
• Can it be deployed to a production environment? (change is running in production)
• Do customers even like it? (change is valuable; let’s expand access to a broader audience!)

We could draw smaller loops inside the local development process, too–configuring development environments, translating the spec into code, waiting on static analysis tools, running tests, preparing resources or schema changes, and so on–at each step, and especially those taking place more frequently, faster feedback makes for happier employees and faster value delivery. Some steps will be easier to measure than others. Whether easily quantified or not, and whether inputs are “formal” (in the sense that backpressure and re-entrancy have clear definitions in a business process) or merely implied (customer churn after a price hike, or employee departures following an RTO announcement), the same abstraction holds.

And the benefits of tighter feedback loops aren’t limited to development teams, either. None of the human agents inside a complex system particularly like waiting, context-switching, or a frequent sense of yelling into the void. The sooner an actor can act on feedback, the better the cumulative results–and the happier they’ll be.

Tightening loops organization-wide

Tighter feedback isn’t all about happier people, either. The longer information is stuck in a feedback loop, the less relevant (and more potentially distracting) it becomes. Imagine going on vacation without a weather forecast. Should you pack a swimsuit or a winter coat–maybe both? Since the plane won’t wait, your first hint of whether you’ll be sweating under your parka or shivering in your shorts (or lugging around too much luggage) will only come once you arrive at your destination–by which point it will be too late.

Organizations run on timely, actionable feedback. When it isn’t available, actors have two courses of action:

1. Keep waiting
2. Flip a coin and hope for the best

Neither option encourages continuous learning or a culture of accountability. Both illustrate how loose feedback loops limit responsiveness, iteration, and predictability. And though loose feedback may temporarily mask behavior, it won’t change it: a bug tucked away inside a production release will still wreak havoc no matter how long the deployment takes.

On the other hand, understanding and organizing around feedback loops makes it easy to understand and address places where slow feedback–from colleagues, tools, customers, or all three–is holding back actors from making needed decisions. A feedback lens can help identify timesinks (holy wars over linter rules) and make the case for solving them (adopting a code formatter).

The cycle length will vary with role and task–senior leaders should be used to months-long feedback loops!–but the principle applies everywhere. Keep feedback loops as tight as possible. And help everyone, as Rajeev says, work quickly, feel good about what they’re building, and be happier as people.