Achieving team cohesion

I often work with my reports on an individual basis, but it's also possible to work with your team as a whole. I was wondering what methods you use to facilitate team cohesion/a sense of team identity or ownership?

Some quick ideas based on a question I received from a peer.

I don't think there's a one-size-fits-all answer. I don't think there's a quick solution. Both the team and the work need to be considered and tuned for a team identity to emerge, and then it will require maintenance to grow it into something self-sustaining.

Characteristics of the team

Each team is different. The right conditions need to be in place for a strong team to emerge. These are the considerations that I've found are critical.

Size

Small teams are always better. Even a sports teams is commonly divided into smaller divisions (first line, second line). Seven people or less. The fewer the connections, the more often the connections are practiced and strengthened. It's also easier to monitor the connections and identity and optimize around communications.

Context

Bruce Tuckman's theory of team formation is a great starting point when talking about team cohesion. He came up with it in 1965 and it's seen some edits over the years, but the shape is the same:

1. Forming
2. Storming
3. Norming
4. Performing

The gist of it is that it takes time for a team to get to a point where it's more than the sum of its parts. Furthermore, there is a dip in productivity when people are forced to work together. There's also a caveat that every time a new person is added, the process resets from scratch while the team calibrates.

It might be easier to start with a brand new team, because there is less potential for negative history between individuals that could get in the way. But if you're confident that there are already strong bonds in place between individuals, embrace it.

Normalize the process of team formation. Spend the first few months over-allocating on face-time, code reviews, design workshops, etc. Explain why you want to do it to encourage buy-in. Don't force it. Encourage people to take chances and to speak up. Encourage emergent processes, and also emergent humor – humor is an extremely strong bonding mechanic.

Maturity

Experienced contributors will likely have many more opinions and might want to be much more involved in shaping the team processes. In this case, take a "servant leadership" approach and leverage Agile activities like kickoffs, retrospectives, etc. You'd also be extremely reliant on 1:1s at the beginning to establish trust to counter to the inevitable anxieties that come with establishing new practices. Play to peoples strengths, helping to position contributors where they are most effective and satisfied, and then get the hell out of the way.

Teams composed of junior contributors will benefit from more directed processes. Don't bother with any brainstorming or discussion – get them working on extremely low risk components as quickly as possible and establish clean code and clean architecture principles, TDD and a code review process from day one. Use 1:1s and retrospectives to course correct week by week.

Characteristics of the work

The type and complexity of work will also shape team dynamics.

Type

Don't force a team structure if there is actually no need for it. Use the cynefin framework to determine what is the most common types of work that your team engages in. Identify what your peers require from each other, and optimize around that.

Line work doesn't require teams, because each person in the line has very few dependencies on each other. If anything, a team might only be for social bonds, and altogether unrelated to output.

Complexity

The complexity of the work can drastically affect team cohesion. If folks are always worried about things breaking in a brittle system, or worried about their productivity because of a high cognitive load, then their autonomy will be capped. If they feel they have inherited a disproportionate downside, or if they feel they are constrained in their output, they won't be incentivized to feel much ownership over their work. In the worst case, this can breed a culture of "diffusion of responsibility" where contributors avoid challenges and risk.

In the case where there is low ownership, it also reduces the benefit of celebrating wins and successes – since folks do not authentically identity with the work or the goals of the team, they do not feel anything when they hear about a success, and in the worst case, it can even widen the gap between leadership and the rest of the team.

In all teams, strive to minimize or encapsulate complexity as much as possible. Less complexity means more autonomy and better productivity, resulting in increased confidence in the project, in their team, and in leadership.

Next Steps

If people feel autonomy over their work and see the value in being able to depend on their peers, dynamics will emerge. It will surprise you, so be careful not to shut it down automatically.

Encourage it, and nurture it. The methods you use will have to change over time, as the team changes. The eventual goal is that the team processes and culture becomes so productive and reliable that you can step away completely.

Don't force team activities. Implement the minimum viable team rituals to ensure mission-critical responsibilities are being handled, and delegate responsibilities so team members are incentivized to interact with each other.

Monitor team health through retrospectives and 1:1s. Encourage emergent practices and humor. Give private feedback, and celebrate successes. Be careful in the successes you celebrate – make sure that they are successes that the team feel ownership over.

Summary

1. A healthy team identity will only emerge in specific conditions, so make sure your team is set up for success.
2. Set up the minimum viable rituals and make sure that the rituals work for the team, and not just for you. Rituals need to be able to become a source of pride for them to outlast your involvement.
3. Employ useful and satisfying feedback mechanisms for continuous improvement. These are the 1:1s and retrospectives.
4. Lastly, there's all the extra stuff that "other managers" tend to over-allocate on; the stuff that really matters the least, the traditional "team-building activities".

Teams aren't formed through team-building activities. That's a joke. A team comes to life when a small group of people are kept together for an extended period of time with a single mission whose success depends on them working together.