The Playbook Playbook

In simple terms a playbook is a manual for how (some) things get done in those bits of an organisation. They can cover single topics — such as How To Do Social Media — or multiple topics , such as How To Do Tools, Technologies and Processes. Some playbooks are adopted by a whole organisation, or, like the GDS Service Manual, which I worked on a few years back, multiple organisations.

These organisations have created playbooks so that their people can better understand how to get things done within their organisation. In a Transformation setting, where organisations are adopting new ways of working, a playbook describing those new ways of working can be an invaluable addition to other change and education efforts.

FKHeath, CC BY-SA 4.0, via Wikimedia Commons

How to create a Minimum Viable Playbook

The scope of your Playbook will determine how much time and effort it’s going to take to create and maintain the playbook. My advice (as always) is to start with the smallest useful scope and expand from there if needed.

How to determine this?

If you’ve been around the organisation for a while you‘re probably already aware of some of the common problems people are facing and that might have sparked your idea to develop a playbook in the first place.

Like many good pieces of work though, it’s essential to start with users! Think about who the people are who will be using your Playbook. Go and listen to some of them. What do they need to know more of, what are they unclear or confused about in relation to the playbook topic? Where are they already looking for information and how well is that information (and the information-finding process) meeting their needs?

Speak to some of the experts in the organisation — what problems do they see people struggling with? How are these experts supporting people (if at all)? Are there common patterns, practices or processes that could be captured in a playbook that could help a lot of users?

A useful Minimum Viable Playbook would document how to solve a few common problems faced by more than a few people. Your playbook also has to be discoverable by users — no use locking it away in a secret tome of the basement of your organisation (if people can never find stuff on the Corporate Intranet then try and find a better location). The playbook needs to be accessible to them (in every sense of that word).

If you haven’t already found a good content designer to work with now is the time! A content designer will help develop playbook materials that meet user needs — not just the needs of stakeholders or subject-matter experts. It’s a class anti-pattern to have experts alone write this content without checking that it can be understood by novice users. On no-budget playbooks you may be the content designer…

While you are at it, it definitely doesn’t hurt to have a user researcher working with your content designer to understand user needs and test how well emerging content is meeting those needs. Again, this might be you (if there’s no budget) or, if you are lucky enough, your content designer may have experience of user research too and can do some of that research work.

The content development cycle

I generally work in an agile way so it’ll be no surprise to see I advocate this for playbook development too. This allows you to deliver value early to users as well as getting the fastest possible feedback from people as to how your emerging content is working (or not).

The content development cycle looks something like this:

• Conduct research to identify unmet or poorly met user needs in relation to your playbook topic
• Prioritise work in some part of the playbook (to address some set of those unmet or poorly met user needs)
• Have a subject matter expert (SME) draft some content that might meet those needs
• Have your content designer take that input and redraft it to make sure it is in language non-expert users can understand
• Fact check that redraft with the SME; redraft if needed; fact check again etc…
• When your SME is happy then test the content with users and iterate again — this could be as simple as sending them the new content and asking them to highlight sections they think are particularly clear or unclear, or interviewing them as they encounter the content for the first time
• Publish when satisfied (depending on your organisational culture you might publish to the Live playbook as the main way of getting user feedback)

I generally work on content from several parts of a playbook in parallel. Subject matter experts aren’t always available so you don’t want everyone to be completely blocked while they do come available.

Organising it all

As noted above, I tend to use agile ways of working so we have regular playbook planning meetings, Show&Tells and Retrospectives each sprint as well as daily stand-ups. It’s possible to work in one week sprints, releasing content every week including the first week.

In terms of collaboration tooling, I tend to use Google Docs when drafting and reviewing content, Trello for visualizing and managing the publishing workflow and Trello again for other Playbook delivery management work.YMMV.

I treat playbooks as products so once a few iterations have passed I build a roadmap outlining what we expect to work on and in which order. The roadmap can be a handy thing to review with either senior leadership or a steering committee or some representative set of users depending on how your organisation does governance.

Publishing Options

There are a *lot* of options for publishing playbooks and I won’t list them here — it is very dependent on your organisations technology choices. Note though that you don’t need anything fancy to get started — even a Google Doc can be better than nothing for users who are desperate for information. A Google doc (or equivalent) is a great way to start because it enables you to start publishing and getting feedback early, whilst delaying the potentially lengthy conversations about technology choices that might stop you getting going.

On that point I encourage you to Publish Early and Publish Often. If you have something ready to be published, don’t hold off till some future agreed publication day or date, and don’t batch everything up — just get it out there for feedback when it’s ready. Your users could be looking for exactly the thing you publish right now so don’t make them wait and getting their feedback early will help you make it better sooner.

Another thing to consider is whether to make your Playbook an internal resource or whether to publish it on the Internet. My default position is to publish whatever you can to the Internet, only keeping content that is commercially-sensitive or needed for security of the organisation. Making things open makes them better. In government, people outside the organisation can already ask to be told this type of stuff through Freedom of Information requests so it doesn’t make sense to hide it away in any case. Publishing in the open also helps keep standards high for fear of embarrassment!

Keeping your playbook successful

In order for your Playbook to continue to be successful it needs to keep meeting user needs. That means there needs to be continued investment in its evolution. Your should still follow the cycle above to develop new content but over time more of your work will be about maintaining that content.

You’ll probably find that those content designers and user researchers (if you had any!) are needed elsewhere sooner than you’d like. Hopefully by the time that happens you will have already gained a critical mass of (happy) playbook users.

If there are Communities of Practice strongly associated with playbook content then they should gradually take responsibility for maintaining that content. The work could be federated over the community.

You might also instrument the playbook, if you’ve not already done so, to see what is and what isn’t getting used and how well your content is performing. Even if it’s in a Google Doc you can get some indication of usage by only sharing a link to the published playbook as a shortened URL (e.g. usingbit.ly) — check your organisation’s stance on URL shorteners with your IT folks first though.

Don’t underestimate the effort required to keep a playbook current over time, there are lots of examples of dead playbooks out there and these actually make it more confusing for people just by their very existence when people get confused about what’s current and what’s not. Avoid this happening by sharing the work out to as wide a group of (motivated) people as possible and making sure it meets people’s needs as they change over time.

Blockers in Playbook Development

Of course, it’s not as simple and straightforward as I describe above.

One blocker can be when people in the organisation (experts or stakeholders for example) don’t agree on how things should be done in the organisation. In some cases this can be fixed by getting folks into the same room to reach agreement and there may be genuine cases for alternative approaches requiring alternative playbook content.

I’ve often seen these disagreements in Transformation type work too though and they can act as a significant block to playbook production where one set of people want to stick with existing ways of working and another set want to move to a different way of working. Where your organisation will continue to use existing ways of working for some projects and new ways of working for others it’s OK for both ways to co-exist in the same playbook, but here you need to help playbook users understand which of the alternative approaches is applicable to their circumstances. So, you need to develop and test content that guides users to the right solution for their circumstances.

Where existing ways of working are being phased out or their use significantly curtailed the playbook can get caught up in wider resistance to change. Here I think you just have to keep plugging away on content where there is agreement and flagging up where user needs aren’t being met because of this blocker. If there is a wider set of people leading on Transformation activities you can (mostly) leave the problem to them. If not then escalation is appropriate. It’s not the playbook creators job to fix problems at a leadership level.

Of course, enough disagreements like this can also be an indicator that it may be too soon to try and document how things should be done in a playbook. If not enough is yet settled in the organisation it becomes pretty fruitless to try and document what is settled. This requires careful judgement about documenting just enough to help people get on.

Another common case is where SMEs don’t see the need to meet novice user needs in the content they produce. This can be frustrating for everyone as content goes round a cycle where the SME drafts it, the content designer redrafts it, the SME reverts that work etc. One tactic I’ve used here is to test alternative versions of the content with playbook users with the SME present. Hearing first-hand the difficulties novice or occasional users of that content have when using it provides the evidence needed to draft it into a better shape.

Getting time from busy people to create content, review your redrafts and keep things current can be an issue. If others can’t be brought in to help unblock then it’s important to keep flagging up the cost to the organisation of not addressing this bottleneck.

Another common anti-pattern is requiring senior level or committee sign-off on everything. That’s a guaranteed recipe for slowing down delivery. If SMEs are trusted to describe how the work should be done, the playbook owners have a good method of redrafting and testing content and user needs are being met there’s little case for requiring senior sign-off. Do keep senior leaders informed though of how well the playbook is performing and how it’s helping people across the organisation.

In complex organisations it may be that it’s unclear who the subject matter experts are or who owns a particular process. Playbook owners need to work hard to establish who should be consulted on content-production. Make sure your work is as visible as possible, when consulting SMEs ask them who else might have a view or should get involved, when researching with users listen for who they might consult.

One final pitfall when making technology choices — if your organisation makes frequent use of contractors then think about how they might find the playbook (on-boarding?) and access it (do they have the right systems access?). If contractors can’t find it or access it then they may not be able to work independently of your permanent staff or worse still, make up their own processes from other organisations…

Some Public Playbooks

I’ve been collecting public, government playbooks for a few years now and here are some examples to inspire you:

Service Manual — the playbook for Service Delivery in UK Government

UK Ministry of Justice Cyber and Technical Security guidance

UK Home Office — Product-Centricity playbook

Homes England — Digital Playbook