Rapid feedback loops are what make good development teams. A feedback loop is ultimately a mechanism within a system to help achieve two main outcomes: more frequent iterations among team members and faster response times to requests. The goal of achieving these desired outcomes is to enable a learning culture and continuously remove bottlenecks. Author and researcher Gene Kim often says it best: “Improving daily work is even more important than doing daily work.”
Modern dev teams strive for Continuous Delivery because the quicker a team can get the code out, the faster it can shorten the feedback cycle. The faster a team member is given quality feedback, the faster they can iterate to improve the product being delivered. This is what high-performing engineering teams strive to achieve and when possible, to incorporate automation into their continuous improvement systems.
Recently, I was joined by some of the most prolific new names in software engineering – Charity Majors, the CTO and founder of honeycomb.io; Dana Lawson, the VP of Engineering at GitHub; and Kathryn Koehler, the director of Productivity Engineering at Netflix — for a discussion on continuous improvement. You can watch the entire discussion here: https://youtu.be/5sAJ3N6KNdQ.
During our discussion, we talked about creating continuous improvement in engineering organizations. We dove deep into feedback loops, the paved path methodology, and more. As an engineering leader, I heard a few key takeaways where all engineering teams can benefit:
The power of a 15-minute feedback loop
Short feedback loops are often the cornerstone that many great engineering teams are built on. While the goal of a 15-minute feedback loop may seem excessive, it’s important to remember that continuous improvement relies on ownership cycles and shipping code quickly and efficiently.
With a 15-minute feedback loop, the idea and context of code is fresh in an engineer’s mind when a problem arises, making it easier to identify the problem and find a solution. Without returning to a problem quickly, you run the risk of losing ownership within the release cycle. As you move through the release cycle, you start batching up other’s changes and shipping them together, resulting in the loss of an ownership cycle.
“If you have that rapid feedback loop, you have that original intent that’s fresh in your head, you know exactly what you’re trying to do, and why, and all the trade-offs you had to make. You can never get that back again. It starts to decay immediately as soon as you’ve switched your focus away from it,” said Majors. “If you know your code is going out within 15 minutes or less, you’re going to go look at it. If you know that your code and half a dozen to a dozen others might go out at some point in the next hour, day, or week, you’re not going to go look at it, right? The longer the feedback loop gets, the more stuff snowballs. The longer the interval, the more time you spend waiting on people.”
The paved path methodology
Similar to the desired outcomes of a 15-minute feedback loop, the paved path methodology can be the golden path to fast feedback. With the paved path methodology, engineers’ jobs and roles are streamlined to their subject domain expertise.
Koehler reiterated this when discussing engineering teams at Netflix: “Our whole goal with the paved path is to maximize developer efficiency. Can we build out curated components? Can we build out end-to-end experiences? Can we get people onto this superhighway that lets them move away from all of the different Netflix systems and everything that’s under the hood?”
As Koehler said, the paved path methodology is all about formulating a workflow enabling people to focus on their domain. Through this methodology, you rely on the experts and trust that each engineer takes ownership over their given domain.
“We have UI developers. We have back-end service developers. We want them to focus on what they know. We want to simplify,” said Koehler. “Enabling engineers to focus on what they do best not only ensures those who know how to get the job done are doing the work, but delights your engineers along the way. They get to do what they love and do it well.”
Learn from what other engineering teams are doing
Successful continuous improvement often stems from learning from others. However, it’s important to find a workflow that works best for your engineering teams. Sometimes a 15-minute feedback loop is possible but oftentimes it isn’t. “I dream of the 15-minute cycle, if that tells you anything. The reality of it is we have a huge, major scale, and we are a polyglot environment,” said Lawson of her engineering teams at GitHub.
What’s important is that you find a deployment and feedback cycle that works best for your teams, while enabling each engineer to own their work.
“You have to find what works for your systems and continuously improve it like you continuously deploy. You need to meet people where they’re at. You need to observe and look back and say, ‘Okay, what friction is really happening there?’ And then assess the risk of change.”
Long feedback loops can ruin everything
The truth of the matter is that long feedback loops can ruin someone’s day, even their lives. “Engineering should be a creative, fulfilling activity. If you’re on a high-performing team, you spend most of your time solving new and interesting puzzles that move the business forward every day,” said Majors. “The longer that feedback loop is, the more you can’t live up to that, and it just becomes a bunch of toil.”
One thing that these engineering leaders and I can all agree on is that engineers don’t get burnt out by shipping too much, they get burnt out by shipping too little. Creating systems that enable fast, quality feedback not only improves the lives of engineering teams but has them own the process and get excited about improving the quality of their work along the way.
