How to use a playbook
Even engineering teams need a playbook, just like a sports league or an elite operations unit. Here’s how having a playbook transforms your team.
Recently, I was interviewed on The CTO Playbook. It was a great pleasure and a tremendous opportunity — and, it got me thinking: why doesn’t every development team use a playbook? I started to wonder, maybe using a playbook isn’t common knowledge. So, here’s my follow-up to my CTO Playbook interview.
Introduction
I was recently asked, “how do you use a playbook?” The question made me realize that some teams might not have one or even know what it is — or, how it transforms software delivery for the better.
Airline pilots have a playbook. They use their playbook every time they fly. They pull out preflight, taxi, takeoff and landing checklists. They have checklists for malfunctions and emergencies, and more. So do SCUBA divers, which totally makes sense — forgetting to check your emergency regulator means you or your dive partner could die. Sports teams have playbooks so they know exactly what to do on the field and what each other’s responsibilities are. Elite military teams rely on playbooks to execute rapidly and reliably even in highly stressful conditions.
It seems everyone uses playbooks. So, why don’t development teams universally rely on them too?
It might help if I define what I mean by “playbook.”
A playbook is, literally, a “book of plays.” It’s a set of strategies, rules, suggestions and methods for doing something. Think of it as an operational manual that provides step-by-step instructions for how to handle various scenarios.
The term originates from sports, where coaches create playbooks containing strategic formations and tactics for different game situations.
Playbooks rely a lot on checklists. I think it would be fair to say most playbooks are extensively about checklists because checklists make sure we don’t forget something important. That’s what a playbook is, ultimately — a way to make sure we don’t skip the important bits.
A playbook gives us a reference, a way to double check what we’re doing. But it’s more than that.
Sure, a playbook offers guidelines and methods and checklists. Some guardrails so we don’t forget something important. But a playbook is also a complete reference manual. Writing software is hard. At least, writing good software is hard. There are many disciplines, lots of players involved, different strategies and innumerable technical solutions.
A good playbook gives us a single reference for all those complicated parts and processes — a way of keeping ourselves honest about following our “way of working.” A way to make sure we follow all the steps, all the checks we need to guarantee success.
It reminds a pilot to review maintenance logs before each flight, to check the altimeter and static system inspection date, and visually inspect for tipping rivets along the fuselage. They may be rote, boring steps — but they keep the plane in the air.
If you’re new, welcome to Customer Obsessed Engineering! Every week I publish a new article, direct to your mailbox if you’re a subscriber. As a free subscriber you can read about half of every article, plus all of my free articles.
Anytime you'd like to read more, you can upgrade to a paid subscription.
Why I wrote a playbook
Decades ago I was learning how to be a software engineer. I worked in defense, entertainment, research — lots of different industries. One thing I remember from all of them: being on time and delivering smoothly was rare. Most projects were late, or over budget, or both. Many failed to deliver what the customer actually wanted.
And not once did I find a team that really had their “way of working” nailed.
But every now and then, something went really well. When that happened, I thought, “maybe I should write this down — remember it, and do it again next time.”
I started to notice a few big themes.
Having your customer at the table, involved in every part of the process, usually turned out well. I turned that into a core operating principle — it’s foundational for my own playbook. Other techniques emerged as clear winners. The right kinds of tools for creating a shared, in-depth understanding between the customer and technology team. An approach to design that results in reliable, repeatable outcomes. A way of putting together a project so that you never lose sight of your most important, customer-driven goals.
I learned from other disciplines. I’m a SCUBA diver, and those checklists we use to stay alive are essential. It made me to think about checklists in software delivery.
I bake bread. I love baking bread, and I can make a pretty good loaf off the top of my head — but I still pull out my bread baking reference manual of choice. I check to make sure I’ve got the portions right. I re-read some of the trickier bits, refine my approach, build experiments using those guidelines. Even with years of experience, that cookbook is an invaluable resource I rely on all the time.1
It’s impossible to keep all the facts in my head, all the time. Having a playbook gives me the tools I need to stay consistent, to tackle those tricky problems and to think about new challenges.
I wrote the Customer Obsessed Delivery Playbook because nothing like it exists. It’s become a proven, tried-and-true way to build software. Every single time I use it, my team succeeds. Period.
Playbooks need to be easy & accessible
A playbook is a tool for turning something complex or tricky into something easy. It’s about tackling tough problems, remembering strategies for known situations and discovering solutions when confronted with the unknown.
A good playbook has to support creativity. It can’t constrain the team, because that stifles creativity. Quite the opposite, it has to foster innovation. Software is about research and discovery. Your team needs room to experiment, adopt new and better solutions, and evolve their playbook on the fly.
It’s a framework the team can use, applying it where it makes sense — but not being forced into it when it doesn’t.
It also needs to be easy to adopt. Accessible. One reason I designed my playbook around a subway map is that it’s easy to comprehend. Everyone has ridden a subway.
I’ve seen a lot of complicated diagrams that try to explain how to build software. Many are very good but few provide an overall map — a way of saying “I am here” at any stage of software design and delivery. A subway map makes the Delivery Playbook accessible, easily usable.
Uniformity is also important. Every chapter in the Delivery Playbook — each “subway stop” along the subway map — follows the same design. There are always goals and impact, inputs, activities and then outputs. To move forward, we need the output from the previous subway stop. By following each stop’s process we generate what’s needed at the next stop.
It’s a checklist. Do you have your product capabilities? Does the product owner agree with them? Ok, you can start defining your acceptance criteria.
The subway map organizes all of these individual activities into a whole, a cohesive way to deliver software. Along the journey are clear activities, proposed methods for solving specific problems.
For instance, Chapter 2.3 Strategic event storming captures requirements. We use event storming because it’s very effective when working directly with a customer, and because it gives the whole team plenty of opportunity to participate, ask questions, and build a common understanding.
Can I ask a favor? I’d really appreciate it if you could share Customer Obsessed Engineering. It really helps grow subscribers and that let’s me keep writing!
How to use a playbook
How you use a playbook is simple: you use your playbook every single day.
Depending on who you are, you’ll use it differently. For instance, a brand new joiner will probably use it as an onboarding resource, going through it like a reference manual, learning the ins and outs of how the team builds software.
A more senior engineer might use it as a reminder about the sequence of important steps, or what best practices and tools should be applied in a certain situation. They’ll probably use it to help prepare for some activities too, leveraging the templates, checklists, and examples a good playbook provides.
Your quality engineering lead will use it differently — as a way to check all the quality gates and as a resource to make sure validation and verification is done well.
And even for me — with years of experience using this style of delivery — it’s a tool that saves me time every day. It’s my reference manual when I need to double-check some detail or technique.
I have my subway map printed out in large format and pinned to my wall. It helps me think about what good software delivery looks like. It’s a tool I can use to walk through specific steps with team members.
It helps reason about how we build good software.
For example, I remember an event storming session with one customer. It seemed pretty simple, we were just expanding on a single post-it card labelled “customer checked in.” By the time we finished, half a day later, we had discovered 24 disparate steps that flowed from, “get the passenger details,” including things like security checks, passport photos, prior on-board preferences and more. The playbook gave me everything I needed to prep the team for that exercise:
Training material for how to do event storming, including plenty of examples.
A “readiness checklist” to make sure the team was prepared; for example, sending background information ahead of time.
Activity inputs; a specific list of artifacts we would need for the workshop.
A suggested format for the working session itself, with timing and workshopping techniques.
Templates so we didn’t waste any time, along with workshop setup suggestions.
A step-by-step plan and agenda to run the activity, from start to finish.
Specific outputs we needed to produce during the workshop, so we had a clear outcome and specific goal.
Getting started with your playbook
A good playbook should not be proscriptive. Remember, it’s a tool to help your team become more productive — a framework and some guardrails, but it also needs to offer a path compatible with refinement and improvement.
Your team needs to own the process. They’ll be most successful with their own playbook, one that they control and tailor to their own needs.
The Customer Obsessed Delivery Playbook provides a team with a framework. It encourages innovation and is entirely adaptable. It fits within and works with any methodology — agile, waterfall, and others. If you don’t have a playbook, it’s a good place to start. On the other hand, if you have a mature process but lack a playbook, it can be used as a model to tailor your own playbook.
The best advice I can offer is to give it a try. Start by doing. The Delivery Playbook is best learned from example, so put it to use — learn from it, adopt what you like, improve what needs improving.
I know from my own experience: when we use the playbook, we have better outcomes. Our customer is well-informed, we actually do ship zero-defect products, and we accomplish more in less time.
Further reading
You may also find these articles interesting, one on the benefits of a playbook, as well as a “getting started” chapter from the Delivery Playbook itself.
Publication details
Accessing the Delivery Playbook online
Paid subscribers can access the Customer Obsessed Delivery Playbook online, either from this link or by clicking ‘Playbook’ in the menu bar on the Customer Obsessed Engineering home page.
If you’re a free subscriber, you will have access to previews of most chapters, as well as select full chapters as they are released.
Can we get a group discount?
You bet! Group subscriptions are nicely discounted too!
Check out the colophon for more details available to your organization.
If you find Customer Obsessed Engineering and the Delivery Playbook valuable, please share it with your friends and coworkers.
Maurizio Leo, The Perfect Loaf: The Craft and Science of Sourdough Breads, Sweets, and More: A Baking Book, Clarkson Potter; First Edition (November 8, 2022). ISBN-13: 978-0593138410.