The best digital teams I’ve worked on give off a buzz when they are working. Even on very large teams, with hundreds of people working in a shared environment, there is an energy, a feeling of stuff getting done.

Sometimes, though, that energy is missing. I’ve worked on projects like that, I’m sure you have too. Instead of energy and harmony, there’s friction. People sitting just feet apart don’t know each other’s names, let alone what the other teams are working on.

I used to work for the UK government’s tax revenue department, HM Revenue and Customs (HMRC), and we did something very deliberate to tackle this problem: we started doing showcases. A showcase is a fortnightly run-through of what every team has been doing.

At its well oiled peak at HMRC, over 20 teams presented in our showcase. Two people spent half a day doing set up and facilitating. We almost always completed within one hour. We celebrated, we commiserated, we complained, occasionally we were wowed. We regularly had 150 people there, from inside and outside the digital and technology team. Visitors were always impressed at the sheer energy of the thing.

As our organisation’s focus changed and the wider team grew bigger, we worked hard to establish what the showcase was for, and to improve how it was run. It initially focused on demos of working software, but as it grew it also became a forum for showing how to grapple with the hard problems you need to solve when building user facing government services.

To keep the quality of showcases high, we developed a set of principles. These emerged from asking ourselves questions that focused on the purpose of the showcase as a session for sharing information and building connections between the teams in our organisation. They helped us answer questions like: are the right people attending? What is useful for the people attending? Are we learning about each other as teams and people, or just as roadmap items or new features?

The principles that helped us were:

1. Every team has to present every fortnight. No exceptions. We wanted people to learn who other teams were and what they were doing — even when they were stuck. In a world of rapid delivery, if “nothing happened”, that was a story. Otherwise everyone was shipping something every week, so you could talk about it.
2. Each team has 2 mins, that’s it. A time limit forced people to share the most important things. People sometimes abused the limit to show something they were particularly passionate about but in general we helped people to get very good at showing something interesting in 2 minutes.
3. Maintain a strong bias to showing working stuff. To avoid it being a status report. Demos of working software, user research sessions, changes in policy or processes — these made a bigger impact and people remembered them better.
4. Milling around afterwards is encouraged. The showcase built moments of connection between people and teams, we wanted people to immediately build on those moments. We made sure the showcase happened towards the end of the day and chose a space designed for people to have impromptu conversations afterwards.
5. Every team member is encouraged to present. Product managers, software engineers, testers, delivery managers , researchers, designers — we wanted people to own their contribution and present their successes, problems and learning. We also introduced every new person joining the organisation and got them to stand near the front and wave.
6. Every week, everyone who presented attends a retro, immediately after the session. We used this to tackle pain points with the AV setup, timings, handovers and more. We regularly debated whether the format and content were meeting the needs of the people that attended and made changes when we felt things were going off track.

The showcase played an essential role in keeping people aware of what was going on with other teams. My role running the platform team meant I needed to have some awareness of what is going on with other teams — will they need some help launching a new feature? Are they new to the platform and maybe not making the most of it? Will they be giving me a headache soon? It is hard to keep track of what is going on with 20 teams, this made it a bit easier.

Almost always I came away with a series of small things on my radar that I could get my team to go and investigate. I’d chat with my team members who were there: “You know when that team said they were using a graph database, where is that graph database? Have they thought about how it is going to work in production? Let’s set up a session to go through it with them.” I’d catch people in the room afterwards. I saw this happen over and over with all sorts of teams: “You’re going to send a bunch of emails? So are we. Let’s work it out together…”

This wasn’t the only way we communicated things, and it certainly wasn’t the only way we kept people informed of breaking changes or big impactful events. It was an incredibly useful heartbeat for stepping out of your world and remembering to care about what other people were doing.