If you are building an effective team, do you know what you are building towards? Is it more than just putting smart people in a room together?

If it feels like team building is some nebulous concept, doing tactical activities without a strategy, it is worth knowing that there is a lot of great research on exactly this. Google did a research project called ‘Project Aristotle’, on what makes effective teams. They identified 5 attributes that make their teams successful. It turns out who is on the team matters less than how the team interacts.

5) Impact of work: Do we fundamentally believe that the work we’re doing matters?

This is usually harder to miss in a startup, the teams are small, with less room for someone working on a project that is not moving the needle. The type of places I see this slipping through the cracks is an engineer who works on some feature with no metrics around success (like the signup form redesign help), without clarity or visibility around how this impacts the company it could feel like work is just being done in a void. The best part about clarifying the meaning of work is that it provides a hook to identify where work is not meaningful (and dropped in favor of meaningful work).

4) Meaning of work: Are we working on something personally important to each of us?

Often the default for each team is to keep the people who are best at certain tasks doing those tasks, which is ironically an easy way to forget to ask if people want to be doing those things in the first place. One of the most effective ways I found to help people work on things that are meaningful to them just asks. A team still needs to get everything done and people generally like doing things they are good at, but just knowing a backend engineer wants to do more frontend and your team happens to have some frontend tasks to work on would be a huge win-win for letting someone pick up a new skill as well as knowledge share.

3) Structure and clarity: Are goals, roles, and execution plans on our team clear?

Who has time to write down goals or figure out enough details to make a plan? In a startup it is really easy to dismiss the value of plans, after all, 2 weeks from now the world may look different. Well if the world may change drastically in 2 weeks, we could probably have plans for 1 week’s time spans and see if that works. For me, the idea of planning is dependant on the time horizon. If after every inch we travel, we get new information that invalidates the current plan, I see no problem in having a plan for every inch that adapts as we go. To me, this makes much more sense if we want to make sure that each inch is going in the right direction. The same follows for goals and roles, having structure and clarity is a great way to prevent things from falling through the cracks.

2) Dependability: Can we count on each other to do high-quality work on time?

To me, dependability is as much about setting expectations as it is following through. Getting work done is a requirement, but ‘done’ is a subjective term. For example, delivering high-quality work on time involves a tradeoff between speed and quality, as well as a shared understanding of a timeline. A task tracking tool like Jira goes a long way here, as well as making sure there has been some conversation about the quality/speed tradeoff. What may seem like acceptable quality to one engineer for one project might not be acceptable to another, and a small conversation can make a huge difference in establishing shared expectations in a group.

1) Psychological safety: Can we take risks on this team without feeling insecure or embarrassed?

Do your teammates trust each other? This may sound like the fuzziest of the five, but there a few questions that can help set a goal for what ‘safety’ means. Can everyone give each other constructive feedback? Does everyone feel comfortable brainstorming in front of each other? Does everyone feel like they can fail in the open, without needing to hide their failures? If some of these questions apply, it might be a sign that there is some room to gain here.

While building effective teams is not a science, there is some science behind it. Hopefully knowing what makes effective teams helps guide a strategy around team building. Just knowing that these are important and talking with your team about them can have a huge impact.

If you want to read more, google’s project rework or the New York Times has a great article titled ‘What Google Learned From Its Quest to Build the Perfect Team’