To most, “closing the feedback loop” may sound like nothing more than management jargon. As a matter of fact, it is. But behind every management buzzword, there usually lies a simple truth that we could benefit from paying a little attention to. This is the second of a series of articles related to feedback loops and how to make sure we close them. Here’s a link to the first article which talks about closing the loop in the context of products.
The feedback loop is relatively short on products. In the building phase, your toolchain instantaneously lets you know if your software built correctly. A product out in the market will usually get you feedback in a matter of days or weeks through actual usage stats and customer reviews.
With processes that define the way we work, the loop typically takes quite a bit longer. That additional review step, for instance, might seem like a good idea now, but it could lead to a late delivery months down the line. Likewise, you probably won’t know how much it improves quality at least until the software has been in the market for some time. Even then, it’s not easy to figure out what exactly caused the improvement.
I can attest it gets stressful not having that level of clarity when it comes to the impact of your work. There’s no doubt that it’s important work though and it’s crucial to close the loop on this. (If you pay close attention, you might even manage to shorten it.)
Closing the loop on process improvements
If you’re in the business of improving work processes, here are a few ways to close and possibly shorten the feedback loop on the initiatives you pursue.
I’m not a big fan of ISO standards in the context of software development. In my experience, there’s a certain level of low-value bureaucracy that becomes necessary when we try to meet these standards. But there is a concept that’s highly emphasized in ISO 9001 called “PDCA” or “Plan-Do-Check-Act”, which I feel is a very fundamental and universal way to look at process improvement.
It’s basically the scientific method. Plan what needs to be done, do it, check how it went, and make adjustments. When planning process improvements, it’s important not to miss the “check” part as this is basically what closes your feedback loop. It’s important to establish from the beginning how you can tell whether your initiative worked or not. The earlier you identify it, the earlier you’ll detect signs of its impending success or failure.
Once in an audit, we were demonstrating to the auditor the life cycle of a customer claim (i.e. a bug in our software). We showed him the original support ticket, the fixed custom version we provided to the customer, and the release note that indicated it being included in our market release.
The auditor’s question was simple enough, “Where do you track which of the support tickets need to be included in the next market release?”
This got us scrambling for a moment – enough to call in several of the software developers who we hoped would have a better idea. In the end, we found a list in a shared OneNote inconspicuously labeled “for release” that included the ticket number of the claim we were looking at. That, at least, was good enough for the auditor.
A lesson was learned. Being able to trace how work flows from each input down to every output is essential in closing the feedback loop on processes. Any discrepancies, such as an output coming apparently out of nowhere or some inputs not actually mattering in the end product, may indicate a flaw or inefficiency in your process. Realizing these gaps makes it possible to quickly identify and address problems.
Objectives and Key Results (OKRs)
I’ve been reading about Objectives and Key Results (OKRs) lately, in the seminal book by John Doerr called “Measure What Matters”. OKRs were a concept developed at Intel that soon became a mainstream movement in Silicon Valley thanks to its adoption by Google, among others.
Simply put, you set an objective that you want to achieve, and you set key results to determine whether you’ve achieved it. Then you track for accountability. It’s “PDCA” in a super simple form.
I see OKRs as a great way to shorten (or at least control) your feedback loop on processes. When you set out to do something and you’ve got a few time-bound and measurable results you can check along the way, you’ll avoid getting caught by surprise by the ultimate effect of your work. Each key result assessed closes the loop just a little bit more.
Improving processes is an important aspect of a manager’s job. The products you make are only as good as the processes that create them. It can be scary to push changes in how people work, especially knowing that the positive and negative effects of it will not immediately be apparent. With due diligence though, you can close the feedback loop a little at a time. It won’t be the same black-and-white feedback you get from, say, a compiler, but it will likely be something actionable in any case.
In my next “Closing The Loop” article, I’ll be talking more about how closing the loop applies to people. In the meantime, I’d love to hear about other ways you might be applying the concept in your work with processes, so feel free to leave a comment or drop me a line.
If you’re interested in learning more about OKRs, I recommend buying the e-book of “Measure What Matters” from Amazon.
Dexter is an engineering manager at Synacy, a co-founder of ATeam Business Software Solutions, and founder of TechManagement.Life. He loves to share his experiences and thoughts on managing software teams and running businesses.