Chris Fleming
Partner
In Public Digital we often talk to clients about working in the open. We think it’s a key ingredient of successful digital transformation.
Working in the open means showing people the work you are doing, as you’re doing it. At a minimum this should be people within your team and people across your organisation. Even better is sharing publicly, with stakeholders outside your organisation who have an interest.
Working in the open is not just about demonstrating progress, but also talking openly about mistakes, changes, and things you’ve learned. It’s partly to support communications, to help you build a movement for change. But it’s also about good governance. It gives stakeholders a window onto your work that drives up quality, helps unblock, and manages your dependencies. Work in the open by being open about the work.
Typical examples of working in the open are as follows.
Hosting ‘show-and-tell' sessions. A show-and-tell is a regular (every 2 weeks, say) open invite event. The team does a short presentation about recent progress, and allows time for questions at the end. Importantly the team does not simply give a status update but “shows the thing”. Such as prototypes, designs, research, or other lightbulb moments.
Publishing regular updates on the team’s progress. For instance by writing and publishing weeknotes. Or writing regular posts about more specific things as they learn them. This could be a set of insights from user research sessions. Or the logic behind making a particular choice about a technology.
NHS trust digital leaders Amy Freeman and Andy Callow both publish weeknotes.
NHS Digital hosts a series of blogs on transformation, technology, and design.
The Defra Future Farming programme blog.
Publishing code and documentation as open source. When a digital team is developing a digital service or piece of software they should code in the open wherever possible. Publishing code in public repositories helps teams focus on the quality of their code and documentation. It allows others to build or copy the work that has been done.
GCHQ's internal Boiling Frogs research paper on software development and organisational change. If GCHQ can work in the open, anyone can.
NHS design and prototyping kit code repository.
The Government Digital Services’s code repositories.
Using workplace messaging tools. This is one of the simplest things you can do to help your teams work in the open more. Posting information in a ‘chatroom’ rather than sending an email switches the default visibility of a message from closed (only the people copied get it) to open (everyone in the channel or room gets it). This helps all the team know what’s going on, and allows the team to discuss important topics together. It also allows discussion to happen asynchronously without the need for a meeting.
Richard Pope has published a brilliant thread on twitter of some of the things teams publish in the name of working in the open & transparency.
Traditional methods of project communication typically follow these patterns:
These types of communications are often impersonal, inauthentic, and frankly boring.
Working in the open is typically low cost and has a number of advantages
It supports better project communications because:
It supports better project governance because:
It supports capability building because:
If you want to build trust, confidence, and learning, we suggest you work in the open.
More advice on agile communications from Giles Turnbull.
More advice on weeknotes from Giles and Ben.
More advice on running great show and tells.
More advice on doing presentations.
More advice on coding in the open.
Partner