Feedback Loops

Positive feedback loops, compounded over time, are a daunting opponent. It’s very difficult to get ahead of another team that is constantly improving.

When we apply the lessons we’ve learned in the past to the things we’re working on now it creates a momentum that quickly becomes a driving force.

When we measure the things that matter most we have a much better foundation to base future decisions on.

When we leverage the experience of all of the other people we work with and, more broadly, with everybody who is willing to help, the result can be much greater than the sum of the parts.

The key that unlocks all of these things is when outputs become inputs.

But, it turns out, while this theory might be obvious, it’s much harder to achieve in practice. Why?

Three Perspectives

There are actually three very different perspectives we need to consider when thinking about feedback: ¹

Firstly, we need to start with the objective results.

We need measurements that record the outcomes empirically - ideally these will be clarity metrics, which are actionable because they highlight trends in our performance and help us to decide what to do differently in the future, rather than vanity metrics, which make us feel good but don’t really teach us anything useful.

It’s common to feel completely overwhelmed or outright misled by data rather than to feel informed or driven by it. But there is a process we can follow to get better.

Secondly, to complement data, we should also consider subjective perspectives - both internal and external.

We need to seek out those who can give us an external perspective and identify our blindspots. Ideally this is somebody with enough distance from the risks and rewards of what we’re working on, so they are not distracted by those things. And, at the same time, somebody who is close enough, experienced enough and trusted enough that we pay attention whenever they say “I noticed…”.

But perhaps most importantly we need to be completely honest with ourselves about our contribution vs. taking credit for the things that just happened to us. It’s too easy to hold onto the things that we hope and dream might be true, and in the process deceive ourselves about what’s actually working. This is especially true when we are just getting started on something new, when there is necessarily a big gap between what we want to project to the world and our internal reality. Ignoring the aspects that only we can see makes it much harder to close that gap over time.

Considering our performance from all three of these perspectives means we’re more likely to see the full picture of what’s happening and why. Then we can ask better questions about what we should do differently in the future.

Don’t Look Back In Anger

One of the most important skills for any team to learn is how to review.

If we can develop a habit of consistently and regularly looking back at the work we did, asking what results we got and what we want to do differently next time, then we have the important elements required for improved performance.

Most teams are familiar with the idea of a debrief when something has gone badly wrong. But that’s a common mistake. Actually, research suggests it’s much more useful to make this something we do all the time, and especially when something has gone well.

For example, an executive team or board might have a brief review at the end of every meeting. Doing that consistently makes it part of a normal process, rather than something to be anxious about on the rare occasions when it happens, and also less likely to be skipped. It makes it much more likely that little misalignments are identified immediately and corrected before they have a chance to fester and grow into something more serious.

Sometimes results go our way, which is great. But unless we take the time to know why, the next time, when they don’t, we won’t know then either. We will be literally hoping for the best.

So, how do we review?

(I’m using “review” rather than “debrief” here intentionally to acknowledge that there is a wide spectrum that can fall under that label, from a quick huddle after a meeting to reflect on what just happened all the way through to a more formal and independent inquiry that investigates the outcomes and root causes.)

Start with some simple open-ended questions: ²

• What went well?
• What didn’t go well? (we should focus on what happened, rather than who was at fault)

Then, go a bit deeper:

• What was surprising or unexpected?
• What missing information created this mismatch?
• What did others do or not do that we didn’t anticipate? (both good and bad)
• How did we respond? (again, both good and bad)

Finally, the most important question:

• What did we learn?

(Please call them lessons rather than learnings! 🙏)

One Step Ahead

But, why wait until after the fact to ask these questions?

It’s even more impactful to consider them in advance and try to anticipate.

It’s often difficult to keep in mind the small number of things that are critical to performance, especially when we’re talking about things we do all the time: team meetings, sales calls, standard procedures etc. And this is accentuated when it’s a diverse team with potentially conflicting objectives.

If we can take time in advance to say the things we are worried about, out loud, in front of our teammates (including all of the things we might be thinking but are generally too afraid or polite to articulate), then that can help to create a shared understanding and, sometimes, real clarity about the things that will make a difference to outcomes while there is still time to influence them.

So, how do we anticipate? It requires some imagination.

First, imagine that we didn’t achieve our goal:

• What explanations or excuses would we give? (we could call this a “pre-mortem”)
• Who else or what other event would we blame for our failure?

Then, and even more importantly, imagine instead that we have achieved our goal:

• What are the things that we will say contributed to our success? ³
• What are the things that we controlled and will get credit for vs. what just happened to us?

Based on these answers:

• What are the things we can do or be right now to minimise or accentuate these things, to increase the chance of success and decrease the chance of failure?

We don’t need to wait for things to happen to us. We can review and anticipate and in the process create the lessons that we can then apply to our work to give our teams the competitive advantage that comes with a growth mindset.

Give & Take

Giving feedback is a delicate art. Whenever we share our perspective, we tread the fine line between helping shine a light on blind spots and highlighting uncomfortable weaknesses.

Receiving feedback is also a skill we can develop. Part of constantly improving is learning to listen without immediately needing to respond - either to deflect or fight back.

For example, here is a common pattern (once you know it you will see it everywhere):

Person A: “We need to do X”
Person B: “Umm, I can see some problems with X”
Person A: “Well, what are you going to do about that?”

If we insist that every observation from somebody reviewing our work comes with a proposed solution, we’ll get given far fewer observations.

If responsibility for fixing things that are shown to be broken always falls to the person who reports the issue, eventually nobody will report issues.

It’s unlikely that the person giving this kind of feedback is the best person to solve the problem they are describing anyway. Identifying problems and solving problems are different skills (remember evidence is the key to identifying problems, experiments are the key to solving problems etc).

Ultimately we all need to solve the problems with our own work, by experimenting with possible solutions and seeing what results we get. Simply acknowledging there are problems when they are pointed out is better than immediately trying to hand that work straight back to the person trying to help.

Or, another variant:

Person A: “I’m doing this new thing Y”
Person B: “Ooh, interesting. I’ve thought a lot about Y. Here are some of the challenges I see with that solution…”
Person A: “Why are you always so negative? I only ever hear you criticise. Can’t you just say something constructive for once?”

If we take every piece of feedback as a chance to start an argument we’ll get less feedback.

Perhaps the person giving feedback intends to offend, but probably not. I’ve found it’s nearly always better to assume the best in these situations. We need to try and reframe from feeling hurt by “negative feedback” to consciously seeking out “useful friction”.

It’s very difficult to find the balance between being delicate with new ideas, so they have an opportunity to grow and develop, and being brutal with new ideas, so they are tested and challenged.

What do you need, right now?

What makes us more uncomfortable: the possibility that we might be wrong, or the experience of having somebody show us we’re wrong? I think for many people it’s the later.

Often the reason receiving feedback makes us defensive is simply related to timing. Just being more explicit about the sort of feedback that is useful at each stage can make a big difference:

In the early stages, when all we have is a rough idea, feedback on the concept is valuable but feedback on the polish is premature. Ask for 30% feedback.

Later, when the idea has been developed but still has rough edges, feedback on the details is useful but feedback on the foundation is too late and so more likely to be annoying than productive. Ask for 70% feedback.

Finally, we eventually reach a point where feedback is no longer useful. When we want praise rather than feedback we should just say that. Anybody on the team who (like me) struggles to see when something is good enough will appreciate that. Ask for 100% feedback.

This is something that a team can work together to do better.

When we are more explicit about the type of feedback we want at the time we share our work, we are more likely to get useful suggestions that improve the work.

And this itself creates another positive feedback loop - the more we see the things we’re sharing improved by feedback we get from others, the more willing we become to share in the future.

If we get this right we create an environment where everybody in the team is much more willing to share work-in-progress at a point in time where it can actually be improved. Then we give ourselves the chance of creating something that is really great.

Related Essays