Cross-Functional vs. Dependent Teams

The speed at which product teams can create value determines whether companies will prosper or remain stuck. Although this statement may sound obvious, the reality of product teams is shocking. Try asking product professionals the following questions, and you may be astonished by the answers you get:

• How long does it take for an idea to evolve into something valuable?
• How independent is your team when creating value?
• How does the team define the activities they need to work on?

When you get answers that suggest that your teams rely on external dependencies to create value, you’ve got something to change. Also, if you notice that activities are being defined according to the team’s technical limitations, take it as a sign that staffing is suboptimal. 

Tech limitations should not prevent teams from working on what matters most.

In our experience, cross-functional teams help businesses grow steadily, whereas dependent teams dramatically limit business growth. The more independence the team has, the faster they can create value.

Staffing teams properly is a necessary step for moving towards empowered teams. Let me elaborate on the downsides of dependent teams and the advantages of cross-functional ones.

Dependent Teams

When teams depend on other teams to transform ideas into meaningful results, they become dependent teams. The more dependent teams are, the slower they become and the more problems you will face.

To illustrate the disadvantages of dependent teams, let’s consider e-commerce with six teams: four teams are focused on specific parts of the product, and two are focused on disciplines, UX and QA. Each team has a clear responsibility and set of skills. The following image shows the dependencies among the teams.

As you can see in this image, all product teams depend on UX and QA teams. This scenario has several downsides:

• Miscommunication: Dependencies require constant handovers, and that leads to eventual miscommunications. Generally, dev teams refine and plan their work completely separately and interact with other teams only on demand. This situation will create misunderstandings and confusion.
• Lack of responsibility: When there are dependencies on UX and QA, no team feels accountable from end to end. For example, say the UX team designed an outstanding experience, the shop team implemented it and QA ensured its quality; however, after releasing the feature, end-users didn’t benefit from it. In this case, UX may blame the dev team for poor implementation, while the dev team may blame UX back due to an inadequate design. 
• Decisions based on limitations: Each team decides what to work on based on what their skills allow them to instead of thinking about significant problems together. Each team is an island and only interacts with others when needed.
• Superficial domain knowledge: Each team focuses exclusively on their responsibilities—the dev team implements what is defined by UX and QA tests whatever they receive, yet no team goes in-depth in their domain to uncover hidden opportunities because they are too busy handling their dependencies.

Dependent teams slow down business growth.

Important note: I used UX and QA for dependencies to illustrate the problem, but there are other disciplines to consider, for example, analytics, DevOps, etc.

Cross-Functional Teams

When teams are able to create value independently, the results can be remarkable. Still, it’s hard to remove all dependencies and transform teams into cross-functional ones. This isn’t something that happens overnight; it’s a journey that will take a while.

Considering the previous team example, we would have four teams with no dependencies when we convert them into cross-functional units. 

What does it mean to be a cross-functional team? It means the teams have all the required skills to transform ideas into results. They are independent and do not need to sync with other teams or hand over tasks to others to complete. Cross-functional teams can create value at a steady pace when they are empowered to solve meaningful problems. The advantages are tremendous and include (but are not limited to):

• Accountability: The team is fully accountable for their results. There’s no room for a blame game because the team has all the required skills to get things done.
• Speed: With no dependencies, teams can move fast, and everyone belongs to the same team. Communication becomes straightforward, and there’s no need for handover or bureaucracy.
• Domain knowledge: As every team member works towards the same goal, they continuously enrich their domain knowledge. The longer they work together, the faster they can uncover valuable insights.
• Focus on what matters: The team has a clear focus: create value sooner. They don’t need to waste their time and energy handling dependencies and begging other teams to prioritize their requests.

Cross-functional teams help businesses thrive.

Another vital aspect of cross-functionalities is that it goes beyond product teams. This means that business stakeholders must be available for the team and have their priorities aligned. For example, teams can easily book time with business stakeholders during an initiative because the initiative matters to them. If that is not the case, value creation will be delayed because the product team lacks relevant input from business stakeholders.

Sometimes, even cross-functional teams will end up with dependencies, which can be counterproductive. For example, consider an e-commerce implementation of a referral program: this initiative may be relevant to my account, payment, and shop team; if each team works separately, dependencies will slow them down. A good way of tackling this scenario is by forming a temporary team with a representative from each individual team and working at full speed to make the initiative go live.

Obstacles to Become Cross-Functional Teams

Cross-functional teams seem like an obvious choice, but many organizations still have dependent teams. Why does that happen? There are some challenges to tackle before any team becomes cross-functional; until then, teams simply aren’t ready for it.

One of the biggest obstacles is becoming a self-managing team. Most dependent teams have requests to fulfill, while cross-functional teams tend to have goals to achieve. The difference is immense: requests mainly require execution, while goals require a different strategy as the team must discover what works and what doesn’t.

Another blocker that teams encounter on their journey to becoming cross-functional is how to handle different activities simultaneously. For example, UX designers might be looking at something that’s not very related to what the team is implementing. How can that fit in with the other activities? The point is, when UX designers define everything in a vacuum, they encounter resistance from software engineers who feel ignored and end up executing tasks instead of creating solutions. 

Cross-functional teams do encounter a duality during their Sprints: some members may be working on the present and others on the future. And that’s fine, and it can create terrific results. 

Software engineers are creative and should be involved in discovering problems instead of only implementing solutions.

A common excuse to run away from cross-functional teams is, “this person cannot be fully utilized, so it’s better to have a separate team serving several dev teams instead.” Don’t fall into this trap. People in product teams don’t need to be fully utilized; they need to have clear priorities in mind, contributing to getting things done with the product team. Once that is done, they can work on other activities outside the team’s scope.

Key Takeaways

• Dependencies limit teams’ ability to create value sooner and lead to poor results
• Teams have to become self-managing before becoming cross-functional
• Dual reality is a part of cross-functional teams
• Cross-functional teams focus on creating value while dependent teams focus on delivering tasks

‍