Productive collaboration: how to build a workflow that works across disciplines
At CDS, we build our product teams to consist of product managers, researchers, designers, developers, policy experts, and communication specialists. But, assembling a multidisciplinary team does not mean the hardest part is done. All of the individuals that you’ve gathered onto your team come from different disciplines and they each have their own preferred ways of working. This includes (but is not limited to) the pace, tools, hours, times of day, environmental conditions, communication methods, and the ways each person prefers to give and receive feedback. With so many different variables, it’s easy for things to quickly get overwhelming.
There are two main ways of dealing with this:
- Assign leaders and managers with the challenging task of establishing consensus — by determining the ways in which they think their teams should work, and hope everyone responds favourably, OR
- Let teams chart their own path: figuring out these differences themselves as they get used to working with each other, and hope they’ll reach a productive consensus on their own.
These strategies don’t always end up being very productive when there are so many unique work styles at play. They tend to create more problems than they solve and result in teams that are reactive rather than proactive.
How can we tackle some of these challenges when teams are formed? And how do we continue strengthening teams as the project goes on?
Crafting team process through a multidisciplinary lens
Culture plays a large role on any team, regardless of its size and structure. But we can’t expect team culture to address all of our problems. There is no one-size-fits-all way. It boils down to crafting a multidisciplinary approach to team process and creating an organized workflow that meets everyone on the team where they already feel comfortable operating and contributing. This is definitely easier said than done, so below is a window into how our citizenship product team has been iterating to get better at this.
We’ve been working together to build our own unique multidisciplinary approach over the last six months (and spoiler, we’re still working on it!). Our product manager has done an excellent job of aligning us around the ways in which we like to work, by creating space to discuss those details openly.
During our initial orientation as a team, we used a tool called “A User Manual for Me” created by Cassie Robinson.
Each person had to fill this in, and then share it with the team. This enabled us to talk through our work styles that don’t always come up organically in conversation. We’ve since used variations of this tool across other product teams at CDS, and created a bilingual digital version for everyone on our wider teams to update frequently.
We also used a tool from the Atlassian Team Playbook called “Roles and Responsibilities” to define and chart each person’s skills, contributions, and needs.
Download a copy of the Roles and Responsibilities tool.
We used this tool with a bit of a twist. First, we filled it out thinking strictly about ourselves. Rather than ending the exercise there, each of us paired up with someone else on the team to fill out this sheet again, this time focusing on how we perceived their role — without talking to them about it first. Afterwards, we shared as a group, and each person took turns reading out what they wrote down for themselves, sharing what they’d written about others, and engaging in a discussion around our perceptions versus reality. This process enabled us to all get on the same page about how we contribute to the team and the ways in which we can lean on and learn from each other.
The tools we use to work together
Armed with a strategic direction and an improved understanding of how each team member works, we were in a better position to create an inclusive workflow together.
As our product team worked iteratively, conducting a lot of testing with users on a biweekly basis, we needed to rapidly make changes to the product we were working on. With this, there was a need to translate all the insights we gathered from research into design interventions that could be implemented by our developers in a timely way before our next round of testing. Working in this way, we realized we needed line of sight into each others’ tasks, to link researchers, designers, developers, and all other members of the team.
As a team, we used Trello to manage our product backlog and keep track of who was working on what during each sprint. In addition, we created a secondary board, called our Decision Dashboard, that enabled us to document the issues users experienced during each round of testing. As a team, we reviewed these issues and considered how we might tackle them through various design and development interventions. We created detailed cards that describe the changes needed, and attached the original “issue” cards they related back to. This way, we can trace every decision back to a research insight. Once a card is ready to be picked up by a developer, we move it to our “in progress” column and duplicate it to our general trello board to officially incorporate it into a sprint.
Developers are engaged throughout the design process in meetings, research activities, and on the decision dashboard. In an effort to help our entire team keep track of all the changes needed, we also open issues directly in GitHub outlining all the details developers need to know. GitHub allows us to engage with developers in a way that is familiar and productive to their existing workflow structure. GitHub also allows members of the public to raise inquiries and issues they experience as they check in on the iterations of the services we build. This has been particularly helpful on our IRCC product work, as we’ve continued to gain insights
As we strive to work in the open, it’s not just about how we operate externally with the public. It’s a frame that we can apply internally across all product teams. These ways of working made it easier for our product team to communicate and keep track of each other. As CDS grows and builds larger teams that include members from partner departments, creating shared processes that address the unique needs of multidisciplinary teams and their members is more important than ever. Larger teams need not be synonymous with larger challenges.
This is a glimpse into our process. It’s still a work in progress — patience, flexibility, and continual iteration are key. We’ll continue to share how we’re adapting our workflow processes in hopes it helps you improve yours as well.
If you’re looking for guidance or have tips you’d like to share, we’d love to hear from you!