We look at playbooks. We ask: what are they, and why create them?
We also discuss our approach for creating playbooks, and the different ways to publish them.
Transcript:
This is the Cherryleaf podcast.
Hello and welcome again to the Cherryleaf podcast. We’re back after our August break. I hope you had a great summer.
In this episode, we’re going to look at Playbooks.
Now we have been asked by a few customers recently to help them create playbooks.
And so I thought it would be an interesting topic to discuss.
So let’s start off by answering the question, what is a playbook?
And it can mean different things to different organisations trainual.com defines a playbook as a place that “houses all your company’s processes, policies, and standard operating procedures (SOPs) in one place. And it outlines exactly how your business does what it does – down to each role, responsibility, business strategy, and differentiator.”
On the sterlingwoods.com website. They describe it in this way:
“A playbook reflects a plan; an approach or strategy defining predetermined responses worked out ahead of time.” While you needn’t expect your employees to channel Tom Brady and memorize the playbook, it is critical to have a playbook on hand for guidance.”
There are a number of playbooks on the web, and we can look at how they define themselves.
One, for example, is from Apigee.
And they have an Introduction to Playbooks page, and we’ll put that into the show notes.
And they say that “Apigee troubleshooting playbooks are designed to provide quick and effective solutions to errors or other issues that you may encounter when working with Apigee products.”
Now, Apigee is part of Google, and Google has developed quite a few playbooks. One they have is for their business messages. Again this is available on the web.
Business messages is a mobile conversational channel that combines entry points on Google Maps, search and brand websites. They have a brand playbook for Google Business Messages.
And for that, the idea of using the playbook is to guide people through building the basics, designing their business messages, experience and then going on to the next stage of enhancing it by adding automation, providing users with quick support through automation.
So it’s more like a training guide or an overview of what’s possible within that particular product. So they’re very similar to policies and procedures.
Now, in some ways they are advice on different approaches that you can take for different situations.
And the idea of the play in the playbook that if you push the equivalent of the play button that you can predict what will happen.
But again, that’s very similar to what you would see or expect with policies and procedures.
For one of our clients, they saw the playbook very much as that policies and procedures, standard operating procedures type role.
For another clients, they saw the playbook as a way of informing, educating and instructing other departments within the organisation.
About what this department expected from them, if they wanted to use and engage this department’s services. So this had an educational element to it and was also focused on planning, project planning, and understanding what people needed to have in place before they actually wanted to do the thing, as it were.
So why have a playbook?
Well, one advantage of writing things down, writing down best practice and good practice, having policies and procedures, is that it can help in making sure that people do stuff in a consistent way.
And help in making sure that what’s produced is of sufficient quality.
And by having that in place.
What it means is you can minimise bottlenecks: that you can delegate more work, because people have instructions and guidance on what to write.
And they can follow that and ideally what is created is consistent, good, high quality outputs.
The two most recent playbook related projects that we’ve been working on have been ones where they wanted to create a playbook that provided advice and guidance and rules on how to write content.
So that they could have different people within the organisation writing content, and that the amount of time that was taken to adapt and improve that content could be minimised. And so that they had good high quality, consistent content throughout the organisation.
For one project, it related to a Fire and Rescue service, or what used to be called Fire Brigades.
Fire and Rescue services have some particular challenges in similar way to other emergency services.
And that when they’re doing the job, what they have to do is they have to follow particular legal requirements and particular codes of conduct and other standards.
And also the situation in which people do things can change, and people have to be able to make decisions in the field that they judge a right for that particular situation.
So for example, if you have a piece of equipment then there are legal requirements on how to check that the equipment is safe before it’s used, the legal requirements about the training that’s provided. There can be particular rules on what happened when it breaks, who can fix it, whether equipment must be tested before it can be used. And then there’s information on specifically how to use it. And how to use it in one situation and how to use it in another. It’s complicated content to write.
What we were asked to do was to create a playbook that provided guidance for the people that have to write this content. They are called Brigade Orders for the Fire and Rescue services.
And of course, as the law changes, the Brigade Orders need to be updated. When new equipment is introduced, they need to be updated.
Again, we were asked to provide some guidance that the people to writing this content could follow to make sure that they write it in the best possible way.
So how do you tackle a problem, a challenge like that?
What we do is we look at the existing content. We look at the existing documents to identify the common information types.
These are the common sections or the common chunks of information that are in the different documents. These are the bits of information that need to be in every new document, or certainly considered whether they should be in every new document.
So, for example, those information types could be things like an introduction. There’s always an introduction in the Brigade Orders. That there’s a section on legal duties, what laws they must follow for a particular situation, what laws they must follow if they’re using cameras, what laws they must follow if they are trying to access a building, and so on.
Another common thing: Roles and responsibilities.
Auditing of a particular order or policy.
And in their case, a way of identifying how to react in specific situations, and how to react in special edge case situations as well. And definitions, glossary terms and descriptions of what particular technical terms mean.
So what we can do is we can create a document with those key headings or sections in the document. We can work out the structure or a sequence in which those can be placed within the document.
And then the other thing we can do is define or provide guidance on how to present those different types.
So some of those the best way of describing them might be by having the content in a table.
And another situation it might be by presenting the information as a flowchart, or a series of numbered steps, or a picture.
So what we can do, by creating a playbook for that type of documentation, is have a document that has all of those topics in the document.
Then information on what that topic is about.
So, for example, that in the audit section, you provide information on who checks the policies are being followed; How often they check the policies are being followed, how conformance of the policies audited.
And it can also perhaps provide information on how the policy is measured.
So after that guidance on the type of information, and in addition to guidance on the types of content that should be written, in that particular section, you can provide advice on how to present it.
And the approach that we take is to provide some example text. The example text comes from an existing document, which we improve and optimise.
For example, if we’re talking about auditing and reviewing of a particular policy, the example text might be that the Chief Fire Officer is responsible for ensuring that the policy is implemented across the Fire Service and that they check that every three months. Or that the Planning and Programme Officer reviews the policy. And they do that every year, or when new legislation arises, or as and when it’s needed by that particular Fire and Rescue service.
So in that situation, the playbook has a series of headings in a sequence that the writer can complete for their particular document.
Now, not always is it the case that they need every section. Sometimes they need to add new ones, but it gives them that guidance to help them get over writer’s block.
And there are those examples of best practice, good ways to write the content that they can use, they can follow when they’re writing their own content.
For another project we had a client who wanted a playbook relating to the developer portal that they had created.
So they’d created a developer portal for APIs, and then different developers of APIs were going to add their APIs to the portal.
With their APIs, then there had to be documentation that explained what the API did, when you might use it, and reference information on things like the operations and endpoints and parameters and so on, that related to the APIs.
This team didn’t want to write that content for all these different providers of API’s. They wanted that content to come from the API owners themselves.
Now it may be that that content needed to have a bit of polish on it, but they didn’t want to do too much work on creating the content.
Otherwise, they would end up as a bottleneck. So in this situation, the playbook had an educational element, and also helped explain the overall process.
It had content explaining the portal itself, what bits of content would exist on the portal and why that content was there.
And the types of things that the API providers needed to have in placed before they could get their content onto the portal.
So it provided some guidance on prerequisites, things that they need to create and prepare before they said, can we put our API up there?
It had the service level agreement information.
And it also had advice on language and grammar, guidance on how to write clearly. For example, using the active voice, writing short sentences.
One of the other questions that we’ve been asked about Playbooks is, what’s the best way to publish them, to deliver them?
Often, the decision is determined by what platforms the organisation has in the normal way in which staff look at information today.
So for some organisations they use Word documents and they use SharePoint. And so the playbook is best written, best published as a Word document.
There are some downsides to that. Word is designed to be a printed document. If you print out the document and then it gets updated and changed, then there are challenges to make sure that staff see the updated version.
For other organisations such as Google, they tend to use a wiki-like environment. They use Google Sites. And there are other customers that use Confluence and other wiki-like tools.
For organisations that are more software orientated, you can have a situation where developers are used to using tools like text editors and publishing their content to repositories like GitHub and reading content as Web pages.
And in that situation, having the playbook written as perhaps a markdown file stored in repository and published as a web page probably makes the best sense.
The most common approach seems to be to publish the content as a PDF. And one of the advantages of having it as a PDF is that it can be graphically rich.
And it can be printable. It can be easy to read, it can be easy to distribute.
And if you look for playbooks on the web, examples from organisations, a lot of them are PDFs, even ones from Google.
Again, there can be downsides to that. It’s designed typically for printed use. How do you make sure the readers do see the latest version?
If that’s the way in which people are used to consuming this type of information, then it makes sense, there’s a good argument for publishing the content in that way.
A lot of the people that listen to this podcast are technical communicators, they’re technical writers, they’re Technical Authors.
From that perspective, playbooks provide an opportunity in a number of ways.
One is you can create a playbook for your department that can help explain to the other departments that need your services how things work, what they need to provide to you, why things are done in particular ways. And that can help streamline the process of getting content done.
And it can also provide an opportunity for using your skills and experiences across the organisation by suggesting that you help other departments create playbooks for the services that they provide.
So that’s a broad overview of playbooks in terms of what they do, how we are involved in creating them, the general approach that we take to creating playbooks, the benefits you have by having a playbook. And, like with all of our podcasts, I hope you found that useful.
If you’d like more information on the types of services that technical writing services and training courses that Cherryleaf provides, have a look at our website to www.cherryleaf.com.
If you’ve got any comments about the podcasts, you can contact us by e-mail info@cherryleaf.com.
And that is it for this episode. Thank you for listening. I look forward to speaking to you on the next episode.
Leave a Reply