Great Teams, Great Products

What makes a great product?

We all spend time thinking about this. Whether you're a manager or not, striving to build the best thing we can is the force that drives most of us to come to work every day. We look at products we admire and we wonder: how do they do it? Was it amazing leadership? Are the people that work there just all insanely talented? While both of those things may be true, they aren't the true reason things are great. Having great leadership and talent are both huge helps, to be certain, but in my experience only one thing can make a great product:

Great teams.

What Makes a Great Team

Think about the amazing teams you've seen or been a part of - the ones who always seem to ship the best products and experience the biggest wins. What made them amazing? It wasn't that they had the exact right number of designers and engineers and product folks. Maybe they did, maybe they didn't. In my experience, great teams have:

• People who trust each other. This means designers who care deeply about their engineers' and PMs' thoughts on design, engineers who care about how their architecture impacts the designers, PMs who are comfortable letting their whole team own the product and process, etc. If a team doesn't trust each other, it will manifest in them not sharing their responsibilities.
• A lot of trust from the company. It's impossible for any team to execute well without this, great or not. Great teams aren't micromanaged. They're given a goal and have the autonomy and support to make it happen.
• A variety of points of view and thoughtful disagreement. A lot of people think great teams don't argue, when the reality is exactly the opposite. However, even when debating, these teams do so from a place of trust (see above) that everyone is arguing in the best interest of the product. They appreciate each other for what everyone brings to the table.
• Senior folks who help less-senior people. This could mean a senior engineer mentoring a more junior designer in html/css, a senior designer showing a new product manager how to run a project well, or a product manager teaching a junior engineer to think about more than the code. Again, many people mistake "a group of all senior people" as a recipe for a great team. My experience is that great teams are a mixture of talents and expertise, but the constant is an environment of teaching and learning.

Great Teams Are Magical and Unexpected

Clearly, it's hard to predict if a group of people will act Great or not when you're forming a new team or thinking about adjusting your organization. I've been wrong many times about how well or not well people will work together. Sometimes all it takes is one person to complete the puzzle and convert an Almost Great team into a Great one, or to take a Great team and drag them down.

However, it's still important to make that your primary motivator (what you optimize for) when creating and adjusting teams. I mean, supposedly your biggest concern as a manager is setting up people you manage to be successful, right? Getting them onto a team where they'll be valued and produce great work seems like a good place to start. But, as I said, it's kind of a crapshoot if you're trying to predict that all by yourself.

At Etsy, engineers are given the ability to go work on any team in the company for a few weeks (with the team's consent, obviously). This is a way for people to try out different parts of the product, as well as working with a new set of people. At the end of their rotation, some people work it out to stay on that team, while others go back to their original team. When you give people the power to experiment and self-organize, you increase the odds of a Great Team emerging.

You Will Experience False Positives

You'll see people on a team getting along really well and assume you have a Great Team on your hands. Then a year later you'll realize they never shipped anything, or that the result of their work isn't up to snuff or (worse) some combination of the two. Strangely, while you may have realized that things aren't ideal, the team itself may think things are great! They get along and everyone has a good time working together, so what's the problem?

Great Teams ship great work. They're great because they're able to work fast and tight and come out the other end with something amazing. And while most Great Teams I've seen are, as a byproduct, very good friends, it's certainly not a requirement, nor a strong indicator of greatness.

They Can Tackle Anything

The most powerful part of having a Great Team is that you can throw nearly anything at them and they'll figure it out. Have a new, important strategic initiative? Most companies try to cobble together "the best" individuals and throw them at the problem. What you find is that now you're dealing with a bunch of people who don't know how to work together yet, in addition to them trying to work on this high-priority thing. Better to throw the problem at a high-functioning team, who already know how to work well together and can concentrate on executing.

Greatness Is Cumulative

The opposite of the cobbled-together dream team scenario. It's real, real tempting for managery folks to see a great team operating at a high-level and discuss splitting the team up amongst the Almost Great and Not Great teams in an attempt to buoy everyone. This is a mistake. Like I said, a Great Team is a mystical concoction that relies on all its parts. The knowledge of how to work together is incredibly valuable in and of itself. If you break up a Great Team, that's all you're doing: losing a Great Team. Their new teams may not support or challenge them in a way that makes them or their new teams successful.

Instead of breaking up a Great Team, why not set them up as the example of what you want in your teamwork? Think about who else might work together more productively, give other teams more opportunities to mix it up and try new combinations of people together.

But We're Professionals

We should be able to work with each other, regardless of the project or the team.

Typically, I've experienced this as resource-focused language, rather than people-focused. The implication of this (and the above breaking up of Great Teams) is that success is about individual skill level alone. And, to be honest, the quote above is absolutely correct, in a way. People should be professionals. Sometimes shit happens and you need help right away on a project and your best option is someone who's currently happy on their team. Or sometimes people have interpersonal problems and need to resolve them (which could result in Great Teamness).

Being professional, however, doesn't mean you're at your most productive and creative. While, sure, good people can always get the work done, you'll achieve better work (not to mention retention) by helping them find a team of people they really gel with.

People and Teams, Not Resources

At some point in your career, if you haven't already, you will hear someone (multiple someones!) refer to people as resources. "We need another design resource on this team" or "We have too many engineering resources assigned to this project." It's not uncommon and, in fact, is generally pretty innocent and benign in my experience, at least on a case-by-case basis. However, building great teams and shipping quality products requires a lot more of us: an improved organizational awareness that goes beyond resource management to become far more people-focused.

It's critical to not think about people as pieces that can be shuffled around at will. It's hard to overstate the power and importance of creating an environment that encourages and empowers people to find their best collaborators. Find ways to experiment with new groups of people who you think may work well together and, if they start working amazingly, double down on their success. If your culture is based on hiring and building Great Teams, then your product, your company and everyone who works there will see and feel the benefits.