Redwork / Bluework

Adam presents the concept of redwork and bluework presented in the book "Leadership is Language".

Learn More

• 🚀 New listener? Start with the introduction.
• 🧭 Get your FREE Guide to software delivery excellence
• ☕️ Small Batches #80: Project Banana
• ☕️ Small Batches #77: Managing to Learn
• ☕️ Small Batches #76: The Coaching Habit
• 📘 Leadership is Language

★ Support this podcast on Patreon ★

Creators & Guests

Host

Adam Hawkins

Software Delivery Coach

What is Software Delivery in Small Batches?

Adam Hawkins presents the theory and practices behind software delivery excellence. Topics include DevOps, lean, software architecture, continuous delivery, and interviews with industry leaders.

Hello and welcome to Small Batches. I’m your host Adam Hawkins. In each episode, I share a small batch of software delivery education aiming to help you find flow, feedback, and learning in your daily work. Topics include DevOps, lean, continuous delivery, and conversations with industry leaders. Now, let’s begin today’s episode.
The previous episode told the story of Project Banana. I wrote the story to demonstrate leadership, communication, collaboration in a real world scenario. The story centers on a team migrating the last of their services to new container infrastructure and their unexpected challenges during the migration.
Let’s us that as an avatar for ideal communication patterns. The pattern comes from the book Leadership is Language. Today, I’m covering into the ideas behind the patterns.
That book describes a simple mental model of leadership. A core competency is communicating to harness the team’s power towards their aims. The mental model splits the work into two modes: redwork and bluework. Leaders leverage communication to work well inside each, and transition between the two.
Redwork is the “doing” work. It’s the action. It’s the production. It thrives in a controlled environment with less variety.
Bluework is the creative work. It’s the planning, thinking, and divergent thought process. It thrives with variety.
Bluework wants a large menu of options for consideration. Redwork wants an ordered set of instructions.
The challenge is identifying the needs of the moment and calling the plays to move from redwork to bluework or bluework to redwork.
Let me explain with a scenario you may relate to. You’re at the beginning of the TDD loop: write the test, write the code, then refactor.
So what happens before you write the test? Well, you need some creative thinking.
This is bluework. At this moment you’re thinking to yourself: how would I write the test? What should the code look like at the end? What are architectural constraints? You’re thinking through a menu of options and possible alternatives. Eventually, you’ll converge on a starting point for the test and commit to what that looks like. Notice that word “commit”. That’s “commit” play that transitions from bluework to redwork.
The commitment comes with specific things to do. In this case, write a test that looks like XYZ. So you switch from thinking to executing. Exciting is redwork. However, the redwork is not entirely opened end. It’s bounded in some way.
The TDD loops builds in way to complete the redwork: the test fails or the test passes. Since we’re talking about TDD here, there’s an implicit completion criteria tacked onto the end of the commitment: “I will stop and revaluate once I have a failing test.”
Skilled TDD practitioners run through this inner monologue without thinking about it. Slowing down to step through the process like we’re doing here allows the implicit mental communication to explicit.
That “stop and revaluate” statement is an offramp from the redwork of writing the test to the bluework of planning the code itself. This is the “complete” play. It bookends the redwork by setting up the next period of bluework.
These cycles of redwork-bluework-redwork or bluework-redwork-bluework play out constantly.
Let’s fast forward a bit through through the TDD loop to the point where the tests passes. Congratulations! The test suite celebrates your progress by displaying a “Tests passed” in green text. You’ve completed a period redwork. Time to call the next play: improve.
The improve play is creative bluework that aims, naturally, to improve future redwork. It typically begins with a simple question: “How could things get better?” This is the “refactor” step in the TDD loop.
You evaluate ways the code may be better factored, better separation of concerns, better assertions, clearer preconditions, less state, more functional, the list goes on.
You consider the alternatives to come up with the next steps in refactoring the code. There’s the commit play again: the transition from bluework to redwork with the implicit completion criteria that refactoring is complete when the test still passes. So off you go, happy hacking. Bluework-redwork-bluework; redwork-bluework-redwork.
Hopefully, you’re able to iterate through that process. So what happens, if you can’t? What happens if your plans just don’t work. Perhaps there’s an architectural constraint that blocks your current plan, or the discovery of an assumption that inverts your understanding?
Well, you call a pause to control the clock. This is the abort handle for when redwork goes wrong. The pause allows you to stop and collaborate (with yourself internally) or with others. This is when questions like: “why didn’t this work?”, “what alternatives are there?”, or “how else could this work?” Fly around until there’s something to converge on. That’s the point of commitment where bluework transitions to redwork, then the cycles repeat.
Let’s recap the plays before completing this episode.
Control the clock to exit redwork to allow bluework for adapting to the current condition.
Collaborate on bluework. This is divergent thinking about the current condition to converge on the next step. Typically followed by the commit play. Think of the P in PDCA.
The commit play signals the end of bluework by committing to specific redwork actions. Think of the D in PDCA.
Redwork ends with the complete play. It’s an opportunity to ask: what comes next? This is the C in PDCA.
The improve play is the curious bluework that aims to improve future work. It asks: “how can things get better?”. Think of the A in PDCA.
You’ve just completed another episode of Small Batches.
Now that you’re equipped with knowledge of redwork, bluework, and the plays, I have a homework assignment for you. Go back and listen to the previous episode on Project Banana. Can you identify the language Brian uses to call the plays with the team?
Go to SmallBatches.fm/81 to find links to Leadership is Language and a handy summary guide.
I hope to have you back again for the next episode. The next episode will cover the specific communication and language used to call these plays.
So until then, happy shipping!