Two short stories.

Daniel is a product manager in a cross-functional team. He values efficiency and is quite protective of his engineers. He believes running a lot of experiments will lead to success, and his manager encourages him to do so. Another member, Jennie, is a product designer. She cares a lot about the team working well together, and that the features they build solve real customer problems. Daniel and Jennie get along, but their relationship is fraught with friction and frustration.

Charlotte is a tech lead in her team. She knows a rotten codebase when she sees it, and from painful past experiences knows how demotivated teams get to work on those. Quality code means a lot to her. Her product manager, Noah, is very business-oriented, spending a lot of time with internal stakeholders. He is very ROI-driven, pushing for features and velocity. Charlotte and Noah butt heads more often than both care to admit.

Do you see a pattern? Does it sound familiar?

It may not be obvious, but it’s one of the most common issues in product & engineering teams: different people are solving different problems, whether they realize it or not. And that is the root of much anxiety, frustration, and disappointment.

Why should I care?

Three reasons (to begin with):

1. Ineffectiveness. When different people are solving different problems, it’s akin to rowing in different directions. Best case, you move slowly and haphazardly. Worst case, you don’t move at all. The (likely wrong) conclusion is too often that the team is “not good enough” or “doesn’t care enough”.

2. Frustration. If we’re addressing different problems, it’s highly likely we’ll be talking past each other. If that happens once or twice, not a big deal. If it happens all the time, it’s bound to get annoying and frustrating. It’s easy then to throw in the towel and just start believing the other person is impossible to work with.

3. Stagnation. Only when aligned on the problem can we learn something from whatever solutions we create. If everyone is prioritizing a different thing, we’ll be in apples vs. oranges territory. It’s not only unlikely we’ll make progress towards the goal—which one, really?—it’s also doubtful we’ll learn anything in the process.

Why does this happen?

The best intentions can create the worst incentives. Imagine that in a push for more experimentation, a PM like Daniel above is rewarded for increasing the number of experiments per quarter. That’s the problem he’s solving. Meanwhile, the designer in the team, Jennie, sees that the team is not learning from these tests. She’s solving a different problem, one of learning about customer behavior so she can produce better designs. In a push for more tests, the quality of each test suffers. While both individuals feel like they’re supposed to be working together, they are effectively apart.

What makes things even harder is that the costs of this are often intangible or difficult to measure. Either because we don’t have any metrics or because we look at the wrong ones. A typical example is the feature factory wherein teams are rewarded for shipping stuff—but was it the right stuff? When in practice output is valued above customer impact, there is no apparent problem: velocity is good, after all. That’s why Noah, the business-oriented PM keeps his stakeholders happy, while Charlotte is pulling her hair about the ever-decreasing quality of the codebase.

The biggest reason is that we assume a lot. Most teams spend all their time talking about the work. The project, the sprint, the user stories, the tickets, the roadmap, the code. But not enough time talking about how they work together, what each individual cares about, and how it all fits together—or not. As John Cutler once quipped, it’s all about the work and nothing about “the work that makes the work work.”

What to do about it?

One of my core principles as a VP Engineering was to make the implicit explicit. The first step in addressing this fundamental misalignment is making this conversation explicit.

As we’ve seen from the fictional stories above, the most insidious “problem misalignment” is project-agnostic and ongoing. It happens at the level of how each individual fundamentally sees their role, and what they care for. Finding the time and space to engage in that conversation can go a long way towards turning a group of people that work together into an effective team that achieves together.

To stimulate some real team-building talk, set some time aside. For example, start by repurposing a retrospective. Then have each individual take turns in answering the following questions in front of everyone else:

• Of all the things I value in my role, what is #1 to me—and why? (e.g. codebase quality, customer impact, shipping velocity, teamwork, motivation and engagement, etc)

• What has been most frustrating or hard to understand for me inside the team?

• What precisely do I see as success for the team?

• Knowing the others’ answers to the above questions, what may I now do differently to help the team win?

The more real this talk gets, the better. Ask each other clarifying questions. Strive to have it be a little awkward. Julie Zhuo, former VP Design at Facebook, points out in her lovely book The Making of a Manager that the most important and meaningful conversations have that characteristic. Don’t get stuck on pleasantries and “shooting the shit”. Real work is being done here.

This exercise can be triggered by anyone in the team, and needs no moderator. It pools together all the relevant concerns, and has everyone being heard and accounted for. Done well, it creates a level of awareness without precedent. “Aha!” moments of the “oh my god, I had no idea you had this priority and this pressure” variety are not uncommon. That’s where compassion begins, and how great relationships get built. Most likely, it’ll surface a bunch of misalignment. But that’s good news—you just made explicit what was dangerously implicit.

A Common Goal

When it comes to conflict resolution, I often tell my clients to seek what unites them with the other party before looking at what divides them. The realization of whatever that is gets you out of the conflict mode, and goes a long way towards resolving the conflict itself. It creates good will.

Likewise, one of my favorite definitions of “team” comes from one of my favorite systems thinkers, Peter Senge. He said that a team is “a group of people who depend on each other to achieve a common goal”. This is a remarkable statement. It says that there is a higher-level reason why the team exists, something that both transcends and binds together everyone in the team.

What is “that” for your team? With everyone’s values and priorities now on the table, how may the puzzle fit together towards “it”?

Going through this type of exercise may sound like a distraction, but it makes everything else easier—and a lot more interesting and motivating. The work is difficult and everyone brings different priorities to the table. By engaging in real talk about what matters, you edge a lot closer to finding those answers. And you put yourself already ahead of many other teams who are struggling to address the elephant in the room—or even notice there’s one in the first place.

Share