What benefits do cross-functional teams really deliver? Better products and less re-work according to the speakers at UXDX 2020. But it’s not all smooth sailing - the challenges of shifting to, and value received from cross-functional teams was one of the most burning questions arising over the three day conference. Let’s delve into why companies are making the move and what they can gain from this transition.
Marty Cagan defines Discovery as “figuring out what you need to do”. He explains that Discovery is the process of validating the four key risks of product development; is your solution valuable (people will buy it or use it), feasible (you can build it), usable (people can figure out how to use it), and viable (it makes commercial sense). No one person can answer all of these questions accurately which is why it is critical that teams work collaboratively during Discovery to offer different viewpoints.
But you can’t just get people together at the start of product development. In a traditional project, a single business case upfront might determine whether it will proceed. With product development, Marty explains that Discovery is continuous and not just a phase, because you are continuously learning as you develop. This was also a core piece of Jeff Patton’s talk on Dual Track Agile, that Discovery and Delivery are happening continuously and in parallel. Jeff highlights the importance of the Team of Three (Product, UX / Design and Dev) to be able to continuously assess the efficacy of the solution.
Ryan Singer has a different approach to Discovery; a separation between Shapers, those who define what is to be built and Builders, those who build it. Ryan’s argument is that individuals need to specialise so they can become great in their specific areas. For this reason, he believes that the Shapers (loosely aligned to Product Managers) should spend their time thinking on the big picture and defining what needs to be done and Builders (designers and developers) focus on the most effective way of building the shaped work. To be clear though, Ryan isn’t advocating a return to large projects - Basecamp limits the max length of any work to 6 weeks. And crucially, if some work slips it is automatically cancelled, as opposed to the continuous extensions that can happen in a lot of death-march projects.
Either way, the consensus is that a continuous discovery phase helps teams to improve product outcomes.
One of the key challenges when moving to cross-functional teams is the blurred boundaries between roles. There is no longer a clean delineation between designers, researchers or developers. Often referred to as T-shaped team members, this is where a team has a core area of strength but also bears knowledge across the breadth of activities required to bring an idea to production. Lowell Goss, Head of Design at Reddit, referred to this during his talk at UXDX 2020. He described how companies can create better solutions by tapping into the creative strengths of the entire team. Gianni Clifford, Product Design Manager at Zendesk, highlighted the value of getting developers involved in design critiques so that you can effectively challenge design decisions at the earliest stage possible. And Peter Wang, CTO at Buzzfeed, advocated knowing your role outside of your title because titles mean different things in different companies.
Speaking The Same Language
Jennifer Cardello, VP of UX Research at Fidelity, highlighted the value of shared vocabulary for aligning people on what needs to be achieved. Within an organisation, different areas or teams will use different language. This is fine when you stay working in your silo but it can lead to challenges when you start working cross-functionally. In the context of Design Systems, the UX manager at Shopify, Hayley Hughes highlighted the benefits of a shared language as it helps to deliver consistency across teams when scaling. When used for Event Storming, Savvas Kleanthous, Head of Engineering at ParcelVision, highlighted that the benefit is getting a shared understanding of all of the different “events” that happen in a system across all people involved in project development. In all cases the benefits of a shared language was reducing miscommunication.
Everyone has a unique bias or viewpoint developed over their career. When communicating through documents, such as handovers in a waterfall process, the risk of misinterpretation is very high due to these differing viewpoints. By involving people directly in the work at all stages we can significantly reduce the risk of miscommunication, which in turn improves the quality of the product and reduces the need for rework.
Over the next few posts, we’ll cover off some of the other trends that arose at UXDX 2020 such as managing autonomous for teams, necessary budget changes, scaling teams and remote working.
If you enjoyed this year’s conference as much as we did, why not register your interest in next year’s conference. We’re running a pre-sale in December where you can save 50% off the regular ticket price. Sign up for our newsletter at UXDX.com to be the first to know when the sale is announced.
I hate "It depends"! Organisations are complex but I believe that if you resort to it depends it means that you haven't explained it properly or you don't understand it. Having run UXDX for over 6 years I am using the knowledge from hundreds of case studies to create the UXDX model - an opinionated, principle-driven model that will help organisations change their ways of working without "It depends".
Free Community EventsSee all
Get latest articles straight to your inbox
A weekly list of the latest news across Product, UX, Design and Dev.