Hey developers, stop your Red Work and do some Blue Work
All developers do is sling code.
To the outside observer that may appear valid. In reality, that couldn’t be further from the truth.
Like any job coding has its mundane parts, and along with that, there are times we need help.
In David Marquet’s book, Leadership is Language he talks about Red Work the doing and Blue Work the thinking.
Red Work
As a former submarine commander, Marquet shares a tale from his Navy time. He had team members that we do their jobs. They didn’t ask questions or think about it.
Then he had an epiphany. What if he stopped giving orders?
Marquet started just asking questions instead of giving orders.
The people that just took orders and did their job. The Red Workers had to start to think.
Blue Work
In Marquet’s example, the Blue Workers are the managers who tell people what to do.
An example would be the manager in a factory. With his change, he had to challenge his team to do both types of work.
Developer Work
As a developer, I know our work consists of both. Red work, developing solutions. Blue work, designing the solution.
Where I find Marquet’s contrast necessary is to take a step back. In sprint work, we focus on our tasks. Often forsaking the big picture.
Take time to consider the overall goal. Perhaps we could be more productive by doing things differently.
Perspective
Developers can get tunnel vision. Focusing on the minutia. Marquet’s guidance to alternate our thinking helps shift our perspective.
I was recently focusing on some front-end validation. Then while pairing with another developer she brought up that a back-end system would do some of this validation.
Small Steps
This brought me back to GeePaw Hill’s small steps. If we do too much without reflecting we get off track.
Ask some questions. Clarify your steps. Then you will avoid wasting time. I need to take GeePaw’s advice!
Shower Time
Sometimes the Blue Work is done off hours. You go for a walk and then bing! A great idea pops into your head.
As you get ready for the morning in the shower it hits you. You have a completely new approach.
If you get stuck on finding a solution, take a break. Walk the dog. Clean the dishes. Getting your mind off it can help.
In summary, Marquet’s suggestion is helpful for developers. Think about your Red work. What monotonous work do you do?
Take some time to think about that work. Are there some changes we could make if we take a step back? Does this work fit better elsewhere?
Mix in some Blue work. What improvements can you make? Is there work that doesn’t need to be done?
Marquet’s work is popular in agile circles. You can see why. It reminds us of similar retrospective principles.