Debunking the Myths of Cross-Disciplinary Collaboration

Alastair Simpson
Head of Design, Atlassian

From the DesignOps Summit website:
Trying to plan and collaborate across different teams whilst creating a cohesive culture can sometimes feel like a pipe dream. This is especially true as we start to work with more distributed teams and as we add more and more specialised functions to the mix, such as Design, Research, Content Strategy, Product Management, Engineering, Data Science…oh my! There are also a few common myths which are just not true in today’s modern team environment. Come along for a few laughs as we explore a few popular myths, debunk them and arm you with a few practical tips and ideas to help you build world-class products.

Sharing stories for the 15 years he’s been working in cross-disciplinary teams. He started with a video of his kids – his daughter is 5 and his son is 2.5. Teams have different skills, expeirences, and maturity levels. But we kind of ignore those differences and standardize – but that is dangerous. We think that is how we scale, and gain efficiencies.

But in doing so we remove the human side of teamwork … and we focus on process instead of outcomes.

He has been thinking about his own beliefs about effective teamwork. It’s about partnerships outside of design, and it’s messy (because it’s abut peple). It’s about havign a clear purpose.

There are a bunch of myths around these beliefs – he will share four of them:

• Solid roles and responsibilities solves all.
• Researchers do all the Research work.
• Trust in teams just happens.
• Aligning on where we are going is the most important thing.

Myth #1

Solid roles & responsibilities will magically solve everything – e.g. research does this, design does that. It becomes and us versus them strategy. Who can we blame when something goes wrong? But teams are made of different indivduals with different skillsets. Our teams, projects are never quite the same.

Strict roles & responsibilities can exacerbate this. Focus on responsiblities, but don’t assume they are tied to specific roles. At Atlassian, they start with the business outcome, and then they discuss what needs to be done to get there. Decouple the roles conversation – your internal roles structure is irrelevant to your client.

Be clear whether you’re progressing, or whether there are risks. Eight attributes that the team uses to self-assess. This is driven by the Ops community at Atlassian:

You can download their Health Monitor at http://www.bit.ly/ops-health.

The a-ha is that great teams want autonomy, mastery, and purpose – they are not going to get there with rigid process. Focus on responsiblities and outcomes – not roles and responsibilities.

Myth #2

The second myth is that researchers do all the research work – or that Designers do all the design work. If you believe that, you are perpetuating and us and them mindset – it creates needless friction between teams, and it really doesn’t help the project. Think instead about co-creation and joint responsibility across teams.

The big reveal needs to stop, it doesn’t work – you have to bring people along that journey. Fifteen years ago he did research with an external agency, and the executive fell asleep during their final presentation. True story. In retrospect he realizes that the project team didn’t bring him along, and he wasn’t engaged.

A year ago Atlassian re-launched Jira, their flagship product. When planning that, he got everyone in the room. He also created a communication plan for the executive team. After just a few weeks, engineers were talking abut architectural decisions – they were engaged and wanted to be part of the solution.

Fight to get the right people in the room. If you are doing research or design work – get it on the walls, share it halfway through. Have a brown bag – it’s more effective way for teams to absorb customer empathy along the way, and it creates a more constructive and supportive team environment.

It is incredibly easy to set up a lab for less than $100. You can download some information from Atlassian about that at http://www.bit.ly.ops-atlab.

When you have non-designers giving feedback on design, it’s hard for everyone involved. There are cards by a company called Attractive. If something feels too technical, the flip side says “human” – in other words, it provides language for how to address that feedback or concern that works for non-designers. It levels the playing field for providing feedback.

The worst thing to do is go through the process and checking things off the list. In exceptional teams, a great designer will be involved in QA. A great engineer wants to create something beautiful for their customers. That mutual sense of ownership enables success as a team.

Yes, effective teamwork is about partnerships. But the unit of delivery is the TEAM. Demand disciplines come in at the right time. That myth that researchers do all the research work. The reality is that building great products is a team sport.

Myth #3

The third myth is that trust in teams just happens. It’s hard to build trust. Imagine someone asks “Hey, why did you make that decision?” In person with someone you’ve worked with is one thing. But imagine doing that in Confluence or Slack. It comes across like “Hmm … I”m not really sure why you made that decision.” If they are in a different timezone and they’re waking up to a huge number of notifications. It comes across as “You are an idiot! I have no idea why you make that decision!”

What happens if people start adding comments … 30+ comments, 85+ comments … that erodes trust.

You have to know when to raise the bandwidth.

Mike Knoop, Zapier co-founder

If 10+ people are commenting on something in Slack, get on a call. Atlassian – everyone is dialed in from their laptops (even if they are together in an office conference room) so all the faces can be seen. There is something called presence disparity – the call will be ineffective if you can’t see the visual cues.

Here are some tools from Atlassian to help with that – http://www.bit.ly/ops-remote.

At the start of projects, meetings are our friend. We have more meetings at the start of the projects. Teams are flown in from different parts of the world, because trust is lowest at the outset. As trust improves, the number of meetings can go down. Meetings can be held remotely.

How to run meetings so everyone is included? Here are some tips from Atlassian – http://www.bit.ly/ops-inclusivity.

Show people that you care. When was the last time you asked someone how they are doing, and didn’t actually rush past them? Or what they did on the weekend … and waited to hear the response? Watercooler conversations help build relationships and culture. Every Monday morning they share what they did over the weekend. Building relationships is the single most important cure to any team challenge. But it has to be deliberate – it has to be intentional.

Help to build relationships that can withstand those messy moments.

Trust takes effort – invest in it. The simple things make a big difference.

Myth #4

Last myth – aligning on where we are going is the important thing. You march into a sprint cadence … only to realize later that the problem was tougher than you thought. If you start with a shared understanding of customers, and goals. But – also develop a shared understanding of how you got there. Why is your product like it is today?

It’s about having a clear purpose. But a shared undrestanding of how you got there helps create that sense of purpose.

During WWII, the Cargo Cult saw planes, cargo being deposited. When the planes stopped coming, they created wooden planes, runways, and people made out of wood. But the planes didn’t come back. They followed all the apparent pre-sets but they are missing something essential. Don’t blindly follow process – great process can lead to terrible results. Invest in the individuals in your team because that is ultimately makes great teamwork.