On effective product teams

Quick: who are your teammates at work?

When we talk about our professional team or the small group of our closest colleagues, it is common and perfectly reasonable to first think of other people who report to the same manager, or of coworkers with the same or similar job titles and duties.  “I’m on the support team; my teammates are the other support reps sitting on the 14th floor, next to accounting” or “I’m in Carla’s QA group, and my team comprises the QA analysts who report to Carla.”

I’d like to propose an alternate or expanded orientation: your teammates are the other people working on solving the same customer or business problem as you, even if they have totally different skills or job duties.  A software coach I knew once described this kind of team-based orientation like this: “If you ask a developer at Google what she does for a living, she doesn’t say, ‘I’m a Java developer’; she says, ‘I work on the Gmail team.’  Her primary affiliation is not with others who have her skills, but towards the group of people working on the same problems and product, even if they have totally different skills.”

So if, say, you work at an edtech company on a product or portion of a product that, for example, helps high school students master their state standards, think of your teammates as the other people working to help high school students master state standards, too, even if they are using different talents (design, testing, research, writing, implementation) to do so.  A helpful analogy: think of an NFL team, where the hulking and powerful offensive tackle, the speedy and fluid wide receiver, the agile and aggressive defensive back, the savvy and decisive quarterback, and even the specialized (and, for Vikings fans, maddening!) placekicker all have wildly different skills, but all are necessary for the team’s success.  A team of the 11 biggest and strongest left tackles in the world wouldn’t stand a chance against even a high school team with a complete, broad set of skills.

Some other characteristics of great program or product teams:

  1. They’re outcomes-driven. A great team is obsessed with the results or behaviors it is attempting to produce, and it recognizes that those outcomes are more important than any specific outputs it is assigned to deliver.  Sure, we want to make a thing or release a feature. But our customers aren’t actually buying our things or our features; they’re buying the results those features are intended to produce.  If the feature isn’t the most effective way to produce the intended outcome, the smart team is willing and able to change course, in pursuit of the outcome.
  2. They’re T-shaped. “T-shaped people” is a simple and powerful model for teams of professionals, popularized by the innovation firm IDEO.  In this model, we look at people’s area of depth and expertise (the vertical part of the T) but also at their versatility and breadth (the horizontal arms of the T).  A few T-shaped people can accomplish as much as a bunch of talented lowercase L’s. T-shaped people are a shortcut to great products and experience – after all, rather than needing a couple back-end engineers, a front-end dev, a database admin, a designer, a market researcher, a usability expert, a QA tester, a business analyst, a copywriter, a project manager, and so on, the T-shaped approach focuses on skills, rather than job titles. Maybe an engineer and a designer can together do usability testing.   Maybe a designer and a market researcher can also write some great copy.  Maybe the entire team can write and execute tests. 
  3. They’re relatively non-hierarchical.  Great cross-functional product or program teams don’t really have rigid levels and managers and reporting structures.  In fact, teammates may all report to different functional managers. Instead, they come together and use their expertise to work out questions of priority and effectiveness.
  4. They have a combination of cognitive diversity and psychological safety. A recent Harvard Business Review study (https://hbr.org/2018/04/the-two-traits-of-the-best-problem-solving-teams) proposed that the these are the two traits of effective problem solving teams, across all industries. Cognitive diversity means a variety of intellectual capabilities and approaches; psychological safety means the freedom to ask questions, challenge each other, and pursue solutions without fear of reprisal or humiliation.  The HBR authors defined it like this: “Psychological safety is the belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes. It is a dynamic, emergent property of interaction and can be destroyed in an instant with an ill-timed sigh.”

Leaders of companies struggling to innovate or to achieve product-market fit should take a look at how their teams are defined. I’m not talking about their formal org charts; I’m talking about the way people refer to each other and think about their coworkers from other departments. If the organization struggles with cross-functional team identity, try a few of these techniques: shadowing, co-location, or identity building exercises. You may unlock the power of a cross-functional team.

Tagged ,

Leave a Reply

Your email address will not be published. Required fields are marked *