Feedback Loop

Over the past few weeks, I've been reading "Thinking in Systems" by Donella Meadows. One of the mental models that I've reflected on is about feedback loops and how it is relevant to our work. 

The concept of a feedback loop in systems is fairly simple, as in the attached photo: you do something, measure the outcome, analyze what leads to the outcome, correct the mistakes, then repeat the action. The biggest problem to deal with is system delay: when there's a significant delay between the first action, the first measurement, and the updated action, oscillation happens. We either commit too little action or too much, which both lead to undesirable results. An analogy and a concrete example can help to understand this.

Analogy: Imagine you are taking a shower and you want the perfect temperature for the water. But your hot-cold water mixer is quite far away from the showerhead. What's going to happen is that there will be a few seconds' delay after you turn the knob before you can sense the temperature change. You first turn the water on - too cold! So, you turn the knob all the way to the hot side, hoping to get warm sooner, but it quickly becomes too hot. So you turn the knob again towards the cold side, and a few seconds later, it becomes too cold again. You constantly cycle through too hot and too cold, tweaking the knob many times before it finally feels right. This is a feedback loop, system delay, and oscillation all explained.

Concrete Example: We want to build something for the long-term, so we need to build a team to execute it. Since at the start, there are definitely not enough people working on it, we need to grow the team via hiring. So, we open lots of headcounts and hire many people, and that takes time. By the time we can finally measure progress, we find that we have too many people working on the project and the fragmentation, management, and communication overhead are counterproductive. So we decide to scale down aggressively to cut cost and inefficiency, but after another period, we find we are short-handed again. How much we should scale back and when becomes the core problem. This is the same concept that happens very often in our work.

Now we know the problem, how do we address it though? Well, as with any complex problem, there is no silver bullet answer. Instead, I've reflected on a few useful points.

Short feedback loop != short-sighted

Shortening the feedback loop is obviously the first-principle solution, but what matters is how, especially for long-term R&D projects. My thought is that we should set up short-term proxy goals so that we have targets to measure against. Those proxy goals are not there to be hit, and hitting them doesn't mean we've made a significant impact. The proxy goals are there to provide feedback and validate that we are taking the right steps. 

Small razor experiments are good examples. They are necessary but by no means sufficient. For example, in the early development of an object tracking system, we've set up a 1-object goal for the team. It follows the principle that if we can't get this one easy objective to work, then the whole technical path is a dead end. However, even if we make it work, it's just one baby step towards the long-term. This proxy goal helped the team to close the loop very rapidly and made progress.

Constant Feedback vs. Constant Intervention

There is a very subtle difference between feedback and intervention. Feedback is about measuring the current state of the project: whether it's good or bad, on the right track or not, and how far away we are from the desirable path. Using the analogy above, it's about whether the water is too hot or too cold, and how much hotter or colder it should be. Intervention is about making a suggestion on taking actions, what we should do given the feedback. Again, using the analogy above, it's about how much we should turn the knob.

Putting it into the perspective of our R&D work, the leadership should provide constant feedback to all the projects they are overseeing, and the team should seek feedback as needed, as often as possible too since this helps the team understand the state of their current project. However, we should avoid having leadership intervene or the execution team asking for intervention at a high frequency. Whoever is executing in the project has the best knowledge of how the knobs function; therefore, given the feedback, they are best to turn the knobs.

Skin in the Game

This is highly related to the previous point. Decision-makers in the project need to have skin in the game. This is not some "abstract leadership principle". Under the feedback loop mental model, when a decision-maker is distant, a few layers removed from experiencing the consequence of the decision, they can't adjust the action in the correct direction. 

Using the analogy above, if the decision-maker, the person who is responsible for turning the knob, is not the one standing under the shower, they are not measuring the temperature through their own skin. Instead, they are relying on a few other people standing under the shower and telling them it's too hot or too cold. This creates various problems like "who should the decision-maker trust?" "how much should he/she turn the knob given various measurements?" "what if the decision-maker just turns it all the way to hot and doesn't care about the ones who are under the shower?"

Why All-Hands-On-Deck Works?

Tying it all together: looking back at the work that we have achieved in the team, there is an interesting reflection: all-hands-on-deck seems to work very well. There are various projects in the past six years where either Richard or I have called all hands on deck, and they turned out quite stressful but ultimately successful. The above three points to some extent explain the reason:

• Short feedback loop: when doing all hands on deck, they are all short sprints, and progress is measured very frequently.
• Constant feedback: there is always one person leading the short sprint execution, and they are constantly getting feedback from the leadership. We are also quite hands-off on how the team is approaching the problem as long as the goal is hit.
• Skin in the game: needless to say, whoever pulled the all hands on deck is spending their leadership capital and has their credit on the line - "so we are all under the shower."