Building Happy Product Teams like Heist Teams by Laura Klein

Laura Klein has been an engineer, researcher, designer, product manager and consultant, which means she’s worked with a lot of teams. But what makes a happy team? In writing her next book “Building Better Products”, she donned her research hat and interviewed a number of product teams around the world. In this talk at Mind the Product San Francisco, she shared some of her insights from that research into what makes happy product teams, and surprisingly how close they come to those heist teams we see in movies like Oceans 11 or The Italian Job.

1. Goal

All great heist teams have a clear, obvious, challenging goal. They usually start with a meeting that brings together the whole team to lay out the goal and the plan for achieving it. So happy product teams know what success looks like, and they feel like they’re a part of making it come true. One slightly dangerous finding in Laura’s research is that having something really hard to do tends to bring a team together. Sometimes having a barely achievable goal is better than something easy but the trick is getting the balance right – no one wants to be constantly challenged and stressed. But the occasional project with a really ambitious but reachable goal is a great way to bond a team.

2. Respect & Trust

Heist teams are made up of experts, and they know they’re experts, which makes the team respect one another. Unsurprisingly expertise and the respect and trust that come with that expertise were common themes in Laura’s research, with 80% of participants citing it as a key component of their favourite teams. Happy teams respect and trust each other because they are made up of people who know what they’re doing. Interestingly, these teams were also better at managing people who weren’t experts, for example helping junior team members excel in the team. As a side benefit, since everyone trusted each other there was very little second guessing of decisions since they were made by the person with the appropriate expertise.

3. Balance

When heist team plans center around everything happening in precise order, they synchronise their watches and then everyone gets on with their job. So happy product teams balance the time they spend together and apart. They make the plan together, check in regularly but leave each other to get on with it. The best teams align in person, work it out separately, and check in daily.

4. Incentives

Most heist teams fail because of misaligned incentives. Whether they failed due to micromanaging, anarchy or being too communal, dysfunctional teams often fell apart because they incentivised the wrong behaviour. So instead of incentivising individual performance or goals, happy product teams focus on incentives that encourage collaboration and alignment with the team’s goals.

What makes heists harder?

So what’s going to stop you from the heist of a lifetime? While everyone can get on board with hiring the best and letting them get on with the work, there are certain structural issues that do make building successful teams harder.

Remote working. Very few of the people Laura interviewed cited remote teams as their favourites, and many cited them as the most difficult. In general, remote teams leads to less respect and trust, and there is of course all sorts of confusion caused by timezones and different nationalities and cultures. There are fixes for this, but it takes concerted effort: Teams where everyone was remote worked best, as it levels the playing field and forces everyone to over communicate. Teams that spread skills across locations tended to work better than grouping all engineers in one place, all designers in another etc. And of course remote teams that invested in spending time together, face to face, on a regular basis helped build that trust and respect even when they went back to working remotely.

External stakeholders. Another major hurdle for great teams was non-team based stakeholders, otherwise known as clients, management, or other departments. Many teams are encumbered with decision makers that aren’t in the team and thus aren’t available which erodes their ability to execute. Another problem is when stakeholders come out of the woodwork months later and derail a project. The key way to solve this is to spend the time to identify all the stakeholders up front, and making sure to check in regularly so that you avoid being blindsided by changes in the stakeholders’ requirements.

Silos. You can’t pull off a heist with 30 safecrackers and no one to drive the getaway car. No successful product team is entirely made up of product managers, designers, or engineers. Company structure can get in the way, especially where departments get siloed. The best and happiest teams are ones that are balanced, cross-functional, and together for long enough to build that trust and respect.

Why bother?

Is all this hard work building and aligning happy product teams worth it? Is there a correlation between happy teams and success? Sadly Laura’s research found no such correlation. As we all know there are a huge number of factors that go into building a successful product, and whether the team is happy is probably one of them, but by no means the only one. However, her research did uncover some clear tangible benefits from happy teams:

Happy teams are resilient. Whether they succeeded or failed, happy teams kept going. If they’re not successful the first time, they keep working at it, and keep trying to achieve their goals.

Happy teams are more open to feedback. When people respect each other they’re better at accepting criticism and feedback, and become better at their job. This raises everyone’s skills and improves individual as well as team output.

Happy teams are more likely to stay. A lot of the sad team stories ended with team members (or even entire teams) quitting. You can’t build a good product that way. If you build a happy team they’ll stick together and keep working at it.

So go back to your product teams, make sure they’re empowered to succeed, and pull off that heist of a lifetime!