Latest / Integrity at Scale™ / Where Teams Get Stuck with EOS

Transcript

Where Teams Get Stuck with EOS · Integrity at Scale™

• Alrighty, my friend. If you have implemented EOS and you are feeling stuck or annoyed, or like it's not doing what either it promised or you thought it would do, this is an episode for you. EOS doesn't typically fail most groups, in a lot of cases, it's either used incorrectly or people just give up too soon. My name is Dr. Tara Vossenkemper, and you were listening to the Culture Focused Practice Podcast. Today we're going to unpack some common stuck points for groups using EOS and what to do about them. Before we go further, make sure you subscribe to the podcast or share an episode with a friend because my goal is always for this to get into the ears of people who need to hear it. 📍 We have three items on our agenda today. First item, the accountability chart isn't clear enough. Second item, IDS without grappling. Third item L 10 meetings that turn into status updates the bane of my fucking existence. That's all I'm gonna say. So we're gonna get into each item right now. Here we go. Agenda item number one, the accountability chart isn't clear enough. Here's why this is a common issue for people. Actually, there's a few things that can happen. One is that what I found is that people rush the initial design. So if you've ever implemented EOS, you know that building out the accountability chart is one of the very first things that you do. What I think ends up happening is that people do not spend enough time really fleshing out that initial design. They maybe spend, let's just say like a half hour to an hour, maybe two hours. They're sort of, grappling with it a little bit. Maybe they have their leadership team or what they think their leadership team will be. They have those folks involved in the process or potentially, they're doing it all on their own if they're the owner. And then it's just sort of done and that's it. That's the accountability chart that then is used. Here's my hangup. A lot of times people don't make it clear enough, like there's either over overlap with the core responsibilities or functions of a seat. There is a confusion around reporting lines, like it is an accountability chart. So even the language accountability, it implies being accountable, like holding others accountable. So if there's a line from, let's just say a clinical service provider to a clinical director, that implies that the clinical director is responsible for holding the clinical service provider accountable. It's an accountability chart. That's one of the implications. When we don't spend enough time with the initial design, building out the seats and the core responsibilities, and let's not confuse the main responsibilities on an accountability chart with all of the fucking details that live in a position description. These are two very different things, so when we don't spend enough time in the beginning, especially building out again, the core responsibilities, the seats, what we end up with is kind of a lackluster accountability chart, or in a lot of cases, an accountability chart where a role has 15 responsibilities or function that doesn't make any sense, like that's not right, for each seat there should be about five main responsibilities, or we have responsibilities that overlap with another seat, which is also confusing, or we have multiple owners of one seat. That initial design, I cannot emphasize enough the importance of really trying to build it out soundly and solidly. Another thing that happens with the accountability chart not being clear enough, not only is there sort of this rushing of the initial design, but in that build out, what people also tend to do, or they can tend to do, is that they don't separate the person from the seat. So when you're going to build out your initial accountability chart, and actually in the case of any sort of evolution or any amendments or edits or changes that you make as you go, we can't be thinking about the person who is currently in that seat. What EOS calls for is that we try to remove people entirely. Like if you could just have nameless, faceless entities, that would be best honestly, in building out an accountability chart, it's really, really difficult to build and accurate and needed accountability chart when you have people in mind, because what we inevitably start to do is that we start thinking about the person in the seat instead of the structure needed for the practice or for the group or for the business. We're thinking about a person. If we do that, what we're then doing is creating a structure based on a person who's currently in place who may or may not be there in two months or two years, or the next two hours, hell, I mean, maybe they leave in two hours, but we've then created something to support a person in one seat. And if it's a linchpin seat, fuck, you're really just screwing yourself over and screwing the group over, because if that person leaves and you've built the accountability chart, not around them necessarily, but like actively with them in mind for this one seat, guess what happens to all those responsibilities? They still have to go somewhere. Like they still need to be living somewhere. And if we can't build a clean accountability chart right now, if we want to double in size the point at which we get there, or even in the process of getting to that doubling place, we're making it really messy for us along the way. One of the ways I think about it is what's the simplest way to  maintain this structure and allow for the next six to 12 months of growth. I think that's one of the questions they ask in traction is, what can sustain the next six to 12 months of growth? Something along those lines. But the intention here is the structure. What structure is needed? What seats are needed? What are the responsibilities that need to be held by that seat? After that's built, it's almost like a dollhouse at that point, then you take people and you place them in what you think is the right seat for them. Are they the right person for the seat? Clarifying what the seat is though is very, very  different than assessing the person in the seat. So let me just get back to, if we're refusing to separate the person from the seat, we are not doing justice to the accountability part process, and also, quite frankly, not doing justice to our group and all the people who are part of it. One more piece here about the accountability chart not being clear enough and this being a kind of consistent hangup for people or a consistent stuck point. What ends up happening, is that the accountability chart, if it's not built out well in the beginning, and well, doesn't mean a hundred percent accurate for the record. It means as accurate as possible. It means as effective, as seamless, as efficient, as healthy as possible. For the structure of the group, it doesn't mean perfect because it's gonna consistently change. You're gonna always get feedback and it's gonna need to be updated. My point is when it's not built out well in the beginning, what happens is that you cannot use it as a decision making filter as you go. So it is a common, like I'm talking about, probably on a weekly, if not biweekly basis, question that me or my leadership team will ask, and that is, who should own this? It's not though who wants it, it's who should own this based on the responsibilities listed in the accountability chart, in what seat does this fall? Whose responsibility is this? Where does this task lie based on role alignment? Who gets to take it and run with it and do whatever with it? Not that that person necessarily wants to take the task, but that doesn't matter. The question is not, well, who wants it or who doesn't want it. The question is, where does this live based on our accountability chart, it is a decision making filter, and I will say as a visionary in the practice, having the accountability chart be a decision making filter has been one of the most clarifying and helpful aspects to traction and EOS. It's one of the few ways that I've actually been able to distance myself from taking on shit that shouldn't actually belong with me. You are literally externalizing the structure of the business, and then you are also placing yourself in a seat, and then you're looking at the responsibilities on this page in front of you and you're saying, oh, shit, like this to-do list doesn't make any sense. Why am I doing this, this, and this? That task actually lives with this role, that task lives with this role. That one lives over here. Oh, wow. Like you're decreasing the amount of work that you have. I just also use the word role. I use that interchangeably with the word seat for the record. So,  here's one of the questions you can ask yourself if you're thinking about accountability chart and whether yours is good. A, I don't know, 'cause I don't know what your accountability chart looks like, so you know, good luck. You just have to sort of assess it and figure it out. But one question you can ask yourself is, when something is breaking or has broken or is like going a little bit, maybe it's on the fritz, can you immediately identify who owns that thing based on your accountability chart? And then maybe the second question is, are you confident that the person in the seat will handle it? They got it. Those are two questions about not only is the accountability chart structurally sound, but also have you created the chart  based on the structure without the people in mind and then place the people back into the right seat. Is the structure clarified? And also, do you have the right people in the right seats? Boom. That's it. That's agenda item number one. The accountability chart isn't clear enough, a common freaking 📍 issue. Agenda item number two. I'll be honest, this is probably one of my favorite things. I don't know if you know or not.. I like grappling, I like issues. I like actively solving problems and chewing on shit, you know, like gnawing on a bone, like a crazy freaking bulldog. If you're familiar with EOS, then you also are familiar or should be with L 10 meetings, level 10 meetings. These are weekly meetings. They are basically a huge part of the traction component of EOS. They are same time, same day, every single week, with the exception maybe of your quarterly full days, you might not have an L 10 meeting that week with your leadership team at least. So in that L 10 meeting, there is a section that is supposed to be the bulk of the meeting, so an L 10 is 90 minutes in total. The issues list should take up 60 of those 90 minutes. And when you get to the issues list, what you also do is you go through issues using the IDS process, identify, discuss, solve. That's it. Identifying the root problem, discussing it, and then solving it for good. You want it to go away forever. Here's what happens people do IDS without grappling. If I didn't clarify, that's agenda. Item number two is IDS without grappling. Here's what I mean by this. People will get to their issues list and maybe they pick their top three issues, just , 1, 2, 3, here, let's talk about these three, and then what happens is that they start talking about a topic, but they are not really identifying the core issue. So there's actually two pieces that I'm getting at here. One is that people will stay at the surface of the issue. There's not enough stones being turned over. There's not enough questions being asked. There's not enough input from all parties involved. And so we have this what we might call an IDS process, but it's like IDS in a very rigid way, almost like it's the letter of the law, but not the spirit. Like we're missing the essence of this. What also ended up happening is that not only are we staying at the surface of whatever the issue might be, you wanna get to solutions, that's the whole point in all of it, but what I think one of the stuck points is that people think the point of it is the solutions we need to get there as quickly as possible. No, you don't. You need to have a conversation that takes as long as it takes without politicking or getting totally off track with tangents  to get to the fucking problem, that's what you need to do. The point of I and D is to get to the root of the actual issue, and if you don't get to that root, then you are not ever going to get to a solution that will solve the problem for good because you haven't fucking identified the problem. This drives me crazy, because I'm a bulldog sometimes, and I'm a little neurotic, honestly. Like I find myself thinking, hang on, hang on, hang on. What's the problem? Wait, wait, wait, what else is there though? What are we missing? What's the actual problem? Like it's this, okay, but if it's this, what do you think about that? And what's your experience and blah, blah? It's hard for me to stop until I feel like the issue is fully massaged out, so then everybody can see and everybody's on the same page, and everybody kind of understands what it is that we're looking at. Like everybody's seeing the same pieces now we're looking at the same table. All the puzzle pieces are flipped over. All right. What do we see then? What's the theme of this image? It sounds so esoteric to talk about. It's hard to describe, because I think that folks think that they're getting to the problem,  but if I sit in on something, for example, or if I'm doing this live with people or if I'm seeing it unfold, I'm almost always left with more questions. And to me that's a sign like, well, hang on. If there's questions, then we're not at the root issue yet, and not questions about, well, how are we gonna solve it? But questions about what actually is going on. Ooh, this is hard to talk about though, because again, it sounds like esoteric. Maybe you're like a little bit abstract and  possibly it is, I don't know, but it is very much a felt sense of this sponge is not rung all the way out. There's more water here, we need to squeeze it out 'cause  there's stuff in here, you know? Let me just recap quickly. So we're doing IDS without grappling as sort of our agenda item period. And some of the ways this can happen is that we're saying at the surface with the issue, and again, I don't think this is necessarily on purpose, but I think that it happens quite frequently. One of the ways it can happen is that people will list symptoms of something, but not follow that all the way down to, well, what's the root cause of this thing? And so if we are just listing symptoms and then jumping straight to solutions with that symptom. We are basically gonna have the same issue or very similar issues week after week. So if you feel like you keep seeing the same issues pop up, like, gosh, you know, I thought we've dealt with this son of a bitch. This, again, you're not getting to the root cause that's indicative, that's a sign basically. I hate to say you're not doing it wrong 'cause kind of, you're not doing something fully all the way, but what it points to is you're not getting to the root cause. And so you need to dig a little bit deeper, stay there, ask more questions. And the questions at that point might be, what have we done? What didn't work? Why didn't it work? What did we think that the problem was? If it's not this, what else could it be? There's a bunch of different questions you can be asking from that point. And then relatedly, if we are staying at the surface, what people also are doing is. They are prioritizing, jumping to a solution. It's like we're jumping straight to solutions, instead of prioritizing the grappling, prioritize the wrestling with the topic because that is what's gonna get you to the root cause of the issue. From there, the solution and the related to dos, it's like they're presented to you on a silver platter. If we know what the actual problem is, then there's almost always, one solution that is just glaringly obvious for everybody that's right there. Sometimes maybe it's two, but even then you could ab test things out, and that's way more contained than having repeat issues over and over. So another question that you might ask yourself is, are we fixing things before we fully understand them? Again, the point in IDS is grappling, and then from there. Comes solutions. One more thing that can happen in this IDS without grappling is that people will avoid tension. I think it makes me feel a little bit alive, like wrestling with something, not physically wrestling, that's not fun, but like grappling with problems, issues. What's actually going on? It's like you're grappling with a living system. I really fucking love doing that, but what I will say is that grappling can create tension, not only internally, it can create tension, and some people don't like that. If you do, it gives you an edge in this realm. And if you don't, it's a skill. Like you can learn how to do it, even if it  stays uncomfortable, it kind of doesn't matter. You could still do the thing that's necessary. My point though is that if we are avoiding tension during discussion, then we're not actually gonna get to the root cause because sometimes the root cause requires us, like me and my leadership team, we might not always agree. I think something is happening. My integrator might think something else. My DCO might be on the same page as my integrator and not me, or vice versa, you know? That is bound to happen. It should happen. That's what grappling also entails. It entails some disagreement and debate about, okay, what's actually going on? Without that friction, though IDS is performative, you're not always going to be on the same page, and it's okay that you're not always on the same page in a grappling process. The reality is that when it comes to a solution, this like IDS process isn't unanimous. Let's just say I am the one that's facilitating our L 10 meetings and let's say my integrator, I haven't given over full reigns to make decisions about disagreements. Like I still retain that power. I'm not ready to hand that over yet. If we got to a point where me and one other person are in agreement and the other person is not, if there's three of us, which there is, we do not all need to be on the same page before a solution is decided upon. If we have talked through an issue thoroughly. Everything's on the table. Anything we say at this point is kind of a repeat discussion and there's let's say one of two options and we can't AB test. Me and my DCO are in agreement. Then I'm going to decide right then, okay, this is a solution and my integrator might disagree with us, and she might say, I think that's the wrong one. I think we should do this. But a healthy L 10 meeting and a healthy leadership team is going to be her saying, y'all know how I feel, but boom, let's do it. Okay. And then we move on. That's what it should look like. You cannot avoid tension during discussion. Again, if you do, you're basically, leaving stones left unturned. It's performative. It's not actually the grappling process required to get to the root cause and then to solutions that present themselves. So, goodness. I think I'm done with that agenda item. 📍 Let's move on to the third one, the bane of my existence. The third agenda item we're gonna talk about in terms of why EOS is not really functioning for you or what the stuck points are, what hangups we have. L 10 meetings that become status updates. When I tell you I fucking hate status updates, I fucking hate status updates. I hate them so much. Maybe this goes back to the accountability chart too, if the right person is in the right seat. Then I'm gonna trust that shit's gonna get done. Please don't gimme a rundown, like, I'm good. I don't wanna rundown on a weekly basis. I'm gonna trust that you're doing things that you are responsible for doing, that you have ownership of, period. Unless there's a problem or an issue, I'm good. There's enough shit on my brain, like I don't need more. So L 10 meetings have become status updates. There's a few key pieces here. One is that. A lot of folks starting out will confuse reporting with traction. So L 10 are not meant to be 90 minutes of updates. That sounds, ugh, like it makes my body, I'm like having a visceral response right now. That sounds fucking awful. L 10 meetings are intended to surface issues and to drive movement. So if we're spending all of our time doing status updates on what the hell various things, we're not surfacing issues, and we're also not driving movement, we're just reporting on the things that we've been doing or the things that have been happening. If most of your time in L 10 is spent reporting, you are missing the mark, like entirely missing the point. Relatedly, if you're spending a bunch of time talking about each metric as you're going through your scorecard or each to-do item, as you're going through your to-do list, or each rock as you're going through your rock sheet, you're fucking missing it. None of that is the point when you're doing a to-do list, all you're reporting on is whether the item is done or not done. That's it. If you're doing a rock sheet review, all you're reporting on is if the rock is on track or off track. That's it. Literally, like that's it. That's all you need to say on track, off track. Done, and done. That's it. Then we move on. This is where it can get tricky with people.  If you're looking at your scorecard and you notice something's off track, some people in the moment they just wanna talk a little bit, well, I think this a little bit off track because blah, blah, blah. Or This number's down, or this number's up because these reasons. Save it. Fucking save it. That's not the place to be talking about why or why not a number is hitting the mark or isn't. If there is a conversation that needs to be had, that item, whether it's too high or too low, gets dropped to the issues list. That's it. Just treat it as an issues list item. Or if you're like, well, actually it's not an issue at all. I just want people to know what's going on. Then send an email. It's an FYI and FYI doesn't have any place on an L10 meeting agenda, even under client team headlines. You don't really include FYIs about status update type things because that's not what a client team headline is for.  And so the reality is what you're wanting to share is the equivalent of a status update, which again, say it with me, has no place in an L10 meeting, so send it in an email if you need to. Two other things that happen, and this is how L10 meetings can become status updates, rocks aren't really rocks, and so if you cannot look at a rock and tell me with confidence what done looks like then it's not a clear enough rock. Rocks should be written like smart goals, specific, measurable, attainable, realistic, and timely. That's it. They need to be measured. They need to be written in such a way that you can clearly say at the end of the quarter, that's done. We know with certainty a vague rock, something like improve culture or work on marketing, that's fruitless. It's such a waste of time. What does that mean? What does current baseline, what does better mean? What is improving? Improving to what end? Work on marketing. So I could theoretically do a social media calendar, and that would be working on marketing, but is that the rock? You don't want vague language with rocks. You want clarity. What can happen with vague language is that when we get to doing like a rock review in our L10 meeting, for example, this is again how it can become a status update, people start then talking about the rock that they have and what they've done and what they haven't done, and they're not sure if it's on track because they don't really know what done is, or there's no milestone set for the rocks. They haven't set any monthly markers for being on track, so they have nothing to assess it against. It becomes a conversation when it doesn't need to be a conversation. All it needs to be is a smart rock with milestones at the end of the first month and the end of the second month. We haven't really talked about that, but just key markers for at the end of month one, these things will be done for the rock to be done by the end of the quarter, at the end of month two these things will be done for the rock to be done at the end of the quarter. They're just ways for people to stay on track basically. When we don't have milestones, when we don't have clear rocks, what we end up having is, a lot of discussion about something where there should basically be none. Third item related to rocks that aren't rocks, or I should say similar to, is to do items that aren't specific. If your to do items, you're going to review them on a weekly basis and you read it out loud to the group and then you're like, wait what did this mean? Wait, what was this about? And you have to maybe go back to last week's notes or the person is like, yeah, I wasn't really sure. I thought I did. I think I did this, but then I blah, blah, blah, blah, blah, blah, blah. Now we're talking, now we're in the middle of a discussion about a to-do item that had it been written clearly in the first place, we could have just marked as done or not done. But instead of what we're doing is we're talking about the to-do not only what it was, but in what context. So now we're pulling up last week's meeting notes. Nobody's really sure what it meant. We don't even know if it's relevant anymore. All of that is, oh God, it's such a waste of time. It's such a waste of time. Your to-dos also should be written as basically smart items, and also they should be doable within a week. So if you have a to-do where you're like, fuck, this isn't doable in a week, but it also isn't a rock and it needs to be done by the end of the month. Then your to-do could be something like schedule time to blah, blah, blah, blah, blah dot, fill in the blank, whatever that is. And then your to-do is done and the item is accounted for because now you have actively scheduled in time to work on the thing that needs to be done by the end of the month. Boom. Problem solved. Well, one problem. Sure, there are probably multiple, but another thing that can happen is that, when your to-dos aren't clear or measurable, sometimes they linger or maybe they're half done and it's like, well, how do we, is this done? It's kind of half done for the record. If it's half done, that is not done. So it's either done or it's a light switch, it's done or it's not. This is not a dimmer switch. We're talking about on, off, done, not done, or the same item, these unclear, not measurable to-do list items, are reported as done, but then they're actually not done. So then, it pops back up on either the issues list or it's just a lingering thing that takes up brain space for somebody at some point in the future.  And there we have it. 📍 Okay. I think I'm officially, officially, officially wrapped up. Like I said, all of these things are kind of consistent stuck points for people trying to implement EOS. Lemme just recap real quick.  The accountability chart first requires a lot more intention and probably attention and design work than what I think most people assume. So that's one thing IDS is about grappling, not just solving period. Just point blank period. L 10 meetings are for traction, therefore moving the ball forward. They're not just status updates, they're not just for reporting. And if you are stuck, it's not typically a tool issue. It's usually a depth issue. It's usually a, we are implementing this, but we're missing the mark a little bit. Ooh, I hope this didn't hurt your feelings. I don't know. I think sometimes this shit is hard. Oh, I think it's hard for a lot of. Reasons and in a lot of ways, but I do hope that none of this landed harshly. That was not my intention, although I do feel passionately about EOS. So thank you for being here with me. Of course. Thank you for spending some time with me. And if you're looking for something, I do an EOS Mastermind at least once a year. Sometimes it'll launch twice a year. If you want first dibs or first access, when my next mastermind opens up, go to taravossenkemper.com/eos-mastermind and join the first access list. You can do it right on that website page. Alrighty, my friends, that's all. I will see you in the next episode. Thanks. Bye.