You know, one of the quotes I really like is attributed to St. Augustine, I think incorrectly, you know, unity and essentials and liberty and all else. You need to figure out where you need to unify. And it's really important to decide where should there be liberty.
Hey, everybody, welcome to the show. This is Brave New Work, a podcast about reinventing our organizations and the search for a more adaptive and human way of working. I'm Aaron Dicton, and I'm joined by my co-host, Rodney Evans.
Hey, everybody. On today's episode, we're going to talk about working agreements, why some teams get explicit about how they want to work together and others don't, and how that changes their performance. But before we do, should we check in?
I think we should check in. So we start every episode of this podcast with a check-in question. This is just a moment to get ourselves here and connected, present. And our check-in question for today is, if you could choose, what would your last meal be?
And because I'm high conviction on this answer, I'm going to go first. Okay. It may come as a surprise to you, my friend, that my last meal of choice would be a medium number one with orange high C from McDonald's.
And for all you haters in the place. Oh, yeah. Oh, this is happening. A medium number one is a Big Mac with medium fries.
Right. Right. Big Macs for me represent what is effectively panacea.
If I am ill or I am sad or I have done something bad to myself, like drinking too much red wine, Big Macs are known to be the only thing that cures me. They'll bring you back to life. Approximately once a quarter, one of those things happens and I go and get a medium number one with orange high C because I am a child.
All these patties. Special sauce. And it never fails.
It never fails. And I feel like it would be very comforting for me to have that as my last flavor in this life. I'm simultaneously tickled by that and a little sad for you. So I'm just going to go with that. Although what's interesting is my answer is equally simple in some ways.
I thought about this for a... about 10 seconds and the answer was obviously chicken and waffles, fried chicken and waffles. And I just feel like it's, yeah, it hits that bliss point that would make me feel good about going on to the hereafter.
So that's my answer. Final answer, fried chicken and waffles. I feel like we really learned something from each other here today. And also, there is a world famous chicken and waffle place one block from my home.
And the next time you're here, I will take you there. I'll be there this week. Let's do it. Rock and roll. So on to the serious business of today's topic, which is working agreements.
Let's just start with talking about what working agreements are. How do you define them? Why do we need them?
Aaron, just get us grounded in this topic. Yeah. So I think one of the things that we found in the research for the book and that we've just learned in thinking about new ways of working over the years is that really high-performing, high-functioning teams tend to be very explicit about how they work together.
And that often means that they have written down and sort of documented and agreed upon, this is how we're going to do these certain important things. This is how we're going to meet or how we're going to decide or how we're going to share simple stuff. Like how will we use email? How will we use Slack?
If I send you a note at 10 p.m., are you going to reply to me or not? And why? And what are our sort of values and principles?
about how we'll work together as a team. And I think that that habit creates this pattern where now they know what to expect. And generally speaking, the teams that don't have working agreements, we find that they kind of labor under a lot of assumptions and illusions about, well, what I expect must be the norm or must be what everyone else should do. So if I send you a note late, I want to reply back late.
If I think that the way we should decide is through consensus, and we don't, then I'm offended or I'm alienated or what have you. And there's this reticence to have the conversation or have the conflict or have the moment of like, how are we going to do this? And in some cases, that's because we're just waiting for the boss to tell us or we're waiting for the company to tell us how things should be. But of course, they very rarely do. And so we end up in this like weird collision of personalities and assumptions and unspoken expectations.
And I think that that's, you know, that's the topic in a nutshell. Yeah, cool. I am totally with you on this. I think one of the things you started with in that definition that is super important to draw out is just the explicit nature of these agreements. So often we get caught up in the content of work.
It's just, it's all about the what of the business and the strategy and the numbers and blah, blah, blah, blah. And we so overlook the how of that work. And these explicit agreements, these working agreements that we do create together, that we do define together, that we do document together are such an important way of saying how we're going to do stuff.
How are we going to make decisions? How are we going to communicate with each other, et cetera, et cetera. It's just, it's so often overlooked.
And to me, it feels like such low hanging fruit. Like it feels so easy to just go like email or Slack, like text or chat, like, um, you know, morning, you know, morning or night, coffee or tea. It's like, it's so easy to just take 10 minutes when we sense tension and say, can we just pick, can we just pick a way for now to try?
But it's so, so rarely done. What do you think the most foundational working agreements are? So when you sit with a team that hasn't done a lot of this work and they're sitting with some tension, what are usually like the spaces where they haven't made agreements? Three things come to mind as the most obvious.
But I also want to hear your answer because I had the same question for you. One is meetings. So. When do we meet, for what purpose, with what design, and who's facilitating? Like, that is some basic hygiene around working agreement that is so often meeting and where I feel like the tail completely wags the dog in systems where they're like, we just have meetings and they're on the calendar and like, God only knows why.
The second is how we make decisions. So because of all that's implied in decision making around power dynamics and around history and hierarchy and all of that stuff. And even just a lack of literacy about the fact that there are multiple ways of making decisions.
I think we usually don't have good agreements around when we ask for advice, when we require consensus, when consent will do, et cetera, et cetera. And then the third one that is so often overlooked, but super foundational is the tools environment. Like where are we going to put stuff?
How are we going to talk to each other on what platforms for what things? And those three are not the sexiest of the working agreements, but I think get you pretty far in terms of clarifying things that are often mysterious and very irritating. Yeah, yeah. Are those the ones that you would have said or do you have others that come up? There's overlap for sure.
I mean, I think meetings, decisions, tools, and how we use the tools, like what are our kind of service level agreements to each other about when and how we'll be there, I think makes a lot of sense. The other areas that I find are often interesting in their sort of lack of clarity are like purpose and intent. Like just generally speaking, why does this team exist and what are we trying to do in the world?
You wouldn't think it, but because we just go through the motions so much, most teams that we sit with and ask, do you all have a shared take on that? They might have it for the company. They very rarely have it for the team.
Or they don't know what it means or they have slightly different takes on it. or they've been reorganized recently, and so they're like, it used to be that we were really focused on customer satisfaction, and now we're kind of in this weird UX-y place, so we're not sure. So I think agreeing what we're trying to do as a team at an outcome level is really interesting.
And then some of the simpler stuff, too, about the space we work in. Are we a remote team? Are we an in-person team?
What hours will we keep? in those forums and, you know, in either one. So it kind of overlaps with tools, but it gets into the physical world. You know, when will we come together? When will we do things apart?
So I think that's interesting. I think roles that we'll play is pretty, is an interesting working agreement. So obviously decisions is important, but also like, are you the one that's going to, you know, answer inbound emails or is it me? And in startup environments, at least we wear so many hats that it's like, everybody will just jump on whatever task comes in the door.
But then later on when there's more people, more specialization, more volume, those working agreements get kind of interesting. And sometimes the written job description is just totally insufficient and totally not based in reality anymore. So having a more alive agreement makes sense, I think.
Yeah. And what you're describing that always cracks me up is in the absence of these agreements, how you tend to have one of two polarities. You- either have kindergarten soccer where it's like everybody reply to the incoming email because it's no one's job or the stuff that like nobody wants to do like you know changing the light bulbs and taking out the trash that just sits and languishes forever and it's like there is you know as there always is there's oh there is a third way which is we neither need chaos nor we need to live with a total apathy we can just make clear whose turn it's going to be for a while to do whatever That makes sense.
And I think we obviously both feel that sports metaphors and analogies are overused. But it is true that like, you know, when you think about a kindergarten soccer team versus, you know, a pro league, it's it's mostly I mean, it's obviously ability and talent and all that. But a lot of it is like really clear working agreements. This is how we will train.
This is these are the plays that we will run. This is the positions that you know, these are the positions that we're going to hold. Like that stuff is ultra clear. Yeah. What's interesting as you say that for me is if you think about a team environment like that versus the team environments that you see inside of a more corporate system, who's making those rules and how are those requests getting made?
Because I think that's often where the difference and where the flip exists is in a team that's like a soccer team, say. Playing from position and having clear rules might be a little bit easier because there is more of a structured playbook and there is a coach who is often making a lot of those determinations. What we're saying is, you know, for the team to figure out what it needs and for the individuals in it to make those requests. That's right. How do you think about that?
How do you think about a team starting to shift into deciding what they need agreements about and then actually going through the process of making them? Well, I think you hit a good point, which is it's important to delineate between the environment that a sports team operates in and the environment that a modern corporate or startup team operates in. Because in the sports environment, what we're going to do, how we're going to do it, where we're going to do it, what the rule, like it's all constrained. It's all defined. So like very little uncertainty.
You're not going to show up in the soccer balls five times as big. Like it's a, you know, it's a very, very certain environment. And so the uncertainty is just all about the competition and the play.
So the... That allows for a great deal of standardization, and that allows, obviously, for a high degree of performance in that theater. I think when you come to the business environment, much higher dynamics, much higher rate of change, much more possibilities, much more complexity.
Even inside a single client of ours, you might see a thousand different kinds of teams that have different ambitions and goals and connections and accountabilities, etc. I think the big insight here is... It's because of that, it's really hard for any leader to define all that stuff because they won't have enough information. And even if they do, they'll be wrong when the world changes.
And so you almost need to sort of push this authority out to the edge to say, you know, not only are we giving you the authority to make decisions and do things, but also we're giving you the authority and the expectation to define how you're going to work. So not only what are you going to do, but how are you going to do it? And that is part and parcel to being a successful team today. And the way to go about it is just to start by having a space for that conversation, a space that says, you know, we are going to put the things that we don't know or that are causing tension or that are holding us back out on the table.
And then we're going to say, is there a way that we can make an agreement about how we're going to approach that thing for a period of time and then see how that agreement serves us, right? So if we agree to play these positions or we agree to. make decisions in this way or what have you, that's kind of at the heart of that process.
So I think even starting with the simple stuff, you know, about how we use tools and about how we meet, it just like builds that muscle and that practice. And then, you know, over time, you can see how it plays out. What is interesting to me, and I'm curious to get your take on is, it is one thing to write down an agreement and everybody's sitting around the table and going, yes, let's do that. We'll only email between these hours. What do you do when an agreement is...
broken or an agreement is violated? How have you seen that handled well or handled poorly? There are a few things that come to mind in terms of answering that question. But the first one is to look at the breaking of agreements not as a personal violation or an interpersonal conflict, but possibly as data.
So it's like, did we just make the agreement wrong? Or what does that tell us about the system? If you break a working agreement that you and I have established. Does that tell me that it's not documented properly?
Does that tell me that it's not understood properly? Does that tell me that those working agreements are not a part of an operating rhythm so they don't live and we forget about them? Or does it tell me that maybe that agreement has outlived its utility and we should revisit it?
So rather than defaulting, as we so often do, to me just going and talking to someone else about why Aaron is so difficult to work with and completely ignores the agreements that we've made and how much that bothers me. I think there's a more useful set of questions to ask, which is... to you, which is, why did you break this agreement?
Is there anything that we should do about that? And maybe you're like, no, I just forgot. Or maybe you're like, yeah, dude, when we make an agreement and then it lives like in our internal Wikipedia for a year and no one ever talks about it again, it's unlikely that I or anyone else is going to stay in compliance with it.
Right, right, right, right. Yeah, that makes total sense. Yeah. I think the other thing that we'd be remiss in not- discussing is talking a little bit about the power dynamics of this. So a thing that I've noticed recently, I just had this conversation with a leader in an organization that you and I both know well, who said something to me to the effect of, as you get to know me better, you'll know that this is how I work or this is what I prefer or something.
And My reaction internally and then immediately externally, because that's how I do it, was like, or you could just tell me. Right. Or we could not do this thing where there is a competition of who is the best at guessing what you want. How everyone else likes to work. You could just be like, I prefer getting emails with attachments to whatever.
It's like, what is it about becoming more senior and having more power in an organization? that entitles you to play this game of guess how I like it. And then for people to legit evaluate themselves on how good they are at guessing.
It's so weird. It is a weird power game that goes on. And I do see that.
And I think it is, in some ways, connecting to another episode, the one about ego and identity. I think it really feeds the ego to be like, I'm this mercurial personality, this leader, and you need to kind of manage my... my whims and my style. And part of, part of becoming close to me is learning my style. Like that's work you have to do.
Um, as opposed to a lot of the systems we study where there's a user manual to me for each person and there's a set of working agreements for the team. Cause I think one of the missing pieces in that thinking that like, Oh, we just need to know how the leader likes to do it. And then we'll all do it that way is that that's not, uh, unlocking the full potential of the team. That's only unlocking the full potential of the leader. And so the team actually needs to decide, well, how as a whole, how do we like to do those things?
Because if the way we do our best work is slightly different than maybe the way the leader would do it alone, well, then that's a worthwhile discussion to have. And that's a worthwhile, you know, dynamic to pull apart and say, like, which way should we do it and why? Because the ultimate goal here is to deliver value and to deliver an outcome and to please a user, not to please a boss. Like the company that has the happiest bosses.
does not necessarily have the happiest customers. Or the best outcomes in terms of actual business metrics. Yeah, I think that's exactly right. And one of the big obstacles to overcome for the team to do that and to make that shift, first of all, you have to have a leader that's willing to make some space for that and that acknowledges that participatory change means that they are also potentially going to have to adapt to new ways of working. But also, there's like a...
there's a vulnerability in making clear requests that I find is very difficult for teams to get to the first time that you sit down to do some chartering work and to say, okay, let's make an agreement about tools or let's make an agreement about decision-making. I find that there's some real hesitance for a lot of people to just propose something, to just propose a starting place that doesn't look like... what it's looked like historically or doesn't look like the leader's preference.
How do you start to get past that? I think that's right. I mean, one way is for the leader or the people with some influence to just start to model the okayness of different possibilities, right? So instead of saying like, here's one proposal from the leader saying like, here's three proposals, like maybe we do it this way, we do it this way, we do it that way. And it creates a little bit of space for people to be like.
Like, oh, there's not a right answer here, where if I say something out loud and I'm wrong, I'm going to be judged. But instead, I can say, hey, you know, I kind of like option B better than option A and C, and that feels pretty safe. So I think as a starting point, the leaders or the people that hold power have to kind of model that spaciousness.
And then over time, I think people will jump into the fray, you know, a lot more readily. Yeah, I think that's right. I also think just giving people.
Making a space to make proposals about working agreements is really helpful and important. And I had a funny thing happen to me this week. It was actually funny.
laugh, like lol funny for me. So I'm working with this team right now and they're very early on in all of, all of the new ways of working in making agreements and doing experimentation, et cetera, et cetera. And I've been, they have a, they have a tool, uh, that is a Slack competitor, but they don't use it a lot.
And I've been really trying to figure out like how to get them ported over to using this other tool so that in our work with them, we're more able to chat. and collaborate and whatever. But I don't know them and I've been hesitant about it.
Anyway, so I said something to one of the people on this team about my desire to do this. And she goes, why don't you bring that as a proposal to our next meeting? And I was like, oh my God. I just got schooled by someone who is on day one of this work.
But the lesson for me, because duh, I should 100% know better and should have thought of that a week ago, is to notice in myself when I'm procrastinating, when I'm kicking the can, when I'm feeling tension, when I'm hesitant about someone's reaction to a thing that I would like them to be doing, to default to the work that we know how to do, which is propose a solution and see how it goes. Propose an agreement and see what the feedback is. rather than languishing in this like, could we, might we, would you, can you help me do it? It's like, yeah, dude, she was literally like, why don't you use the template that you gave me and bring it to the meeting?
And I was like, oh, snap. Okay, will do. But it was a reminder to me to notice my own tension and turn that into a proposed agreement, which should be very obvious, but isn't always. Proposals over politics, right? For sure.
So for today's guest, I reached out to Mike Bravort, who is a friend of mine who works at Slack. And what I thought would be so interesting about that is for that company to function, they have to use and wrangle with and deal with their own tool, which for so many other companies is such a challenge. And yet, from what I hear, they seem to really do it inside. So he's going to join us and talk about the working agreements around Slack and also what they use across the rest of the company to.
do what they do. So with that in mind, we'll be joined after the break by Mike. Ready, set, go.
Hey, everybody, we are back with Mike Bravort, Director of Engineering at Slack and my recent friend. Mike, welcome to the show. Thanks, thanks for having me. So tell us a little bit about Slack.
Most people that listen to the show are probably using it, frankly, but if they haven't heard about it or haven't dipped their toe in, a little bit about Slack, and then a little bit about your role there, what you've been up to lately. Sure, yeah. At Slack, I mean, ultimately what we're trying to do is we're trying to make your working life simpler, pleasant, and more productive. And that sounds very, very loftily, but ultimately what we're trying to do is trying to... make Teams more efficient.
And one of the ways that we do that is through this application called Slack, which is available everywhere that you might use it, on your desktop, on your phone, on your tablet, that just connects Teams both in real time and then asynchronously as well. And in essence, replaces the way your team used to use email to do coordination and collaboration into a more modern messaging-based interface. And so I joined Slack. about 15 months ago as part of an acquisition of a product called Missions, which was a messaging based workflow system.
And so we were building a workflow layer on top of Slack. And so we joined Slack. We helped to build out the Denver office. I'm located in Denver.
And now my team just launched a new product, a new feature as part of Slack that's called Workflow Builder. And so we are continuing to build out the features of Workflow Builder to help people. automate, you know, simple tasks that their teams do on a day-to-day basis. It's very cool.
I've used it. I love it. It's, you know, I want to automate everything so I can go home. That's a goal. We're really trying to get ourselves out of jobs as soon as humanly possible.
Yeah. So we're, you know, big fans of Slack and certainly have been using your tools for a very long time. But we're also very curious about Slack culture because I think a lot of ink has been spilled on the ways in which your organization does work differently. And that as you create this tool that's around working differently, you also have the kind of culture that supports that. So, you know, Aaron and I have been talking about working agreements and what we need to make explicit to make teams function well.
What are some of the working agreements that you all really value at Slack? The one thing I found fascinating about Slack when I joined was it was this tool that came out of a whole other effort to build a game that the team built this tool to be able to communicate more effectively to build the game. And so we as a company, like our core foundation, we use it for everything. Slack is our bloodstream.
It's sort of everything, everything works built on Slack. And so as part of that, the product has evolved and the team has evolved and the sort of habits and the norms of how people use Slack have evolved as well. And so, you know, my favorite part of the ethos at Slack, especially from a work agreements perspective, is this notion of work hard and go home.
And so it's something that I heard in onboarding. It's on the fifth floor in our San Francisco office. It's like painted really big on the wall.
And it's the reason that we don't have things like ping pong tables and foosball tables. But we have really nice offices because we want people to do sort of the best work of their lives while they're at work and go home. and have a life and be an amazing person, both at work and outside of work.
So that's one of the sort of agreements that we ultimately have that I think bleeds into a lot of others. That's super cool. I have heard and read about the work hard, go home ethos. How do you see that showing up in terms of day-to-day behavior? We see it in just expectations of when people are available.
Uh-huh. So at Slack, typically, it is not good form to DM somebody at night or on the weekends. And so you'll see if you've used the product for long enough, you've seen features evolve, things like do not disturb. Or now there's this really nice status that shows up in the DM above the message bar that if someone's in a different time zone, it tells you what time it is in their local time zone.
So that's only if they don't have do not disturb turned on. And so... So that gives you at least an awareness of if I send this message, is that person going to get notified? Yeah.
And if someone has that turned off, it's usually kind of generally bad form to send them a message late at night unless it is really an emergency. And so it's just one of these things where people take their time on the weekends and at night very seriously. And we encourage that.
And we want to encourage good behavior. It's interesting to me that... Because, you know, the counter argument to that is, well, I just wanted to send it and I don't expect someone to respond, which I hear people say all the time. And I always think like, well, you know, that's then that's just releasing yourself of the burden and putting it onto someone else. So it's really cool that it sounds like the implied working agreement you all have is like, no, hold your own burden.
Don't just shove it into someone else's Sunday and then pretend that you, you know, are reasonable and actually want them to enjoy their weekend. Right. And it. It really ties into a few other things too, which is, one, at Slack, everything is public by default.
And to make that possible, it means that we pull a lot of conversations out of DMs. It's one of those metrics that you can look at your own Slack team's usage and see the percentage of messages that happen in DMs or in channels. And so we encourage work to happen inside of channels. We encourage those channels to be public and open to the extent that the information isn't sensitive inside your company. And if you do that, you could send that message at 11 at night and you won't get pinged on it unless someone is explicitly mentioned.
And so we want to encourage that behavior for people to work at the times that are most convenient to them. But if you send a message directly to someone, usually the intent is that you want them to see it and they'll be notified of it. But they have control on their side, too.
So a lot of times you'll send this message at 11 at night if you know someone. does have do not disturb turned on. But this is like the contract between people. If they don't, it means that they want to be notified, but probably of things that are only emergencies.
So it's not so cut and dry, right? No, they seem like really subtle working agreements between groups and individuals, which is, you know, respects the actual complexity of work. Mike, when we were having lunch, you mentioned some things to me that sounded really interesting around how you use the tool, you know, emojis and other things.
to actually communicate as sort of a set of agreements about the way things work within Slack around responding to customer requests, et cetera. Can you explain how some of that works? I thought that was pretty memorable. Yeah, we use emojis for all sorts of things. We use it for formatting of messages, for more rich formatting.
We use reactions, which is a way to apply an emoji to a message as a way to respond or acknowledge without having to send a message. And so this ties right back into... those do not disturb settings or the ways that people would get notified or sort of disrupted in their workday. So if you send me a message and say, hey, Mike, how does to meet for lunch sound. And instead of me typing a message back to you that says sounds good, which might prompt, you know, an under read message, notification that you have to go and read, I'll, I'll apply an emoji to it, which is thumbs up.
And so if it's important to you, you'll check back at it, but you won't get a ping on it. And so that's a little subtlety in terms of how we can you can you replace a message with an emoji reaction? Which a lot of times is more efficient on your end anyway, because if you have to craft those boilerplate, yes, sounds good to me.
It really doesn't add any value to the conversation. It's not something you want to find in search for posterity's sake in the future. So that's one way.
The other way is that there's a lot of conventions depending on the types of channels we have at Slack. For example, there are channels where you'd go and ask a team for help. And some of those start with a prefix that's help dash, or there are other ones where...
you are sort of pleading a team for help. There's not like an existing contract where you say like, there's subtle differences here. There's channels that start with like PLZ, so it's please or help.
And the one to start with help, the sort of the implicit agreement is part of their, what the team does is to service you or other parts of the organization. You go and ask for help, you expect response, right? It's part of that function. There are other channels that it's less.
formal and less agreed upon where it's just a please dash, but they both work the same way where you'll come, you'll post a message. And as part of that, you'll prefix it with a certain circle. So there's red, blue, and white.
So red is urgent, need a response as soon as possible. Blue is, you know, definitely need a response, but not urgent. And white is don't necessarily need a response, low priority. And so you'll see that conventionally in Slack. everywhere in all these styles of channels where I'm posting a message and I'm communicating the intent of that message, both the priority and what my expectation is for a response.
And then there's another set of conventions in terms of how those are acknowledged. So again, this goes back into using emojis as reactions. So if I'm on the team, like help-marketing, so I'm on the marketing team, and I'm the one on my team that's looking after that channel today. and I see one of these messages come in, I'll use the eyes emoji to indicate that I've seen it and that I'm looking at it.
So that you know, and you can come check and be like, oh, great, they've seen it. And if nobody's done that in a couple hours, then you know, you know, maybe to escalate. And then we use the check mark. So like the green check mark to denote if the issue has been resolved, the question has been resolved. And that helps other people on your team know which of these questions are still outstanding, which of them.
you know, might still be in flight. Like what might I do is you kind of scan the channel and use it as a cue. So those are some of the ways.
Yeah, that's really cool. I was, I was with a team recently that was wrestling with a very similar, uh, sort of issue and, and suggested actually something to them very similar to what you, uh, are doing at Slack because they were saying that, uh, when, when people are posting things internally, effectively a thumbs up has become synonymous with an acknowledgement of having read something. But then there's this conflict for people who like actually didn't like the thing and don't want to necessarily endorse it with a thumbs up, but want to indicate that it's seen.
And I was like, yo, there's more than one emoji in Slack. Like just decide what the taxonomy is for what means what and then make that be one of the working agreements. You know, it'll make everybody's life so much easier. And I think the difference is, too, when we talk about working agreements is that these aren't just patterns that people have observed and imitate. they're they're taught so in the first week of onboarding you come and join slack there's a whole session on how slack uses slack and we go over each of these things we go over how to set up your do not disturb settings how to when to use things like you know at channel or at everyone or at here or mention people individually what are the common emojis that are used for reactions and what do they mean at slack and what are the conventions for certain prefixes of channels and so there's a number of these things that have evolved over time but have become more formal working agreements and are taught from the very beginning.
And so Mike, that's really interesting because most of the teams that we study that do this really well, they do make the agreements more explicit. And then the other side of it is teams that do this well also make them living. They do change and grow and adapt.
How does Slack manage that? So if a new emoji convention is emerging or something needs to change about the way the things that go into training need to change, How's that handled? Have you seen that happen yet in the company's history? Yeah, all these conventions.
they're not hard and fast rules. And they've all been emergent in and of themselves and sort of been recognized as like culture and best practice. But it's all evolving. And I really, you know, one of the phrases, the quotes I really like is attributed to St. Augustine, I think incorrectly, is, you know, unity and essentials and liberty and all else.
And I think I've seen that a lot in principle at Slack, where, you know, what are the... what are the sort of the foundational things about, and this goes into more of the macro working agreements, right? Like how do we work together collectively and then sort of unify in the way we do things so that it's clear for people.
And I think where we need to unify is a, it's a moving target and it's evolving. And so we, we totally give teams if you don't want to use that emoji convention that I mentioned, we totally give teams freedom to, to do whatever they like to do. And. There are certain features of Slack that we use. For example, the topic field in a channel that might explain, here's this channel, here's what it's for, and here's how to use it.
But we've seen people do use that for channel onboarding. So when you join a channel, it says, hey, welcome to this channel. Here's what we do here.
Here's what you can expect. Here's a list of frequently asked questions. And here's how to move forward. And I think that is a great way of communicating. Here's how our team has shown to work.
Like you've shown up on our front door. And so... A lot of the practices that you see at Slack is very emergent, and it changes as we change features of the products as well. So some of the older conventions don't necessarily make sense with some of the newer features.
I think it's interesting that you talk about how this is how we do it. If you want to use it this way, if you don't want to use it, that's okay. Because one of the things we really have dug into at the ready is the difference between a default and a standard. And the idea that a standard is like, all right, we all do it this way no matter what. This is kind of a bright line governing constraint, as we say in nerdy parlance.
But I think way more helpful is actually just to have a set of defaults. If you don't know how to communicate with emojis in Slack, here's how we do it. And if you want to iterate on that or invent beyond that within your team, knock yourself out. But to have a default is really helpful. Yeah, those defaults go a long way, I think, in encouraging people, especially in...
By default, this behavior is acceptable. And if you have special needs and circumstances, you could certainly improve on that or evolve on that. But it's up to you to make it clear to other members of the organization what you expect if you expect something different. Right.
Mike, you started to touch on this in your last answer, but I am curious about the working agreements that you hold at Slack that are not necessarily inside of the tool stack. Are there things that you've made explicit or that have emerged over time that don't have as much to do with how you work inside of the tool, but maybe live outside of that or are more non-technical in nature? We do. We use a lot of tools. We use hundreds of tools.
And we certainly do our best to connect those through Slack. But depending on what team you're on, you might use a different tool. Like, for example, the engineering teams tend to use JIRA for...
issue in backlog management. And each product team does a certain flavor of Agile. And we haven't unified on any one hard and fast flavor. We've let the teams define that.
And teams typically do define and write them down in a document around like, our sprints are going to be this long. This is how we're going to manage the categorization in a tool like Jira. This is where we're going to store sort of tech spec or like...
product definition documents and in these folders. And we leave that up to the teams. And typically it's encouraged that those things are explicit. But we use all the same common tools as anyone else around issue management and customer relationship management and all the other tools that you would expect.
So Mike, the question that we ask all of our guests here is related to the topic today, if somebody wants to get started, if they haven't had good explicit working agreements, either in their communication tools like Slack and email or just in their working lives in general, what do you recommend for somebody that wants to get started and dip their toe in this way of thinking and doing? So I think first, what I recommend people do is just talk, have a conversation. And when you talk, talk about what's working and not working.
If you're on an existing team, you need to evaluate. uh, how things are going, like where is there tension between, uh, how work is getting done, expectations people have, where there's, there's a need for clarity. And I think those are the places where have the greatest, uh, sort of.
you know, potential for establishing working agreements and write them down, write them down, treat them as experiments and continue to reevaluate them. And most importantly, don't go too far. Don't try to do too much at once. Don't write the 20 working agreements and try to all hold to them.
Do them one at a time. You know, going back to that quote I mentioned around unity and essentials, you need to figure out where you need to unify and, you know, liberty and all else. It's really important to decide where should there be liberty.
A lot of this goes into the same makeups of a team, a company, a family. You need to identify who are we? What do we believe?
Yeah. What makes us us? Right? Fundamentally, what do we believe? And these working agreements extend.
It's like an extension of your beliefs and culture and the ones that you want to see to manifest to be true. And as you ask, what don't we believe? what are we, what are we flexible on? And I think that your working agreement should represent that as well.
And, you know, you should be careful about how overreaching you are. It's so easy to put a lot of rules in place or these agreements in place that end up doing more harm than good, both procedurally and culturally, like treat these working agreements as an extension of your culture and then figure out how you apply them to the tools. That's another thing I've seen a lot of people do is they start with a tool and they try to map how they work to the tool.
I love Slack. I think it's great. I think it's really flexible.
It's been completely transformative to the way that I've worked both before and after I joined Slack. But it's really irrelevant in the context of who is our team, what do we believe, what are we trying to accomplish, and what does success really look like? And how do we want to get there? How do we want to get there is the working agreement. Right.
Which is how do we know if we're successful, but also, you know, what's this journey look like and how do we want to steer it? Like working agreements really steer the journey in a lot of ways, in my perspective. Absolutely. Mike, we couldn't have said it better ourselves. Seriously.
And that seems like a pretty good place to draw things to a close. So thank you, Mike. Thank you, Rodney.
And thank you to our listeners. If you like what you're hearing on the show so far, leave us a review. And as always, we'll see you next week.