Elise Keith:
So, on that front, you get a group, they've worked through an initial agreement. Initial agreements are best guesses about how things will work well. Where should they put it, and how should they keep it alive?
Dave - NR4W Intro:
Welcome to the New Rules for Work Labs, where we're rewriting the rules of work. In our lab, we gain insights from the world's foremost minds, exploring leadership, team dynamics, creativity, artificial intelligence, and more. 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, where insights meet action.
Gwen Stirling Wilkie:
Visible, as visible as possible. And I don't just mean literally, where you can physically see it, but visible in the conversations the team is having. Whether that's on a team digital shared space, whether it's visible in the manager's language, or in the sense of shared accountability within the team for the team agreement to be successful. It shouldn't just be something that's done and then ignored.
Chase Warrington:
Ideally, in a transparent space, such as a company handbook. This should be accessible to everyone on the team, and everyone should be able to suggest improvements as the team evolves. I would consider it a work in progress at all times.
Lisette Sutherland:
So, one, it needs to be at a place that's easily accessible by the team. It doesn't matter what tool it is, but it needs to be easy to access so that you're not searching in the depths of whatever file system you're looking for. It has to be easily accessible.
When I did it with my team, we found a need to review our agreement, and we were a team of three—right, a loose team of three. We looked at it every week during our team meeting. We had ours in a Google Doc, and what I found very helpful was that you could comment in the Google Doc. If the team agreement had a comment, it meant something came up during the week that wasn't clear. Then, we'd discuss it.
We had a section in the meeting where we would discuss that. If nothing came up, we'd just say, "Okay, nothing came up last week, on to the next section." But we actually had time for some review every team meeting because stuff came up. I don't think every team will want to do that, of course. We were a small team, and it was easy enough to do, but you have to find a cadence, right? At a minimum, once per quarter. Otherwise, it's useless.
Chase Warrington:
These should be referenced frequently, such as when kicking off a new project, onboarding a new teammate, and in regular updates from leadership. There's no such thing as overcommunication in this case.
Gustavo Razetti:
What we try to instill in people is that this is never perfect, right? Teams that will be working for a long time, or maybe at least a couple of months—let's say, not just one-off—need to understand that they need to come up with an initial agreement, put it into practice, and see if it works.
When coming up with these kinds of approaches or agreements, maybe we're missing stuff. Maybe we're trying to be too perfectionist, or maybe, to your point, we're anticipating tensions. I always say, let the tension arise, and then we'll revisit it. Maybe we need to learn how to play with this rule that we agreed on together, or maybe we need to revisit the rule because it's not as easy as we thought it would be.
Jim Benson:
Right, I'll share my screen again because I love it when I tell people to do things from my position of authority, and then I leave, and they do something completely wrong that totally works. There's no better thing in the world.
For me, it's all encapsulated in this particular board here. Wow, that's a fabulous thing that you have to live in that world to understand, isn't it? So, this is a Kanban. I want every Kanban purist or anyone who has ever created an online Kanban tool that thinks things only flow from left to right, and that there are just tickets, to take a good hard look at this because this is reality.
When you're building any giant building, you have to buy all the stuff for the building. This is the procurement schedule for two large buildings being built up in Harlem, New York. These are all the things that need to be built. All of these are columns, and the Kanban runs from top to bottom. Where there's a Post-It note, that's where something is in flight.
These numbers have significance to the people who are there. As these things go down, they're learning more and more about on-time performance and what holds them up. They have all of this data here the whole time that they're gathering.
Software or construction is entirely built on spreadsheets, so you can't take the spreadsheet out of the people. This is how I know their team working agreement is working—they're taking the time to invest actively in making the team better. That's the only metric for whether or not a team working agreement is in operation.
It's not if you're attending meetings. The letter of the law is just fascism; the spirit of the law is freedom. They said, "Jim Benson told us to build a board that looks like this, screw that guy. Our work says we should build it like this." I showed up and was like, "This is awesome." They were like, "We thought you were going to totally kill us." "This is my favorite thing ever. I don't know how to read it, I don't know what it says, but it's so awesome."
Lisette:
Yeah, and it's the same sort of theory as what GitLab has. People can commit; anybody can alter the handbook, GitLab's handbook. You just have to—you know—you add a commit or whatever terminology they use. I like that aspect of it.
Another aspect would be, one, it's accessible and easily accessible. It's editable by everybody, if possible, so that everybody can add, question, or whatever it is. It's reviewed regularly. Those are the three criteria.
Elise:
Really, I think about it well, and there's another implied criterion in what you just said: It's built into the work you're doing on a regular basis. It's embedded, accessible, like in your face.
Lisette:
Yeah, part of the agendas or the—in fact, I had one team use Miro as their team agreement. Basically, it outlined how the work flows. It was just a visualization of their workflow, and the roles, and who did what. It didn't make sense to me when I saw it, but it totally made sense to them. They used that as their agenda every week at their meeting. It's just a cool visualization, and I'm like, "Great, that works for you, awesome sticky notes."
Jim Benson:
Oh man, if I could just bottle that day. One other quick story about Turner: One of the other projects we had, which went incredibly well, was when COVID hit. They had their OBA all set up with their visual controls, and they were living their working agreement better than any team I've ever had in any field, ever.
When COVID hit, every other Turner thing called back to the main office and said, "What do we do?" They went into their OBA, laid out the problem statement, and said, "What do we do?" Their COVID plan ended up becoming the one that was implemented for all the other construction sites across Turner.
That is also how you know you have a team that's actually paying attention to their working agreement. When something really horrible happens, do they panic, or do they embrace it? If your working agreement doesn't allow you to embrace that, then you don't have an adequate working agreement.
Elise:
Cool, very cool. Are there any first-time mistakes that you've seen people make when trying to put these agreements together?
Gustavo:
Perfectionism, right? Trying to get it right the first time or being too prescriptive.
Sometimes people think, "Oh, we need to find an organic approach to working." Too much organic doesn't work, and too much control and anticipation doesn't work either. I always advise teams to start simple. Find the key agreements, don't try to list everything, and take it from there.
Mark Kilby:
I recall working with one distributed software team, and they were often told how to lay out their board. As we were having a conversation about how they might change things, they suddenly realized, "We can change our own board."
I said, "Sure. As a matter of fact, I have admin access. I'm going to give you control of the board, and I'm going to leave." So I did that. I said, "Okay, I'm giving you people the access to change the board however you like. I'm going to leave; just ping me online when you want me to come back."
It was the next day. They had a conversation about how the board setup was all wrong, and they ended up restructuring the whole board. After that, they said, "You know what? We're going to run some of our own meetings now that we realize we can do this. We'll just call you when we need you."
They did a great job of running their own meetings, simplifying how they worked. They also started having online lunch meetings. They wanted to know more about each other and what was important to each of them.
That group ended up influencing other teams. They started setting UI standards, taking more ownership of things, and bringing other teams into the conversations. It pulls back to what I was saying about respect
. That team influenced many other teams in that organization.
Elise:
That's cool. Have you ever seen an agreement go bad, to backfire in some way?
Lisette:
No, I've never had anybody come and say, "This was a bad experience, or we're worse off because of it." I do have a lot of teams saying, "We don't need it." They'll say, "We're a close-knit team, we've worked together forever, we know how each other works, we don't need this."
That's the most common thing I hear. I'm like, "Yeah, you don't need this until somebody leaves or joins the team, and then you really need it." There's all these things. I can see why they'd say that. Right now, it's just me and Tahira on the team, and we don't have a solid team agreement. We don't really need it. She does the finance, so there's not really a team. It's more like she's a very important subcontractor that I need to have regular contact with.
Elise:
Right, right, right. That is pretty different. Have you ever had a team agreement go wrong or heard of it?
Elise:
I haven't seen the agreement go wrong, but what I have seen is people who get clear about how they work end up sometimes discovering that some people are not interested in working that way.
It's a blessing and a curse. If you can be clear about how work gets done successfully in your environment and the values that are important to your team and company, there will be some people who don't like working that way or don't share those values. There's always a risk that those people are already on your team.
In these situations, it's just implicit. Yes, you've got an agreement; it's just not clear to everybody. You're not saying things to avoid potential conflict, change, or challenge, and at the same time, everything is slightly tense and goes slower. It can get worse and worse as people lose trust.
Eventually, those people do leave, or you leave. Those teams break, but they break slower and in an ugly, nasty, aggressive way.
Gustavo:
Yeah, let me rephrase that. For example, when I do team off-sites and leaders ask me, "What does success look like?" I give them two or three pointers, but I always include one: If someone doesn't quit in the next few weeks, we didn't do our job.
When working with executive teams and looking for alignment in a team that's not aligned, it doesn't mean everyone's going to get on the same page. It means the majority will, and some people will take a stand. Some people won't change their mind.
To your point, sometimes being vague or lacking clarity helps everyone hide in the shadows. When you bring clarity, not only will the team perform well, but people will need to take a stand. Some will say, "Maybe that's not the culture I want," and move on, and that's okay.
Elise:
Right, right, exactly. Usually, when those splits happen, it ends up being kind of hard. It's hard, hard, hard, but a huge relief for everybody involved. You don't have to pretend to be something you're not.
Gustavo:
Absolutely. Or, like you mentioned earlier, trying to please everyone. If you create a culture that pleases too many people, you end up pleasing no one.
Elise:
Right, right, right, yeah, absolutely. Especially yourself. You don't get to have fun being excellent if you're being beige for everyone. Although I did read one time that they had a way to translate sound into color, and they found that the resonant frequency of the universe is beige, which I find very distressing.
Gwen:
And I think the other area they can go wrong is when you're working in multiple teams. I'm going to come back to something I said at the beginning about how much of those practices are consistent across the organization.
The more consistency there is around particular protocols, like response times, which channels we use, or which platforms we use for certain things, the easier it becomes to follow. Otherwise, you're working on one project with one set of rules and another project with a different set of rules. It's really hard for someone to keep switching between them.
If there's consistency across all teams and projects, it helps bring an organizational way of working and an operating model together. Going forward, as more teams embrace team agreements, there needs to be work done at an organizational level to set guiding principles, guardrails, or simple rules that are universal around certain practices.
Otherwise, you're going to get so much complexity and difference. It's that balance of too much control and rigidity versus too much freedom, and we find that difficult too. What's the right amount of just enough but not too much? I call it the Goldilocks principle.
Elise:
Yep, okay, cool. So, you've got these outcomes: getting clarity about how changing the way you're working is going to change behavior, and then you try stuff. Which means that you then have to learn whether what you tried worked.
You talk about retros in both that context, but then we also talked about them in terms of helping the team work together better. They're different, right? The retro on whether the project is succeeding is definitely a different conversation than whether you and I are enjoying working together and what we can do to fix that.
Bud Caddell:
It's a very good point you made. We think of there being two kinds of retros: a team retro and a process retro. A process retro should really happen at key project milestones, and they should happen frequently enough that you can actually remember what you did. It's about improving the process of work.
The team retro depends on the kind of team. We generally advise a quarterly team health retro but find little rituals throughout the process. If you're doing sprint planning, you can do a start-stop-continue at the end of the week. How do we feel about being a team together? Is there anything we'd want to try differently?
It doesn't have to happen every quarter, but large changes to the culture can't be felt at least until a quarter. It's difficult to retro that and constantly try new things if you're not giving yourself time to test and reflect.
The team health retro is more about the elements of a team. You can use different things to reflect on as a team. You can use research from Google about accountability, communication, and trust. Whatever it is, it's just seeds of having a deeper conversation. Are we actually, as individuals, thriving on this team? Is there something about the culture that we want to call out and improve or not?
Elise:
That makes me think it would be handy to have a super simple pre-flight gut check on those core elements of teaming. Almost like a fist-to-five. "Hey, how are we doing on accountability? 3, 2, 1," and then find the ones that need your attention that week.
Bud Caddell:
Right, because teams can really only metabolize one change at a time meaningfully.
Elise:
Right, which is plenty because they all ripple. You give yourself an afternoon off, and that's the one change. Everything else changes around it.
NR4W Closing:
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 in action, check out our companion newsletter at labs.newrulesforwork.com for 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. Thanks once again for joining us. We'll see you next time in the lab.
