Cross-functional teams are made up of people from different functional areas within a company. These teams can take many forms but they're designed to be working groups that improve coordination and integration, span organizational boundaries, and reduce the prodution cycle time in new product development. Bringing people together from different disciplines can improve problem solving and lead to more thorough decision making.

Cross-Functional Teams

<ul><li>Cross-functional collaborations bring out fresh perspectives</li><li>There is adequate communication between each team member and those who have certain questions about something that is unfamiliar to them they can easily reach the person with experience in said topic</li><li>Cross-functional teams also hone management skills because in order to work with divere backgrounds and work styles they must develop special skill sets to effectively collaborate and/or lead.</li><li>Cross-functional teams will know the strengths of other teams and understand each others' efforts.</li></ul>

Benefits of having a Cross-Functional Team

This workshop is where we can look for key stakeholders that we can place in a room together for the specific purpose of ideating and defining the project objectives, requirements, and expected outcome. Whilst the benefits of cross functional discovery workshops are clear, there's also a downside that includes: limitation in imagination of product and design and the fear of prospect building will arise most especially when it's seemingly complex.

Cross-Functional Standups and Discovery Workshops

Cross functional teams are a modern take on what has always been at the heart of successful, productive companies; groups of people working together to achieve shared outcomes. However, if executed badly, these teams can feel like a pressure timebomb. In order to execute it properly you must:<ul><li>Find the right balance of skillset</li><li>Have proper goal setting</li><li>Have durable support systems</li></ul>

Implementing Cross-Functional Teams

Getting the most out of groups of multi-disciplined team members‘Cross functional team’ is really just a fancy way of saying groups of people with different skill sets working together to achieve common goals. And that’s what business has always been about. Despite this, the term ‘cross functional team’ or ‘cross functional squad’ has gained popularity over the past decade or so. In a product development context, a cross functional team is typically responsible for building products. And in this case, product managers are often the ones attempting to act as the glue between team members so that the overall team can achieve its objectives. It sounds simple, but it’s often not.<h3>The problems cross functional teams solve</h3>When they work best, cross functional teams solve problems. What problems? The cost of translation Conventionally used in BDD terminology, the cost of translation refers to the cost of translating requirements between various disciplines or stakeholders. Like Chinese whispers, the cost of translation slows down overall product development time. Cross functional should mean faster development since you’re not sitting around waiting for a member of one team to clarify something before you can speak to the other.Lack of perspectivesDiverse groups of people with different skill sets will ultimately solve problems and generate better solutions. If problems are solved only by engineers, or only by designers or only by content writers, it’s likely that the solutions you’ll settle on might be suboptimal.Discipline-based dysfunctionWithout cross functional teams, skilled employees are instead segregated by skill set. This causes problems when different disciplines are pitted against each other; rather than identifying as the ‘product team’ to solve product problems for customers, the narrative becomes ‘engineering’ vs. ‘design’. <h2>How to set yourself up for cross functional success</h2><img src="https://www.departmentofproduct.com/wp-content/uploads/2020/10/Cross-functional-teams.png" alt="cross functional team members" width="628" height="353">A cross functional team in a product context will typically comprise the following:<UL><LI>Engineers</LI><LI>Product manager</LI><LI>Designer</LI><LI>Content writer</LI><LI>QA</LI></UL>Not every company is the same, and not all companies actually adopt the cross functional team or squad model, but those who do will usually have some variation of these roles.If you think about it, that’s a pretty diverse group of people. Engineers, designers and content writers have wildly different skill sets with little in common and this inevitably leads to some tension. But that tension is healthy. It’s tension that ultimately powers the team; without it, the product team would be a stale, homogeneous mess. Like muscle tension, when stretched a little, the team grows as a result.So let’s say you’re a product manager, a member of a cross functional team or indeed an exec who is looking at implementing cross functional teams in your organisation. What are some of the ways to do it?We’ve worked with numerous product teams over the years and this is what we’ve seen work best. Let’s have a look shall we?<h2>Weekly goal setting</h2><img src="https://www.departmentofproduct.com/wp-content/uploads/2020/10/Cross-functional-teams_WeeklyGoals.png" alt="how to set goals as a cross functional team" width="628" height="353">The cross functional team exists primarily to execute on strategy. Yes, many cross functional teams have a high degree of autonomy where teams can decide how to test strategic bets or how to achieve OKRs, but ultimately, much of the time spent as a cross functional team member is on execution.Since the skill sets of team members are so vastly different, it helps to set weekly goals which align with the wider goals of the business. If you’re on a 2 week sprint cadence, maybe the goals can be fortnightly. But the principle is the same. You agree collective, outcome based goals that involve all members of the team.Intercom <a href="https://www.departmentofproduct.com/blog/how-to-build-better-internal-tools/" dir="ltr">built its own tool </a> to track weekly goals. HR startup CharlieHR gives each cross functional team ownership of <a href="https://medium.com/@tomcarra/moving-to-cross-functional-teams-9e4bce313523" dir="ltr">achieving key results set by OKRs</a>. Netflix <a href="https://medium.com/@gibsonbiddle/6-a-strategy-for-each-swimlane-38be75f65129" dir="ltr">empowers each team</a> to own the strategic bets it is placing using its ‘pod’ structure. Balancing Vertical and horizontal alignment<img src="https://www.departmentofproduct.com/wp-content/uploads/2020/10/Cross-functional-teams_Alignment.png" alt="alignment in cross functional teams" width="628" height="353">Before you can decide on your weekly goals as a team, the upfront work to align with the <a href="https://www.departmentofproduct.com/blog/how-to-run-product-strategy-workshops/" dir="ltr">wider business strategy</a> must happen. Alignment is a critical part of successful cross functional working.Horizontal alignment ensures the cross functional team’s workload is relevant to the wider strategic objectives of the business. Vertical alignment ensures individual members of the team know what their role is in helping the team reach its objectives. Both are equally critical and dependent on each other; horizontally aligned teams working on irrelevant things are just as useless as teams working on vertically aligned items who are incapable of communicating with each other. <h3>How to set weekly goals</h3><img src="https://www.departmentofproduct.com/wp-content/uploads/2020/10/Cross-functional-teams_WeeklyGoals.png" alt="weekly goal setting as a cross functional team" width="628" height="353">Keep it simple and borrow from the Checklist Manifesto by creating a checklist of realistic goals to achieve that week. Goals should be outcome-based, just like key results in OKRs.During your weekly planning sessions, set cross functional goals which align neatly to your overall roadmap. Product managers will need to do some thinking before cross functional teams come together but the idea is you craft a set of achievable goals which move you closer to your desired goal.ExampleLet’s say you’re working towards launching a new version of your user onboarding. This will likely involve a huge effort from across the team:<OL><LI>Engineering needs to ensure the frontend and backend are built </LI><LI>UX / design need journeys mapped out to cover all scenarios</LI><LI>Content needs to design journeys which make sense to the user and tick all the legal requirements</LI></OL>A typical set of outcome-oriented weekly goals during your build process might be:<OL><LI>Complete password reset email sends (engineering)</LI><LI>Get brand sign off for new account creation landing page (design / content)</LI><LI>Finish content for SMS 2 factor authentication reset journey</LI></OL>Goals are agreed at the start of the week and are reviewed at the end of the week. Finding the right balance between what’s achievable and what’s not is difficult but teams often get better at it the longer they work together. At the end of the week you can review what’s been achieved, celebrating the successes and delving deeper into areas where you’ve not been successful.Some companies have built their own tools to allow product teams to set and track weekly goals, but assuming you haven’t done that, a simple alternative can be tools like Evernote or Slack. Slack actually has a little konwn posts feature which allows you to create and share a post in your Slack channel with your goals set for that week.<h3>How to link weekly goals to backlog items</h3><img src="https://www.departmentofproduct.com/wp-content/uploads/2020/10/Cross-functional-teamsAndStrategy.png" alt="cross functional teams and strategy" width="628" height="353">One point of confusion that often arises is the relationship between weekly goals and product backlogs. If you’re not careful, running two, parallel systems of weekly goals and product backlogs can get messy, and this is particularly true for teams working in a sprint-based environment, since the sprint itself works using a goal-based cadence.In most product companies, the work of design and content sits outside of the engineering development backlog so it’s best to think of your goals as items which sit above your backlog but beneath your overall product strategy. <h3>What if different parts of the team are working on different things?</h3>Weekly cross functional goals don’t necessarily all need to be relating to the same feature or priority. It could be that UX and design teams are in product discovery mode for future, as-yet-unbuilt features and so UX / design goals would be unrelated to engineering goals. The key is to ensure all goals are relevant, not that they all link to the same piece of work.Setting goals is one thing, achieving them is another. In order to achieve the goals you set at the start of each period, the systems and operating rhythms you put in place are just as important.<h2>Cross functional standups</h2>In companies without cross functional teams, standups normally include engineering and product managers and perhaps scrum masters. In a cross functional set up, daily stand ups will include everyone from across the spectrum. With your weekly goals set, you can refer to them in standup alongside the relevant development boards if not every day then on a Monday, Wednesday and Friday.Whilst many turn their nose up at the necessity of gathering together daily, we’ve worked with teams where they’ve experimented with getting rid of standups and it’s often led to a breakdown in horizontal alignment. It’s ten minutes out of the day, and in a remote setting it’s still the best way to reduce opportunities for confusion.<h2>Cross functional discovery workshops</h2>When you’re deciding what to build next, or how to approach a solution to a customer problem, working cross-functionally can be beneficial. The so-called ‘3 amigos’ session includes engineering, design and product thrashing out some potential solutions to problems together.Whilst the benefits of cross functional discovery workshops and 3 amigos are clear, there’s also a downside. Sometimes, when engineering and design work together from the outset, technical boundaries can limit the imagination of product and design in coming up with solutions. Some (and not all) engineering teams will get terrified at the prospect of building something seemingly complex and will shoot down an idea in its entirety. The role of the product person is to manage the gap between creative, innovative solutions and the realms of what’s technically possible. Scope management is product management, after all.<h2>Ad-hoc, discipline-specific sessions</h2>This is where things veer off into a slightly different, perhaps more controversial direction. For all the good that comes with cross functional collaboration, from our experience working both in and with cross functional teams, space still needs to exist for deep-dives into specific disciplines.Common issues with cross functional squads<UL><LI>Designers get bored when we delve too deeply into engineering challenges</LI><LI>Engineers don’t want to be involved in too many irrelevant discussions</LI><LI>Standups can go off-piste and in random directions</LI></UL>Ad-hoc, discipline specific sessions can help alleviate some of these concerns when working in a cross-functional team. Here’s a selection of some of the most beneficial ad-hoc sessions you can introduce into the mix.<h2>Engineering backlog grooming</h2><a href="https://www.departmentofproduct.com/blog/backlog-grooming-an-essential-guide/" dir="ltr">Backlog grooming</a> is a laborious task that few people look forward to. And some companies do away with it altogether. However, if you stick to weekly goals only, this often doesn’t give engineering teams enough time to digest the requirements fully and to collaborate with engineering team members on how best to approach solutions from a technical perspective.An engineering-only backlog grooming session can help prepare engineers for the upcoming work. Without the entire cross functional team present, engineers have the space to consider requirements without the niggling feeling that maybe they’re wasting other people’s time. <h2>UX / UI backlog grooming</h2>Just as engineers need time to technical complexity, a separate UX / UI grooming and prioritisation session can be helpful when used as a supplementation to the core team. In UX / UI backlog grooming sessions you’ll prioritise design work which isn’t yet ready for engineering and consider edge cases that may have been missed. Occasionally, these can be combined with 3 amigo sessions, too, but it’s important to give time and space to design problems, just as you’d do with engineering. It may feel as though it goes against the cross functional mantras of collaboration but it’s still essential to carve out time for ad-hoc, disciple-based sessions.<h2>Cross-functional pollination</h2>Finally, an ad hoc session with other cross functional teams can also be helpful, particularly when it comes to reducing ambiguity and the communication gap between teams. Tech leads, UX and PMsIt’s probably impractical to try to bring all members of all cross functional teams together. Instead, focus on tech leads from each of the teams, along with product managers and UX. It’s tempting to try to use these sessions as a forum to harmonise all product development processes across teams. This rarely works and teams are best left to decide the intricacies of how they’d like to work on a day to day basis.The purpose of speaking to other cross functional teams isn’t to harmonise all processes but rather to share ideas on what’s working well, what’s coming up on the roadmap and how and where there might be opportunities to help each other out.<h2>Bringing it all together</h2>Cross functional teams are a modern take on what has always been at the heart of successful, productive companies; groups of people working together to achieve shared outcomes. When executed badly, cross functional teams can feel like a box ticking exercise for digital transformation champions to prove that they’re ‘doing digital’. But, with the right balance of skillset, goal setting and support systems, cross functional teams can give you the best shot you’ll have of achieving the goals you’ve set.

Stashed ideas

Getting the most out of groups of multi-disciplined team members

‘Cross functional team’ is really just a fancy way of saying groups of people with different skill sets working together to achieve common goals. And that’s what business has always been about. Despite this, the term ‘cross functional team’ or ‘cross functional squad’ has gained popularity over the past decade or so.

In a product development context, a cross functional team is typically responsible for building products. And in this case, product managers are often the ones attempting to act as the glue between team members so that the overall team can achieve its objectives. It sounds simple, but it’s often not.

The problems cross functional teams solve

When they work best, cross functional teams solve problems. What problems?

The cost of translation

Conventionally used in BDD terminology, the cost of translation refers to the cost of translating requirements between various disciplines or stakeholders. Like Chinese whispers, the cost of translation slows down overall product development time. Cross functional should mean faster development since you’re not sitting around waiting for a member of one team to clarify something before you can speak to the other.

Lack of perspectives

Diverse groups of people with different skill sets will ultimately solve problems and generate better solutions. If problems are solved only by engineers, or only by designers or only by content writers, it’s likely that the solutions you’ll settle on might be suboptimal.

Discipline-based dysfunction

Without cross functional teams, skilled employees are instead segregated by skill set. This causes problems when different disciplines are pitted against each other; rather than identifying as the ‘product team’ to solve product problems for customers, the narrative becomes ‘engineering’ vs. ‘design’.

How to set yourself up for cross functional success

A cross functional team in a product context will typically comprise the following:

<ul><li>Engineers </li><li>Product manager </li><li>Designer </li><li>Content writer </li><li>QA </li> </ul>

Not every company is the same, and not all companies actually adopt the cross functional team or squad model, but those who do will usually have some variation of these roles.

If you think about it, that’s a pretty diverse group of people. Engineers, designers and content writers have wildly different skill sets with little in common and this inevitably leads to some tension. But that tension is healthy. It’s tension that ultimately powers the team; without it, the product team would be a stale, homogeneous mess. Like muscle tension, when stretched a little, the team grows as a result.

So let’s say you’re a product manager, a member of a cross functional team or indeed an exec who is looking at implementing cross functional teams in your organisation. What are some of the ways to do it?

We’ve worked with numerous product teams over the years and this is what we’ve seen work best. Let’s have a look shall we?

The cross functional team exists primarily to execute on strategy. Yes, many cross functional teams have a high degree of autonomy where teams can decide how to test strategic bets or how to achieve OKRs, but ultimately, much of the time spent as a cross functional team member is on execution.

Since the skill sets of team members are so vastly different, it helps to set weekly goals which align with the wider goals of the business. If you’re on a 2 week sprint cadence, maybe the goals can be fortnightly. But the principle is the same. You agree collective, outcome based goals that involve all members of the team.

Intercom <a dir="ltr" href="https://www.departmentofproduct.com/blog/how-to-build-better-internal-tools/">built its own tool </a>to track weekly goals. HR startup CharlieHR gives each cross functional team ownership of <a dir="ltr" href="https://medium.com/@tomcarra/moving-to-cross-functional-teams-9e4bce313523">achieving key results set by OKRs </a>. Netflix <a dir="ltr" href="https://medium.com/@gibsonbiddle/6-a-strategy-for-each-swimlane-38be75f65129">empowers each team </a>to own the strategic bets it is placing using its ‘pod’ structure.

Balancing Vertical and horizontal alignment

Before you can decide on your weekly goals as a team, the upfront work to align with the <a dir="ltr" href="https://www.departmentofproduct.com/blog/how-to-run-product-strategy-workshops/">wider business strategy </a>must happen. Alignment is a critical part of successful cross functional working.

Horizontal alignment ensures the cross functional team’s workload is relevant to the wider strategic objectives of the business. Vertical alignment ensures individual members of the team know what their role is in helping the team reach its objectives. Both are equally critical and dependent on each other; horizontally aligned teams working on irrelevant things are just as useless as teams working on vertically aligned items who are incapable of communicating with each other.

Keep it simple and borrow from the Checklist Manifesto by creating a checklist of realistic goals to achieve that week. Goals should be outcome-based, just like key results in OKRs.

During your weekly planning sessions, set cross functional goals which align neatly to your overall roadmap. Product managers will need to do some thinking before cross functional teams come together but the idea is you craft a set of achievable goals which move you closer to your desired goal.

Let’s say you’re working towards launching a new version of your user onboarding. This will likely involve a huge effort from across the team:

<ol><li>Engineering needs to ensure the frontend and backend are built </li><li>UX / design need journeys mapped out to cover all scenarios </li><li>Content needs to design journeys which make sense to the user and tick all the legal requirements </li> </ol>

A typical set of outcome-oriented weekly goals during your build process might be:

<ol><li>Complete password reset email sends (engineering) </li><li>Get brand sign off for new account creation landing page (design / content) </li><li>Finish content for SMS 2 factor authentication reset journey </li> </ol>

Goals are agreed at the start of the week and are reviewed at the end of the week. Finding the right balance between what’s achievable and what’s not is difficult but teams often get better at it the longer they work together. At the end of the week you can review what’s been achieved, celebrating the successes and delving deeper into areas where you’ve not been successful.

Some companies have built their own tools to allow product teams to set and track weekly goals, but assuming you haven’t done that, a simple alternative can be tools like Evernote or Slack. Slack actually has a little konwn posts feature which allows you to create and share a post in your Slack channel with your goals set for that week.

How to link weekly goals to backlog items

One point of confusion that often arises is the relationship between weekly goals and product backlogs. If you’re not careful, running two, parallel systems of weekly goals and product backlogs can get messy, and this is particularly true for teams working in a sprint-based environment, since the sprint itself works using a goal-based cadence.

In most product companies, the work of design and content sits outside of the engineering development backlog so it’s best to think of your goals as items which sit above your backlog but beneath your overall product strategy.

What if different parts of the team are working on different things?

Weekly cross functional goals don’t necessarily all need to be relating to the same feature or priority. It could be that UX and design teams are in product discovery mode for future, as-yet-unbuilt features and so UX / design goals would be unrelated to engineering goals. The key is to ensure all goals are relevant, not that they all link to the same piece of work.

Setting goals is one thing, achieving them is another. In order to achieve the goals you set at the start of each period, the systems and operating rhythms you put in place are just as important.

In companies without cross functional teams, standups normally include engineering and product managers and perhaps scrum masters. In a cross functional set up, daily stand ups will include everyone from across the spectrum.

With your weekly goals set, you can refer to them in standup alongside the relevant development boards if not every day then on a Monday, Wednesday and Friday.

Whilst many turn their nose up at the necessity of gathering together daily, we’ve worked with teams where they’ve experimented with getting rid of standups and it’s often led to a breakdown in horizontal alignment. It’s ten minutes out of the day, and in a remote setting it’s still the best way to reduce opportunities for confusion.

When you’re deciding what to build next, or how to approach a solution to a customer problem, working cross-functionally can be beneficial. The so-called ‘3 amigos’ session includes engineering, design and product thrashing out some potential solutions to problems together.

Whilst the benefits of cross functional discovery workshops and 3 amigos are clear, there’s also a downside. Sometimes, when engineering and design work together from the outset, technical boundaries can limit the imagination of product and design in coming up with solutions. Some (and not all) engineering teams will get terrified at the prospect of building something seemingly complex and will shoot down an idea in its entirety.

The role of the product person is to manage the gap between creative, innovative solutions and the realms of what’s technically possible. Scope management is product management, after all.

This is where things veer off into a slightly different, perhaps more controversial direction. For all the good that comes with cross functional collaboration, from our experience working both in and with cross functional teams, space still needs to exist for deep-dives into specific disciplines.

Common issues with cross functional squads

<ul><li>Designers get bored when we delve too deeply into engineering challenges </li><li>Engineers don’t want to be involved in too many irrelevant discussions </li><li>Standups can go off-piste and in random directions </li> </ul>

Ad-hoc, discipline specific sessions can help alleviate some of these concerns when working in a cross-functional team. Here’s a selection of some of the most beneficial ad-hoc sessions you can introduce into the mix.

<a dir="ltr" href="https://www.departmentofproduct.com/blog/backlog-grooming-an-essential-guide/">Backlog grooming </a>is a laborious task that few people look forward to. And some companies do away with it altogether. However, if you stick to weekly goals only, this often doesn’t give engineering teams enough time to digest the requirements fully and to collaborate with engineering team members on how best to approach solutions from a technical perspective.

An engineering-only backlog grooming session can help prepare engineers for the upcoming work. Without the entire cross functional team present, engineers have the space to consider requirements without the niggling feeling that maybe they’re wasting other people’s time.

Just as engineers need time to technical complexity, a separate UX / UI grooming and prioritisation session can be helpful when used as a supplementation to the core team.

In UX / UI backlog grooming sessions you’ll prioritise design work which isn’t yet ready for engineering and consider edge cases that may have been missed. Occasionally, these can be combined with 3 amigo sessions, too, but it’s important to give time and space to design problems, just as you’d do with engineering. It may feel as though it goes against the cross functional mantras of collaboration but it’s still essential to carve out time for ad-hoc, disciple-based sessions.

Finally, an ad hoc session with other cross functional teams can also be helpful, particularly when it comes to reducing ambiguity and the communication gap between teams.

It’s probably impractical to try to bring all members of all cross functional teams together. Instead, focus on tech leads from each of the teams, along with product managers and UX.

It’s tempting to try to use these sessions as a forum to harmonise all product development processes across teams. This rarely works and teams are best left to decide the intricacies of how they’d like to work on a day to day basis.

The purpose of speaking to other cross functional teams isn’t to harmonise all processes but rather to share ideas on what’s working well, what’s coming up on the roadmap and how and where there might be opportunities to help each other out.

Cross functional teams are a modern take on what has always been at the heart of successful, productive companies; groups of people working together to achieve shared outcomes. When executed badly, cross functional teams can feel like a box ticking exercise for digital transformation champions to prove that they’re ‘doing digital’. But, with the right balance of skillset, goal setting and support systems, cross functional teams can give you the best shot you’ll have of achieving the goals you’ve set.

Bite-sized knowledge
to upgrade
your career

How to Make Cross Functional Teams Work - Department of Product

Cross-Functional Teams

Benefits of having a Cross-Functional Team

Cross-Functional Standups and Discovery Workshops

Implementing Cross-Functional Teams

IDEAS ABOUT

MORE LIKE THIS

The Benefits of a Cross-Functional Product Team

How to Overcome 6 Key Product Leadership Challenges | Roman Pichler

5 ways engineers can make a positive impact outside the code editor

It's time to

READ

LIKE

A PRO!

Bite-sized knowledgeto upgradeyour career

How to Make Cross Functional Teams Work - Department of Product

Cross-Functional Teams

Benefits of having a Cross-Functional Team

Cross-Functional Standups and Discovery Workshops

Implementing Cross-Functional Teams

IDEAS ABOUT

MORE LIKE THIS

The Benefits of a Cross-Functional Product Team

How to Overcome 6 Key Product Leadership Challenges | Roman Pichler

5 ways engineers can make a positive impact outside the code editor

It's time to

READ

LIKE

A PRO!

Bite-sized knowledge
to upgrade
your career