Team init

tl;dr:

Define team

A few points that will constrain the content of this note:

This note is not limited to new and empty teams. Team init might as well work for an existing team, even quite an old one, when its configuration changes.

What is team init?

There should be a better name for a ceremony where the whole team comes together to set expectations for each other, but somehow I never really came across it. The closest would be Tuckman’s forming–storming–norming–performing notation, under which team init falls in the “forming” bucket.

Note that it’s not about the team mission. The reason the team exists is to create value, or support other teams in that, and there’s a clear business incentive behind that. This defines the scope of work for the team, but it rarely defines the team’s daily operations. Or, at least, it shouldn’t: people should be expected to find a way to ensure smooth operations, eventually, on their own, with the help of an engineering manager who supports the team in that.

It’s also not about the position of the team in the organization. If a team has dependencies on, or is a dependency for, other teams, this might shape the inbound and outbound communication, which in turn might go as deep as expectations for an individual role in the team. However, relation with the rest of the org shouldn’t make much impact on how the team operates internally.

The opposite of team init is, of course, letting things develop on the go. It’s very likely you have seen it working many times, and it might even feel right for every person in the team, because people are generally very confident in their ability to estimate what other people think of and expect from them. Which is often wrong. And this is why, as a team, we need to lay out expectations in front of each other and talk about them openly.2

So, specifically, team init is

Participation

This one is simple: the whole team participates. No exceptions. Regardless of the role, if a person directly contributes to the team and is formally assigned to it, they’re in.

If even one person cannot make it, reschedule. If you have to reschedule two times, talk to the team: they might not be taking it seriously, which means you as an organizer should do exactly the opposite and insist on having this session.

Timeline and structure

This might sound like an off-site or a day-long meeting and in certain situations (large teams, team configuration changes coinciding with strategic pivots, etc.) it should be like that. However, in most cases all you need is 1–2 hours of uninterrupted time and some preparation done by each of the participants in advance.

I like the structure of the design double diamond so I stole it. Team init is structured, at a high level, very similar:

  1. Diverge: every team member lays out in front of the group their expectations toward their peers, giving only short explanation whenever necessary
  2. Converge: the team collectively observes the material, clusters similar points, finds patterns, and recognizes outliers
  3. Diverge: discuss the clusters and the outliers
  4. Converge: based on the outcomes of the discussion, we collectively decide on behaviors and values that we will expect from each other from now on

If the team has never met in the current configuration, make time for an intro where each team member, starting from the one who has joined most recently, introduces themselves to the team.3

The first phase, divergence, where people lay out their points, can and should be prepared beforehand. For this to happen, ask the team members to prepare the points they will bring into the session. Some tips:

Effects and artifacts

The main purpose of a team init session is for team members to talk openly to each other about what they expect from themselves, their peers, and the team. There’s also a background job for a team leader (which is probably you), and that is to make sure the organizer of the meeting (which is probably you again) documents the outcome and distribute it among the team members. At least the outcome of the team init meeting should be persisted so that the team can refer to it any time in the future. A physical or virtual artifact also implies that it’s serious.

Some teams might come up with a “team constitution”, where they describe what core behaviors they expect from each other. Some go even further and incorporate that into their regular team retrospectives, where they explicitly evaluate themselves on what they believe is the right behavior for the team. Since team init happens at the team forming stage, it’s likely none of that would work from the get-go, so you just got a job: make sure the team doesn’t write the outcomes of the team init session off and forget about it, and make sure the team uses it to self-evaluate and hold each other accountable. It will get easier over time.

  1. In practice, there will likely be functions that cannot be integrated into the team, varying from very technical, like QA or infrastructure engineering, to non-tech, like marketing or legal. (up)

  2. Talking openly about things like when each of the team members likes to start their day, how much they like small talk, whether they expect feedback to be given in-place or within a certain context (say, feature review), is really hard, because the definition of “openly” varies across cultures and individuals. A couple relevant books on the topic are Daniel Coyle’s “The Culture Code”, Erin Meyer’s “The Culture Map” (different topic, don’t get confused just because the titles sound similar), Kerry Patterson’s “Crucial Conversations” and, a recent one, L. David Marquet’s “Leadership is Language” (up)

  3. Dan suggested doing it in one of the team init sessions, and it turned out adding this small but significant change to the process makes a lot of sense now that we’re all remote and the likelihood of people meeting each other, unless explicitly scheduled, is near-zero. (up)