Separating Thinking & Doing Time: Learnings from David Marquet’s “Blue & Red Work”

Separating Thinking Doing Time Blue Red Work

David Marquet’s “Blue & Red Work”

David Marquet is the former US submarine commander that you may have read his book “Turn the Ship Around!” and his famous video on “intent-based leadership,” which is his take on how to transform a passive team of instruction followers into critical thinkers and autonomous decision makers.

In his second book “Leadership is Language“, Marquet introduces an easy to remember “blue and red work” concept to highlight the importance of separating thinking time and doing time in both individual work and teamwork.

Red Work: Doing Time

We continue to be haunted by the ghosts of Taylorism (“Scientific Management,” 1911), and the decades of promoting the human side of the enterprise, learning organizations and reflective leadership show how pervasive the factory model of business is in the workplace still.

Red work is doing, executing, producing so there’s no work that doesn’t involve red work. The problem is the stigma associated with red work.

Marquet rightly characterizes that one key of aspect of red work is the avoidance of “variability,” i.e. the seeking of consistant output and quality. While there is value in reduction of variability itself as that’s the whole idea behind Lean Six Sigma, it becomes a problem when it translates into instructive leadership and “just tell me what to do” followership. Over-emphasis of red work stymies creativity from risk taking; red work dominated workers fear errors as a display of incompetence, and often become slaves to procedures (in psychology we call this phenomenon “learned helplessness”).

Blue Work: Thinking Time

Blue work is time for thinking, exploring, learning, improving.

If red work is about reducing variability, blue work is embracing variability. As in the divergent thinking in Design Thinking, it’s time for being creative and risk taking.

Blue work is also time for decision making and planning. And Marquet’s book makes a particular emphasis that the class separation of leaders and managers as decision makers and planners, and the rest of the workforce as just doers, is a relic of Taylorism. In today’s complex world, the person who is closest to a particular aspect of the customer, product (service) etc. most likely will have the best information to make a decision. So we lead each other and follow each other’s decision making.

It’s All in the Balance of Blue and Red Work

Too much blue work is a problem too. One of the problems of blue work oriented teams is that they often fall into the trap of analysis paralysis, and their red work can lack follow-through thanks to the frequent meddling of blue work midway in execution (“I think we need some more time because we need to review…”). And judging from the popularity of Nike’s “just do it” slogan, Stoicsm and books like David Allen’s “Getting Things Done,” there is clearly a population that is frustrated with our general inability of execution and delivery.

From a psychology perspective, “planning falacy” is a real thing. It’s a form of optimism bias and heuristic error that creates the “tendency to underestimate the time, costs, and risks of future actions and at the same time overestimate the benefits of the same actions.”

What we need is a blue-red iterative process: what is planned in blue work is executed without distraction during red work, and an inspection and adaptation process follows in blue work to adjust the plan to deliver with more precision in the next red work phase.

In short, we need to build a process of iterative blue and red work. Both are important, and they need to be done in iteration.

My favorite definition of critical thinking is the ability to engage in independent, reflective thinking. To grow everyone in the team to become critical thinkers, dedicated time for blue work is essential.

Agile Scrum and the Blue-Red Work Operating Rhythm

By now you can tell that this iterative process of blue and red work is very “agile.” Indeed, this book is an homage to agile by Marquet. Although he doesn’t specifically mention Scrum, Marquet makes direct reference to the Agile Manifesto and explains how his blue and red work concept works in the timeboxed sprints and other Scrum events:

In the world of computer software, for example, many companies are adopting “agile” development practices. The agile approach was launched in 2001 with the publication of The Agile Manifesto, which attempted to guide a more effective way for teams to develop software. At the time, most software programs were managed the way the Industrial Age projects were managed. That approach stressed significant upfront planning and then a long execution period that might extend for years. As the pace of change increased, this approach became more expensive, wasteful, and painful.

The goal of agile development was to start with the most basic product feasible, test it, then decide what to do next. This approach differed from the Industrial Age. First, working products were to be delivered frequently, as frequently as every two weeks. These short bursts of work were called “sprints.” Early and frequent testing exposure to users allowed early and frequent adjustments.

Second, the team would work with the product owners to decide which features they would include during the next sprint. Rather than the Industrial Age approach of separating doers and deciders, the agile approach turned the doers into deciders.

Software companies large and small have adopted many of the tenets of The Agile Manifesto and reorganized teams and processes to align with agile software development practices. The structure of the red-blue operating rhythm and the plays here should allow a similar approach throughout all leadership levels.

One challenge is that the pressure to obey the clock keeps teams moving from redwork to redwork without thoughtful reflection. Take the navy, for example. In a typical submarine environment, the scene is one of unending doing—continuous action. Once one action is completed, the next task on the schedule is tackled, without pausing for deliberate consideration about whether the next task is appropriate. All are locked in redwork mode.

As a submarine captain, if I were to announce that we were going to conduct a certain tactical operation, it should be clear to everyone that a particular arrangement of engineering systems, sonar systems, missiles, and torpedoes would be appropriate. However, in a redwork culture, even if the crew in the torpedo room are aware of the mission, they do not typically think through the implications. Nor do they take initiative to get the right torpedoes loaded. Instead, they wait to be explicitly directed on whether to change the loadout.

If, with little time to spare, I happen to ask about the loadout, only to realize it’s still suboptimal, I am faced with a tough decision: either go into the operation unprepared or rush around to fix the problem at the last minute. In the latter case, intense stress will be placed on the torpedo room operators, increasing the chances they will make a critical mistake. This stress will plunge them even further into a prove-and-perform, redwork mindset. If they make a mistake in the torpedo load, it’s easy to notice and to blame the torpedo operators. But how much of the mistake occurred because we had a culture devoid of bluework?

This example illustrates how important the balance between redwork and bluework is in a system as a whole.

– Chapter 2, Leadership is Language (2020), David Marquet

Agile Scrum separting blue thinking red doing time

Agile management is an effective tool for this purpose. Used by many software development teams, agile management structures teamwork in sprints. These sprints are commonly two weeks long but could be longer or shorter. The sprint is bookended by bluework—collaborating on what to include during the next production increment at the beginning, and testing and reflecting at the end. Because the length of the sprint is determined ahead of time, there is a planned exit from the redwork. This allows the team to focus deeply on the production work right until the next pause happens.

While teams are in production, designing and coding software, one of the key rules is that leadership is prohibited from redirecting or interfering with a team’s work. If leaders have a new idea, they add it to a backlog for discussion at the next sprint planning meeting.

The end of the sprint includes bluework. The teams present and celebrate what they have accomplished. They reflect on their work practices from the previous sprint and feedback they have received on the product. Then they decide what to take on for the next sprint cycle. This is bluework. The sprint can be represented as /blue-red-blue/ and the continuing sprint cycle would look like this: /blue-red-blue//blue-red-blue//blue-red-blue//blue-red-blue/ . . . and so on.

– Chapter 3, Leadership is Language (2020), David Marquet

Raising Consciousness of Blue and Red Work is Highly Effective in Coaching Stagnant Scrum Teams

As an agile coach, I will sometimes come across “stagnant” Scrum teams – teams that you can feel the collective creative juice isn’t flowing. My intervention approach will typically be around working on igniting the critical thinker inside each team member, and I am finding this blue and red concept from David Marquet a powerful coaching tool that aids this effort.

If you are experiencing that the creative juice isn’t flowing in your team, give this blue and red teamwork process a try.

NB: I have intentionally used the expression “blue and red work” in this article instead of “red and blue work” which author David Marquet typically uses in his book. The reason behind this is because I simply find “think-do” more naturally flowing than “do-think” as a sequence of action.