How to be a better collaborator

The internet is awash with articles about improving your collaboration skills. Have a look. We need to communicate clearly, listen actively, be open to different ideas and so on. Yes, I agree about all of these things. But they seem to be a bit vague, and not that helpful in the public sector right now.

I’ve been reflecting on why collaboration happens in the LocalGov Drupal community, and why there’s been less of it in other places I’ve worked. A couple of pints with Adam also helped. Scroll down for a few thoughts.

Mission patch stickers from LocalGov Drupal Camp 2026 in Westminster, UK. Photo by me
Mission patch stickers from LocalGov Drupal Camp 2025 in Westminster, UK. Design by Sally Varne, photo by me

1 Consider other people’s needs as well as your own

Many councils and colleagues go on a journey when they join the LGD community. I think I did the same myself back when we started. Most join thinking solely about the needs of their citizens and council, but over time some begin to wonder about how these apply to others. They realise that including a wider set of users from other places makes things better. They start looking for common or shared needs.

I do this instinctively now. From small tweaks to major new features, I think about who might benefit from the change, what they might need and how to involve them in the work.

It’s easier for me to do this as Product Lead of LGD than as a digital lead in a council. It’s part of my job, and council colleagues aren’t typically encouraged to think about the needs of citizens elsewhere. But I’ve seen the best digital leads in our community do this successfully and often, and they and their council benefit as a result. 

It might take them a little longer than doing nothing, but the trade off is better feature development and more of it, as councils across the country start doing the same thing.

2 Share everything openly

I’ve seen people, teams and organisations keep their cards so close to their chest that they end up delivering nothing of value. Instead they spend time second guessing themselves, trying to anticipate what others are doing, or revisiting/ duplicating work.

I don’t think LGD is perfect here. A lot of organisations in our community still work alone and in private, but we’re definitely improving. There are more open and active collaborative projects going on now than when we started.

The LGD core team is leading by example with public roadmaps, shovel ready projects, and lots of events targeted at specific interests within our community. We’ve also got a buzzing Slack channel where team members are always around to chat about new ideas.

We’ve made it clear what work we’re doing, and the subjects we’re interested in. I’ve heard talk of Human or Team APIs previously, and it feels like we’ve provided that: here’s our current work, future plans, and ways of getting in touch.

If you’re not able to share openly as an organisation, have a think about why not and try to address it.

3 Acknowledge what you know and don’t

As a Product Manager, I’m fine with uncertainty – it’s part of the job. I’ve found that the best collaborative people, teams and organisations are upfront about what they know, and what they don’t. They’re humble about it. They invite others to fill the gaps.

We do this in the LGD community all the time. The recent Dev Days run by Aaron, Finn and Tim in our team were all about combining different people’s skill and knowledge to get things done. Everyone came along ready to get involved for the greater good.

If you have a challenge to overcome, think about the parts of the puzzle you have the answers to, and who else holds the rest. Then consider how they could get involved.

4 Have a shared endeavour

The LGD community has a shared goal of improving our code, and growing our community so we can make the best and most inclusive public sector web publishing platform around. We haven’t written that down or run workshops about it (maybe we should?), it’s just evolved that way. 

I haven’t yet found a good lightweight framework for aligning multiple teams – everything I’ve seen has led to generating endless docs and OKRs for a PMO machine rather than doing meaningful things for end users. If you have suggestions to avoid this, please let me know.

One thing the LGD has been able to do reasonably well is focusing on specific missions, generally delivering between 3-5 per of them year depending on their size and complexity.

Council and supplier colleagues continually post about their needs on Slack, and talk about them at community events. As Product Lead, and with the help of the core team, I look for patterns in these needs and propose new missions twice a year – during our virtual LGD Week, and in person at LGD Camp. We also talk about them in our newsletters and on Slack, so everyone has a chance to comment. 

If any proposal is judged to be good enough for now, we’ll add it to our backlog, and then prioritise based on the community’s strength of interest.

This missions based approach means we’re focused on work that most of our councils will be able to use. It also doesn’t prevent people from working on their own stuff – there are lots of ways to get things done.

5 Find simple ways to stay aligned with others

In the early days of the Government Digital Service at Aviation House, there was an incredible curvy glass wall with a swimlane for each product split into now, next and later columns. Does anyone have a photo of it?

Product and Delivery people would gather around this wall every Thursday to talk about new work and anything marked with a red dot (which anyone could place ahead of the meeting).

Years later, this remains one of my favourite meeting formats. Was it your idea, Jamie Arnold? In half an hour or less, you got to hear what everyone was doing, and checked how we aligned. Problems and opportunities could be quickly identified.

I’m still doing something similar today with LGD councils that do a lot of development work in house. It helps us see who’s spending a lot of time and money on any specific issue, and how we could make that investment do more for everyone.

Whatever method you settle on, it needs to be something quick and easy to follow that encourages conversations amongst the right people about the work and how you approach it.

6 Always be iterating

Maybe this goes without saying, but you always need to be ready to change the way you’re working. From two councils to 60+ now, we’ve changed a lot at LGD over the years. 

Rather than changing for the sake of it, we’ve tried to stay focused on our shared community goals. For example, we’ve been working on growing contributions to our code and documentation for a while, from making the assets easier to access, to holding in person Dev Days with introductions to contributing and real life challenges to work on. Recently we’ve seen a huge lift in code contributions, so it’s definitely making a difference.

Think about what’s working and not for you, and changes you can make immediately and over the long term.

7 Work in an organisation that supports all of the above

LocalGov Drupal is financially sustainable and we can make decisions quickly, so all the above is straightforward to organise. If your organisation isn’t able to do these things, maybe start with identifying individuals who you can align with to start making changes. 

My good friend Ali used the phrase ‘coalition of the willing’ years before our current Prime Minister, and she’s so right. You can do a lot with a few people who are bought into an idea, and show up for each other.

Thoughts welcome

It feels like everything above ought to be doable in the public sector. After all, we’re not in competition with each other – public funding ought to mean collaboration and public code as standard, surely?

As with all of my blog posts, I’ll be coming back to this one as new ideas pop into my head. Please let me know if this is useful or not, and if you’ve any comments or suggestions. 

4 responses

  1. […] Callaghan – who knows more about this stuff than most – shares his thoughts on how to be a better collaborator, based on his experience with the LocalGovDrupal […]

  2. […] I write a lot about how government should procure custom software, but all of my high-falutin’ theories are built atop some crucial prerequisites that I don’t often write about. I recently wrote about the enormous value of hiring people who understand how technology works, and in the spirit of that, I want to point you to Will Callaghan’s recent blog entry on the subject: “How to be a better collaborator.” […]

  3. […] How to be a better collaborator by Will […]

  4. […] How to be a better collaborator […]