Discover more from Customer Obsessed Engineering
12 reasons to level-up your team with a delivery playbook
Just like a sports team or an elite operations unit, even engineering teams need a playbook. It's the secret to reliable, repeatable delivery. Here's 12 reasons to use a playbook.
One of my many passions is making sourdough bread. Every single day, I spend a little time baking bread — or, more precisely, every morning I “feed” my sourdough starter. And at least twice a week I bake something using that starter. Right now my favorites are ciabatta and a mixed-grain sourdough boule. But sometimes I’ll mix it up and make biscotti, or a nice polenta loaf (which, if you haven’t tried, is a delicious, hearty bread with enough corn meal to give it a satisfying crunch and golden color).
You’d think with the amount of time I spend baking, I’d have it down. After all, bread is usually just flour, water, salt, and a bit of starter. Sure, sometimes you do something a little more elaborate, maybe a couple different kinds of flour, or some olive oil — but bread is basic.
But it’s actually not. Even something as simple as bread can be surprisingly complex. The myriad types of flour and mixing percentages, the levain, how long to let the autolyse sit, warm and cold proofing, different baking techniques… so, I don’t do it from memory. I use a playbook. My playbook is The Perfect Loaf, by Maurizio Leo, and it makes baking bread a delight.1
An engineering playbook
Just like I use a cookbook when baking bread, I rely on an engineering playbook when building software. I’ve been doing this for about 40 years now, a lot longer than baking bread. Again you might think I’d have it down, right?
But building software is complex, and even after 40 years I go back to my playbook again and again.
Here’s the thing: Every single time we use the playbook, the project goes well. And nearly every time we don’t use the playbook, something goes wrong. And every time it goes wrong, it reminds us: Use the playbook.
Trying to deliver software without a playbook is like trying to win the World Cup without a game plan. Or an elite operations unit going into battle without a tactical manual.
Use the playbook. It makes it possible to effortlessly deliver software that delights customers.
What is a playbook?
A playbook is your strategic and tactical delivery plan. It provides an overall roadmap for the entire delivery lifecycle. It encompasses the “what” as well as the “how.” Most importantly, it’s yours. It’s a playbook that you adapt and craft to your specific situation, and likely evolve over time as you find better ways to deliver.
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.
How is a playbook different from a methodology?
An engineering playbook is not a methodology. A playbook should work equally well across methodologies — agile, scrum, kanban, waterfall. Think of the methodology as an operating framework that you’ll slot your playbook into. The playbook focuses on:
What are you building? Your playbook provides a path to current and future state analysis, so you can accurately define what you are building.
How will you build it? The details of the implementation are realized in specifications — the playbook creates standards, templates, and architectural stereotypes that explain the “how.”
Playbooks are tailored to the needs and preferences of the team. As you’ll see as we go through my playbook, there is ample opportunity to substitute the design principles, preferred artifacts, and different approaches your team decides to use.
The “Customer Obsessed Delivery Playbook”
I’ll typically just refer to the “playbook,” but this is a Delivery Playbook as defined by Customer Obsessed Engineering. This introduction explains what my Customer Obsessed Delivery Playbook is and provides a high-level overview of the entire playbook.
My playbook covers a lot of territory. It’s divided into four major sections: Mobilization, Blueprinting, Delivery and Operations. It needs to be comprehensive, so that no matter where you are in the delivery cycle, you can look at the playbook and know what’s next. It covers things like:
Team mobilization and strategy
Planning
Quality gates (entry / exit criteria)
Requirements gathering
Value mapping strategy
Architectural foundation and North Star vision
Target state architecture
Design specifications
Validation and verification strategies
Engineering models
Delivery models
Monitoring and operations
The above is a very shortened version of the table of contents for my playbook, a rolled up version that hits on the major highlights.
I’ll be releasing about two playbook chapters a month. Each chapter will be available to paid subscribers in full. Free subscribers will have access to partial chapters and a few select complete chapters.
My playbook is a strategic and tactical guide, and includes numerous examples in the form of templates, documents, diagrams, and recommendations.
How the playbook ups your game
The playbook is fundamental. It gives you an edge most teams don’t have. A small number of organizations take it to heart, and those are the top performers in the industry. Accenture is a company that believes deeply in following playbooks — a process, a formula for success. It’s served Accenture well: Over 120 countries, about 9,000 clients, and roughly 743,000 employees and counting.
The playbook is about reliable, repeatable execution. Let’s think about that for a minute: How would projects go if you could count on reliably executing, every single time, without fail? How will your customer feel when you reliably deliver exactly what was promised, no disappointments, no misinterpretations?
Want to expense Customer Obsessed Engineering and the Delivery Playbook? Most companies will do it! If you need a starting point, try this template.
The Customer Obsessed Delivery Playbook focuses this reliable, repeatable execution on the customer. I do this by including value stream engineering in the playbook. It’s a technique for making sure customer value is identified, protected, and realized throughout delivery. No customer misunderstandings or disappointments.
My playbook has been developed and vetted with well over 100 customers. It’s been validated and continuously improved over the past 20+ years. Along the way, it’s been co-created with experiences gained at Lightbend, Accenture, and others.
Twelve reasons to use the playbook
Consistently following the playbook delivers many benefits, some of which I’ve summarized here. As we dive into the chapters, we’ll also explore where things go wrong when steps in the playbook are by-passed, and how to keep that from happening.
Don’t miss important details. The playbook provides a roadmap to follow, an easy step-by-step guide, and puts guardrails in place. For example, before transitioning from Mobilization to Blueprinting, we need a product vision, sufficient core solutions identified, 1-3 user journeys, a team with enough dedicated time (and a few other things).
Decisions are clear, decisive, easier. With a complete roadmap that spells out how to execute, we avoid second guessing and missteps. For example, before moving into technical design, we know that user journeys and use cases need to be discussed with the customer. The customer becomes involved at all the right points along the delivery pipeline, giving both us and the customer confidence.
Move faster with confidence. The clarity gives us confidence. We can accelerate because we have the roadmap, we know the inputs, and by following that map repeatedly we gain confidence.
Become more consistent in execution, which drives repeatability. The playbook gives us specific inputs and outputs at each stage. The outputs from a prior stage are needed in subsequent stages (most of the time, but there is quite a bit of flexibility too). It’s a functional model, and really drives consistency across projects. Having all of the necessary steps, inputs, and artifacts — not to mention well-designed templates and stereotypes — allows us to execute with professionalism. We aren’t re-inventing the wheel on the fly for each customer. Instead we’re executing well-defined, repeatable steps.
Collaboration is much easier. Gone are the days where each team is “doing their own thing.” Disparate teams that share a playbook are able to work together in a streamlined fashion. Each team knows exactly where the other is and what’s needed next. Having common artifacts — the same approach to design and documentation for instance — means sharing resources is easier. A single stereotype becomes a reusable tool for every team.
Delegation is easy. Leveraging the functional model — known inputs, specific steps to follow, and known outputs — makes it much easier to split work across the team (or even between teams). For example, one team can confidently take on specification design while another tackles a North Star architecture, because both teams use event maps as inputs. Everything is spelled out, even to the detail that these tasks can be parallelized.
Customers always get the most important thing next. This is because value mapping activities and value stream engineering is built into the playbook. For example, customer workshops are used to identify the relative value of product features. Value mapping exercises guide very intentional decisions about build versus buy, and repurposing or adapting existing technology. Value mapping highlights the relative cost of features, pushing customers to prioritize the most impactful things rather than asking for everything at once. At the same time the cost in terms of time to market is highlighted, creating drive for small, rapid iterations.
Problems are caught before they become crises. Risk is proactively managed using guardrails and quality gates. Each stage has a series of quality checks (such as having models that are understood by the customer before beginning specification). These gates establish clear expectations and statements of responsibility up-front, and prevent moving forward if there’s risk. The entire project team (including the customer) is deeply involved in these decisions so there are no surprises. It leads to very early and very high awareness if anything is going off-track.
Roles and responsibilities are explicit. During mobilization, the entire team is identified. Gaps in knowledge, skill or capability are identified and addressed. Each individual’s availability, involvement, responsibilities and accountability is spelled out clearly (for example, the RACI matrix mentioned below).
Team and customer communication is greatly enhanced. The playbook is very rich in communication, partly because of shared activities and checkpoints, and partly because of the high degree of collaboration that it enables. As a result, awareness of the overall project soars, responsibilities are much more clear, and artifacts (such as documents, designs, specifications, code) are more clear.
Team efficiency is put front and center, acting as a multiplier. A good playbook establishes visibility into wasted effort, and pushes it out of the project. We’ll use techniques like waste walks to identify effort that is less than optimal and eliminate it. For instance, time wasted waiting for slow server builds, or manual processes that could be automated, will be captured and made highly visible. With the cost of waste made visible, eliminating it will be prioritized.
Customer confidence soars. Your customer will simply love it when they see a confident team executing at speed. With a mature playbook you have a mature and well-vetted interaction model with the customer. There are specific activities that require the customer. For example, during Mobilization team dynamics are established, such as ceremonies, meeting cadence, RACI models, so everyone knows what’s required of their role. Later, event mapping exercises and user journey development tightly involve the customer in the design. Those interactions and artifacts are provided in detail so you can show the customer what they will expect ahead of time.
Getting started
I’ll be publishing a new playbook chapter every few weeks. The first step is to start following along. Each chapter will include practical steps for implementing your own playbook. I’m glad to have you along for the journey!
If you’d like to get a taste for some of the methods, techniques, and stories that accompany the playbook, take a look at this post on delivering using a steel thread. Or, just dive right into the playbook’s getting started chapter!
Publication details
Accessing the Customer Obsessed 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 my organization get the complete Customer Obsessed Delivery Playbook?
Yes, absolutely! Check out the colophon for details on options 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.