Leadership is Language by L. David Marquet is my favourite book about agile that doesn’t describe itself as being about agile. At it’s heart, it argues that leadership is about people, and how we lead people is ultimately about how we talk to them. That’s a very agile idea: prioritising individuals and interactions over processes and tools.
One of the book’s most important insights is to distinguish between thinking and doing, which it calls blue work and red work respectively. It recognises that these are different processes that we should treat differently. Leaders can encourage the different modes with their language: encouraging curiosity and reflection for the blue thinking mode and focus and clarity for the red doing mode.
This rhythm of working in short cycles, alternating between the two modes, also feels very agile. But the emphasis on language in the book is a subtle nuance often missed when thinking about agile ways of working.
How Leadership is Language relates to agile
Red and blue work need different approaches. Thinking mode benefits from embracing variability, getting diverse ideas and perspectives to improve decision making. Doing, on the other hand, benefits from reducing variability – focusing on consistency and execution.
This idea might sound familiar if you’ve read what I’ve written on convergent and divergent thinking. Again, these are two different processes, and we need to separate them out within our meetings.
Marquet is applying a similar concept to our work as a whole. We should look at as many ideas as possible in brainstorming, and at lots of different perspectives before decisions making. But in day-to-day execution, you should just focus on one thing at a time to avoid being pulled in too many directions. The trick is to get the right balance between the two modes, working in short cycles of doing interspersed with thinking.
This absolutely resonates with many agile practices. Agile encourages you to work in short cycles, pausing at regular intervals to reflect and improve. We don’t describe them this way, but retrospectives and idea generation should both be drawing on the blue thinking mode, introducing variability to help you improve. Marquet calls this ‘improve, don’t prove’. It’s all about a non-judgemental reflection on how things are going and what you might want to do differently.
Stand-ups are all about reducing variability, efficiently clarifying what you are focusing on that day. You should be breaking the work down into small, manageable tasks and completing them one-by-one. This is exactly what Marquet argues for as his ‘complete, don’t continue’ play.
But my favourite secretly-agile part of the book is the section on ‘collaborate, don’t coerce’. Marquez encourages leaders to empower their teams, listening to them and encouraging the sharing of ideas. Where possible, he wants you to let the doers be the deciders. Again, this is a very agile idea.
How the book can help you take agile ideas further
Unsurprisingly given the title of the book, some of it’s best ideas are about language. And it’s particularly helpful on ways leaders can use language to create true collaboration without subtly prompting the group just to agree with them.
This is how the book puts it:
‘When leaders attempt to collaborate with their teams, they often end up skipping the divergent part (“What does everyone think?”) and jump straight into the convergent part (“Here’s what I think. Does everyone agree?”). This represents the language of too many brain-storming and decision making meetings, where the boss states an opinion and others fall in line. Bosses try to be compelling, not curious. They ask leading and self-affirming questions. They suppress dissent and push for consensus. This is not collaboration. This is coercion disguised as collaboration.’
The book is filled with great ideas for how to tackle this. A few of my favourites:
- Vote first, then discuss. I’ve written a lot about anonymous dot voting as a way to get input from a group rather than just the loudest or most senior person. The book takes this further by suggesting you vote before you discuss, so you aren’t influenced by what the leader thinks.
- Asking probabilistic questions rather than binary ones. For example, asking ‘how likely is this to work?’ rather than ‘will it work?’ to allow more space for varying opinions.
- Highlighting dissenting opinions in a non-threatening way. If you’re responding to a comment that’s an outlier from the group (perhaps added privately in a retrospective), asking questions like ‘What might be behind this?’, ‘What might someone who said this see that we don’t?’ invites the group to explore it, without automatically assuming it’s wrong.
- Leaders speaking last in discussion, something I’ve also advocated for in my blog on how to be an empowering manager.
- Asking good questions, without an implicit answer embedded in them. For example, ‘what are we missing?’, ‘what do you see?’ rather than, ‘is this right?’, or ‘have you thought about the needs of the client?’.
This is a book I keep coming back to. You probably can’t implement all the suggestions in one go, because remembering to change your language in the moment is harder than introducing a new practice like a retrospective. But just taking one or two ideas from it each time can make a big difference to how you are as a leader.
Have you read Leadership is Language? Did the resonances with agile strike you?
This is part of a series of reviews of books that are tangentially about agile. Subscribe to receive my monthly newsletter and not miss a post.
Leave a Reply