I recently was asked to share some thoughts on how you can cultivate a culture of collaboration across a product organisation where multiple teams are all working on their own products and risk becoming siloed.

Whilst teams being independent and able to move fast is a good thing, this can result in different parts of the organisation operating differently, becoming inefficient, reinventing the wheel and ultimately not delivering the overall strategy and value to its users.

This article summarises my advice on the topic, based largely on my own experience of growing a product organisation at FutureLearn. We grew from zero to seven cross-functional teams and 75 in product, technology, and design by the time I left.

I’m going to talk about three broad goals that I think help teams collaborate effectively in organisations with scale:

1. Create a shared sense of purpose
2. Build a consistent environment
3. Nurture a supportive community

1. Create a shared sense of purpose and show how everyone contributes to it

Perhaps the most important thing you can do to cultivate collaboration is to create a shared sense of purpose. Make sure everyone has the sense that they are working towards the same goal. Without a clear North Star for the whole organisation that is regularly communicated, teams will inevitably gravitate towards focusing on their team’s short term objectives.

There are various ways that you can help visualise what is sometimes referred to as your agile onion—the idea that a team member can connect their daily work, to sprint goals through quarterly objectives all the way up to the strategy, vision, and purpose.

An agile onion

I’m a fan of how Asana shows this connection through their ‘pyramid of clarity’. This helps you communicate how everything fits together and is a useful tool to help understand where the gaps exist and what isn’t clear.

Asana’s Pyramid of Clarity

The top of the pyramid (or the outer onion), is about being clear on the overall purpose or mission (why your organisation exists) and the vision for how you tangibly plan to make an impact over the long term. The product vision should be succinct, inspiring, tangible, long term, and customer centric. I will be writing more about this.

Next, your strategy should articulate how you plan to make the vision a reality over the near term and from that then flows the various objectives.

For large and rapidly growing organisations, it might be useful to create a ‘vision map’ that shows how everything fits together and how your vision and strategy will help you achieve your purpose/mission.

I’ve recently helped OpenClassrooms to do this. I created a map that enables you to follow the main threads of the narrative and understand the key staging posts towards the 2025 vision. There is a deck that introduces and walks the team through the vision alongside the map that provides an artefact that can be referenced ongoing.

The key thing with all of this is to constantly refer to these artefacts and communicate why you’re doing things using a clear framework that works for your organisation.

This will keep everyone on the same page and help them understand their team’s role, where the work they are being asked to do fits on the map and how it relates to other teams. Make sure that new projects, team changes, quarterly planning etc. are all communicated in the context of these tools.

Visualising your vision and strategy in this way is also helpful for you to design your team ‘topology’. In order to most efficiently deliver your strategy and for your teams to clearly understand how they are contributing towards it, you should design your topology around your strategy and vision.

Often this might also be informed by your customer journey or funnel, with teams organised around different parts of the experience. Organising around the user and their needs should be the biggest influence here, but other considerations may also be a shared technology approach (do teams need specific skillsets and to collaborate more closely) or organisational (do they need to work closely with specific stakeholders).

At FutureLearn, after adopting a marketplace strategy, we organised our teams into three product groups: learners, educational partners, and platform.

FutureLearn’s product groups and team topology

It’s also important to give teams a mission that supports the long term vision and mid-term strategy, rather than a specific product or set of features.

If you task a team with simply improving a particular surface area of the product, they are likely to focus on just making that better rather than thinking more holistically about improving a specific part of the user journey and delivering upon the overall strategy.

We tasked teams with a mission and a key metric to guide decision making in their area and gave them the opportunity to achieve it by touching any part of the product they needed to – provided that they communicate with other teams.

As we grew and our product matured, we realised that it was important to also introduce the concept of ‘responsibilities’. These described all of the key components of the product and ensured that all of the product was owned. It also ensured that a team was responsible for maintaining it and ensuring that it didn’t ‘rust’. This made it easy to organise maintenance and modernisation work alongside work that delivered upon strategic missions.

FutureLearn’s team missions and metrics

To recap:

1. Be clear about how daily work, roadmaps, and teams are all related to a shared driving purpose
2. Use some kind of visualisation to help orientate everyone
3. Keep referring to it so that it sticks

2. Build a consistent environment and guide rails for autonomy

Once teams have a clear sense of purpose and how they fit, you can give them a significant degree of autonomy over how they do it.

However, in order to make collaboration easy, you also need to ensure that there is a shared language, approach, and tools to support it. Otherwise everyone will do things differently and find it hard to connect.

For example, at FutureLearn we gave teams a significant degree of freedom over their own roadmaps but we needed to make sure that these were communicated and shared in consistent ways.

All plans were shared via a joint Trello board. We ensured that ‘Now’, ‘Next’ and ‘Later’ had consistent meaning across teams (this quarter, next quarter and beyond). Each item included an owner (usually the product manager) making it clear to anyone in the company who to talk to about it.

All of the teams had a consistent set of ceremonies such as daily standups, planning, and sprint reviews. Sprint reviews happened in a single morning and everyone was encouraged to take part, at least for other teams in their group and the Scalable Platform team.

We also had a consistent set of organisation cadences that made it clear when change could be expected. Teams worked in fortnightly sprints and were encouraged to adjust plans and improve the way they worked within that time frame.

We planned across the product organisation on a quarterly basis. This enabled us to align plans but also make changes to team personnel or how we worked together across the wider team. Knowing things are stable for a quarter but to expect some incremental changes every three months gives teams the opportunity to find a rhythm and deliver something meaningful. But the relatively short cycle also gives us as a leadership team the ability to be agile with the priorities and improving processes.

With strategic refreshes, this could have a bigger impact on the team topology. Typically our strategy lasted for 12-months, although as with most startups where funding rounds and other unpredictabilities play a part, this wasn’t always the case. The important point is to be as clear as you can about how things are likely to last and give as much notice as possible of a change.

FutureLearn’s cadences

Team identity is really important to creating high performing teams—feeling part of something with a sense of purpose and autonomy over how you do it—and this should be encouraged as much as possible. At FutureLearn, teams created badges that included mascots and in jokes which was a great physical manifestation of this. But you also need to manage expectations around this, which is where the team’s place in the overall sense of purpose is necessary and an understanding of when changes may occur.

FutureLearn’s product team badges

Other things about the environment that help foster collaboration are shared tools that all teams use and contribute to. One good example of this might be a design system.

FutureLearn’s design system

Another important aspect to this is insights. Regularly doing foundational research that members of multiple teams take part in helps teams build a shared understanding of the users. Creating a repository of this that everyone can access and contribute to also helps teams spot areas of shared interest and potential collaboration. Again we used a Trello board for this.

Foundational research at FutureLearn

Lastly, it’s important to involve the team in building the shared environment. This way you get much stronger understanding and buy-in around processes and working practices. It also provides a shared sense of identity across the organisation.

One way we did this at FutureLearn was to run something called The Big Retro, where we mixed up teams and ran a retrospective looking at the things we wanted to keep, change and ideas for how to do it that were bigger than individual teams. This gave us as a leadership team the agency to make some of these changes we need to make and the teams a sense that they were making the change and it wasn’t being done to them. I’ve written more about this here.

Some of the output of the Big Retro

To recap:

High performing teams need a sense of autonomy as well as a clear sense of purpose. But in order for them to collaborate, you need to create a shared language, processes, and understanding of how far this autonomy exists.

3. Nurture a supportive community by creating multiple smaller communities

The final piece is to nurture a supportive close-knit community.

The best way to do this is through creating interweaving sub-communities. Professor Robin Dunbar is an academic who has done lots of research into how communities operate and how many relationships a human can reasonably be expected to manage. Dunbar’s number is quite famous but it actually breaks down into smaller groupings.

Dunbar’s social groups

It’s these smaller numbers that are helpful to replicate in an organisation to create tight bonds and trusting relationships. You want people to have ‘loved ones’ and ‘good friends’ across the organisation, as well as ‘friends’ and ‘meaningful contacts’.

Emily Webber has also written lots more about how Dunbar’s work translates to professional communities of practice.

At FutureLearn we had the concept of product teams but also a strong sense of discipline teams e.g. product management, frontend engineers, technical architects. Building strong communities of practice in these areas naturally encourages collaboration across teams. Practical things we did here were regular team meetings, design critiques, architecture show and tells, discipline team retros and encouraging pairing between product managers and designers on different teams.

Spotify’s teams and communities of practice model

To truly cultivate a collaborative environment and effectively achieve the first two goals that I’ve outlined above, these mini communities need to start with you as a leadership team.

Myself, the CTO and CXO worked hard to ensure that we were always ‘co-parenting’ the organisation consistently and on the same page. We started the week by having breakfast together and informally covering the important things on all of our minds. Major changes were always planned together to ensure that the messages across the communities of practice were consistent. This takes time and effort but without leading by example, your teams are unlikely to see collaboration as important.

FutureLearn’s product leadership team (CEO lurking on the decks)

As well as these communities, we also had cross team players. Roles like UX researchers, technical architects, delivery managers, engineering managers, data analysts… you don’t need one of these in every team, so we’d include one or two of these in each product group. These people were also key to joining the dots between teams with similar missions and in turn part of their own small discipline community across the organisation.

Product group roles

Team moves are another way to do this.

It’s important where you can to keep teams stable, both in terms of mission and personnel. This enables them to build effective relationships and a good knowledge of their problems space and codebase. But strategic use of team moves can help you move knowledge across the organisation, help build cross team relationships and give people development opportunities. The trick to doing this is to try and make it gradual, rather than doing it all at once.

Creating shared moments to collaborate is another way to cross pollinate and form new relationships. One good example of this at FutureLearn was our quarterly Firebreak sprint.

These were two weeks at the end of each quarter where engineering teams could focus on maintenance and modernisation while product management could focus on cross team planning. It provided a natural deadline at the end of every quarter in amongst the more flat sprint rhythm. In this fortnight, shared interest groups from different teams worked together on cross organisational problems, again sharing knowledge and forming tighter bonds.

Finally, regular shared moments are also key to feeling like one community. These might include running things like Lightning Talks or bringing people together to watch a great online talk on a new way of working.

Above all, having a monthly all hands meeting is the most important way to make everyone feel part of something bigger.

These can feel expensive and time consuming. There’s a lot of people involved, who may not always see the point in being there. But I believe the value they bring far outweighs the cost in terms of a shared understanding of where the organisation is going, who everyone is, what everyone is doing and how it all fits together.

These were a ritual that we started at FutureLearn in sprint zero with a handful of people and continued all the way through to 200+ when I left. The way you plan and organise them needs to evolve. For example, we brought in the concept of rotating hosts and set formats to make them easier to plan. However, the principle of them is something that you shouldn’t let go, whatever opposition you might face.

FutureLearn’s first ever all hands in Sprint zero and an all hands in 2020 (pre pandemic)

So. Provide your teams a shared sense of purpose. Show how they and their daily work contribute to it. Give them the autonomy to play their part. But in a way that is consistent with the wider organisation and enables the opportunity to collaborate. And foster a shared sense of community by creating lots of small, close knit interweaving communities.

If you can find your own way to introduce some of these principles, you’ll start to really cultivate a culture of cross-team collaboration.

This article was originally a talk I gave to a leadership team within the Department for Education. Please get in touch if you’d be interested in me talking on this topic.