As we undertake a lot of work based around knowledge-sharing and best practice, we’re looking into the concept of ‘playbooks’ as one proven way to share practical lessons. Our aim is to ensure that none of our learning is lost, and that it is shared with practitioners who face similar challenges in the future in as useful and accessible a way as possible.
What is a playbook?
‘Playbook’ is a word that’s used a lot these days, by tech and management people. They’ve borrowed it from the world of sports, where the idea of a book telling you ‘how to play’ is a more straightforwardly obvious concept.
If you find this terminology a bit too hipster, though, you can think of them by the less trendy terms of ‘manuals’ or ‘toolkits’ — though a playbook does have the advantage of sounding like a lot more fun than a workbook.
Whatever the name, what they aim to give you is a collection of repeatable plans and tactics for responding to typical challenges. As such, they can be absolutely invaluable as an internal company tool; and we think they can also help in sharing knowledge between organisations.
In either case, a well-managed playbook would be easily available to employees, widely used and regularly updated.
Playbooks might be for one department (like sales, or design) or for the organisation as a whole. They typically contain several different kinds of content, such as:
- Plays (or guides), detailing the steps that need to be taken to achieve a goal or cope with a scenario
- Scenario or problem definitions, describing things that may happen, or go wrong; how they are caused and how they are identified
- Ingredients: details of the resources needed and the costs associated with them
- Case studies: Written summaries of real life projects that have come up against scenarios and utilised similar plays or guides to solve them
- They also usually contain some signposting or navigation method, such as tags or categories — or one of our favourite methods, the questionnaire.
Questionnaires as a content discovery method
One great way to ensure that people are seeing the most relevant content in an often hefty playbook is to use a questionnaire that leads the user to the precise content they need at that particular time.
By answering a series of questions, the visitor can provide some information on their own situation, and in return be delivered the most relevant content.
For example, Atlassian’s health monitor, part of their playbook, asks you to rate how well you feel your team is doing on certain attributes, such as shared understanding, decision making, and dependencies.
Once the questionnaire is completed it offers suggested plays and lets you assemble and share your own action plan.
What goes into a useful playbook?
Practical advice that is specific to your situation is often the most helpful, and this where playbooks really shine.
A well thought-out playbook, with a questionnaire that asks the right questions, can make available clearly-defined, tailored content that is domain-specific. This means that the reader doesn’t need to work hard to apply generic advice to their situation, nor untangle clumsy metaphors.
Playbooks often solve the problem of ‘how do you know what you don’t know?’, with tried and tested solutions to known problems.
A playbook should be designed with the target audience in mind — and that audience can potentially be a narrow one, operating solely within one domain or department — offering rich advice based on experience. It should empower people to achieve their goals, solve their problems and, ultimately, shape the culture of their organisation.
A well thought-out playbook will become invaluable to its users, and consequently they will want to keep it up to date and useful.
For this reason many playbooks have a method of feedback to aid continual improvement, such as rating a page based on its utility, open feedback methods or collaborative wiki-style editing.
Where we’re working with playbooks
Local Digital FOI
One of the prototypes we pursued as a result of our research into how councils manage Freedom of Information requests was a playbook, fronted by a self assessment questionnaire.
We identified a need where teams want to improve their service but don’t necessarily know where to make improvements (eg, should they invest in better software, train staff, or revamp their processes?).
Our prototype playbook asked questions to determine the shape of the council’s FOI service, which then presented guides and descriptions of potential problems relevant to their case.
We’re looking at developing this idea further in a future project. If you work in a local authority, and are interested in partnering with other local authorities in a Local Digital funded project to develop this prototype into a resource that could be used across the sector to improve services… please do get in touch!
Our Public Square work focuses on citizen engagement in local democracy, and we think a playbook could form a key part of this project.
We’re planning a series of guides, case studies and research presented in a clear and accessible playbook format, to be used by councils and other public sector organisations where greater citizen involvement in decision making is a goal.
Our favourite playbooks
There are hundreds of great examples, but here are the ones we’ve singled out as particularly strong:
- Thoughtbot’s playbook for software design and development
- GV’s design sprint playbook
- Atlassian’s team playbook
If you’ve been working on a playbook, or your organisation already has one that you think is doing interesting things, please do let us know.
Image: Playability.de (CC by-nc-nd/2.0)
Against conventional wisdom, we’ve just published the staff manual for FixMyStreet Pro online, where it’s easy for anyone to access.
When we were putting this manual together, we thought we’d have a quick google round for other council SAAS documentation, to see if anyone was doing it particularly well.
We didn’t get very far, though — it seems there’s a culture of corporate secrecy amongst other suppliers, and a fear of publishing such materials in case of imitation.
It seems that our decision to publish our entire manual online, along with a handy print version, freely available with no password, is perhaps a little unusual.
Why so open?
We’ve gone our own way on this one for a few reasons.
First, because it helps our clients. We know that it’s far easier for customers to look online for materials than it is to remember where they’ve put a physical handbook.
We know we could have put it behind a password, but that just adds an impediment for our existing customers, as well as for anyone hoping to understand the service a little better before making a purchasing decision. Plus, who remembers passwords for something they might only be accessing a couple of times a year? It’s just extra faff.
This way, staff only need bookmark the documentation page, and they’ll always be able to find the most up to date version of the manual.
There’s another reason as well, though. Most mySociety codebases — including FixMyStreet — are Open Source, meaning that anyone who wants to can inspect or use the code for their own purposes. If anyone really wanted to know our ‘secrets’… well, they’re already out in the public domain.
We reckon there’s more to gain by publishing our instruction manual than there is to lose. Sure, competitors might see what features we offer, and they might even copy them. We’re confident, though, that our customer service, company culture, and our insistence on making our products as user friendly as possible, all give us an advantage that imitators are unlikely to be able to match.
So, if you’re from a council yourself (or if you’re just curious) please do go ahead and read the manual. We hope you’ll find it of interest, and that it might cast some light on what makes FixMyStreet Pro different from other offerings in the field.
Image: Alexandre Godreau (Unsplash)
One of the projects we’ve been working on at mySociety recently is that of making it easier for people to set up new versions of our sites in other countries. Something we’ve heard again and again is that for many people, setting up new web applications is a frustrating process, and that they would appreciate anything that would make it easier.
To address that, we’re pleased to announce that for both FixMyStreet and MapIt, we have created AMIs (Amazon Machine Images) with a default installation of each site:
- Instructions for the FixMyStreet AMI
- Instructions for the MapIt AMI
You can use these AMIs to create a running version of one of these sites on an Amazon EC2 instance with just a couple of clicks. If you haven’t used Amazon Web Services before, then you can get a Micro instance free for a year to try this out. (We have previously published an AMI for Alaveteli, which helped many people to get started with setting up their own Freedom of Information sites.)
Each AMI is created from an install script designed to be used on a clean installation of Debian squeeze or Ubuntu precise, so if you have a new server hosted elsewhere, you can use that script to similarly create a default installation of the site without being dependent on Amazon:
In addition, we’ve launched new sites with documentation for FixMyStreet and MapIt, which will tell you how to customize those sites and import data if you’ve created a running instance using one of the above methods.
These documentation sites also have improved instructions for completely manual installations of either site, for people who are comfortable with setting up PostgreSQL, Apache / nginx, PostGIS, etc.
Another notable change is that we’re now supporting running FixMyStreet and MapIt on nginx, as an alternative to Apache, using FastCGI and gunicorn respectively.
We hope that these changes make it easier than ever before to reuse our code, and set up new sites that help people fix things that matter to them.
Photo credit: duncan