Good team culture strives for cohesion. Once organizations get large enough, a tension emerges between the culture of individual teams and the culture of the larger organization. How do you achieve team cohesion across small teams and the larger organizations they comprise?
The culture at Artsy is driven by every team member, not mandated or handed down from above. This adds another level of tension, between individuals and their smaller teams. Team working agreements embrace that tension to provide a framework for converting tension into healthy culture.
Artsy Engineering is part of a larger organization we call PDDE (Product, Design, Data, and Engineering). PDDE is divided into several product teams, and each team contains at least one representative from product, design, data, and engineering. Each PDDE team delivers product solutions targeted to a specific product need.
Until recently, those teams could expect a significant change in team members at the start of every quarter, as we encouraged engineers to explore other teams. The purpose of this practice was to spread knowledge throughout the organization, and give folks the opportunity to keep themselves aligned with projects they found most interesting.
The downside of this practice was that it made teams feel short-lived, impermanent, and unstable. Some teams were hit harder than others - they’d see their team completely turn over every quarter. This was felt most strongly by our product managers who would take the time to learn the skills and strengths of each engineer on their team over the course of a quarter, just to have to start the process all over again, making it difficult to plan projects or set goals for the following quarter.
To address these challenges, PDDE decided to set the expectation that engineers would stay on the same team each quarter, with the option to request a team change, when necessary, to fill a skill, capacity, or growth need elsewhere. This effectively ended the practice of shuffling teams every quarter. It was too much change, too often.
As a result, our teams feel more stable and long-lived. We’re able to build deeper team identity. We’ve found one tool particularly helpful in finding and building team identity: team working agreements.
How did team working agreements come about at Artsy?
The current breakdown of our PDDE organization is relatively new; it’s also an on-going process. We are still feeling out how these teams will/should work together. One of the core beliefs at Artsy is that when you are a part of something - a process, a team, a culture - you are empowered to make impactful changes to it.
Since being pioneered by Adam’s team, team working agreements have spread to most of our engineering teams. They’ve been a learning opportunity for all of us, and a chance for our team members to share experiences and practices with each other.
What’s a team working agreement?
A team working agreement is a written set of guidelines for an engineering team. It enumerates the habits and practices that the team requires to be productive and successful. The agreement is a living document, and every member of the team has a part in shaping it.
According to Bruce Tuckman, a team moves through four phases of development: forming, storming, norming, and performing. Team working agreements can help a team move more quickly through the stages. A team in the “forming” stage will quickly uncover areas of disagreement and move to “storming” when they attempt to align on a working agreement. A “storming” team might move to “norming” more quickly when their points of friction are arbitrated in a working agreement.
Examples of habits or practices on a team working agreement might include:
- Any change to the sprint backlog requires product manager approval.
- Everyone owns the backlog and should add tickets for untracked work.
- Update the backlog before each day’s standup.
We’ve been using a fairly consistent process to develop team working agreements at Artsy.
Step 1: Educate the team about team working agreements
We want every team member to recognize the importance of creating an agreement.
Each team reviews our docs on the process of creating a working agreement before creating one. They might also review an existing working agreement.
Step 2: Conduct a brainstorming meeting
The team meets for an hour to brainstorm ideas that promote success from each individual or the team as a whole. Some of our teams have met fully in-person and used physical sticky notes for brainstorming; many have used an online tool like Miro to include remote members.
It’s vital that all members of the team attend the brainstorm. For us, that includes engineers and product managers, but also designers and data analysts. This is a discussion of how the entire team works together - everyone’s voice should be heard.
A sample brainstorm agenda is shared in our docs. The output of the brainstorm is a set of ideas that everyone has contributed to.
Step 3: Distill brainstorming ideas into discrete, digestible habits
The ideas from the brainstorming process can be sorted into themes. Within themes, we work to condense ideas into habits and practices that are agreeable to the entire team. We have found success in keeping the language for these habits small, discrete, and slogan-like.
The distillation step might take several round-trips of gathering feedback and wordsmith-ing.
Step 4: Commit the most important habits to a “Team Working Agreement” document
The team votes on which habits should be included in the agreement and a document is circulated.
It’s not done, though. Remember: it’s a living document.
Step 5: Revisit the working agreement
As a team, decide how often the agreement should be revisited, and what “revisiting the agreement” means. When should we amend it? When should we do another brainstorm? It probably doesn’t make sense to scrap the old agreement when one new team member joins, but how much change on a team would inspire us to recreate our agreement?
Why establish a team working agreement?
The brainstorm itself is incredibly valuable.
Dedicated time to talk about values, habits, and processes is incredibly helpful to a team, yet rarely scheduled. The brainstorm for a team working agreement can fill this void.
During the team agreement brainstorm the team looks at how they work, instead of looking at what work they’re doing. It’s similar to what you might get out of a retro but at a higher level. It offers time to discuss “soft” skills that you don’t often discuss, in a context that you don’t usually discuss them - with other individual contributors, and with your closest collaborators.
It can lead to better engagement in sprint activities.
One of our teams established in their working agreement that sprint meetings were valuable. This might seem too obvious to put in a team working agreement, but it portrays clearly to everyone that they should attend all sprint meetings and be actively engaged.
The same team got a lot out of making slogans for the items in their working agreement. Phrases like “Pair by default” and “Incremental improvement over consistency” were introduced during the brainstorm. They’ve since become mantras for the team to refer to during sprint work and ceremonies. Team values and habits solidify through this kind of repetition.
The team working agreement provides on-boarding documentation.
When new members join a team, it takes time for them to adjust. A team working agreement provides an up-to-date reference on the team’s preferred methods of working. The working agreement isn’t set in stone, and as the team changes it’s important to update it… but having it in writing helps new members acclimate quickly.
What are some challenges with team working agreements?
Uncertainty about what the team agreement should include.
Some teams have struggled to identify what belongs on a team working agreement. Should it describe our team values? Habits? Procedures? Rules? Favorite afternoon snacks?
It likely varies from team to team what you want here. Some teams might require guidance around working with JIRA; others might be more focused on taking ownership of problems. These differences are likely a reflection of the problems the team is currently facing or has recently faced.
It’s definitely important that you identify what you’re looking for up front, and make it clear heading into the brainstorm. Suggest categories, sample habits, & questions to ask heading into the brainstorm, and keep them visible during the meeting.
Take notice of known problem areas: are they addressed or avoided in the agreement? It is easy for a team to avoid confrontation at their own expense.
Also be cautious about introducing individual bias.
Remember that the working agreement is a living document. If the team learns that it missed something in the brainstorm, don’t hesitate to update the agreement. Team retros are a great time to make updates.
Working agreements are hard to define for teams without a well-established identity.
For a team that has a strong and cohesive identity, the agreement is likely to affirm many things the team is already believing and doing. For a less cohesive team the agreement is harder to pin down. Many opinions will surface, and they may be in conflict with each other.
While this is indeed challenging, it is also important to note that teams that lack identity benefit greatly from the team agreement brainstorm. Provided there is psychological safety, this is a really great time for the team to learn about what matters to each other, and move toward establishing an identity.
Facilitating the brainstorm can be difficult on a distributed team.
Some of our teams were able to brainstorm with everyone on-site. They were able to rely on post-it notes and in-person conversations, and read each other’s non-verbal communication. Other teams have a mix of on-site and remote members, and used tools like Miro to facilitate. This can present a challenge…but if you’re already a distributed team, they are likely the same types of challenges you’ve worked to overcome for all meetings.
The differences are worth noting, though. The importance of reading each other’s non-verbal communication is magnified when you’re having conversations about identity. It’s quicker to organize and re-organize real-life post-its than virtual post-its in an online tool. These are all opportunities to get better at being a distributed team.
It takes effort to make sure one person isn’t introducing their bias into the working agreement.
It’s important for the team agreement brainstorm to provide an environment in which every team member is heard. Even if your team is successful at this, there are still opportunities for individual bias to affect the working agreement.
We saw earlier how bias can appear when the examples provided for the brainstorm are too narrowly scoped.
We recognized another bias vector in the distillation of the brainstorm into an actual agreement. If this is handled by a single person, it’s very possible for them to produce a working agreement that misrepresents the rest of the team. To counter this, we’ve had multiple team members pair on the distillation process. Feedback on the initial draft of the agreement is also important to ensure it does not misrepresent the team’s ideas.
The problem of introducing bias to the distillation process is most challenging with topics that are disputed across the team. One of our teams spent a lot of time talking about meetings in their brainstorm, but struggled to come to consensus on them. No single person, or even a pair, could add a disputed topic like this to the working agreement without introducing their personal bias. In this specific case, the team chose to leave meetings off the working agreement until they could reach consensus. Topics that are disputed across the team are important to talk about at some point, but the brainstorm is probably not the time.
Team health is easy to postpone when you have important product work to do.
One of our teams put the act of distilling the brainstorm notes into an agreement on one person. That person became busier than expected, didn’t have time to write the agreement, and the team’s agreement stalled.
Just as personal self-care gets put on the back burner during stressful times, creating a working agreement is easy to bump down the backlog during intense periods of sprint work. The longer a team drags out the working agreement process, the more context is lost from the original brainstorm. We recommend not letting your working agreement linger.
It’s also important to revisit the working agreement often. It is a living document, not one-and-done. Review the agreement as a team occasionally; update the agreement as your team learns how to collaborate better; cultivate the agreement. If an agreement gets stale, it will become inaccurate, meaningless, and unused.
What does it even mean to have a team working agreement?
A team working agreement is a neat artifact. The brainstorm process has great value. But there is non-obvious work involved in turning a team working agreement into the team culture. We have many questions that we aren’t sure how to answer:
- How do you enforce the agreement?
- Should you enforce the agreement?
- How do you get the entire team to embrace it?
- What happens when the agreement is violated or disrespected?
If you’re using working agreements on your team and you’ve got answers for us, or you want to start using them and have more questions, we’d love to hear from you!