🗣️ Leadership Is Language
For a while now I've heard Adam Hawkins (Software Delivery in Small Batches podcast & the Flow Collective) describe work as either redwork or bluework. I only had the vaguest notion from context of what those were, but it was apparent they were a clear, concise, and deliberate way of distinguishing the types of work we do. What were they really describing? Where did those terms come from? It turns out they're from Leadership Is Language by L. David Marquet, so I was excited to see it on the list for The Profound Book Club. We recently finished reading and discussing it.
Leadership Is Language by L. David Marquet
I had read his first book, Turn the Ship Around!, several years ago. This one picks up where that left off: if the leader stops giving orders, what should they say instead?
Red and blue
- Bluework is thinking, decision-making, and "embrace-variability" work. It is cognitive, complex, and creative.
- Redwork is doing, execution, and "reduce-variability" work. It is often skill-based and physical, focused on getting tasks done against the clock.
Neither one is better. Marquet's point is the rhythm between them. Redwork without bluework is brittle; bluework without redwork never ships. What struck me reading it is that this rhythm isn't just a meeting cadence. It shows up at every timescale of how we build software.
The iteration
On any software team I've been on, we seem to naturally gravitate towards redwork. We'd rather be coding. As the book mentions though, agile frameworks such as Scrum and Extreme Programming (XP) explicitly build bluework into each iteration by design. Think about the Planning Game or the Retrospective. In Scrum, Backlog Refinement is an opportunity to slow down and reflect on what we actually want to build and what we think we can deliver. In between, we focus on the delivery itself.
The timebox is Marquet's Control the Clock play, decided in advance. Nobody has to notice we've been heads-down too long and "call a pause". The end of the iteration guarantees the redwork stops and the bluework begins.
The TDD cycle
The iteration isn't the only feedback loop, though. Even within the redwork itself, it isn't all red all the time. Let's examine Test-Driven Development (TDD) with this same lens (and forgive the color clash):
- Red: decide what the next test should be (bluework), then write it and watch it fail (redwork).
- Green: make it pass (redwork).
- Refactor: step back (bluework).
It's easy to forget the Refactor part of the Red, Green, Refactor mantra, but refactoring is first and foremost reflective. How is our design holding up so far? Is there duplication to deal with? What's our next move, and do we need to reorganize anything to make it more straightforward?
"For each desired change, make the change easy (warning: this may be hard), then make the easy change." —Kent Beck
The improvement cycle
The model for improvement, Deming's Plan-Do-Study-Act (PDSA) cycle, deliberately shifts between the two as well. Plan is bluework. Do is redwork. Study is bluework again. Act is the decision about what comes next: adopt, adapt, or abandon.
This also underpins why improvement is continual rather than continuous (Deming's preferred framing). Improvement happens in steps, with pauses to study in between. Try to improve continuously and you're more likely following Do-Act-Do-Act, skipping the Plan and Study steps where the expansive examination and direction setting actually happen.
Heads up
Marquet describes a powerful metaphor of an open-water swimmer:
Occasionally, they find it necessary to check their location by raising their heads, sighting the buoys, and adjusting course. This process creates a rhythm: (1) sight the buoys (bluework), (2) swim in that direction for a while (redwork), (3) raise your head to check your progress. Keeping their heads down for longer periods means faster swimming overall, but they may end up much farther off course, erasing any lead their pace had given them.
That last sentence is the case for small batches. Every increment into production is a chance to lift our heads and sight the buoys. The bigger the batch, the longer we swim blind, and the farther off course we can drift before we find out.
It's the language
So far this is all about structure: when to pause. But the title is the real point of the book. What makes time blue or red is the words we use. A status meeting where everyone answers "Are we on track?" is redwork, no matter how much it feels like a break from coding. Ask "What did we learn?" or "How do you see it?" and the same thirty minutes becomes bluework.
Marquet organizes the book around six plays (Control the Clock, Collaborate, Commit, Complete, Improve, and Connect), each one a shift away from industrial-age language toward something more effective for today's world. A few that stuck with me:
- Vote first, then discuss. Have people write down their view or vote before the conversation starts, so the first (or loudest, or most senior) voice doesn't anchor everyone else. Diverge, then converge.
- Talk less. People often stop speaking up because the leader can't stay quiet. Talking less is a prerequisite for listening more.
- Commit to learn, not just to do. It changes how a team reacts to setbacks.
That last one, along with small batches, hits closest to home for me. Committing to learn is, in my opinion, the heart of agility. It asks leaders to step out of the command-and-control mindset, the posture of already knowing how it should all be done. Delivering in small batches is how we multiply our opportunities to learn.
On a recent team, this was a constant struggle. Organizational leaders were both prescribing how the work should be done and pushing the schedule, deciding which way we should swim and how fast, while expecting our heads to stay down. Some developers' reaction was to batch up tickets, which caused other bottlenecks and reduced our potential to learn from the system. Looking back through Marquet's lens, both were redwork responses to a problem that needed bluework. The language coming from above was "Get it done!" and "Are we on track?", and the system answered in kind.
Greatness
If you haven't seen it, Marquet's short animated video about Turn the Ship Around! is well worth a few minutes.
Greatness by David Marquet, animation by MindSpring
A book club, by the way, is a great way to read full books, especially if you're much better at starting books than finishing them. Beyond that, ours has been a fantastic driver of conversations: a regular opportunity for deliberate thinking and reflection. Bluework, in other words. If that sounds like something you'd enjoy, come join us.
- v1.0.0 - Nov 1, 2026