Looper

I'm sure there are people out there who can do things purely on faith. That have the conviction that the path they are walking is the right one and can use that conviction to just keep trucking along.

From my point of view those people are insane.

Whenever I do something, regardless of what it is, I want to know whether or not it was the right thing. At the very least, I want to know if the thing that I did created the effects that I desired.

I want a feedback loop.

Time Travel Hasn't Been Invented...Yet

The core idea of a feedback loop is simple:

• Do the thing
• Measure the effect
• Reflect on the result
• Repeat

In fact, it's so simple that you probably do it all the time without even realising.

But effectively using feedback loops can be tricky, which can be clearly seen when you look at two of the most common delivery methodologies.

The classic Waterfall model is filled with all sorts of feedback loops.

For example, in the planning stage, you gather requirements and then validate them through a variety of methods. You then use any new information gained to mutate or add new requirements until you reach a point where you are comfortable enough to move forward into implementation.

That sort of requirements elicitation feedback loop is pretty textbook, but it's also widely regarded as ineffective. The validation mechanism, the part where you measure the effect, is ephemeral. The people who you're building the system for are not actually using it, so any feedback that you get is questionable.

In fairness, it's better than nothing, but it does show that there is some subtlety to effectively using feedback loops.

The Agile model also has a number of embedded feedback loops, but it uses them differently. It focuses on the actual delivery of working increments that the user can engage with to provide feedback and inspire improvement.

It tends to deliver much better outcomes, but has challenges of its own that I'm not going to get into.

The difference between the two models is subtle but important; feedback loops are effective when they are short and when it's easy to draw a line between action and results, such that you can effectively reflect on that relationship and adjust as appropriate.

30 Years Is A Long Time

In my experience, as you become more and more senior in a role, whether it be management or engineering, the feedback loops that you participate in get longer and longer.

This is challenging, because it means that the lines between your actions and the effects that they create get harder and harder to reason about, which makes it more and more difficult to figure out if you need to adjust.

When I was a novice engineer, my feedback loops were quick. I would have a hypothesis about what I'd need to do to implement a feature or fix a bug, I'd write some code, then I'd know whether or not it was working thanks to the magic of tests or manual validation.

It was nice.

As I became more senior from an engineering point of view and started being responsible for larger and larger pieces of work, the lines started to get pretty fuzzy.

I'd make a diagram describing an overall flow or create a series of tickets to breakdown a large task into smaller, more digestible pieces and then wonder whether or not I'd actually made a difference. Whether I'd progressed towards that high-level goal.

It wasn't impossible, it was just harder to reason about.

When I became a manager, it became even worse.

As a manager, you might have a high-level goal of growing a person in a particular direction, helping them to mitigate their weaknesses or perhaps amplify their strengths.

Over a period of time, you might have hundreds of small and large conversations to that effect, engineer certain opportunities, provide feedback and so on, but it's incredibly hard to really know whether or not you're actually making a meaningful difference.

Frying Your Brain Like An Egg

In what is fast becoming a theme for these blog posts, I don't really have any rock-solid solutions to the problem described above.

I do have reflections though, so strap in.

One reflection is that not everything needs to have a tight feedback loop. It's hard to come to terms with this one, considering I just wrote a few hundred words about why feedback loops are critical, but bear with me.

When you have no feedback loops, no proof that what you're doing is making a difference, it's easy to get disheartened and demotivated. But it only takes a few victories to buoy you up. If you can establish a few things that do have good feedback loops, then you're going to be able to use the momentum from those things to help with everything else.

Or at least that's how it works for me anyway.

I used to get this by pairing with my direct reports on things they were working on, thus living vicariously through their victories. I don't have time for that anymore unfortunately, but maybe one day.

The second reflection is that long feedback loops can still work.

Yes, short feedback loops are hard to deal with, because the lines that connect effort with result are difficult to see. But if you manage your large pieces of work well, by establishing the problem or opportunity clearly and defining good success criteria, you can still get that do -> measure -> reflect -> adjust cycle going.

This doesn't really work for the people side of things, where the problem or opportunity and the measures of success are much harder to quantify. Managing people is a whole different ball game compared to delivering something.

The last reflection is something that I still struggle with; sometimes you just have to believe.

The reality is that sometimes you really do just have to have faith that you're headed in the right direction. That the sum of your experience means you're making a difference.

The most important part of this reflection is that when you do see success in those hard to reason about areas (like a person improving professionally) and you were even vaguely involved, you can take that as a victory. Even if you can't prove it objectively, so you might as well try to bask in that goodness.

It's Called Closing The Loop

If I was capable of being really meta, I would just take this blog post, publish it, get feedback and then write another blog post on the same topic to see if I could do it better.

Which is exactly what I do for every single blog post that gets published here.

I write a draft, push it to a trusted person to read, they give me feedback and then I rewrite the post taking that into account along with any evolutions around my own thinking.

Terrifying right?

These posts have already gone through at least a few cycles before you see them.

Imagine how bad they must be in first draft form.