Building resilient software through triple-loop learning

Get briefed on the learning modality that can help you stay on top of complex software systems

👋 Hey, Ash here! Welcome to this week's instalment of the Cruform newsletter. Each week I look into a topic relevant to how production software work gets done.

I bring particular attention to issues like work design and professional development.

If you’re not a subscriber, here’s what you missed recently:

1. What makes SRE leaders highly effective

2. SRE: critical to the future of healthcare?

3. SRE is not a monolithic role

   (yes, this newsletter has an SRE-specific theme for the moment, but might shift to a more general technical team and professional development angle in the future)

Why is the right learning loop important?

1. Every software team aims (or at least should aim) for highly functional code supported by a robust, secure system

2. You can't approach such a feat if you don't understand the motives of the system as it evolves on a continuous basis

3. Microservices and their delineations may have reduced the cognitive load on teams, but there is still a pressing need for the whole unit to negotiate with each other and adapt to emerging challenges within the system

   and so…

4. We are shifting (and in many cases, have already have shifted) in how we perceive systems — from complicated "process-oriented" systems (where specific inputs create expected results) to increasingly complex "sociotechnical" systems (where specific inputs create unexpected results)

5. And so we need to consider triple-loop learning as part of our professional development arsenal

   Take a minute to let that second last point sink in. I found it a tad perplexing the first time 'round.

=====

Learning loops explained — single- to triple-loop

• Single loop - identify, execute, and solve specific problems with specific actions to achieve specific results "We'll fix any mistakes that come up as we progress"

• Double-loop - reflective problem solving aka root cause determination "Why do we have that problem in the first place?" and tweaking after chasing a set goal

• Triple loop - nudge at the entire system at play — questions like, “Why is our system the way it is? What is it disposed to do? What skills do we have to make this work? How easily can we move skills around to work the system?" Maybe even deeper with a "What is our purpose behind this way of doing things?”

=====

I found the breakdown on different levels of teams by Luca Rossi of Refactoring to be somewhat analogous with how they execute on learning loops.

Let’s see if we can get on the same page about it:

• Bad teams are given solutions to implement. (Single-loop learning — “Here’s the problem. Follow the runbook* and implement the solution.”)

• Good teams are given problems to solve. (Double-loop learning — “Here’s the problem. Make sure it doesn’t worsen or turn into a theme.”)

• Great teams are given the agency to find problems and provide solutions. (Triple-loop learning — “How can we make the system better?”)

* There is nothing inherently wrong with following runbooks. I’d simply argue it becomes problematic when overreliance forms on humans to fix problems with toil.

=====

Parameters for doing triple-loop learning

I’ve included a few parameters for achieving triple-loop learning below. They are appended with specific advice (in brackets) for software systems. See below:

• We can't impose our will upon a system (aim for a degree of system flexibility)

• We can listen to what the system tells us and discover how its properties and our values can work together (continue to refine your observability practice)

• We move with an attitude that's people-positive and complexity conscious (do Agile but do it right i.e. servant leadership, strong learning culture)

• We can't control systems or figure them out. But we can dance with them! (develop and nurture context-driven and continuous learning)

  Adapted from Donella Meadows' and Aaron Dignan's thinking on systems.