While some platforms and tools may be centrally created and operated, others may emerge from a particular project, or be collaboratively developed between different parts of government.

Achieving this can be challenging in a world where government projects and agencies are accustomed to having control over everything within their policy domain, while often having little control over that which is adjacent. The dominance of a “not invented here” culture could render moot the work done by platform teams.

By fostering a culture where teams are encouraged to think about users beyond their own domain, and by investing in shared tools, these silos can begin to breakdown.

1. Work in the open and use cross-government tools

If teams can’t find each other’s work, the chances of them working together are slim. By understanding the needs of teams across government, in areas like source control, project management and deployment, you have an opportunity to reduce barriers to collaboration.

Google, for example, has a single version control system for its code, which thousands of engineers across the organization have access to. It enables them to find, reuse and improve existing components.¹ Estonia and the USA both emulated this, with publicly searchable repositories of source-code.²³

Shared project backlogs, such as those operated by the British Columbia Design System allow anyone with an interest to suggest an improvement. ⁴. The Federalist publishing platform maintained by 18F allows anyone to submit issues via github and has a public chat room for users to ask questions.⁵ The Pipeline project in the UK, lets different local governments share the projects they are working on and solicit for collaborators. ⁶ While, in Italy, the team leading the development of a national population register maintains a public forum where the 8000+ municipalities involved in the project can ask questions.⁷

Identify opportunities for using common, cross-government tools for things like source-control, project management and messaging. Publish code in the open, and under a suitable open license that makes reuse simple. Create a public register of projects currently in development, ideally with links to open backlogs.

2. Foster a culture of sharing

Shared tools are not enough on their own, and while publishing open-source code is necessary, it is probably not sufficient when it comes to collaborative working. For this reason, a recent study of code.gov has recommended that, in addition to publishing code in the open, agencies also invest in community management and ensure that the reasons for publishing code are clear to all.⁸

The barriers that exist to prevent people from contributing to a project may be cultural rather than because of tooling.⁹ People may be time poor, lacking in confidence or permission, so you will need to work to foster a culture where teams across government think beyond their immediate domain. Community events, like those organized by #OneTeamGov and #GovDesign, create spaces for people to share their work and establish shared ways of working. Both are grassroots efforts that bring people working on digital government projects from different agencies (and different countries) together.¹⁰¹¹ Governance process and guidance also need to support (and hold to account) teams in using platforms and looking for opportunities to collaborate. The digital service standards, playbooks and assessment processes that many countries have created provide an opportunity to do this.

Celebrate and reward people for working collaboratively across silos, be that via community events, performance reviews or encouraging them to write about their work. Ensure that the processes you create for people to use and contribute to platforms are open and inclusive.

3. Get the leadership incentives right

Teams need to feel they have the permission and support to work in this way, and that means the leadership incentives need to be right. Cross-silo working is hard if managers are focused on their own domain rather than the value to the wider organization. For this reason, one of Amazon’s leadership principles is “ownership”. Managers are encouraged to “act on behalf of the entire company, beyond just their own team” and “don’t sacrifice long-term value for short-term results”. ¹²

Leaders taking a platform approach to government need to be comfortable allocating time and money to support work that could have a wider benefit, and help everyone feel it is part of their job to work together.

Example: Building a community of contributors for the GOV.UK Design System

The GOV.UK Design is an open-source project that takes contributions from across UK central government.

“When we started working on the contribution model for the GOV.UK Design system, we optimised it for the scenario of one individual contributing a whole design pattern including all of the research, code, design and guidance.”

“We treated with that as our “stress case”, believing if we could deal with that, other types of contribution would be easier to support in comparison. But we’ve since realised that if you build a model around the people who have the time, confidence, permission and knowledge to do that, it may only work for a small, highly-engaged and relatively privileged group of people.”

“We’re now considering how to make contribution possible for people who might find it harder to contribute. It’s important to understand what barriers they might face, and what we could do to reduce them.”

“You also need to foster a spirit of collaboration. The right tooling, processes and documentation can help, but it’s as much about creating the cultural infrastructure to support collaboration as anything else. That’s hard to measure, but you can see it when it’s happening.”

— Amy Hupe, Senior Content Designer, GOV.UK Design System