Welcome to the new Rules for Work Labs, where we're rewriting the rules of work. In our lab, we glean insights from the world's foremost minds, exploring leadership, team dynamics, creativity, artificial intelligence, and more. Join us as we dissect, analyze, and incubate ideas shaping the future workplace. Stick around to learn how we turn these insights into practical activities. Get ready for a journey into the future of work. This is the new Rules for Work Labs. The nature of teamwork is changing rapidly. We're being asked to frequently pivot between different team configurations. Some short lived, some enduring, some co located, others globally distributed, and sometimes all of the above all at once. Amid this flux, creating explicit working agreements can provide the clarity teams need in order to collaborate productively. But the traditional approach of lengthy team charters and off sites doesn't always fit our need for adaptability. That's why we're exploring how to evolve working agreements for the future of teaming. For this four part interview series, I connected with pioneering experts who all shared their hard won wisdom. In this first episode, we set the stage. How did these folks first fall in love with team agreements? Why are they useful? And when should you create one? I would love to hear from your perspective, what is it that you do? And, and as part of what you do, what got you interested in this question of like, how do we form strong working agreements? Well, one of the things I help teams do is design their culture so intentionally, and the first team step actually always is codifying what they have in place before they can understand what's working, what's not working, and then move on to the new state. And to a point that happens with teams that are established, but also with teams that need to get together for a quick project, last minute sometimes, and figure out how to work together. goes way, way back. Uh, so first to being in, in bands. Throughout high school and college and One of the first things that happens when you get together with anybody to play music is you instantly set up a working agreement Often it is tacit Often it is based on just kind of Standard work for musicians, like if someone's playing in five, four time, you don't suddenly start, you know, playing a rhythmically or whatever there are norms. And then there are areas to push beyond those norms. And it's one of the beauties of music. And the, the norms just happen to be a lot of fun. And it was when I was a member of a team, and it would have been in the late 1980s, so 35 years ago. And, and it was my first experience of being part of a team that wasn't all in the same location at the same time. And I remember this conversation, I can remember exactly where we were. And it was part of a bigger team building event. And the facilitator who was working with us just kind of said, you know, well, let's have a talk about what it is that's important to you and how you're going to work together and support each other. And I can remember at the time thinking, Oh, this is really different and really new for me. I have made a career out of learning from failures. I, I talk a lot about how I was a software developer who fell into consulting companies to become more digital or through digital transformations and built a lot of labs and innovation teams and helped launch a lot of ideas that like 95 percent of them were just abject failures and dead within. Six months or 12 months. And then I had to come to a realization that it wasn't how clever the idea was or how well it was packaged or what beautiful narrative you could wrap around it. It was the ways teams work together, the way cultures were designed to push back on new ideas or not to let new ideas really have an attempt to grow and scale throughout the organization. So much of my background is in software. And I found that software engineers are really good at avoiding team agreements. And not, not that it's, and it's not that it's intentional, it's just they assume since I can talk to the computer all day and it have a decent conversation, I should be able to talk to people the same way. Of course, it doesn't work that way. So then I went into urban planning and, um, and, and, and civil engineering, and I was suddenly running, uh, large design charrettes, uh, in Seattle, in Portland, in San Francisco, in Los Angeles, uh, and, uh, every place you went, There were different types of people. People in Portland were very collaborative. People in Seattle were very suspicious. People in San, in Los Angeles were very combative. Um, and so you had to prepare yourself to build again tacit working agreements. Uh, so that no one flipped out on you. I mean, I described that I just help people work better together remotely. That's what Collaboration Superpowers does. And we do it through workshops and we've got a bunch of free work, uh, resources, but workshops is the primary thing. And I started with team agreements when I interviewed Phil Montero. Oh, cool back in 2014 and he was, he was just totally ahead of his time. But he talked about that that point the ICC workflow, which was the information communication collaboration workflow. And that's where it began I mean that that interview was an aha moment for me. He was the first person to talk about it, but the reason why it was an aha moment Well, it wasn't really an aha moment It was sort of over time an aha moment, but the reason was because so many people in interviews after him mentioned the exact same thing It's like he's the first person who actually really structured it, but everybody else had some kind of way of Organizing themselves in with with an agreement that would just came up over and over Uh, so, so whether they've been in the same physical space with me or more often than not spread across different locations, how do we set the ground rules so that everybody's heard that ideas can be put out there so that we can make a decision together on what's the best way to move forward on some piece of work? Some of the things that came out of that conversation, and I learned so much about my fellow team members. Right. About how their working days in some respects were very similar to mine, but also that there were some differences. And so, you know, and also little things about, you know, I can remember one of my colleagues and she hated morning. She was really rubbish in the morning, you know, whereas I'm one of these people who's up and about bright and breezy and she's like, no, no, no, no, no, no, When, please don't call me first thing in the morning, you know, and it was those really little things, which when I think back to it, it just created a sense of us coming together, that cohesion, you know, team cohesion. So when did you start working with? What did you call it? Like those initial agreements and team charters and things like that? What did that come into your practice? It's a good question. So the team charter, for our version of it, was mostly created because we were invited in to teams that were dysfunctional. That were showing an inability to You know, I think it's both two things. It's like they didn't have the means to move work forward in a clear way, but they also had a hard time identifying even where they were in the context of work. Like, are we in a generative place? Are we in a decision making moment? Are we in a refining and optimizing place? Like, there was no shared reality on the team. That way. And our first charters were designed around like a one or two day intensive workshop for teams. And we call them like team design bootcamps. And it was just really to help them get a grasp of like where we are in this, in our shared context of work and some simple rules to move forward. Is it that foundational alignment question, right? Exactly. Uh, so obviously the, the first thing that you want when, uh, achieving or when seeking to achieve alignment. is the easiest thing to align around, which is basically in the end, what is it that we want to improve? Um, the challenge is that when all of those people arrive in the meeting, they might all be working loosely towards the same thing, but they all have different words to describe it. So, we will take a page from the game storming book and we will do an affinity mapping exercise generally around something oblique. So what we tend to use is something like what interrupts you or stops you from getting your work done. And then we get people to start looking at the problem sphere without talking about the problem directly. And that gets them to see all of their commonalities and cool divergence. And then we can start talking about what we want to actually align around. Yeah, and you know, in every workshop, the team agreement is the first session. Because we talk, every workshop we start with by talking about personal productivity and how that maps into team cohesion. Because one of the things that we've learned during the pandemic is we all have a different view of work life balance and like what our ideal days are like. But we can't all do what we want or it's chaos. We have to align somehow, and if we can't see each other, we have to create transparency somehow. And I think nowadays, I think it's something that actually every team could do with spending time looking at because the complexity of the role of leader or manager has just changed so much. You know, not only are we talking about where people might physically work, we're talking about all of the different technology now which can enable and really improve effectiveness. And it can also overwhelm and really get in the way. You know, so I think not only the working context has changed, as we become embracing more flexible and distributed ways of working, which is about the place, also our ways of working, the how, has really transformed and changed and is going to continue to do so. And I think when you put those two things together, I actually think that a working team agreement is a really good way for us. Every team to pause and go, How are we doing? It's usually different. Engineers, architect, engineer, leadership, product management, combating with with others because of that, those different perspectives. And sometimes it's it's getting down to that lowest level common ground. Sometimes it's Just understanding the lenses that they're, they're looking at, uh, so it, it's, it's trying to figure out what's, what's the fastest way that we can meet that, that common ground. And it may not be an elaborate agreement. Sometimes. When you come in and there's too much team cohesion, and then you realize that you're not talking to the team, you're talking to a silo and that the company has put like this group of hyper focused people in a group together and called them a team, but actually no work can be done by that team because it all always has to be done in conjunction with other people. And therefore, if you set up a team working agreement with that group, you will get nothing because almost all of their work is collaborative relationships with people outside the group for this conversation. We keep talking about team. How do you define a team? How do you recognize when you've got a team? Yeah, interesting. I think there's something about a common shared objective, a common shared goal. So it might be your team, so which is like, might be a functional team, or it might be a particular project team. Now you see, for me, I think team agreements work in both environments, but actually on a, on a particular project, they can, I think they can be even more impactful. Because it's a, it's generally lasts for a certain period of time and its outcomes and goals and deliverables are perhaps much clearer than a functional home team. We have a, we do a great job of, of building huge discriminatory systems in companies and then pretending like they're teams. Oh, and there are all kinds of forms that working team agreements are taking now when, when you're working with clients now at the, and I, and I recognize like chartering. It really was this big thing, right? It was, it was something you did in workshops and it had a poster and it was awesome. All of, all of that. And there was definitely cookies and coffee and time in that process. Um, what does it look like for you today? When do you choose to introduce these kinds of agreements to clients and what form do they take? I think they take a number of different forms because it, you know, I think so much depends on an organization's context. So I think, you know, pre pandemic, I was definitely doing a lot of work around team agreements and team charters and simple rules, you know, just trying to get some consistency of performance, both Within a team, and then with multiple teams across an organization, so often as part of a larger piece of transformation work, um, which then might be set within some simple rules, you know, these are the five simple rules, which will guide all of our working together, you know, as an overarching, and then each team would take that and say, well, what does this simple rule rule mean for us in this team? How, how are we going to see it come to life? How can we measure and track how we're doing against that? So they've changed a lot, but they also haven't changed a lot. And I think for me, one of the, one of the important things that guides my advice and guides my decisions with organizations is what is it that you're not seeing happen, that you want to happen within this particular team? So is it a performance? You know, we need this team to be generating more business. We need this team to be more innovative. We need this team to problem solve faster. We need that strategic, strategic execution. So I have two, let's say, frameworks that I use. One is a little bit more complex, which is the culture design canvas. And that encompasses lots of elements from purpose, values, how they manage meetings, and that includes some of the, the agreements. But then when it's just about the team agreements, I use what I call the washing instructions. Washing. Yeah. And I took that metaphor from an agile coach. And then I develop like a frame. So she said that she used, I don't know, uses still the metaphor. Basically, we were taught to treat people the way we want to be treated. And that's wrong because each person has different preferences. So the same way that your clothes come with a label on the back that tells you how they want to be treated, that's what you need to understand from your colleagues. And I love that you're starting with understanding yourself. Um, I like your personal user manual as an example. I wish I had seen it as I noted before I had written the article where I was out looking at personal user manuals. I think you did a really lovely job of, um, especially of acknowledging places where you've got Potential for friction with people and then owning them, right? Like the, here are some things I take responsibility for. Yes. Yeah. Yeah. That was, that was nicely done. Oh yeah. Because you can say like, I used to have a boss who would say. Um, if he doesn't say hello to you, don't take it personally, because he just saw you yesterday, so if he passes you by and just sort of passes, he doesn't feel the need to say hello. And I was like, so, you know, those kind of things were in his personal user manual, and I thought, well, it's good to know, but it still doesn't give you the right to be a jerk. Right. Like, okay, you can say that you're a jerk, but it doesn't mean that it's okay for you to be a jerk. Right. Like, you know, so I, I really look at sort of this personal, like, oh yeah, I remember him. Right. Okay. So are washing instructions something that each person then shares about themselves? Exactly. And that's basically what I work is first on personal. The tool has a personal preference approach and a team needs approach. So basically first we need to understand how people want to collaborate. Are you an early owl? Do you like to work late or not early? What communication preferences do you have? What are your expectations in terms of response? Do you like to provide feedback in the open? Do you like more to kind of work on one on ones. Do you like participating in, in, in, in huge meetings? So you prefer smaller settings to your work, that kind of stuff, no? And people share them. So the tool has four different quadrants and a, and a washing machine as a metaphor, and each team members completes There's and then usually what I do is that I pair them in Teams of two or maybe three people to share some stuff and go deeper And then at a group level each of them shares the two or three things basically one thing that people Need to know one thing That's a surprise that people probably don't know about the person and one thing that you never need to cross that line so if you want to successfully work with me, you better don't do this. You better, for example, don't call me without letting me call because I'm doing a lot of deep work, don't interrupt my flow, whatever that is. And after that, we reconcile and the personal preferences, because if we just follow what people like, then we cannot have a team. So we need to find common ground. And common ground for me doesn't mean looking for the lowest common denominator, finding that right tension between how people are going to thrive, but also what the team needs them to, to work together. So we have a step two, similar tool, washing instruction, but this is for team instead of for people. So the first is individual. The second is collective. So on the, so on the collective thing, do you end up covering the same ground, but then doing it as, as a team version? Exactly. And one thing that's important is that sometimes teams have either implicit or explicit agreements. So we want them to put it in writing to make sure everyone's clear. But most of the times people, teams haven't, have expectations and have frustrations, but they haven't discussed these things. So we start with that. Like, uh, how do you think the team should work? What are the expectations? What gets you frustrated? So we cover the different, uh, Areas, so to speak, from collaboration, from what are, how are we going to manage asynchronous and synchronous collaboration? What's the communication protocol? If, for example, how do we want to communicate? What, is there a tone style? Which communication medium do we need to use for what? What's the expected response rate? You know, some people send an email and you know this and they expect people to answer it like in 10 minutes and no, that's not going to work because people have, so that kind of stuff, no? And, um, And then working together, how we build relationships, how we want to facilitate courageous conversation, what's okay, what's not okay. If people are working different schedules to understand what are those schedules in terms, I mean, I work with lots of, most teams are no joke, right, but distributed across different time zones. So it's important that we also understand that to make sure that we bring people together. Um, uh, then alignment. So for example, that's for me, part of the norms of a team. No, what do we want to accomplish together? What does success look like? What is non negotiable in the team and how do we make decisions? So the non negotiable for me, it's a very interesting question because usually brings a lot of things that people say, okay, this is, again, this is not okay. And if we don't put that at the front and center of the conversation, they were going to get a little friction because people have different expectations. So. So when you do that, when you introduce that to a team, um, you know, I mean, most of the, most of the practices like that, that I've seen and that I've used are we're developed with the assumption that our team might be together for a while and that we've got. We've got an afternoon or we've got a day or we've got, you know, several days, spill it up over the course of weeks to work through all of this stuff, right? Yeah. Um, what's your experience in terms of, um, when a process like that is a great fit? And when it's maybe too heavy, or not enough, or, you know, how do you know that it's time to run that particular? Yeah, so I've had a couple revelations, and again, these are all, you know, from our experiences, I think different experiences and different cultures will metabolize these things. In a separate way. I think first, our mistake was like we tried to bring almost too much intellectualism to our charters and our, and working with teams and we would call it, we had this like entire scaffolding system that we call the anatomy of a team or sometimes we'd call it like MV teaming, which is like, how do we define? The most minimum characteristics but even within and it was like five or six elements that we wanted to make sure people were aligned Around but even each of those could have been a month long intervention program. Like the very first one was who's your customer? Getting teams to even be able to answer that question or you'd be arrested by people who We're arguing over like, who's our actual customer? No, it's, it has to be the end customer versus like actually who, who does something with your output, right? Is usually the way we define that. But that would it be its own place. And so like we brought, we had a lack of understanding where the team was versus our own intellectual rigor behind what a team needed. So that was a challenge. And then the second thing we realized is that especially in the last few years, like teams are moving so quickly. And the idea of stopping the team and trying to re contextualize or re codify everything and then sending them back out into the world like a baby bird just wasn't meeting their needs. So, it was more about what's the recurring rhythm we can put the team in for self reflection and continuous, not just continuous learning and continuous improvement, but continuous definition. So, like, what's the most, so these charters also, in the history of team charters, they Become these things that like just dust settles on over time and I'm not using it. How do we make it in terms of like, what's the most important pain point that you need to codify right now in order to move yourselves forward? And then do that. And then, you know, at some point kick in sort of like simplification, but that's a problem further down the road. Most teams are operating with just like everything is ad hoc or implicit. There's too there's too much really to pick at at once and until you focus on pain points or needs Interesting. Okay, and that's like that's like our perspective. There's lots of other teams That do things differently and a lot and our context is we're often brought in To an existing team that's been through some kind of change and needs to metabolize more change, but they're usually an existing team Now when we form like we also form change squads Which are wholly new teams that are tech they're supposed to attack a single outcome in the organization We can start sort of afresh and have some kind of chartering that occurs early on, but again, like our learning is like, make sure that you always pay attention to cognitive load. Like, if we're giving the team too many, it's like. It's like playing Dungeons and Dragons where it takes two weeks to explain the rules before you get started, and that becomes enough. Right. And there's no way, there's no way Uncle Bob's gonna play because he doesn't have his character made and one other twelve dice, I don't even. And now we're gonna meet in a few more weeks to keep talking about it. Yeah, it wasn't, it wasn't bondage. Just checking. This was not in the agreement. for checking. Um, I feel that this is a safe space. Thank you for joining us in the lab. We appreciate our guests for contributing to the thoughtful discussions on the future of work. If you've enjoyed the ideas we've explored today and want to put them into action, check out our companion newsletter at labs. newrulesforwork. com for the practical activities and additional resources. Don't forget to subscribe, rate, and leave a review on your favorite podcast platform. Your feedback is the catalyst for our ongoing journey. Into the future of work. Thank you once again for joining us. We'll see you next time in the lab.