10 Behaviors to Make Your Team Great
By: Adam Prescott
Tags: Growth, Leadership, Management, Personal Development, Productivity

10 Behaviors to Make Your Team Great

Is your team greater than the sum of its parts?

Photo by Michael Ankes on Unsplash

My team was in a bit of a rut. There was no trust and poor communication. People weren’t collaborating, and there was no transparency into anyone’s days. Updates in our daily standup meetings were vague and non-committal. Morale was low. Things just weren’t getting done.

I knew it wasn’t a people problem. I’d been with most of the team for years, and everybody was smart and talented. No — this was definitely a behaviors problem.

But, while I could feel the problems, I didn’t know how to articulate them. Before I could address the issues, I needed a better understanding of what they were, and I needed to establish a vocabulary with the team to facilitate a discussion. Only then, with awareness and buy-in, could we begin to implement change to improve our effectiveness.

Good Behaviors, Bad Behaviors

I was discussing the team’s underperformance and collaboration problems with a colleague, and they joking-not-jokingly proposed doing a Five Dysfunctions of a Team exercise.

It had been a while since the five dysfunctions had been front of mind, and I had to look them up for a refresher. “Let’s see what we’ve got here,” I thought as I clicked through some search results.

Absence of trust — check. Fear of conflict — yup. Lack of commitment — oh yea. Avoidance of accountability — definitely. Inattention to results — mhmm.

Wow. We had ’em all. People on the team didn’t trust each other to complete assignments. Rather than confront the lack of trust, they preferred to work alone on whatever they felt was most important. Updates in standups would be, “I worked on some things and will figure out what’s next,” and people would leave for a coffee and disappear for the rest of the afternoon. Meanwhile, user stories would drag on for days and weeks with no sense of urgency. Yikes!

The five dysfunctions also reminded me of Project Aristotle. This Google Research project attempts to answer the question, “What makes a team great?” One of their key findings was that effectiveness depended more on how the team worked together than who was on the team. In other words, team dynamics and behaviors matter more than people and individual performance.

…what really mattered was less about who is on the team, and more about how the team worked together

Google’s “five effectiveness pillars” go with the five dysfunctions like peanut butter goes with jelly, combining to create a gooey smattering of team efficiency — and they gave me exactly what I was missing most: a vocabulary for talking about the areas we needed to improve and ways to communicate the importance & impact.

The Actions in Action

Photo by Trym Nilsen on Unsplash

I had the concepts. Now I needed to deliver the message. I decided to put together two hypothetical situations based on our very real problems to illustrate the impact of these behavioral patterns & anti-patterns.

Example One. In standup, a dev says, “I’m going to work on implementing the Thingamabob. I’m going to try to complete tasks A, B, & C today, then we can test and close it out tomorrow.” In the afternoon, they say, “Something came up and I need to leave for a few hours, but I’ll be back to finish up. I completed task A and am almost done with B.” They come back later when everyone else is offline, complete task B, and leave a note before signing off: “Completing task B took longer than expected, but I got it done. I wasn’t able to get to task C. I’ll pick it up first thing in the morning.”

Example Two. In standup, a dev says, “Not sure what I’m doing today. I might start working on implementing the Thingamabob.” They start working on the story to implement the Thingamabob and complete task A plus part of task B. They need to leave for a few hours, but they don’t say anything. They come back later when everyone else is offline and complete task B.



In both examples, the person might’ve been equally productive, written brilliant code, and completed the same tasks. In both cases, the person had to leave for several hours, and in both cases they didn’t complete the (stated or unstated) goal of finishing task C.



However, the first example demonstrates all of Google’s dynamics of great teams.

Psychological safety. The dev wasn’t afraid to share status or go away because of other responsibilities; they felt safe to let the team know they didn’t complete their stated goal.

The dev wasn’t afraid to share status or go away because of other responsibilities; they felt safe to let the team know they didn’t complete their stated goal. Dependability : The developer made commitments in standup and was transparent about progress and effort.

: The developer made commitments in standup and was transparent about progress and effort. Structure and clarity : They communicated status so the team had awareness, which allows the team to adjust its actions and priorities. (For example, this could allow someone else to jump in on completing task B while the developer was away, and upon returning they could complete task C versus only completing task B.)

: They communicated status so the team had awareness, which allows the team to adjust its actions and priorities. (For example, this could allow someone else to jump in on completing task B while the developer was away, and upon returning they could complete task C versus only completing task B.) Meaning : The developer appreciates having a job that allows them the flexibility to take care of other responsibilities during the day.

: The developer appreciates having a job that allows them the flexibility to take care of other responsibilities during the day. Impact: Ensuring progress and helping the team achieve its goals feels good.

Conversely, the second example exhibits symptoms of all five dysfunctions.

Absence of trust : Low visibility and poor communication lead the team to wonder what the developer is working on.

: Low visibility and poor communication lead the team to wonder what the developer is working on. Fear of conflict : Sporadic availability makes it hard to collaborate; team members become exasperated and prefer to work alone.

: Sporadic availability makes it hard to collaborate; team members become exasperated and prefer to work alone. Lack of commitment : The developer was non-committal in standup, and the team has no expectations or ability to coordinate.

: The developer was non-committal in standup, and the team has no expectations or ability to coordinate. Avoidance of accountability : No commitments and poor visibility & availability; the dev does nothing to demonstrate their effort.

: No commitments and poor visibility & availability; the dev does nothing to demonstrate their effort. Inattention to results: Individual behavior prevents the team from achieving its goals.

All this is to say that, in order to be an effective team, individuals must focus on their behavior and interactions with teammates more than just being productive themselves.

Staging the Intervention

Photo by Todd Quackenbush on Unsplash

Okay, I had my ideas to share, and I had my plan of how I wanted to roll my message out to the team — it was time to put the wheels into motion.

The first thing I did was to send an email using the examples above. My messaging (paraphrasing) was, “Hey, team — I’ve been thinking that we haven’t been as productive lately as we’ve been in the past. I think we’re exhibiting some of the Five Dysfunctions of a Team, and we’ve lost some of Google’s pillars of effectiveness that we had previously. Consider these examples.” I also shared my analysis about how the examples were illustrative of the five dysfunctions and effectiveness pillars.

I didn’t really get feedback on the email, but there was a mention here & there in standups and retrospectives. I feel like the email did a fine job of planting the seed and helping to establish a vocabulary for the conversation. Mission accomplished there, I’d say.

Step two was to solicit feedback in one-on-ones. I’d ask people what they thought about the email and how they felt about the team in that context. These conversations were helpful because it confirmed my feelings and demonstrated that others were experiencing similar frustrations. This also helped to establish that we were all on the same page and had similar perceptions of our team strengths and weaknesses.

Finally, I decided to bring it up in the team’s sprint retrospective. I was blunt with them. I said, “I don’t think the team is doing enough to demonstrate commitment & accountability.” It took some courage, but I had to trust the team and not fear conflict — to practice what I was about to preach. The groundwork I’d laid proved valuable. People referenced the email I’d sent, and we’d all had miniature versions of the discussion in one-on-ones. It was a really productive conversation and a catalyst for positive change.