Leading an Exploration

I've written a lot about how software delivery leadership is about adapting to context. Every situation is different, with cultural challenges, complexity, people's experience and the dynamics between them, making no two situations ever quite the same. Recently I've been observing the importance of another facet of this.

Different types of work

On my personal kanban board, I have three columns to visualise my work, 'to do', 'doing' and 'done'. There are differences in the language I've used to describe the work represented. The first three items read 'Arrange a meeting with...', 'Prepare a slide deck ....', 'Write a blog post'...

However, other work sounds different. 'Learn more about....', 'Find out the right person to talk to regarding....', 'Improve the dynamic between....'.

The first three items are nice and straightforward; I'm confident I could pick them up today and get them into the done column, then pat myself on the back for my productivity. The others, though, where do I start? One has been sitting in my 'doing' column for weeks. Oh no, my cycle time metric!

There is a difference in context between 'Arrange', 'Read' and 'Write', and 'Learn', find out', and 'Improve'.

L. David Marquet, in his book 'Leadership Is Language', discusses the difference between red work, and blue work. Red work is execution, doing tasks, and delivering. Blue work is more focused on exploring, learning and decision-making.

When everything is red work

When all work is treated as red work, the patterns, practices, and leadership styles don't fit exploring, learning and decision-making. This can have very negative consequences.

Some common red flags in software teams are:

• Exploring and learning is broken down into highly specified granular work items.

• Exploring and learning is estimated like all other work.

• A cycle time or velocity is calculated by averaging all work, including exploring and learning.

• Exploring and learning is expected to be completable in arbitrary time boxes.

Some of these practices might fit red work, but they will hinder if the point of the work is to explore.

In the wider context of product development, the red work of delivery generates the blue work of analysing feedback and deciding what to do. Ignoring that is an obvious source of failure.

In addition, understanding organisational context, learning new technologies, figuring out existing codebases, gathering user insights, building alignment, and agreeing on the initial design and direction all require exploration.

Teams that struggle to effectively explore knowable information either end up in painful loops of failed execution until they are lucky enough to find a way out or lose engagement and carry on delivering the wrong thing regardless.

An Environment for Blue Work

Traditionally, thinking and doing were separated into different roles. Managers think, workers do. Today, it's a collaboration. Different thoughts and ideas come together to uncover the right way forward.

In my opinion, leadership is less about doing the thinking, and more about creating the time and space in which exploring, learning and decision-making can happen.

When we share ideas, we take a risk. Will we be ignored, punished or ridiculed? The job of leadership is to enable everyone to feel safe enough to take that risk, to invite it, to make it expected and normal.

Leading by example means inviting dissent, welcoming it, thanking people for it, and drawing out a conversation about what would work better, allowing blue work to take centre stage before we deliver the wrong thing.

To do this, we need to bake blue work into working methods. Given the common bias towards red work, it's perhaps even more important that we are deliberate about how we do that.

Patterns and Practices for Different Types of Work

Here is a comparison of patterns that, in my experience, fit the context of red work and an equivalent pattern that works better with blue work.

Red Work	Blue Work
Thinly sliced, well specified work items	Work items defined as knowledge desired from areas of exploration and learning
​Estimated or shaped for regular and predictable delivery	Space and time to navigate the unknown
​Short time boxed recurring meetings with tightly specified agenda, like a daily stand up	Longer time boxes, freedom to go where the conversation takes you, workshops to diverge and converge on ideas.
Measure progress and make forecasts for when you will be done	Regular cadence to discuss learning and progress, and maintain a direction until 'just enough' is known.
Show working software and visualise progress in charts	Visualise learnings, initial designs, options, and decisions made or needed
Gather feedback on working product increments	Co-create ideas, mock-ups and test assumptions.
​Control work in progress to create focus until done, and protect bottlenecks	Set work in progress limits to be a little more relaxed. Protect delivery by learning what doesn't need doing.

Interlacing Red and Blue Work

A traditional approach was to create an upfront analysis phase. Once everything is figured out, we can 'just execute'. Of course, this is doomed in all but simplistic scenarios because there is no adaptability.

We need a balance, with Initial work weighted more towards the blue work. Otherwise, we miss out on important, knowable information. A common approach is a phase of 'discovery' before 'delivery'. An effective initial discovery is about knowing 'just enough' to start, a direction on the compass, rather than an exact destination. Discovery becomes a continuous activity that lives as long as the team or endeavour.

However, even in the initial discovery, we still see red and blue work. Consider the examples on my personal kanban board, arrange a meeting, write up a report, and prepare a presentation. These types of work are likely to occur in discovery; the work that spawned them may have been blue, but undertaking these tasks is red.

Just as we discussed red work generates blue work, blue work also generates red work; it's a constant cycle.

Leading software delivery is always a balance of helping teams be effective at both types of work, never just one.