top of page

Never Ignore the Importance of Teams Setup

How companies staff their product teams define how easy creating value is.

The speed 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 the following questions to product professionals, and you may be astonished by the answers you get:

  • How long does it take for an idea to convert into something valuable?

  • How independent can your team create value?

  • How does the team define the activities to work on?

When you get answers suggesting that teams have external dependencies to create value, you’ve got something to change. Also, if you notice activities are defined according to team technical limitations, it’s a sign staffing is sub-optimal.

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

We have experienced that cross-functional teams help businesses grow steadily, while dependent teams dramatically limit business growth. The more independence the team has, the fast they create value.

Staffing teams properly is a required step to move 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 focused on specific parts of the product, and two 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 would lead to several downsides:

  • Miscommunication: dependencies require constant handovers, and that leads to eventual miscommunications. Generally, dev teams refine and plan their work totally separated while interacting with other teams only on demand. This situation will create misunderstandings and confusion.

  • Lack of responsibility: within dependencies on UX and QA, no team feels accountable from end to end. For example, the UX team designed an outstanding experience, and the shop team implemented it while 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 on meaningful problems together. Each team is a separate island and only interacts with one another 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, and yet no team goes in-depth in their domain to uncover hidden opportunities because they are too busy handling their dependences.

Dependent teams slow down business growth.

Important: 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 can create value independently, the results can be remarkable. Yet, it’s hard to remove all dependencies and transform teams into cross-functional ones. This isn’t something that happens from day to night; 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 the teams into cross-functional units.

What does it imply 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; some of them are:

  • 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: within no dependencies, teams can move fast, and everyone is inside 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 discover valuable insights.

  • Focus on what matters: the team has a clear focus: create value sooner. They don’t need to waste their energy handling dependencies and beg 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. That means business stakeholders must be available for the team and have aligned priorities. 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, the product team will delay creating value because it lacks relevant input from business stakeholders.

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

Obstacles to Become Cross-Functional Teams

Cross-functional teams seem 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 aren’t ready for it.

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

Another blocker teams find on the journey to becoming cross-functional is how to handle different activities at the same time. For example, UX Designer might be looking at something far from what the team is implementing. How can that combine with the other activities? The point is, when UX Designers define everything alone, there’s resistance from software engineers as they feel ignored and end up executing tasks instead of creating solutions.

Cross-functional teams do have a duality happening 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 inside product teams don’t need to be fully utilized; they need to have a clear priority in mind, contributing to getting things done with the product team; once that is done, they can indeed 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


bottom of page