Creating Team Contracts
BOUNDARIES
〰️
BOUNDARIES 〰️
One of the first things that we have our Rad Studio teams do is create a team contract. This is an excellent way for development teams to communicate boundaries and expectations early on. Team members all tend to believe that they have the “default” expectation when it comes to everything from office hours to communication standards, and yet most of the time people aren’t aligned at all! This can lead to boundaries being unknowingly crossed, resulting in resentments or conversations that are way more uncomfortable than they had to be.
In my experience as a project manager, I can confidently say that every single frustration or resentment that arises within teams is a result of misaligned expectations and a lack of communication around those expectations.
The purpose of creating a team contract is to deliberately step through all of the expectations inherent in undertaking a group project in order to unearth and remedy any that don’t line up. The contract is then written up, shared, and agreed upon by every team member. It provides a reference for everyone’s behavior and a very handy document if boundaries ever get crossed down the line.
To illustrate the usefulness of this, think about this:
Have you ever found yourself pissed off after receiving an “urgent” email from a coworker on the weekend? You don’t want to work on the weekend, but you find yourself stuck uncomfortably in between three less-than-great options: do the work and add a little bit to that “resentment bank;” ignore the message, but feel unsure about your choice, and maybe experience preoccupying feelings of guilt; or negotiate a potentially tough conversation about your boundaries on the fly and field your coworker’s reaction.
Of course, there are strategies for asserting boundaries even when they have not already been stated. But when it is done ahead of time, it is SO. MUCH. EASIER.
Imagine that same situation but y’all had already decided (and put in writing!) that messages sent on the weekend are not expected to be answered until the following workday. So your coworker sends you an “urgent” email on the weekend. Can you sense how your options feel really different now? You’ve already stated your boundaries (and they’re written down!!). So, you ignore the email, and you don’t feel a bit guilty or unsure. And maybe on Monday, you calmly point your coworker back to the team agreement. You’re able to have a constructive, drama-free conversation with them, using your contract as a tool.
TLDR:
Why you should create a team contract:
Sets crystal clear expectations of every member of the team, right at the beginning of a project.
Provides a tool that makes tough conversations much easier.
When a team should use this:
Ideally, after the team has a had little bit of time to get to know each other, but before production has begun.
How a team should use this:
Hold a team meeting (in-person, if possible! So much better for reading body language).
Go through all of these questions as a group, writing down the answers in a document as you go.
Circle back around and iron out any disagreements. Everyone must agree. Skipping over a problem only means it’ll come back later - and be a much bigger pain in the ass.
Clean the document up into one page - make it nice.
List everyone’s name at the bottom along with the date.
Hang it up somewhere where the team can see it (if you’re working remotely, consider pinning it in a chat channel).
Feel secure knowing that you just nipped a whole bunch of potential problems in the bud.
I’ve included the template that we use here at Rad Magpie. I encourage you to use this and make modifications based on your own organization and experience.
Happy expectation management!
Rules of Use
This blog post is based off of a portion of the 2021 Rad Studio Online curriculum. Rad Studio 2021 was a fully online summer program for game development students, and the information above was shared with the cohort of emerging devs during a workshop session. We’re making this information free and available to anyone who’s interested in it. You can learn more about Rad Studio and this initiative here.
Rules of Use:
Feel free to share this information with others! We ask that you cite Rad Magpie (and any relevant linked sources) if you use this for your class / workshop / etc.
If you find this useful and are financially able, consider making a donation to Rad Magpie. We’re a 501(c)3 nonprofit organization and rely on the generosity of our community to continue producing resources like this one. Learn more about Rad Magpie here.
This blog was written by Dana Steinhoff