Often when I am coming into a new team much of the work I am doing, while I get up to speed on the product and market, is helping the team focus and work together. Over the years I have come across, modified, and developed several tools to help facilitate establishing teams, norms, and roles. As always, no tool is exactly right for all teams. Adapt and change for the nature of the team you are dealing with.
Norms
Goal
Establish a common set of team level rules for how we collaborate and interact. This can be everything from SLAs around PRs to the number of meetings we have, from how we handle conflict to support rotations.
This process should be team led. The team leader should be a participant in the discussion. As such it can be very difficult for the team leader to also facilitate the discussion. A team norms discussion also becomes a way the team actively works through their communication and conflict management style. If possible, it is better to do this synchronously. The conversation is part of the point. Approximately an hour should suffice for this discussion. Some teams can do multiple exercises (norms + mandate or norms + decision making) in one session. Once norms are established, they should be updated over time.
Process
Let the team know you will be doing an exercise so they can think about it in advance. The prompt is “Think about a team you worked on that was great. What made it great? Think about a team you worked on that was terrible. What made it terrible?” Capture one thought per sticky.
Then group stickies together into themes. Talk through the stickies in each theme together as a group. As a facilitator make sure that people are engaging in debate on whether that idea is important to them as a team or not. This will allow you to come to a set of statements that basically boil down to “We believe…”
Examples
From a very mature team with a lot of baggage, this set of norms evolved over the 2 years the team existed. This example is only a subset of the total norms the team had. They did a remarkable job of holding each other accountable by simply saying “thank you for following our team norms”.

At a very different company, a very different result. This was a team coming out of a lot of process whiplash. Also, they were globally distributed (designer in India, team lead in South Africa) so there was a lot of concern for async communication and clear hand offs.

Roles and Responsibilities
Goal
Clearly define who owns what part of a process or has decision making power is essential to clean hand offs and action. While many activities fall clearly into one job title (HR is a great example of a job with clear boundaries) in the space between Product and Engineer, or between levels in an organization, things can be a lot murkier.
This process can either be leader with team or leaders among themselves depending on where you are seeing grey areas. It is best that anyone who’s position is being defined is part of the process. This process requires a willingness to engage in some difficult discussions about both skills and responsibilities and can become heated so it’s best to have someone with position power that can break an impasse.
This process should be done in conjunction with establishing a DACI process or establishing a 7 levels of authority so you can clearly talk about both the “owner” of a process and who should be involved in the decision and how involved.
Process
This is a classic card sort exercise focused on job responsibilities. This should happen in two phases.
Phase 1: Collect responsibilities
Bring the affected group together to collect all the responsibilities that need to be defined and owned. Working alone capture one responsibility per sticky. This can be as simple as “review a PR”, as mundane as “schedule meetings”, or as complex as “architectural direction”. Set a timer for the independent brainstorming. At the end of that time, go through all the items and group them and chose a “winning” card to represent each group of ideas. Take these cards to a new clean area.
Phase 2: Card sort
Have boxes for each of the roles you are trying to define. Together as a team determine which box each sticky belongs in. If the sticky belongs in multiple boxes, duplicate it. If a sticky represents a “decision owner”
Example
Most of this kind of discussion I have done has been in person, so I don’t have a captured shot. This is a heavily cleaned up example from our process of hiring a Head of Eng and establishing teams with a “pod captain” for each.

Decision making structure
Goal
Sometimes it is helpful to separate the Roles and Responsibilities discussion from the decision-making structure. This can especially be true when there are a lot of people involved in decision making and it can be separate from the actual job responsibilities. This has been the case for my current role as we have moved from a single Engineer team of 25 to 5 pods with pod captains.
Process
Same as ‘roles and responsibilities’ card sort with the initial part focused on decision making stages. In our process we also added in the variable of where and how the decision should be made and SLA because of how async we are.
Example

