Latest / Integrity at Scale™ / The Owner's Room: When Structure Becomes Control
Transcript
- All right, my friends. Welcome to the Culture Focus Practice podcast. I am your host, Dr. Tara Vossenkemper, and we are talking structure today, and control. The two. The two interwoven. So I'm gonna be real honest. I love structure. I like clear ownership. I like obvious and visible numbers. I like shared expectations. I like clarity of roles and responsibilities. And I've used all of those things, including processes and workflows, to appease my anxiety at times, not every time. I've asked for excessive reporting, or I've created rules after one instance of something rather than, multiple instances And sure, like sometimes that's responsible leadership, but then also sometimes it's me assuaging or appeasing my own discomfort, my own anxiety about, you know, Lord knows what. So this Owner's Room episode is really just about exploring the intersection of structure and control and anxiety and leadership. That's what we're doing here. If you're new to the Owner's Room, we do a series of five or six questions and then one scenario, and basically I just kind of explore as we go, and that's kind of it. So let's move on. Question number one, what do I actually mean when I say structure has become control? Oh, this is good. I like this one. I guess for me, there's like a sense of rigidity and exactness associated with it. I like to think of a structure as, you know, almost like a reed in water or like a cattail in water or a lily pad. You know, something where it's like there's some level of groundedness, but it can't actually be rigid because if it was something straight up and down, at some point the water would just knock it over and pull it out. And so you have to have a, like fluidity that goes along with it. In order to survive in that environment, you have to be able to like move with the flow, literally move with the flow. You know, move with the tide or the the water flow. And so I think of control as, being much more about requiring or wanting, like, very specific things every step of the way that aren't necessarily necessary for the outcome that's desired. So From my perspective, a solid structure might have a variety of different paths to get to the outcome, or it might allow for some nuance when it's being lived out, you know? And that nuance is to account for the variables that we can't control. There's always gonna be things we can't control And so I think there is some level of control within a structure. Like, there are some things that can't move, you know, some, whether they're, like, ethical principles or whether they are legal requirements or whether just the very basic needs of the business Those are the sorts of things, and probably some other things, that are non-negotiable But for example, if I was like taking over client care, our intake coordinator process, or my client care coordinator's role There's very clearly structure in that role. There has to be sequences of events and steps that need to be followed. Structure is capturing what are the things that need to be done in order to successfully turn an inquiry into a client, and then what do you do at that point? You know, how do you pass them over to a clinician or a provider? Control, from my perspective, would be me saying, "You have to do it in this specific order every single time. There are no exceptions." That is the difference. For me, that's the difference. That's what I actually mean when I say structure has become control. Talking about something that has the ability to give a little bit of space to breathe versus something that is rigid and exact and uncompromising. You might define it differently, so you know, tit for tit. That's an Office reference, thank you very much. Okay, question number two. When does greater visibility help me make a decision, and when does it only reassure me that I can see everything? This is a super good question, and I don't actually know if I have a good answer for this. And by good answer, I mean, like, almost any answer I guess I think that the answer is Can you make a decision? Because if you're able to make a decision, like if you have enough information that you are saying, "Okay, I can decisively say this." And that doesn't mean 100% confident, and that doesn't mean you know it's going to work exactly like how you think. To me, that means I'm making a decision because my information gathering in order to make that decision is satiated, so to speak. Like I feel fairly confident that I have enough information to make this decision. I might still feel anxious about the decision, whatever it is, you know? But in terms of like information required, That's different from me feeling anxious about the decision, period That to me is the visibility piece. So when does greater visibility help me make a decision and when does it only reassure me that I can see everything? That's hard because I like to be able to see something clearly any time I go to look at it. Like, if I'm looking at a number or a process or a workflow, I want to understand as much as possible about what I'm seeing But with that said, it's not all the time. Like, I don't really wanna look at all the details all of the time. I just know that if I'm coming up against a problem, and let's say there's a problem on the issues list in our weekly L10 meetings, and it's related to a department that I'm not engaging with consistently, it's not really, like, appropriate for the visionary to be involved in that department If we're having a discussion about something I wanna make sure that there's enough information to be able to make any decision that is required. And so I don't really know if I am somebody who gets reassured by seeing everything, typically what happens Is that when I start to see a bunch of things that aren't really like what I need to be focusing on for my role or in my seat, I get distracted. I end up being like a dog with a bone, where I'm like, "Well, wait, hang on a second," and then I'm like digging into shit that has nothing to fucking do with me, you know? And sometimes that means I end up creating a problem, but more often than not, it means that I question whether there's a problem or a hiccup or something off, and then it turns out there's not, and it's just me not being involved enough to know the nuance within the system. So maybe actually my answer is that I don't get reassurance from seeing everything. That is not reassuring to me. It creates I think a little bit of a frantic energy. I wanna be able to sit and sort of expand out and have as much information as possible, and then shoop, come back in, boop, make a decision, and then leave. Like, disperse, like I'm gone, 'cause if I stay too long, I'm gonna find shit that I wanna pick at, and that's... It's just, it's not reassuring. So I think that's an answer. I feel like it's a little bit of a non-answer, so my bad. What I will say is I do know that some people have trouble letting go of a lot of the details, and maybe I used to be like that. I think to an extent I was more wrapped up in details the further back I go into the practice history. But over time, I don't know, it's just I think getting the right people in the right seats and getting more clear on the seats on the accountability chart and the responsibilities of each and who does what, and then having a lot of lived experiences of people doing what they're supposed to do, you know, a lot of really positive experiences, all of that just created this trust in my people. And then also trust that shit that isn't going well is going to land somewhere on an issues list or it's gonna be caught somehow, and it will be tended to at that point. So I think probably old, old Tara might have said, "I wanna see everything all the time." I do like to see things when I want to look at them, but right now Tara says, "I don't wanna see anything that's not actually relevant for me to see that is not reassuring." All right, let's move on. Question number three When I feel uncertain about what's happening in the business, what kind of structure do I reach for first? That's interesting This is hard. So I have two responses. One is that sometimes when I feel unsure, I'm gonna, quickly like text or call or email my integrator and just do a quick like, "Hey, what about this?" And then, she's gonna answer and it's gonna be gone, or I'll add it to the issues list, and then it's answered and then we move on. That's like one whole half, if not half, you know, a third or something, probably more than a third, of what can happen with regard to feeling uncertain and then the structure. The structure I reach for, so to speak, or lean into is going to be my right-hand person, my integrator, or it's gonna be a standing, stable, very steady and helpful L 10 meeting that we have weekly. So that's one half or a third, like I said, I don't know, something like that. The other half to this is I think a little bit the mark of a visionary And what happens is that I start to get a feeling about something happening in the business, and then I can't language it, and I can't fully articulate what it is that I mean, but I can talk around it. And it's like, I just know there's like some big connections or something big kind of like shifting and Usually what I do is I'll sit with that because I know, like in the background, it's percolating. I can't not feel this thing in the back of my mind. And so what almost always ends up happening is that I'll have little moments. There will be like another example of something and it feels kind of related, and it just kind of gets like filed back. And then an issue pops up and it feels like, you know, it gets filed back. And then something feels off and I'm trying to figure out what it is, and it's, uh, another example, and then it gets filed. And so eventually over time I have more clear examples that I can start to kind of talk about this thing. So at that point, I'll typically bring it to leadership, and I'll take it to L10, and I'll put it on the issues list, and I'll talk around it. And then leadership will ask questions. I might ask specific questions, but a lot of times it's me just talking out loud and, like, getting some feedback from them on how they might be feeling or what they've noticed or if they agree or disagree and to what extent and about what and why, you know? But then from there, I almost always take it, and then I just have to process it. I have to, like, mull it over further, and that might mean I plug it into my Codex, and I'm like, " I need you to hash this out with me. Here's what I'm thinking. Here's what I'm feeling. Here's kind of what it's about. I'm really struggling with articulating the themes of what I mean." And then that back and forth for Codex to be able to ask questions or poke back at something, that's the kind of thing that allows me then to see it clearly. So it's funny because I don't think I would've said I do this, but, like, in talking out loud right now, I realize I kind of do have a process. It percolates. It's too big for me to really articulate, but I bring it to leadership when it's a little more formed. They push back a little in a good way, you know, and it condenses it down, and then I take that further into Codex, and I get more clear on it. And then often there's some clear outcome that comes up for me, and it might mean, like, this is too fucking much to do right now, so it needs to go on the quarterly, or it needs to go, you know, that's a project for next year. Or it can be something that I can start to work on on the side. It is almost always visionary in nature, and then I can bring back something to the leadership team, and now we have an actual, like, project or process or thing to discuss. So Ooh, that was a lot of talking, but that's usually what happens when I feel uncertain. Okay, moving on. Again, question number four. Oh my gosh, when have I scrapped or rebuilt an entire process because one part of it wasn't working? This is kind of like a spoof of a question for me because anytime I build a process, I really... I think I've used this analogy before, where it's like I'm building a sandcastle right next to a shore, you know, and the tide's coming in soon. It's like I walk away from it. I build a process or sandcastle, I turn and walk away. I sit down, maybe I look out at the water, and then I look back and it's gone. It's just like this, pile of sand, and I'm like, "God, fucking hell," like, "I just built that. I know I just built that. What were the details again?" And then I have to basically go and rebuild it again. So by me saying this is kind of a spoof of a question, what I mean to say is It's really effortful for me to Not do that. And I've had to figure out how to maintain almost like an externalized second brain. That's sort of the system that I've set up for myself is how do I ensure that the context and the process and the structure is held outside of me so that I can go to access when I need it, and I don't have to re-remember every fucking thing about the process or the system or the dot, dot, dot, but I'm saying all that to say I don't know if I've ever scrapped an entire process because one part of it wasn't working But I absolutely will dissect it, and I will try to figure out something's wrong in this. What is the thing that's happening? And then that one thing, if I can isolate it down to one probable, like, key variable, I'm gonna fix it. I'm gonna tend to that problem, and I'm gonna fix it. And my goal always... It's sort of like when you start a new habit, you always wanna pair it with something that you already do habitually. So if you're trying to, um, I don't know, take a pill in the morning, you put it right on top of your toothpaste, assuming you brush your teeth every day, you know? My point is I don't ever wanna create a bunch of new shit when something is mostly working, and if I can isolate that key piece, I just want to add in something that's already a part of what's already happening or easy to include in what's already happening. That's better language. So that way it is a relatively simple fix. It's a very small mental ask for the person enacting the process, and it gets us the outcome that we want. So Yeah, I was just thinking this is a spoof because of my fucking sandcastle metaphor. It doesn't matter. I never know. But I, I don't remember a time where I've, like, scrapped or rebuilt an entire process, again, because one part of it wasn't working. It's typically because I forget that the process is there in the first place. All right, question five, and then we move on to the scenario, or scenario if you're fancy. All right, question five: Can I let structure help the organization carry complexity without asking it to eliminate complexity? Yes. Yes. My answer is yes I don't think it's possible to eliminate complexity. I think we should strive consistently for simplicity, as simple as possible, but not so simple that you are losing the essence of the business or the ability to do what needs to be done to have a business, you know? So I think that striving for simplicity, I always think back to, God, like undergrad psych, one of my very first, maybe it was a, might've been a research class, but Dr. Jennifer something, I can't remember her name. She was a sex researcher too. She was so freaking funny She would almost, like, yell at us, like, "Parsimony!" You know? Like, what's the simplest way of saying something that captures the complexity of what it is that you're trying to say? You don't need more words. You need the right words to relay the exact message that you're trying to send. That's what I think about with complexity in a business. You don't need more bells and whistles. You don't need more things. You need the structure that is the simplest version of what's required to achieve and attain the business goals. That's what you need. And I do not think that eliminating complexity is, A, possible, and B, a realistic option for any growing business, for any business that is intending to scale or seeking to scale And then if I take this to the first part of the question, can I let structure help the organization carry complexity? My answer is yes. I don't think that complexity has to be built into structure. I think that structure can be built simply, and it can allow for complexity when required. So, for example, let's take a PTO policy. I'm trying to think of something, like, policy-oriented just to try to capture this. When I first started offering PTO, I... Of course, you know, you have to figure out the calculations for a accrual rate and all that. But I remember thinking, like, "Okay, so then full-time people will accrue this, and part-time this. And then also full-time you can hold this many hours, and part-time you can hold this many hours." And there was, like, all of these variations, and all of this work to figure out, well, what constitutes full-time versus part-time? And then what if people are off track? What if somebody's full-time, and then they drop down to part-time, but they've used all of their PTO? Is that owed back? What if somebody is part-time, and they bump up to full-time, and then they drop back down? There was just so many, like, what if, you know? And I remember trying to create a policy that Like effectively captured all of the what if options and, like, this part-time, full-time transitions and what happens when, and I mean, I feel like I've said more than once on here, I don't like maintaining systems. Like, I fucking suck at it. I don't like it. Very soon after that, I just thought, "This is the worst." Like, this sucks. I don't know what to do when this thing happens. I don't know what to do when this thing happens. And ultimately, the PTO to me was... It was just overly complex. It resets every year. There's... I just, ugh, I just hated it so much. So long story short, let's cut to currently our PTO policy is that you accrue up to a certain number, you use, and then you re-accrue. You use, and then you re-accrue. It's just a constant rolling cycle, and the accrual rate automatically calculates based on hitting full-time or part-time hours. So somebody hitting full-time hours in a year, they're going to accrue much more PTO than somebody hitting part-time hours. So it's almost like, for me anyway, I built the system to solve the problems I was trying to solve manually. I don't have to think about it. The system is set up in such a way that I can let it freaking ride, and I'm not in there thinking about part-time, full-time, start of the year, what rolls over, what doesn't. Annual you know, the someone hits a year, what do I do now? Like, all of that is, nope it's all done. It's all taken care of in a much simpler system. And again, if I haven't made this point, that simpler policy does not make it less complex. The execution of it is clean and simple. It's complex in terms of, like, it absorbs the complexity. It's not complex in terms of all of these micro steps need to happen in order to do it right. So I think I've answered that question. I'm gonna shift now entirely change tracks to the scenario All right, you heard it first, folks. A new clinician begins seeing clients before their enrollment with one of the practice's largest insurance payers is confirmed. Ugh, yikes. The application was submitted, but nobody verified the approval. Now, several weeks of claims are on hold. Operations thought the credentialing vendor was confirming it. The vendor thought billing was tracking it. Billing assumed operations wouldn't approve the start date until everything was complete. That's a fucking mess right there. This is the first credentialing failure, but it's the third onboarding detail missed recently. Your immediate reaction is to require a weekly onboarding report and personally approve every start date. Your operations director says that you will slow everything down, and you also will be put back into work that you deliberately delegated. That person is on point. You do not trust the process right now, but you can't tell whether the problem is global or specific, and ultimately you're wondering, does this need more structure, different accountability, or a direct conversation with the person who owns it? I love this scenario. I like it because there's a lot of handoffs. There's a lot of, like... It's intricate is how it feels. You know, I think onboarding can be kind of intricate. Especially with credentialing and billing and marketing and, you know, there is timing that has to be considered very specific timing. So First of all, global or specific, what does that mean? I mean, I think it's obvious what it means, but why is that here? That is one way that I start to assess whether or not a process or a system needs to be rebuilt, like we actually do need structure, or we have a fluke of a problem. Like, this is a fucking fluke. We're not gonna change anything. The process is good. It's just one specific weird situation. If it's one specific weird situation, again, we typically don't change things. We talk through it. We, you know, we'll, like, turn over all the stones and assess. Is this something that we need to actually address? And if it's, again, a one-time deal, we typically say, "Okay, I think it's just a one-time deal." It's just one of those, again, weird circumstances that we... It's kind of a fluke. If it's global, then we're not looking at a one-off. We're looking at a consistent and potentially patterned experience, which would indicate that we have a problem with the process or the workflow or the system or something In this case, I would absolutely say there's a global problem, and it might not be credentialing in particular, but it sounds like the onboarding process is a global problem. And there might be a few different problems. One is, who owns it? Like, who actually owns the onboarding process? I don't mean who executes it, because execution is different from ownership. I mean, who's the one person that anybody could go to and say, " Is this thing happening On time, what's the status Are there any hiccups or issues? What happens next? Like, one person should own the process, and that person might own, the execution, but probably not. You're gonna usually have, especially with an onboarding process, you're gonna have execution in a few different camps. So That to me, again, is the first issue. Who's the clear owner of the onboarding process? And if that's not clear, then nobody owns it and nobody is accountable for it, and shit is going to consistently fall through the cracks Second thing, hell no, there doesn't need to be a weekly onboarding report that you personally approve every start date. No. Don't do that. That's just putting yourself in the middle of something that is going to bog you down. And also, it's not even fixing the problem. Like, you don't need to be the problem fixer here. You need to assess the process and figure out what the fuck is happening, where are things going wrong, where are things going on that shouldn't be, who owns this, you know, from start to finish? The other piece to me is that this does need more structure. I think that if nobody owns it that's like the core piece, is there has to be one owner. So from that central argument, now we have this dropdown of, okay, that person establishes the timing of everything. That owner of the process says, " if we hire somebody, they don't start for at least four weeks. We need credentialing information by this point. I need a confirmation from this person, and that has to get relayed over here." Like, they would establish the rhythm, the timing of the person onboarding, what needs to be done at what point, but all that comes from having a clear owner. The second piece is the direct conversation. Again, if nobody owns it, if we don't have a clear owner, there's not only not a direct conversation with that person who should own it, there's also no direct conversations the owner can have with people executing the onboarding. So if my integrator, for example, owns the onboarding process, not the execution, but if something's going wrong, she's gonna follow up with my, DFA or my billing manager or my marketing strategist and say, "Why isn't this getting done?" "This needs to get done by this point in time. Why is it not happening?" That's on that person to ensure that things are happening at the right, rhythm, cadence, timing, et cetera. And additionally, in terms of a weekly onboarding report, the accountable party should not, again, should not be providing this. However, if I was enacting something like this after, like, what I have been reading here, as the visionary, as the owner, I would absolutely want status updates from my person owning the onboarding. I would say, "Just give me a rundown. Like, where are we at with things? Is it flowing better? Where are the hang-ups? How's the timing?" You know, I would want to either approve the process, just to have a second set of eyes on the timing before we, like, enacted it fully, or I would want a status update on the next one, two, you know, three onboards that we had just to ensure that it was flowing much smoother. So that's what I would do. I love onboarding. It is so overwhelming, and I just love it so much. I think because it's like a make or break. You know? If you can do it well That's a really beautiful experience for somebody joining your team, and I think that's what I especially love about it. And also, I think there's just something about, like, a well-oiled machine, like a well-run system that, ah, just so satisfying. Like, I just love it. It's so satisfying. Yeah, so that's all I have for you today. I hope that this is, I don't know about helpful, but maybe resonates with you. I'm sure that all of us have been in situations where, you know, we're kind of like bouncing between structure, control, anxiety, leadership, and trying to make sense of where we are in that, um, not trifecta, quadfectra of things. So yeah, hopefully you see yourself a little bit in my answers. All right. So thank you for being with me today and listening to me riff on these questions. If you are thinking of somebody that would benefit from this exploration, then share this episode with them. If you haven't subscribed, please do. There are related episodes linked in the description below, so take a look, have a listen, whatever floats your boat, and I'll see you on the next episode. Thanks. Bye. Thanks for hanging out with me today. If this episode got your wheels turning, I would love for you to stick around. You can, of course, subscribe wherever you're listening. If you are interested in more ramblings about leadership culture, EOS, and all the weird fucking ways humans make organizations harder than they need to be, head over to my website and join the email list. Until next time, make sure you take care of yourself and the people around you. This shit is hard, and we are better together. See ya. Bye