Healing Dysfunction in Cross-Functional Product Teams

An approach to maximizing the value of each team member in cross-functional teams

Cross-functional collaboration is an essential component of successful software development, but it is often also a source of friction and conflict. According to the Harvard Business Review, a study of 25 leading corporations found that as many as 75% of cross-functional teams can be said to be dysfunctional.

It’s not always clear why conflicts in the workplace arise when we are supposedly working towards a common business goal, but one thing is clear: Though product teams are well-trained in understanding users’ pain points, it’s not always easy to turn the mirror unto ourselves and understand or anticipate the pain points and tensions that arise within our own cross-functional teams.

People first, roles second

In our projects, we love to follow processes. We do kick-offs, define milestones, assign tasks, and host weekly syncs. However, as the saying goes, the devil is in the details. And when it comes to team dynamics, this is where problems usually happen — at the detail level. Maybe someone was not included in an email. Or someone did not inform someone else about something they were doing. Suddenly, a conflict comes to the surface and becomes visible. But what lies at the roots of such conflicts?

When we staff projects, we don’t staff projects with roles, but with people. To go back to basics, they are staffed with people who perform a role. Individuals who must collaborate with each other, who want to contribute, add value, affect meaningful outcomes, who have feelings, and want to be seen as competent and trustworthy.

They have different backgrounds, different histories and expertise in the project domain. Some might already know each other, have experience working together, know how to “read” one another, how to interact, and what to expect from each other. Others have never met before, and the only thing they might know about each other is their roles.

Individual project team members often have different understandings and deviating expectations about the project that is ahead of them, their contribution, their impact, their sphere of control, and the role of the other team members. All of these people come together and are suddenly part of the same project. The moment they come together for the first time at the beginning of a project is where the risk for a potential conflict starts to creep in. The seeds of conflict are planted and need to be identified as soon as possible before they grow roots.

Creating a psychologically safe space for collaboration

Dr. Lisa B. Kwan, professor of Economics at the University of Rochester, argues in her work on collaboration that groups define and develop their sense of security along three main dimensions:

1. Group identity is what a group understands itself to be. They know what they stand for and who they are as a group. Identity gives cross-functional groups a center of gravity and meaning in the company, argues Kwan, which in turn helps them to build a sense of security.

2. Group legitimacy develops when a group’s existence is perceived by others as appropriate and acceptable within the company, and the group is regarded as valuable.

3. Control over what they do as a group is vital, too. This means that the group is able to act autonomously, determining the terms on which they work, and effecting meaningful change.

When we join cross-functional projects, we are effectively leaving the security and comfort of our parent group and are working as individuals, representing a certain role. The principles of our parent team no longer stand, and we become part of a project team with new dynamics, principles, and norms.

In her book Mastering Collaboration, Gretchen Anderson claims that cross-functional teams often lack an understanding of the value that each role brings into the mix .The reason is simple: each member of the team has a different understanding of the value they bring, which is based on the value their “parent” department believes it provides. To make successful contributions, each team member needs to find their space in the project and help others understand their worth.

Mapping out the value of cross-functional group members

In software development, we make a habit of using tools to align, agree, and get on the same page. We use stakeholder maps, empathy maps, job maps, and user story maps to collaborate on problems to solve, create empathy with our customers, define our value proposition. The actors in these maps are our users, our stakeholders, our competitors, and our domain market. From our project work, we also know that misaligned expectations early on can lead to problems later. So why not use our own tools to make our lives easier (and ultimately the life of our users)?

As product people, we strive to create value for our users and customers. One widely used approach that helps teams create products and services that customers want is the Value Proposition Canvas. However, products and services only create value in relationship to a specific customer segment and their jobs, pains and gains. The Value Proposition Canvas proposes that there must be a fit between our customers and our value proposition. But, what about the fit between our project charter and our individual value propositions as team members? Could we apply this framework to ourselves?

We need to see every new collaboration (from the smallest request we are about to accept to the biggest mission assignment) as a value creation opportunity that starts with:

1. Understanding our customers (the stakeholder ecosystem of the cross-functional project):

· Whom does the project add value to and why?

· What do our stakeholders expect from the project? What is the goal, what problem are we trying to solve? And why? What are the risks we foresee, or the undesired outcomes? What is the business value of the project?

2. Identifying and communicating the value we can bring as team members:

• What can the individual project team members contribute? And what not?
• What are the product services and support they can provide that create value?
• Gain creators: how can the individual contributions (products and services) create gains for the project?
• Pain relievers: which project problems are we addressing?

3. Evaluating if there is a fit between what the customers (aka project stakeholders) expect and the value we can provide:

• Does our project contribution address any of their problems?
• Is it creating gains for the team? Do we all agree?
• Does anybody see a red flag? Does anybody feel their contribution is being misunderstood?

If there is no match, not even a partial match, there might be no point in collaborating.

From conflict to collaboration

Conflict is an inevitable part of human dynamics, but frictions can be minimized if all team members invest time and effort to align on their expectations and goals before starting to work together. Ultimately, we all want to do meaningful work and create the greatest possible value. We can foster that drive by putting extra focus on communicating clearly about what we can contribute to a project, and what not, to achieve our best work.

Emmanuela Rogdaki leads User Experience Research for SAP SuccessFactors. She also authored “How to Get Product Teams to Agree on the Problems to Solve”.

A special thank you to Mimi Leinbach and Andrea Waisgluss for their contributions to this story.

Experience matters. Follow our journey as we transform the way we build products for enterprise on www.sap.com/design.