Podcast Ep #90: Stop Writing Policies and Start Creating Working Agreements with Tim Lennon

John: You already know that having clear policies in your law practice is important. They help ensure consistency, reduce confusion, and clarify expectations. But that doesn't mean you should rush out and write a big fat policy manual. In today's episode, I'm back with Tim Lennon to talk about why the better approach is a collaborative one. A process of co-creating working agreements with your team and even your clients so that everyone's aligned on what needs to happen and how it's going to get done.

Yes, it takes a little more time up front, but the results are way more sustainable and more useful in practice. You're listening to the Agile Attorney Podcast powered by Agile Attorney Consulting and Greenline Legal. I'm John Grant, and it is my mission to help legal professionals of all kinds build practices that are profitable, sustainable, and scalable for themselves and the communities they serve. Ready to become a more Agile Attorney? Let's go.

All right, welcome back, everybody. I have got the pleasure of bringing Tim Lennon back on the podcast. And you all have heard Tim multiple times if you're a longtime listener, but Tim and I just co-taught sort of this first version of a new take on Agile Kanban that Tim's been thinking about for a while, and he's dragged me into his adaptive way of thinking. And this class is one we called Adaptive Kanban for Lawyers. I think it went really well. We got some good feedback from it. But one of the things that I wanted to bring Tim on is that this adaptive approach that Tim's been developing got some evolutions from some of the core Kanban concepts. And so I wanted to let you all hear from the horse's mouth what he's thinking around these evolutions. So, Tim, welcome back.

Tim: Thank you. Good to be back.

John: Yeah, and let's kind of set the stage, right? So the Kanban method, which, it's funny because I mean, I'm teaching the Kanban method in this podcast, and I use it as sort of my core philosophy. And I refer to it sometimes. I'm not always going through it, you know, the way that you and I learned it in the sort of certification courses that we took back in the day of these sort of six Kanban practices, right? Make the work visible, make policies explicit, limit work in progress, these sort of very directive mandates that come out of the methodology. And maybe let's just start by saying, because you've been coaching this a long time, longer than I have, at least in the tech world.

How have those mandates performed in your experience, right? Make the work visible. Let's just go with those three, because I think they are kind of the initial backbone of a transition into a more Agile systems thinking way of working.

Tim: Yeah. So it's funny these days, most folks that I interact with do a pretty decent job of making the work visible, whether it's on a system or an app or a board or a combination, I feel like, at least based on my experience, that we're doing better at being able to see things and share them and align on them.

John: And not to like over-amp on that, but the reason why is our brain just processes visual information better, right? So whether it's on a Kanban board, whether it's on your calendar, right? I mean, one way of making work visible is just to make an appointment for everything and put it all on there. And part of what it does, and again, not to like over-amp it, but with knowledge work, we don't have a sense of quantity, and we don't have a sense of size. And so by making work visible when we're knowledge workers, it forces our brains to be more intentional about the commitments we make and the work that we take on, right? So that's my quick parenthetical on that.

Tim: No, I love that. Completely agree. And, you know, half of our brain is dedicated to visual information, whether it's accumulating it or processing it. So anytime that we as individuals are able to get together, align to what we see, we've got a tremendous amount of horsepower now engaged around whatever it is we're facing. And as everybody knows, you know, diversity of thought is what gives us the best results. So visualizing that together as a group and making group decisions about it is absolutely key. Much better than it used to be.

John: Yeah, I think that's right. And then the limit work in progress part, I'm giving the answers to the question that I asked you. But the limit work in progress part, that's the thing that becomes obvious once you make the work visible, is you almost always go, oh my God, this is too much, and now I have to put some containers around it, some guard rails on it, whatever. Right?

Tim: Yes. I think actually it was you that said that the first time you put your board up, you get a sense of relief because you're like, oh, look, I can actually see all the work. And then your subsequent emotion is, oh my God, I can see all the work, and there is too much of it. Right?

John: There's too much, yeah.

Tim: So, the next idea is to limit our work in progress. And as you know, we kind of struggle with that because it's not that we don't want to, and sometimes it's not even that we know instinctively that focusing on one thing gets it done faster than trying to focus on three. But when we're confronted with the demands from customers, whether they're internal or external, managers, supervisors, bosses, directors, partners, whatever the case may be, we tend to backslide a little bit because we don't want to tell people not now or no.

John: Yes.

Tim: Right? Everybody's got a sense of urgency, so it's sometimes difficult to figure out that what is.

John: Although I talk about that as urgency signals, right? People have learned how to hijack processes by giving urgency signals, whether or not something is genuinely urgent. And that's a, what you and I would call an anti-pattern, and I've used that word in the podcast before, but it's something everybody does even though it's not a great thing.

Tim: Yeah. Limiting work in progress isn't about escalating it to expedited or emergency work, right? Like, it's just we've got to keep it down so we can focus better. And to get there, we have to agree, right? So the first step is seeing it, so we can see the problem. Now we can have some discussion around what we want to do with it, AKA limiting how many things are in process. And then the next step is getting to that agreement.

And what we do in Kanban, in the Kanban method, we talk about making policies explicit. And, you know, what I've found over the past, jeez, five or six years of literally training this stuff is that, especially with our folks in the United States, make policies explicit tends to hit a little differently in the States than, at least in my experience, than it does with our European counterparts. What we're actually trying to say and make policies explicit is make agreements unambiguous. That is the explicit nature of a system policy. It's the unambiguity, it's the clarity, it is the, the fact that it's simple and easy to apply. Sometimes we get trapped in these if-then kind of trees of decisioning for what something should happen.

When in reality, it's about agreeing to what the problem is, agreeing what our next step is, and not just creating a policy, right? Policies require enforcement, and most of us instinctually feel that. How many times have we heard something's against a policy or that's not our policy, not within policy? And so we tend to make policies kind of an adversary. When in reality, they are the only tool we have to change the way our systems work and function.

John: That's fascinating. So that's unlocking for me because obviously in legal, right? And I've dragged you into working with more and more law firms, but you weren't working with law firms before I showed up in your aura, in your orbit. Obviously, law firms, we love our policies, right? I mean, we like clear, unambiguous statements, but often times the way we get to them is through more and more and more, right?

And it's funny, I've talked about this with other folks this week, but there is a book, and I won't call out the organization behind it, but it's a very common lawyer industry group that is basically a $180, 300-page tome full of example law firm policies and procedures. And when I cracked it open, the first thing that struck me was that it looks just like every other legal resource that I learned how to use in law school or in practice where it's this wall of gray and lots of bulleted and numbered things and maybe indents and subparts and really maybe clear and precise language that as I look at it, has no prayer of actually succeeding in the workplace because it is just a wall of gray. It's far too complicated for anyone to follow.

And so it seems that the purpose, you know, through the lens of this lawyer trade group, right, which is full of eminent lawyers doing their thing, it seems that the purpose of those template policies is to CYA the managing partners or the whatever, the office managers of those law practices that will be implementing them, not to actually accomplish the thing that the policy or the agreement is meant to accomplish.

Tim: And we actually have very similar issues in the information technology space. And one thing that I have seen personally and have friends experience is this tendency to, we see something, well, first of all, let's agree that every process yields the results that it was designed to yield.

John: And we hope it yields the result it was designed to yield. And this is like part of the dialing it in, is… is actually, I can't remember where I first saw it, but it's this notion of well, when you are coming in as a consultant, right?

So you learned this probably same as I did. When you come in as a consultant, we want to start with what you do now. We want to meet people where they are. And one of the ways that I was taught to do that is to figure out what are the policies as they're actually practiced, not as they're written. And the description that was given to me is imagine the college quad that's got all the really nice designed concrete walkways going through it. And then inevitably, there are the dirt paths that the students are taking that actually get them more efficiently from point A to point B. And when we're coming into a new organization, we want to know where the dirt paths are.

Tim: That's right. And, you know, the funny thing I have to add about that, too, and I think it's important to remember, is even as we're thinking about policies, human beings, especially when they are on autopilot, have a natural tendency to follow the path of least resistance. That is why the dirt paths emerge, right? It's because they're just trying to make it a shorter path, even if it really isn't. The perception that it's shorter. The sidewalk only works when everybody agrees to use it.

I like to use speed limits a lot when I talk about policies in class. A speed limit is a policy, right? For a specific section of this road, you must do this speed. Now, here's my question. What makes you do the speed limit, right? If we don't agree that this is the right speed for this place, we're not going to do it, even if it's the law, right? Like we know it's the law. We know it's the ticket, but we still want to do it. So that's the challenge that I've found. First is this, I don't want to badmouth supervisory approaches or managerial approaches, or sometimes we have to give direct supervision, right?

John: Sure.
​​​​​​​
Tim: When we have folks that haven't demonstrated a behavior, we got to show them the behavior.

But frequently, we'll bump into a problem. We'll immediately say, oh, I know what that problem is. Here's a policy. Let's never do that again. And then we bump into another problem, another policy, another problem, another policy, and it starts to spin out of control, where we feel like we're just trying to keep the wheels on. At the same time, we're trying to improve things, at the same time, we're trying to deliver results. And usually it's been because in our haste to come up with a solution or a policy that will solve our problem, we go right through it. We guess and hope it's going to work, we put it in, and then the next thing you know, you're back to bandaging whole breaches, right? Like you're taking on water and you don't know where the actual problem is. So…

John: Yeah.

Tim: …that's the compounding nature of them.

John: Totally. And I've thought about it in a slightly different context, but I've done a lot of work and thinking around the access to justice gap. And one of the points that I constantly make is there is a spectrum, and at one end of the spectrum is public protection or protecting things from going bad, and at the other end of the spectrum is accessibility and usability. And the more you work towards protection, and the thing that can shorten that spectrum is good design, right? And good collaborative, I think, negotiated agreements, right? The thing you talked about, getting the diversity of thought into the room to see things from different approaches, will get you to that place. But if you're not intentional about that, then everything you do in the name of protection, right? Risk reduction, which lawyers love, right? We are built to spot and try to account for risk. But every little layer we add makes it harder and harder to use.

Tim: Mhm. Yes. Yeah, because we're adding complexity. And here's kind of what I feel like a lot of people take away from the Kanban method proper. When I approach the Kanban method, I don't see it as six individual practices. I see it as a sequence. So first, we see the problems by visualizing the work. Now we know we need to limit the work in progress, but to do that, we have to create a policy. When we just create a policy, it's not live yet, right? So what's our next step? After we create a policy, we want to have a feedback loop about it. Let's talk about it. Will this work? Let's have an experiment, still not live yet. That's what I'm trying to get to. It's not until we agree to improve collaboratively and evolve experimentally where we are supposed to pull up this proposed policy.

Maybe it's a try-before-you-buy, maybe it's some kind of math simulation, but whatever we can do to make sure that it's not going to be harmful from an improvement standpoint, then we agree, and then we improve it. But the path to get us here has required that we have a feedback loop, AKA a meeting to discuss, align, and agree, and then we've created an experiment to make sure that it's not harmful. And that's where I feel like we get stuck a lot. We can make the policy, but getting it through the agreement process, the alignment process, is where it gets hard, and then we're not as diligent sometimes.

John: Yeah. Well, and I think in a world where people are already overburdened with work, overwhelmed by the volume, the quantity, and the type of work that they've taken on or has been pushed on them, right? I have a slide in one of my, you know, long-time training decks that I talk about the Deming Cycle, right, which is plan-do-check-act, plan-do-study-adjust, build-measure-learn, there's different ways of articulating it. But it's a cycle, so it goes around and around, right? You plan a thing, you try a little way of implementing it, right? Hopefully, this safe-to-fail experiment that we talk about in the Agile world sometimes. But then you have to do the study and adjust part or the check act part.

And that's the completion of the feedback loop, but that's what nobody ever gets to, right? People do the plan and the do, and then the do feels like way back in my corporate life, or even in my, when I was working for a bigger consulting firm, the thing that comes up a lot is this notion of a bias towards action, right? We want to have a bias towards action. And I don't love that framing. I understand where it comes from, but that bias towards action gets you a lot of the do. But we somehow don't consider the study adjust part or the closing of the feedback loop as part of the action, right? We think of that as something else, maybe.

Tim: We need a bias towards curiosity, right?

John: Yeah.

Tim: We got to bias towards action.

John: Right. Exactly.

Tim: Let's have some curiosity about the impact or the effects.

John: Yes, Ted Lasso, right?

Tim: 100%.

John: Be curious.

Tim: But it's like doing half of the scientific method, right? You gather some data, you have some ideas, you create a hypothesis, you design and execute an experiment, and then we keep on going.

John: Well, half of the scientific method might be the new scientific method in the United States, but that's a whole different conversation. This is not a political podcast, so I won't go there.

Tim: Good call. Good call. Well, basically, we're asking questions and we're not waiting around to get the answers, right? So we make the policy. Is this going to work? Yeah, I think so. And then let's do it.

John: Yeah, okay. Let me pull you back for a minute because the make policy explicit thing, I think one of the things that you and I have both sort of bristled at is that it's a very command and control approach, which, you know, in a lot of law practices and a lot of businesses, that command and control approach is actually comfortable, right? It feels like it's that bias towards action. It feels efficient, right? It's like, okay, we're getting things done. We're solving this problem. We're going to do this and move on. And I will also say that even if you're taking this command and control approach, make policies explicit is better than the alternative, which is try to read each other's minds, right?

I mean, and that's the actual status quo in many, many law practices, right? I sometimes joke that if lawyers are having trouble with their staff, I will say, oh, well, clearly in your job description, you must have had a line that says must have ESP, right? And of course they say no, right? They get the joke. But it's natural, right? The things that seem obvious to us and especially experts of any kind, but lawyers who have lots of training and knowledge and experience, and so we just kind of know things in our bones at some point, right? Because of where we are on the expertise cycle that our team members, our staff members, maybe our more junior attorneys, whatever, they're just not there yet. And we get, lawyers can get frustrated. We can, I will use the we, it happens to me sometimes, too. It's like, oh, how can you not see that? Let me put it that way, right? How is this not obvious to you?

And the answer is, it's just not, right? You don't have to know how it's not. You have to just accept that it's not obvious. And so when I do this work with my law firm clients, I will sometimes say it's like I'm trying to cast the Harry Potter spell that pulls what the lawyer knows out of their heads and puts it in the bowl, the pensive, so that other people can whatever, put their face in there and actually see what's going on.

You've evolved it. So we've gone from make policies explicit to the terminology you're using now, and that we used in this adaptive for lawyers class is negotiate working agreements. So tell me about that evolution.

Tim: So it actually starts way back when, I'm going to say, without dating myself, Agile and Scrum were still relatively new. Everybody was still kind of figuring it out. And I have had the good fortune and pleasure of being able to help stand up dozens of Agile teams without being exaggerating at all. And one of the things that I started early on was this idea of creating working agreements. Now, in those days, we weren't talking about systems really. We had a process, but we weren't talking about systems, and we weren't talking about policies. In those days, policies were things that the company created. We didn't think of what we did as a policy.
So when we would have a team kickoff meeting, we would create working agreements. And in those days, they were designed to help create a structure around which all the team members could align on the work and to one another, and to also set up some guardrails for people. So one of the things very common is we want to have a daily stand-up meeting for 15 to 20 minutes every business day, right?

We create a working agreement, and we vote. We do Roman voting, right? And so that means if people are in a thumbs-down mode, that forces us to negotiate to either halfway or to a thumbs-up. And if it doesn't get negotiated and we don't get all thumbs-up, guess what happens? We don't do it. We're not ready yet. We're not ready yet. And so it's not even a we're not gonna. We're just not ready.

John: Yeah, it's because we don't have that shared understanding yet.

Tim: That's right. So what we would do is as the team evolved, as we grow, learn more about the work, learn more about each other, learn about our process and our partners' processes, right? Because we depend on external experts very often to do things for us. We would continue building them into working agreements at every retrospective. Is this something that we should keep doing? Feels like it, yes. How do we know it's going to continue working? I will go do some math or whatever the thing was. We would go spitball it, make sure it was going to be okay. And then based on those results, welcome back to consensus-based voting again. We're going to do another Roman vote to make sure we're in alignment, and it's good to go.

John: Yeah, so it's that getting back to feedback loops, it actually begins with the subjective feedback loops. So I think that's one of the things that maybe people miss is that when we talk about feedback loops and scientific style experimentation, people's brains immediately go to, okay, there's going to be numbers and I'm going to have to do math, right?

Tim: Mhm.

John: And, you know, that's true in a lot of places that we don't like that, but in legal in particular, there's a cultural bias against some of it, or at least a stereotype against it. But starting with the subjective is totally valid. In fact, it's probably correct.

And I will say that I still think there's a role for the numbers, the data, because I think that will tend to validate or invalidate our subjective feelings. I've run into both things where it's like, okay, I'm feeling this thing, I don't know why, and I can bring some numbers in or some graphs in that says, yeah, this explains what's going on. And then people feel totally validated. It's like, oh, or there's other things where people are like, oh, I feel like we need to do this, right? And maybe I need to add this layer of protection in order to solve for some risk.

But I could maybe bring in numbers, or we could find some information that says, okay, like, yes, you have spotted a potential risk, but we've looked back X number of months or X number of years, and the likelihood of that risk is extremely small. And so we don't necessarily need to build robust structure to solve for it. We can just kind of acknowledge that it's there without putting heavy layers of policy on it. So anyway, that's feedback loops. So you're getting to, well, this notion of a working agreement. And part of why I like the term working agreements is that there's two interpretations of that word, right? It's the agreement about how we work, but the agreements themselves have to work.

Tim: Yeah. And you mentioned feedback loops. And a lot of people, I agree, they hear that phrase and they're kind of like, eh. But I just like to think of it as a decision-making meeting. It is a meeting designed to make a decision based on some information. So it doesn't have to be super fancy. It could be you and me on this Zoom right now. We are having a series of feedback loops reacting to what each other is saying. It's not nuts, right? So really, when we say we should have a feedback loop, number one, to identify the issue that needs to be addressed. And then number two, to talk about what we're going to do it, those are really natural for us, so we don't have to think about it in terms of some feedback loop nomenclature, which creates sometimes language boundaries we don't want. It's just a meeting to make a decision.

John: Well, and the other thing that I've observed, and I know that you've observed, is the feedback loop is going to come whether you plan it or not. And so, like when we talk about negotiating working agreements, and I think one of the objections to this idea of having the meeting and doing the discussion and having the Roman voting is, where am I going to find the time to do all that, right? That seems like a lot of time and effort, and coordination in order to get there. But if you don't do that, that work up front is the ounce of prevention that will save you the pound of cure when that feedback loop comes out of nowhere like a comet and smacks you all upside the head.

Tim: You know, I used to have, I won't call it a joke really, but I would kid around with folks because I would work with Scrum teams, you're familiar with Scrum, who were too busy to do retrospectives.

John: You're describing most of my clients, but yes.

Tim: I know. And, you know, I'm not going to judge, right? Like, if you're getting results, you're getting results, and maybe that's the best you can do right now, and awesome. And when you’re a little more mature, you might have to. But one of the things I say is, okay, so you don't have retros, so nobody talks about anything that needs to be changed or improved. Well, no, I mean, everybody knows there's tons of things. Okay. Well, that means you're still having a retro, but you're having a decoupled and asynchronous retrospective, right? It's lots of people talking about it, but we're not aligning. And that again is where the power comes in this working agreement space. We have to align with each other and with the problem, and then with the solution.

John: Right. That's funny. So I'll give you an example. I recently did an on-site meeting with one of my clients, one of my few clients here in the Portland area. So it's nice because I can go visit them and go on-site. And the stated purpose of my three-hour presence in this law firm was going to be to roll out a thing that I'd been talking about with firm leadership. But when I got there, I just instinctively start all of my group discussions with a little mini retrospective, right? Hey, good to see you all again. Before we get started, let's just do a pulse check, right? What are the things that are going well for you all? How do you feel since we last all spoke? And, right, this is again, it's not on a cadence per se, but then what are the things that aren't working?

And something came up in that meeting that I immediately identified as a much bigger issue than the thing I was there to roll out. And I pivoted. And it's funny because there's two partners in this firm, and one of them was like looking at me side-eyed like, What are you doing? Like, this is not what we're here for. You're going off script. You're not following the plan. And fortunately, I've built some trust with this organization, and they went with it.

And we identified this gap, basically in the initial setup process, right? Sort of from first client contact to the time where they're assigned a legal team to actually work on their litigation. It's a litigation firm. And there just were tons of assumptions, right? The intake person thought things were happening this way. The sort of the rainmaker attorney, the guy that's bringing in the work, thought things were working this way and that it should be obvious to everybody else.

But then the attorney team that was actually taking over and responsible for delivering the result was missing tons of information that would help them in the strategy and planning, and everything of the work. And then in the whole thing, the client was just sort of spinning, right? Because they were getting handed off and this thing and whatever. And so we've now spent the better part, well, maybe not the better part, but a good chunk of the last three weeks, like teasing that out and trying to just better understand what's going on. And in the most recent meeting I had with them was a Zoom call.

Even though they haven't rolled right, we've been planning this sort of new workflow, some policies to go with it. They have not rolled out yet, right? To the point you made earlier. However, the first thing that the rainmaking partner said is, this is going so much better, even though we don't have the policy in place yet. And the reason why is that the policy itself isn't the magic, right? It's the discussion and the shared understanding that's the magic. And the policy is just our best attempt at documenting what our shared understanding is. And I think that's fascinating to me.

Tim: Yeah, it is. The policy can be a fantastic teaching device because in the early days, I'm going to say mid-2000s, we didn't have a lot of the word daily standup in our lexicon yet. That's everywhere now, right? Everybody does it, even if they're not doing Agile.

John: Yeah, or a Huddle, or a Scrum, or whatever we call it. Yeah.

Tim: Or a Huddle, right? But in those days, it wasn't common. And it certainly wasn't common that the guidance was going to be 15 to 20 minutes for everybody to talk, right?

So we would though, through the course of a team kickoff, I could usually sell folks on it. And so we would at least start with every other day if not daily, just to get some muscle memory. See where I'm going? So we've created a working agreement that says we're going to have our daily stand-up. It's going to be 100% team participation every morning at 9:30. And if you can't make the stand-up, this is important. This was the team. If you can't make the stand-up, email the rest of the team and let us know. I did not make that up. They created that. They agreed to it.
Now, over the next couple of months, it's kind of hit or miss. Sometime everybody shows up, sometimes they don't. Sometimes it runs short, sometimes it runs long. But after, guess how long, 30 to 60 days, I don't even have to show up anymore. And I know the meeting will happen. And it's because they've gotten the practice and the policy, AKA the working agreement, has allowed them to build some muscle memory. And in the course of doing that, now they hold each other accountable.

Hey, where were you at the 9:30? oh, this, that, and the other. You didn't send an email, man. We were… That starts to happen. So we don't even have to be the boss anymore. If we create the poli-well, the better yet, if we propose the policies that our associates and team members and employees agree to and align to, we don't even have to write it up most of the time, to your point. People agree to it, and they're like, oh yeah, we should be doing this. Mhm, and they just build that practice themselves.

John: Well, and it's coming back to your traffic analogy, it's interesting, right? Because there are multiple approaches. And I can give you an example, right? I live near a city street, Hawthorne Ave, Southeast Hawthorne, here in Portland, that has a long stretch where it is a four-lane street in a mixed commercial residential neighborhood. And they recently put signs on it that have reduced the speed limit to 20 miles an hour. But there is nothing about the visual signals happening on Southeast Hawthorne that tell people that this is a 20-mile-an-hour street. It's a four-lane road. And so people are regularly going 30, 35 up and down this thing. And the proposal, or one of the proposals, is, well, we should put speed cameras on it, and that'll teach people.

And all that's going to wind up doing is catching lots of people who are going 30 and 35, right? And it may cause some people to slow down, and the neighbors who drive it frequently will learn, but the poor out-of-neighborhood folks that don't know are going to keep getting stuck, and it becomes this gotcha. Whereas just one major block over, right? Not neighborhood blocks, but kind of big city blocks over is Southeast Division Street, where also has a 20-mile-per-hour speed limit, but the city has put in sidewalk trees, and they've put in curb bulbs, and they've tried to turn it into this sort of very pedestrian-friendly zone. And people generally go 20 to 25 miles an hour because all of the visual cues and all of the sort of situational information that you get tells you that's what should be going, right? So, to your point, the speed limit sign on the road is irrelevant to the behavior of the team, right? It's how you set the culture, it's how you set the context.

Tim: You also raise another interesting point, I think, and that for the people that have been using that route for any extended period of time, when it was 35 miles an hour, they are more than likely the going to be the people that struggle the most to accommodate the new speed limit because they not only have muscle memory for the speed they're going, they're accustomed to seeing that speed limit sign come by and ignoring it. Because they know that the speed limit is 35, right?

No flashing lights, no speed bumps, none of that, then yeah, I'm going to do what I've always done. And that's why when we create working agreements to change behavior, that's why it's critical that everybody aligns, everybody understands, and everybody agrees so that we can get some help from each other trying to adhere or execute the vision of the policy or the guideline we've created.

John: Well, and it's interesting because I think what you're getting at is that the behavior change stems from a new perspective.

It stems from a mindset shift. Like, oh, I'm now, right? And again, the difference between the two streets, because Southeast Division used to look just like Southeast Hawthorne, right? When I first moved to Portland, it would… They were the same type of road. One of them has been significantly re-engineered, and tons of grumbling along the way.

Don't get me wrong, right? A lot of people that really liked using it as a quasi highway to get to the eastern parts of the city. But it is also now, you know, whatever, food and wine calls it one of the best restaurant streets in America, which I appreciate because I… I live here, right? So things have changed, and it's not how it always was, but I think most people would agree it's changed for the better.

Tim: There was a, and I can't remember if this was in Ohio or Illinois, but I feel pretty confident it was in… in the Midwest. And there was a similar street, wasn't four lanes, but there was a similar street that went through a neighborhood that was heavily used as a… a traffic artery during commute times, very residential, lots of people. So what the city decided to do was instead of putting up speed limit signs or speed bumps or speed cameras, they repainted the lines to make them serpentine so that if you're going to stay in the lines, you have to slow down to make every little curve turn.

And two interesting things I want to point out. Number one, it had the intended effect. People absolutely slow down and follow in between the lines to get to where they're going. However, the side effect was that people found another way to exploit the traffic system, stopped using that street, and started using one a street over to save time.

John: That didn't have the squiggly lines.

Tim: Correct, right. So that's another thing we have to be thoughtful about.

John: It’s another dirt path.

Tim: Yeah, it's back to the path of least resistance, right? If we see it and we feel like it's going to cause us a slowdown or friction, if we're just working off our gut, we're going to go around it and find a different way.

John: Well, it's funny. So that strikes me as an example of adding complexity without actually creating the mindset shift. It's like, oh yeah, we're going to try this hack or this trick, and like, sure, okay, yeah, you have to turn on your brain and think a little differently when you see squiggly lines. Of course, but it's still not the shortest way from point A to point B, and so I'm going to go find it.

Tim: That's right. That's right. And, you know, they had a great alignment from the neighborhood, but not the participants.

John: The external parts. Yes. So the negotiation wasn't… ultimately, wasn't broad enough.
Tim: Correct.

John: Right? It wasn't inclusive enough. Well, Tim, I think we should leave it at that. I mean, I'd love to get a final thought on how you would approach this negotiate working agreements, different from having no agreements, right? And just assuming things, but as an evolution from sort of the top-down push a policy into your system as opposed to develop a policy with the people who best understand the system and use the system.

Tim: I think that we give ourselves too hard of a time with our expectations on the way things are going to work. And I say that for this reason, in a startup, and I'm speaking technology startup, things are crazy. They're crazy; they are all over the place. We're just trying to swim and make a little bit of profit. We don't have time to talk about policies. We don't have time to talk about Kanban boards or anything else. However, when we reach some level of competitive advantage, right? Things start to level out, and we're less erratic. We tend to start forming teams because that's what humans do. We form little small social groups focused on doing the work.

John: Yes. And they may not be official teams, but they're going to form one way or another.

Tim: Right. There might be clicks. Even at that level, the organization probably still heavily depends on supervision. It's still just made that transition from a little while ago, where everything was the wild west, and now we've got a little bit of order and a little bit of somebody trying to keep things, you know, keep the temperature down. And that's okay, because that's what that organization needs in that moment. But it's when we do start creating teams with an identity, when we identify ourselves as a team member and the team's name is XYZ, that is part of our image. And then as part of that, we have a stake in improving our space. And as such, that's when the supervision and the direction, in my opinion at least, has to start dialing it back. Because as the teams become more mature, they require less supervision from higher up.

John: And it needs to be more about vision and goals…

Tim: Yes.

John: …than it does about individual tactics and activities.

Tim: Mhm. Ideally, leadership would set the division, and a mature team creates the working agreements on how to accomplish and reach that goal.

John: And that gets all the way back, and I'll give a quick plug, and I'll have to put the episode number in the credits or in… In the show notes, but I have done an episode around effective law firm policies, and the number one takeaway I hope people get from it is that your policy should have a why statement, should begin with why we do it this way, or what we're trying to accomplish, right? What's the goal here? And then the recipe is secondary. With all these things, working agreements and policies, you want a situation where even if someone doesn't follow it to the letter, they still are doing it wrong in the right direction as opposed to missing the mark entirely.

Tim: Completely agree.

John: Great. Well, Tim, thank you so much for coming back.

Tim: Oh, thank you.

John: We should do this more often. I mean, you and I chat all the time. We should record more of them because I think they are, uh…

Tim: I don't know, I think I might like your fans too much. I feel too bad for…

John: Well, all right, talk soon.

All right. As always, when Tim comes on the show, there is a lot to unpack from that conversation. But here's the main thing I hope you'll take away.

When you co-create working agreements with your team, and again, even with your clients, the document itself becomes secondary. And yes, of course, you should write it down. You're lawyers, after all. And having something in writing helps ensure shared understanding, and it gives you something to refer back to later. But the real magic happens in the conversation, in the alignment, in the shared clarity that emerges when a group of people gets engaged around solving a problem instead of hanging out in silos. When you've had that conversation together, you'll start to see the benefits of the agreement show up in the behavior of your team, whether or not it ever gets printed out and stuffed into a policy binder.

I'm also going to put in a quick plug for Greenline here. One of the things we've done is make it easy to embed your working agreements right into your Kanban card templates, so they're at your team's fingertips every time someone needs to work on the task represented by that card. These aren't just generic task titles or to-do lists. They're useful tools just in time that help ensure the quality and consistency of your firm's work product, regardless of who's doing the work.

If you'd like to see what I'm talking about and why this can be such a more effective way of working together, head over to greenline.legal and click the Request a Demo button. Or if you just want to chat directly with me about how to engage your team around this more collaborative approach, shoot me an email at john.grant@agileattorney.com and we'll set up a call.

As always, this podcast gets production support from the wonderful team at Digital Freedom Productions, and our theme music is Hello by Lunara. Thanks for listening, and I'll catch you again next week.