Lean By Design
Lean by Design explores how organizations can fix what’s predictably broken in their operations — starting with the systems, decisions, and behaviors that shape how work gets done. Hosts Oscar Gonzalez and Lawrence Wong speak with leaders from biopharma and beyond, drawing lessons from industries that share the same pursuit of clarity, efficiency, and sustainable execution. Each episode breaks down real challenges into practical insights that help teams align better, think smarter, and move faster. Produced by Sigma Lab Consulting, Lean by Design helps organizations design for what works—and eliminate what doesn’t. Listen on Spotify, Apple Podcasts, or wherever you get your podcasts.
Lean By Design
0302. When Processes Exist but Work Still Doesn't Flow
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
Most organizations have documented processes. SOPs exist, ownership is defined, and work keeps moving. Yet ask different teams how work actually flows — and you’ll hear very different answers.
In this episode of Lean by Design, Oscar Gonzalez and Lawrence Wong explore why operational friction persists even in organizations with mature processes. They examine how workarounds become normalized, why improvements often fail to stick, and how effort can mask deeper workflow misalignment.
The conversation reframes a common misdiagnosis: the issue isn’t that people don’t follow the process — it’s that the process doesn’t reflect how work actually happens. As organizations grow, this gap creates variability, hidden risk, and confusion around ownership, even while productivity appears high.
Rather than offering best practices or quick fixes, the episode focuses on recognizing where workflows lose shared understanding and why diagnosing that gap requires more than documentation. It’s a debrief-style discussion for leaders and operators who sense that work gets done — but doesn’t truly flow.
Order Predictably Broken Now! https://books2read.com/predictablybroken
Learn more about us by visiting: https://sigmalabconsulting.com/
Check out video episodes: https://www.youtube.com/@LeanByDesignPodcast
Want our thoughts on a specific topic? Looking to sponsor this podcast to continue to generate content? Or maybe you have an idea and want to be on our show. Fill out our Interest Form and share your thoughts.
And we're back with another episode of Lean by Design. Lawrence, thanks for joining us today. I am uh excited to have this conversation today with you. I think we are gonna be talking about something that many of us, many of our listeners, have probably dealt with before. Have you have you ever worked or been involved at an organization where um everyone sort of has their own way to do things? Where there may be some SOPs that don't necessarily have follow-through. Maybe they're expired, maybe they've never been introduced to the new people that come into the organization. But what we end up finding ourselves are a number of people that know that work is getting done, but no one actually agrees on how it's supposed to flow, who is supposed to be involved, when things are supposed to be delivered. And that just creates friction upon friction upon friction. It removes the ability to have any level of consistency in those deliverables. And as we know, through you name it, working day-to-day through athletics, consistency is what's gonna drive growth, consistency is what is what's gonna drive improvement in how you operate. So, Lawrence, I mean, this is a topic I think that a lot of us are gonna really connect with, especially when we join a new organization and we find out that there are no type of procedures written out, explained, no procedures in how to perform the duties. Have you been through that before?
SPEAKER_01:I'm pretty sure everybody deals with this. You know, the I I think the other side of it is we we sometimes have procedures that um detail a little too much, and then it becomes something that's so hard to follow that people just create their own way of doing something. You know, just because it's written there doesn't actually reflect the reality of how people work. And and this applies to many different things. Sometimes either the the SOP or whatever work instruction you're following isn't um reflective of how things have been operating to date. Sometimes there's a lag between updates, right? You it's not just I edit a Word document and magically it appears to be this new way of working. And I think and and this is like just a complaint about the how training is is handled in general in our industry, is we have this thing called the read and understand, which is like not really something that makes a whole lot of sense because you're it's I think a lot of people work way better when you actually show them how it works, and these these updates and things that we do to our processes should reflect how the majority of people are navigating that system, right? So, you know, to your point, I think the problem isn't that people don't follow the process, it's just the process doesn't describe how work actually happens.
SPEAKER_00:And sometimes that's a factor of who was actually writing the process or when it was written. You know, version control is important and putting when these things were updated is also critically important. And I I can empathize with the groups that feel that things are moving so fast, things are moving at lightning speed. So what ends up happening is that you end up losing ownership of these processes that, you know, now this person's changing their duties, now they're on another initiative, they're on a project or two, and these things become nice to have. I do want to make one point of clarification because I think this is something that comes a lot when I'm working with my clients, is SOPs versus another type of document. Um, and and what we're explaining here, what we're discussing here is SOPs are those standards. These are standards, operating procedures, standard operating procedures, and how you are performing your work and what is required of it. That is a little bit different from a work instruction that allows a little bit of flexibility. And what I tell people is that if you find yourself having a process that you know is a little bit fluid while you guys are trying to find out what your internal standards need to be, then it's okay to create something and develop a work instruction where there might be some modifications depending on what space your project is in, perhaps an indication, perhaps a phase of development. You're not going to have those more mature documentations or processes early in a project. Those are usually after a couple of years of working as a team. So I just wanted to point out that difference. And this is one of those feelings that um, one of those things that might be hard to see. So let's talk about what's happening. You're at your organization, you're working. People seem busy. Work is happening. You see people going back and forth, going in and out of meetings. You know, there's conversations that are happening. This is our understanding of work. But how we actually get there and how you button up the end of what these workflows are. That's that's the the the question here. You pointed out SOP is not reflecting reality. Sometimes teams describe a process differently. Workarounds start to become normalized. And this is a thing where I found this a lot in the project management space because there's a lot of ownership and accountability when you become a project manager and everything is pointing to you. And when you find that the systems that should be reporting you on the status of your project are broken, you start to create your own workarounds. And as your portfolio begins to grow from three to five to 10 to 15 projects and programs, that flexibility needs to start to have a structure to it so that other projects that come on board now have a level of scaffolding. They have a scaffold that they can actually follow. There might be some nuances, but what we end up seeing is, you know, this project is working better than that project. And it's always pointed to the people. And I have to say that is part of it, you know, the team chemistry, how well, you know, they communicate. But a major part of it is how these teams are creating their internal workflows. And in some cases, they are just being designed by whoever is on that project team, developing these workarounds that are preventing the consistency that is demanded when you're scaling or working in in large operations. And then, you know, these sort of band-aid improvements don't always work out because now we're creating band-aid improvements to a workflow that has workarounds that we've built into it. So patchwork, patchwork, patchwork. So everybody seems busy, we're all working together, but I would say it's probably really not as efficient as we can make it.
SPEAKER_01:Yeah, I mean, do you you think like so this this idea about the you know people developing workarounds? And you know, why do you think people find it easier to build a workaround than to point out that, hey, this doesn't make any sense. Maybe we should update something so that everybody is doing the same thing. I think, you know, to what your your earlier point about process ownership, there's uh it's sometimes when you come into a new company, you're you're not clear who actually owns the specific process. And so you come into these situations, and I'll use an example of like, you know, let's say you do become a uh you're a PM on a project, and you're being asked to develop a timeline for a specific type of change or initiative, right? And so as you're developing a timeline, obviously different types of changes require different timeline structures, right? So there's different things that would have to happen. And so oftentimes, you know, it's it's um maybe not something that's written in like an SOP, but more something like a work instruction that kind of tells you, okay, as you're developing this sort of timeline, these are the constraints that you should think about. These are the people or a guidance of some kind, right? But in probably 80% or even more of a lot of these situations, it's like, all right, just go and draft a timeline and bring it back. And then everybody goes, this looks completely different than the same exact type of project I've worked on before, right? And there's this um difference between, like you said, you when you're trying to manage multiple projects at the same time and then they all timelines look all different. You can't you can't gather data on each thing because they're you're not comparing apples to apples anymore. They're all different shapes and sizes, and it makes resource management incredibly difficult. It makes anybody coming in and out of projects incredibly difficult. It's just uh these these workarounds. I think people are incredibly creative when it comes to these workarounds, but I'm I'm just it's surprising that more people don't um really step back and maybe question the system itself and improve it that way. They just go, you know, this is my lane, and I got this thing to do, and I'm just gonna focus on my own project.
SPEAKER_00:Yeah, that's that's that's there. I mean, I think that there's a couple of pieces that we have to think about too, is that depending on who the person is, they may have some internal cynicism to if I go bring this up to somebody, they're just gonna look at me and say, Yeah, why don't you just focus on executing this? Even if this update in process, this update in, you know, instructions is to benefit the pace or the consistency of doing something right. They're often, you know, people are often met with like a, you know, this is not a priority. Well, the process itself is a priority to accomplish an end goal of some kind. So how do we get past ignoring when the instructions we're giving to people are completely incorrect or outdated? So what happens? No one has the owner. Okay, who's the owner? Well, let me go, let me go reach out to this function, let me go reach out to finance. Well, they're busy, they're not gonna address this. Why? Because this is not their concern right now. This happens to be your concern right now. So this is sort of that cynicism with this, like, I'm gonna have to like go in circles to find somebody to do this, or they're gonna just make me lead the charge. I'm too busy. What's the fastest thing? I'm just gonna make my project work the way I want it to work so that I can work efficiently. I, I, I. This is what ends up happening. This is why, this is one of the reasons why you find such a difference in capabilities in project teams and program teams, where you have sort of these siloed initiatives that are only happening within an internal team. Instead of addressing these types of challenges head on as a group, you're having them challenged like by a project leader that is just trying to, you know, develop the presentation, trying to create context for what the data looks like for the leadership presentation. It doesn't surprise me, but when you think about how often that happens at an organization, you are just compounding these individual heroics, one on top of the other, on top of the other, probably leaning on the same people. And then you find this unequal distribution, unequal success rate. You find a few more, perhaps, project leads that are more successful than others. Oh, well, they have these views. Well, how do you do that view? Well, I open up an Excel spreadsheet, I click this, I go here, I move this into this system, then I process it this way. They start to create these big, arduous workflows that are not really utilizing systems that they have available. It's more of how do I understand what I know, you know, in terms of the systems that I have access to? I'm gonna create a band-aid for this because I don't want to deal with it anymore. And that's what ends up happening. And so when we look at what is the risk here, well, I think pretty directly, you're gonna find a misalignment behind the documented processes and the actual workflows. So, how are you gonna train somebody? How are you gonna train somebody to read these documents and then they go to their team and they say, uh, yeah, I saw this and I read this, and the teammate that's been there for two years will say, Yeah, that's all. We don't really do that. This is what we do. That is now becoming tribal knowledge, something that needs to diminish as organizations grow in complexity, whether it's scale, size, approach, whatever the case is. You want to make sure that the people that you are bringing on board have the same level of role-based training. Otherwise, you're gonna have 10 people in the same role and they're all doing things completely different. And this happens all the time. When you get to leadership, they have all have a presentation, so everything's okay. But to your point, well, this project is looking two quarters in the back, four in the future. This project is looking at six years in the future. This one pulls in three years in the past. And what we have to recognize is that when we are showing people data, charts, elements of our work, and we are changing their resolution from project to project, it makes it incredibly difficult to understand where your risks are. Are we at risk to meet certain things? Well, I looked at one timeline and it was across three years. I looked at the next one, it was eight years. I looked at the one after that and it was five years. So now my brain keeps trying to analyze like, okay, what's the difference here? What's the difference here, as opposed to having similarities, having those standards, so that you can look at the data for the data and not be distracted by appearances by the resolution.
SPEAKER_01:Yeah, I mean that that's that's a good point in having some sort of retro, not even retroactively like looking at the um, you know, how things have progressed over time, but you know, for for somebody that is coming new to a project or an organization to, you know, I think having some mechanism to ask them, like, does this make sense to you? And if it doesn't make sense to a new person walking in, it probably doesn't make sense to some people that are already there at the organization for an extended amount of time, right? And so how do you think about as these teams or or companies go about finding out which workflows are misaligned and to focus on, right? Because it can be, you know, there's there's different levels of workflows having a certain impact to the overall output of groups. And sometimes it's you know, maybe you have a group that's really good at a certain point in the workflow, but then the handoffs are really broken. And so it's not really, it's like the group does an excellent job in delivering the information that's needed, but then then the information just sits there for a decided amount of time because some other team didn't know that it existed, right? And so there's there's like these workflow boundaries that you'd also have to consider. But it it is uh it's not necessarily easy to pinpoint, especially if some of those processes are not or they haven't been formalized, right? It's just oh yeah, so and so gives me this thing and then I give it to this thing. But what is the start and end of that particular process or workflow, right? So you kind of have to like segment these things and then prioritize them. So, you know, from um an operational workflow alignment point of view, what are some of those considerations that you would perhaps look at in evaluating a situation like this?
SPEAKER_00:So usually there's some um there's some warning signals. And a lot of times, believe it or not, leadership will call out a lot of these things when they look at portfolio level views. Hey, why am I noticing this in these projects, but I don't see that over here? Why are these milestones listed like this? But on these projects, the milestones are listed like that. And so these are sort of the things that jump out to us most. Now, in order for you to identify where in the workflows are these particular problems happening, because if you think about any kind of portfolio, you know, it within biopharma, you're gonna have very early stage ones that have, you know, very lofty goals and in their timelines. You're gonna have some more, some that are more mature that say, hey, we have 18 months before we're submitting, you know, uh an IND or an NDA or something like that. And so understanding approximately where in the process, where in that drug development process that these issues are arising is going to be sort of that first look, that first sort of gut instinct of let's go look over here. And then you have to start understanding how are you forming your teams? What kind of transparency do you have in the the shared workflows? Because these are cross-functional teams. None of these teams are working in isolation. They require everybody to be a part of the team for the assets that you're developing, the RD that you're doing to test it, um, you know, any of these safety signals you have to check, you know, even early on, aims testing, and then you're managing that project with a budget with vendors. There's partnerships. These are very complex projects that require a lot of coordination. And it starts internally. If you show this outward facing into partners, they're gonna start to scratch their heads and say, Did we partner with the right people? So we tend to forget that how your operations are internally very much affects how your relationships are with your partners, and vice versa. You know, you want to make sure that you can trust that when we have these things scheduled out that people are gonna actually, you know, take them on and do them. You know, I think that there's process ownership when we have sort of attrition, we have people changing roles, we have people changing internally and new people coming in, really making sure that there is a process owner and there is a solid description that is understood by all of what it means to own a process, of maintaining that process, of being an ambassador to that process. If somebody comes to you and says, hey, I don't know how to do X, it is not your job to sit there and tell them this is how you do it. You can go grab the link, grab the document, and say, This is your document. This will tell you what to do. Come back to me if you have questions. This is something that's really, we don't want to take that extra step to show somebody how to fish. We just tell them really quickly because, oh, it's a quick thing. I don't mind. It's not that you don't mind, it's that you are not doing any favors to that person that's actually trying to find what is the workflow that we're supposed to be doing. I had these challenges even working in the lab. There are so many ways to do basic science and depends if it came from this book or if it came from that book. And there's some subtleties. So I, you know, even doing something as simple as a transfection where you have a small piece of DNA, you're trying to get it into a transfectable cell, like a DT, for example. This is just a cell that is commonly used to sort of create, you know, versions of other disease-state cells. So we're going to use this one, we're going to inject it with this piece of DNA. It's going to spit out this ligand on its membrane, and then we can do some experiments. There's a couple of different ways that you can do that. You can do electroporation, you can use uh some transfection models that is more of like an incubation that over time it uses a viral vector to go in, deposit the DNA, and then come back out. And then now you have your model system. Now you have a model system that you can work with safely. Well, there's multiple ways to do that. And when I came into one organization when uh we were when I was still working in the lab, they said, Yeah, just do a transaction. So, okay, how you guys do it here? Just do one. So that was to me sort of like a okay, well, now I have to decide which way that I'm gonna do this. And my results may confirm or negate whatever they had just because I did something differently than how they did before. And this is what, you know, these are creating structural inefficiencies completely by the effort of the person that's trying to just get work done, right? They're trying to get work to happen. And this is again what we talk about where we're mistaking being busy with being productive. Being productive is not creating 17 workarounds to get your job done every day. Being productive is finding the best optimal route to perform the duties that you need to produce the work that is your role, that your role provides. And I think sometimes we forget about that. And it's super critical. Because we often mistake and and and it's let me ask you this. When was the last time you heard I'm so busy I can't do X? Was that recent? Last time you heard that from somebody? I didn't have a chance to. I wasn't able to. I never had a chance to reflect on this. I did not have a chance to look at the document you sent that was requested. I didn't have a chance to look at the action items. I didn't have a chance to look at the decisions. I didn't even know you did it. I didn't even know you did it. Right. I mean, these are things that we're you're doing a lot of things, but it does not mean that you're aligned to the people in the organization. And to really create an operational workflow is to create a rhythm for your business that is just breathing with a consistent rhythm of activities, recording, reporting, and continuing on in the process. But it's so critical and important to ground all of these things in reality. If you make a change, it's not just making a change and creating an SOP. It's making a change in saying, how, what do we need to hold as standards? For example, something as simple as like your timeline should be three quarters in the back, five quarters going forward. So we know a little bit of the bit of the history. That is a standard. A work instruction is where you're going to say, okay, I want you to go in here, verify the numbers. You're going to export this and drop it into here and update the colors for leadership. You know, because a lot of times we don't recognize how damaging it is when we present things that are not consistent, especially to leaders that unfortunately probably did not do the recommended homework of reviewing the slide deck before the presentation. And the first thing that their eyes are going to force their brain to think about is why does this look so different than the last one? What am I looking at now? They have to reorient themselves. And what you want to be able to do is develop the consistency of what we're looking at, of how you're doing your work, so that you can compare apples to apples. You can identify where the risks are happening. When people want you to identify risks and understand what the major problems are, if you're looking at, you know, elements, like let's just say slides, for example, that are all different, the first risk I would point out is that everything is different. There is no alignment, there is no consistency in how we are representing any of these programs. And that slows down progress time and time again, and is not a sign of alignment by any stretch.
SPEAKER_01:Yeah, and I I was gonna come from the other angle of if, you know, again to your example of the slides, and you know, as as we're we all go to these meetings, and sometimes it's called a steering committee, but other times it's called something else. But essentially there's a bunch of people in leadership, and you have these very condensed slides with very specific metrics. And well, first of all, hopefully everybody agrees that those are the numbers that we actually care about because now it trickles down to like, how do you think about how do we get that number in the first place, right? And then you think about all the effort that goes into people updating things and and moving it all the way up the chain till it gets to that final slide deck. And the the workflow and the process that you talk about, it's it's really the entire thing from the moment that somebody is maybe say performing something out in the field or on the floor in the lab, wherever it is, every you know, activity kind of feeds into something that is being rolled up further and further up to ultimately it is that number that they care about because those numbers help them give context to the decision that they're about to make next that influences everybody underneath, right? And so I I think um, you know, these these these workarounds, the risk in doing that is you don't have consistency in how people are gathering the necessary um information to go back up top. And so different projects report out different things, or maybe certain person does like six of the required activities and another person does two. It's just, you know, there's there's so much inconsistency with how the information is is being collected. And um it's I I think it's very important to yes, question why it is that we're collecting the um particular metric or whatever it is, but it's also to really important to ask the other people like, is it how much of a pain it is for you to get this information in the first place, right? It might be something that you have to log into like 10 different systems and you're updating one thing after the other, and then you go, okay, well, what can we do to make that less painful for you so that you spend less time updating slides and more time doing work? Just those simple things like that that just you know make sure that not only you're aligned with the intent of that particular workflow, because each hopefully these workflows are developed in a way that it's for a specific decision being made, right? It's not just like you're for the sake of I'm gonna pick up this rock and move it over here. There's gotta be some point to that, right?
SPEAKER_00:It's usually non-exploratory, not not in not in the system when you're working in academia, right? There might be like an end goal to understand something, but typically once you're already in an organization that has a couple of assets, you're trying to directly build something, create something that can be licensed, that can be sold, that can be internally developed through the clinic into their first product, which is a very different approach than in academia that you're looking to discover sort of the relationships in these living systems that are not quite elucidated. You know, and I think you're you're you're pointing out things that muddy the perspective of we're in trouble. They don't actually show where the issues are, and so trying to recognize what the signals are so that you can recognize that there's a problem. Well, why is there a problem? We're getting we're getting worked at. But I'm reminded of conversations that I've had where, you know, cynically you say, Oh, so what do you do for work? I get paid a lot of money to do something stupid. I got to pay a lot of money to make slides, I get paid a lot of money to, you know, write reports. Let's think about that for a minute. Actually, the salaries that we have that are a factor of the education, of the technical knowledge, of our skill sets. And yet, when we end up in these organizations, our first target is how much can I do? And not what impact can my work have. So we find ourselves taking on these challenges of workarounds and building workarounds and not communicating them. These are lessons learned, they don't have to come from a project. What's my lesson? The SOP is wrong. What did I learn? Steps five through 10 don't actually exist anymore. So here's what we're doing. Here's how we've mitigated this. And I'm telling you guys now so that you guys have an approach that is structured to what we're trying to deliver as a group to leadership, respective to the project or respective to our research that we're doing. And that's important to pause and take a look at and say, okay, well, why is that happening? Why is it that you're getting paid so much to do slide presentations? It probably has something to do because you're spending so much time on these workarounds. You don't have a consistent structure to follow to deliver that consistency at the end of the day. Operational workflow alignment is as much about creating connections to your neighboring functions and departments as it is how you are delivering your work product. Um and this depends whether you're in manufacturing in the facilities, if you're a scientist, if you're in HR, if you're a project manager, if you're a leader, middle manager, you have some type of work product. The success of some of these projects is probably what everybody is looking at. But you have specific deliverables, whether or not they're explicitly written in order to make those things a reality.
SPEAKER_01:Yeah, as you're saying that it made me think about some, you know, the overlap between your process lifecycle and a product lifecycle, right? So I think everybody knows every now and then you'll get a little thing that pops up in your computer that says, oh, I gotta update this thing and then restart because I have to fix the bugs or right. And so like that same concept of, you know, somebody in the background is maybe collecting information about how the computer is performing or whatever the program is. And then they're recognizing, wow, a lot of people are getting stuck in this one step. And then they're issuing out a patch to fix the issue so that you don't have to go through that again. I think as um these these workflows and processes, we don't, I don't think it comes natural for us to go, yeah, this thing is uh really difficult and cumbersome for me to work through. Let me just put in a ticket so that everybody else knows. The automatic thing is, oh yeah, let me just work around this thing by building something else.
SPEAKER_00:And we should be, we should want to do that. Why, why don't we do that? Why don't we? It's it's the most bizarre thing to me where we look at an issue and instead of saying, how do I create a fix and communicate that, or how do I get the right people on board? You know, we just turn to, well, I gotta get my work done, and so I'm just gonna make this happen. Now, granted, every once in a while you have to create a workflow because there's this new request that came in, our system's not built for that. But I mean, are you working for yourself or do you have other people on your team? If you don't care, you probably shouldn't be a part of that organization or that that team.
SPEAKER_01:Yeah, and and look, I I I get it. You made a point about the like lessons learned. Um, and I think in in working with other companies and projects, the usually the thing with lessons learned is that if I have a formal request to change a certain process and I submit it, who is supposed to do that, right? Where is that? Where does it go? We put in a change a request to change something and then it just piles up into this giant, it's like a little like a like a box that you put like you know, suggestions in. Like a ballot box, yeah. Suggestion box. Well, then the question is, okay, well, who opens that suggestion box? And then how do we prioritize all the things that are suggested here? Yeah, who takes ownership of it? And I think that's where you know we're we're coming back to this whole idea of process ownership, right? Part of your job as a process owner is not just being the steward of the process from start to finish, but it's also to iterate on it and to take in these improvements and actually prioritize what things need to get fixed and um improved. Or maybe there are things that you shouldn't, right? It's not ever I'm not saying everything needs to get fixed because we only have a finite amount of time, money, and resources. So you really have to focus on the things that are giving people the most pain and value, yes, value. Yes. So do it. I mean, that's risky. It's like there's certain things that you would consider criteria.
SPEAKER_00:That's a huge point there where you're going to get a lot of noise out of this. Hey, I don't like that this does this. I don't like when you see something that says, I don't like X, that's a personal preference. When you hear that something is preventing the further part of the workflow, or if we did X, it avoids these last couple of steps. These are suggestions that should definitely be taken into consideration when you're looking at that workflow. And as you said, like as a process owner, no, there's we will take ownership of activities without taking the responsibilities of owning a process. Right? We will take, okay, I want you know, this person to make sure that we have a schedule for when we need to get budgets ready and blah, blah, blah. However, this group is not a finance group, which you would think money goes into finance. So you're gonna just sit there and wait. And you're gonna wait until finance decides to intervene, whatever they, whenever they're doing it. And they're gonna come back and say, okay, you guys have two weeks, you guys have one week to get all of your budgets, et cetera. Like there needs to be some awareness of these other activities that are happening that will directly impact your work and the work that you're doing that impacts others. And if there are processes that are internal to your function, your stability, a factor of that stability is how well you can manage your process, how your people are managing, how they're owning those processes so that they can communicate them the right way. And then to your point, it's important for us to understand when we create a work instruction, a walkthrough, a video, that's version one. That is version one. Because you are more than likely creating a process or updating a process based on some discussions that happened, some pain points that happened that are probably not yours, where leadership is quick to say, we don't like this because of this and that and the other. People that are on the ground level will find that work around so that they can just produce whatever they need to produce. That's a conflict, that's friction. That will continue to disrupt the goal of consistency in your operations, which becomes a risk.
unknown:Yeah.
SPEAKER_01:And in in you're describing again the the flow of information, right? I think a really another kind of very simple example is that I think these process owners imagine they're they're the people that really own the roadways for how these companies like navigate certain things as far as getting stuff done. The people that built the roads um don't drive it every day. And if if there's a couple of potholes and people are just driving around them and nobody finds out about them, they're just gonna get bigger. They don't improve themselves, right? It's like you just have you have to tell somebody that these things are happening, and then the person who you know owns their process, you gotta go about filling those potholes or making it drivable so that people can navigate this thing. You can't just ignore it and go, yeah, I built this thing, and then you take all the credit for this thing, you know, being built, and then you don't take any of the blame for this thing not working, right? It's it's like a weird thing that people will uh stick their heads out for for that, but then when things go wrong, they like, oh yeah, that's not me. That's just so you're just driving incorrectly, and I don't know what you're talking about.
SPEAKER_00:It's like too much effort. I mean, we I lived in Boston. There's rats out there, there's mice out there, they end up in your house sometimes. Imagine living in a rental and you see one of these guys in your kitchen, and you just go, Hey, you decide to move out. You never tell the landlord, you never tell your roommates, you know, like that's what we're doing. We're finding issues, and and and not everything is this monumental issue. I will say that there's a number of things that have come my way of just like, oh my gosh, like this disappeared from whatever space. And all it was was like somebody moved a column header, something like that, which means they were unclear about the guidelines of working in that space. So, what does that mean? That means that person needs a little bit of a refresher. And we've we failed to continue the follow-up, and that's where these things, these sort of issues just continue to be exasperated. So if I'm gonna say anything, it's how do you fix it? Number one, say something to somebody. Don't let these things that are broken in your internal systems just disappear. Say something, bring it into light, and connect the pain that is being caused by this process being broken, by this workflow, this cross-functional workflow not really working out. Address things with the right stakeholders. The five to ten minutes that you spend in doing that, you know, over the course of like, you know, a week or two or something, a quick conversation here, a quick conversation there, you're gonna find people that are gonna want to help support the new fix. And it may not be one that needs, you know, 50, 60 people involved. It might just be one that needs like two or three to say, hey, I noticed this. Is that a problem? Yeah, I noticed that too. How often do you hear that? Yeah, I noticed that too. Why didn't anybody say anything about it? Why? Right, and then we wanna we want to complain about things. You have to speak up, you have to point out things, even internally. Hey, this is broken, guys. What do we got to do to fix that? Don't take it on to yourself. What do we? We are a team. Somebody might have bandwidth. Maybe somebody's new and knows that system and they haven't started a project yet. Hey, this is great. Can you take two weeks to work on this and fix this up before you start your other work? Maybe yeah. You know, we have to provide the opportunity to be successful in things like this. And when we're not, you know, when when we're just walking around and saying that, yeah, we have SOPs, but they're not really updated, and we're just glossing over that. Your onboarding becomes slow. Your ability to uh carry knowledge starts to dissipate because now you're starting to create this tribal knowledge of like who knows what, who knows the real process. Your source of truth is probably riddled with holes that you can't see. You know, it should not be weeks for somebody to say, you know what? I didn't get any kind of notifications like I thought I would. And there's like 35 entries. It should have been like the second day of like, yeah, I looked in there and I saw the workflow worked, but I didn't get notified. Okay, there's a there's a mistake there, let's fix that now. You know, making sure that we really outline what these processes are supposed to do, these workflows are supposed to look like. We need to give that time to let it go into the field, let that workflow happen, and be prepared to take in a number of changes and separate those ones that are personal preference versus potholes in your road to success.
SPEAKER_01:Yeah, I was gonna say the, you know, as you know, but we I I think it's pretty clear that if companies or teams are in a situation that they recognize that there are workflow misalignments within their operations, um, there are a number of things that you can do. And you know, the the even the issues that you have with the workflow misalignment, they can take different shapes and forms depending on how they're connected with you know how many teams does this impact, how frequently are you using this workflow. And so I want to kind of lead this conversation into the assessment that you've developed for operational workflow alignment. So let's kind of talk about what are those risk factors that you would look at in evaluating something along the lines of we've identified the workflow itself, but we're not really sure about how to go about evaluating what we need to focus on within the workflow. Because there's different pieces to the workflow. It might have to do with onboarding, it might have to do with handoffs to another team, it might be people just don't even know that the workflow is visible, right? There's certain metrics that you use to evaluate it. Um and I I think to your earlier point, you can't see some of these workflow problems by just reading a document. You have to see them by observing how people work in them. And so that's really important too. You know, how often are people submitting suggestions on how to improve it? There's all these like nuances to evaluating it. So, how you know what what what would you say is the typical way for companies to go about addressing this? And then let's talk about the assessment that you've developed for that and how it's different.
SPEAKER_00:So, what I wonder what what I my experience in sort of solving these challenges and solving these problems has been usually some level of heroics, and that is shocking, some factor of, you know, I've I've been blessed with working with direct senior executives, but usually there's some frustration that comes out. And in my past, I've had Oscar. This is a disaster. Every time we go to talk about this, you know, bullet point one, two, three, four, five. We try to get one, two, three, and we're unable to because four, five, six. Can you work with that team and figure out how to approach it? So, of course, I go in there and I'm just like, you know, what are we doing? What's the big deal? And usually it goes, well. They want X. One of the things that I try to really empower people with is letting them know that when you become the process owner, you own the process. You are able to say, that is not possible. However, we can do X. I can't give you metrics like this, but I can deliver this because not every system is going to be the same. Not every process is going to give you all the metrics that you desire. So I think what we need to also understand is that leadership likes to point these things out. And it's because they have a certain expectation of my baseline of understanding in order for me to make this next decision. And if we can't provide that to them, they will come back and say, I don't really understand what's happening. That's a failure for us to understand what is really required from leadership. And in the in the way of when those things are, you know, granted to leadership and they change their approach, that might happen, but you also have room to sort of push back and say, these are the things that we aligned on. Are you saying that you want these metrics now instead? We'll have to go back and adjust how we do these things so that we can provide you the right metrics that you're looking for. And that is the kind of conversation, not they changed their mind again. Now we have to redo the whole thing. Have the conversation, you know, first before you start making any kind of changes. So that's usually what ends up happening. It's this one-off, let's create the the uh uh the the fix, let's do the patchwork. Um, and these usually what they're seeing is what they're struggling with is visibility. So one of these risk factors in the operational workflow alignment assessment is this notion of milestone visibility, where really leadership is not able to see real-time views without having a formal meeting. Perhaps your milestones or the things that you're delivering are only identified by you guys. And this was another thing that we talked about, where you're creating creating what you think they want to see, as opposed to going to them and asking. And if they are not able to give you a strong answer, start to ask questions, create the dialogue. So, what I'm hearing is, and this is a great therapy conversation. What I'm hearing is X. So this is what we can do, as opposed to taking word word for word, verbatim, what a leader wants, and then saying, okay, we're gonna just deliver that to them. Because they don't understand your process, they don't understand your workflow. They they are going based off of their recognition of the type of work they're doing, but they don't really have the full transparency of the nitty-gritty details, you know, and then how effective are you at predicting those things? So if you're consistently showing milestones, I had one issue where we were consistently showing milestones where we were hitting like 95% of our enrollment goals. But the problem was you're not adding 95% month over month. It's actually with uh percentages and statistics, you have to multiply them. So after six months, we were not 95% to our goal, we were much less than that. And it was sort of uh oopsie. We were creating this view of how we were doing monthly, but when you compounded month over month, we were getting further and further and further away from our ending point of the clinical trial. And I'm sure as you know, another month on a clinical trial can be hundreds of thousands of dollars. Easy, easy, especially in a global trial. You can probably hit into the millions. So our assessment looks at five major spaces, your workflow handoff, five major friction points that these are these risk factors. The workflow handoffs, is there clear ownership? Do we know at the end of this process, at this part of the process? You said it yourself. Things start in the very beginning and they slowly roll up, right? So as we go from one function to the next, to the next, to the next, is it clear who does what? Is it clear when done is done for this group and it becomes the new start for the next group? Duplication and reworks. Are you having to rework uh any of the data that you're doing or recreating or re-entering deliverables because they were inaccessible or they were in the wrong format, or um, you know, the the the timeline, the resolution is different across your programs. You know, what is are you understanding what those root causes are of those duplication points can be related to the system, can be related to the ownership, to clarity. Um, and you lose time. You lose time just redoing things and just fine-tuning and you find yourself, and this is I think where you get those when you get those scientists and and other folks that are just saying, yeah, I create PowerPoint slides because it's this constant like finessing of a message when the message should be pretty clear if we're developing our workflows to provide responses to these types of questions. And then we talked about it before, clarity, and the one that we didn't really talk about was tool fragmentation. So, you know, are our outputs connected, or even are they able to be connected? Are we, you know, what tools are we using internally that provides the various components to create this full project level view, this full view of our operations here in this section of the facilities or in this part of RD in this research project? Are they providing support together? Are they matching up? If I get data from this system and data from this system, can I put them together on top of the project timeline? If the answer is no, your tools are fragmented, your data is fragmented, and these start to create silos and forces that reconciliation work, forces the rework. Why? Because you can't find anything. You can't find anything. I have no idea how somebody listed a folder. I don't know how they listed a and then what you'll hear. I always sent that to you guys. I'm sorry. I'm sorry, I have to say this. Sending a message on Slack and saying, here it is for something that is critically important to your operations, and then three months later saying, Oh, yeah, I sent it. No one knows where that is. This needs to be curated into a repository of sorts and something again that is the documentation of your system. And as it grows, it demands for you to groom the system, to reconcile, to archive things that are not relevant anymore. Why do I care about the things that happened in Q1 of 2024? I don't even want to see them. Put them into a folder, put them away. If somebody asks for it, we can find it in the archives. But in terms of what is visible, visible to me right now, that is it's 2026. I don't need to see that stuff. Why do I even see it? There's a lot of work there.
SPEAKER_01:I find that, you know, even just looking at the different risk factors, it I think this assessment and even the the one that we talked about last week about 1.1, it's very qualitative focused and not so much quantitative, right? So we're not asking you're not asking for like, what are the numbers behind this or that? It's it's really about how people are experiencing these workflows as they work through them day to day and how they experience these these pain points. And I think that's something that that people should take away is it's um Yeah, just because it says it's green doesn't actually mean that it's green for everybody working in it. Then I think it's it's don't turn it to red.
SPEAKER_00:Don't turn it to red. I've seen discussion after discussion of if you're about to turn it red, you need to have a whole team. Like, holy cow, we agreed on the guidelines of what is green, what is yellow, what is red. It's qualitative. The perception of the color red is like smallpox. I mean, people want to avoid it so much, even if you say the intent for the red is to gain the attention of leadership, that we require support. And that safety also has to be there from leadership. That this is a cry for help, not we're gonna lose everything, we play, oh no, it's the end of the world. That's not what we're doing here. Let's get out of those egos, let's get out of those that fear. Let's create a system that if you actually want to be, as many people say, as many organizations say, the best company of X of this, of this place, you know, in the Greater Boston area, in New England, in California, in the world, in Europe, you have to be able to accept when there are challenges, when there are issues, when there are changes that need to happen and carry those through and carry people with you. In order for those workflows to continue to thrive, it needs to fundamentally become part of the culture to manage those processes, to look at how you're combining your tools, to create the visibility. And then comes the behavior part. And that's that's a challenge where it does need to come a combination from the top down and also throughout the middle layer of making sure to say, hey, we are now being held accountable. If these things are exceeding our capacity, that is what we need to discuss. But it's just so easy for people to, as soon as they get busy, to drop things like this, to drop how you're designing your workflows in your organization. And I think they can be hard to describe, they can be hard to pinpoint and to understand. So our assessment 2.1 does just that. It asks a lot of sort of specific but also uh qualitative. So it's not, you know, I wouldn't call them general questions. They are very specific to how your operations work. The teams we ask about, the teams that you're working with. We ask about your outputs from different systems as it relates to your challenges, to your operations. These are the fundamental pieces that we find to be critical to having solid operations that are resilient to change and allow you to grow and to scale.
SPEAKER_01:Stop those band-aids.
SPEAKER_00:Everywhere, man. Everywhere. So I think that's all we have for today on this topic. I love it, I'm so glad we got to talk about it. I think these are issues that are top of mind, and your priorities are gonna change. Your leadership structure is probably going to change, which means the the way that you do things day to day today is not gonna be the same way that you're doing things in two or three years. Change is inevitable. So part of maintaining this is also maintaining the notion that change is gonna happen. And once these things are developed and created and curated, you still need to have some system to monitor when the changes need to happen in those workflows. 2.1 does that. 2.1 will find where you are hurting the most. And working with us will help you understand what's the path forward to fix it. So if you have any questions, if you want to take a look, we have our assessments online now, sigma labconsulting.com. Take a look for yourself, see the different assessments that we have available, and we'll be happy to work through a lot of the challenges that you're facing today, and maybe some that you see coming down the pipeline and really design solutions so that you can grow and your teams can grow, and you're not just being busy, you're being productive and you're finding efficiency and lowering that operational risk. Lawrence, thanks for your time, buddy.
SPEAKER_01:Yeah, see you on the next one.
