Original transcript

Welcome to the Collaboration Superpowers podcast. My name is Lisette and I’m interviewing people and companies doing great things remotely. Welcome to another episode, everyone. Today we’re going to be talking about team agreements. But first I want to announce that I have teamed up with another learning 3.0 facilitator. And we’re going to be offering a remote working learning shot in London on the 25^th of July. So if you’re curious about what that is, then keep your eye out on the Collaboration Superpower newsletter.

So team agreements. In many of the interviews that I do with remote teams, I hear that creating a basic set of guidelines helps decrease misunderstandings. Through my workshops, I am learning that very few companies have team agreements in place. So I wanted to share a little bit about the process and experience of the Happy Melly team which is completely remote in hopes that it sort of highlights how to create a team agreement and what the process might look like for you. Phil Montaro from the anywhere office introduced me to a guideline that he created for team agreements, and he called it the ICC Workflow. I’ve definitely talked about it in past. And it stands for breaking your work down into three categories: information, communication, and collaboration. So specifically, you would ask the team what kind of information do you need for the projects that you work on, what kinds of communication do you use to get your work done, and how do you know what everybody is doing.

So for the Happy Melly team, the way we started out was when we use Zoom, the videoconferencing tool, and along with Zoom, I set up an online sticky note board in [inaudible – 01:59]. And all I did was I put four sticky notes on the board, one called information, one called communication, and one called collaboration. And then I also put an extra sticky note on just for tools because I was curious what tools people found important to what they were using or what just came up.

We then took about 15 minutes to brainstorm. And people could just drag sticky notes and put anything they wanted in any category. It was just a free for all. So very quiet, everybody working on their own.

Once we were all done, we used the opportunity to talk about each sticky note as a team. And the things that we agreed on got placed in a Google Doc. In the beginning, I remember it being a relatively pain-free process. There wasn’t really any large disagreements about anything we just laid down the ground rules for. What are the expected response times? And how are we going to give each other feedback? And what tools we were going to use to communicate? So just a basic set of ground rules. And the idea was that we would evaluate them regularly.

So it’s been about four months now since we created those team agreements. And in the meantime, we’ve hired a couple new people to team. As I was walking the newest team members to the team agreement, it was pretty obvious that a number of things were out of date. And given that we had just hired new people, I thought this was a good opportunity to revisit the team agreement to see if we all were still on the same page. Now I didn’t do it right after we hired the new people. But instead, I waited about a month and after the last person had been hired before we looked at the team agreement. And I thought that was a good idea because it gives them a chance to sort of settle in and to see who’s who and learn how things work. And I think it gives them a better perspective for giving input during the review process. So I found that to be helpful. We of course tried to set a date that everybody could make, but it just turns out that with nine people and pretty wide range in time zone that that was just not possible. So we decided for those who were there, we recorded the meeting and the people that weren’t able to make it then had the option of watching the meeting and giving their input on the latest version of the team agreement.

Instead of starting the ICC workflow from scratch, I decided that it would be easier to go through the Google document point-by-point of what we had decided last time and just take a look at everything we wrote down and decide its relevance. And I will admit it was a bit tedious to just go down the list. So I wonder if there’s a way to make that more fun. But still, even doing so highlighted some differences in how we use the tools, and it gave us an opportunity to clarify some assumptions which was very interesting. So for example, Chad, our illustrator, he [inaudible – 05:02] status updates, and other people pay very close attention and really look at it every day. This kind of thing is good to know because if you want to communicate something important to Chad, you’ll need to specifically tag him in an update, and I’d done this, or use a different tool where he is paying more close attention. One of the assumptions that we came across was from [inaudible – 05:24] who assumed that when she saw someone’s Slack status set to available, she assumed that they were online and available to answer questions. But it turns out that most people on the team don’t keep their Slack status accurate. For example, I’m one of those people. I just have it open in my browser all day long, but I have all the notifications turned off. So it’s open, but if I’m working on something else, I’m ignoring it. Clarifying this assumption saves her from being frustrated in the future when she doesn’t get an immediate response from people because she knows that she can’t assume that they’re online.

A lot of other things came up too. For instance, meeting protocols and ways to improve our feedback process and how much everybody struggling with OKRs and what we could do to make that process a little bit easier. And we discovered that we didn’t have each other’s phone numbers, which was interesting. So one day, all of Chad’s communications went down, and he realized that he couldn’t let anybody on the team know because he didn’t have any way of communicating with us. He didn’t know our phone numbers. Not something that’s ever come up before, but it just highlighted that it would be a good thing to have. So I would say that even though the Happy Melly team was already a happy and working like a well-oiled, remote machine team, we still found ways to align and improve when we reviewed our assumptions together. And it really highlighted for me that whether you’re starting with a fresh team on a new project or whether you’ve been working together for a long time, creating a team agreement and setting those assumptions together can really help form the glue that binds your team together.

I encourage you to give it a try. And of course, I would love to hear about how your experiment goes. Report back at collaborationsuperpowers.com. Next week I’m back with another interview with an Agile coach who is living in Vietnam right now. Our weekly shoutout to the awesome Nick, the podcast monster whose show you really should be listening to. It’s called where there’s smoke. All right, everyone, until next time, be powerful.