0306. When Your Systems Don't Match How Work Happens

Most teams believe their tools are the problem. The system is clunky, the interface is confusing, and nobody can find anything. So they work around it, spreadsheets on the side, manual reports, tribal knowledge passed between people who've been there long enough to know the workarounds.

In this episode of Lean by Design, Oscar Gonzalez and Lawrence Wong explore why the real cost of broken workflows isn't frustration, it's the data inconsistency, hidden rework, and eroding trust that builds up quietly when systems are implemented without designing how work actually flows through them.

The conversation reframes a common assumption: when people bypass your systems to get work done, that's not a behavior problem. It's a design problem, one that usually starts the moment a tool is selected for reporting or compliance without asking how the day-to-day work will connect to it.

Oscar and Lawrence unpack the patterns that drive system misalignment: tools implemented without workflow design, ownership gaps that leave no one accountable for how the system is configured, inconsistent data entry across teams, and the slow erosion of trust in technology that was supposed to create clarity.

This episode is not about which project management tool is best or why some people love Smartsheet and others don't. It's about recognizing that technology only becomes leverage when the workflow design comes first and why getting that sequence right is far less costly than inheriting a system nobody trusts.

Episode sound familiar? Reach out for a 30 min situation read so that we can look at your situation together. https://calendly.com/ogonzalezslc/read

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.

Transcript

Welcome And The Real Problem

SPEAKER_00 0:02

Welcome back to another episode of Lean by Design Podcast. I'm your host, Oscar, alongside my co-host Lawrence. And uh today I think we're going to be talking about something that is very familiar to a lot of people that are listening to this podcast. You know, you find yourselves in a new organization, there's new process, there's new people, the space that you're working in is different. You might be completely virtual, you might be hybrid, you might have a desk, you might not. And what you start to find out is the way that organization is doing work is not quite using the systems that have been integrated into the day-to-day operations the way they're intended to be used. We often find ourselves or find people that we are being trained upon working around the systems as opposed to working through the system. That's actually not a behavior problem. That is a design problem. And what we're talking about today is when we are implementing new tools or bringing in new reporting for compliance or for visibility for leadership. But we don't actually design how we get there, how the work is actually going to flow. We sort of make a decision on what the end state needs to be. It needs to be a report. So what typically happens? Well, if we don't have a system that can provide that, we are in a room with multiple people looking for artifacts. It could be documents, old reports, timelines, rosters, failure reports, what have you. And we are trying to piece together these requests that come. Sometimes ad hoc, sometimes we know they're coming. And the leverage that we have is still sitting in the systems that we have been given.

Working Around Systems Creates Waste

SPEAKER_00 2:05

In what the organization has paid for. And the result isn't just frustration. It's a waste of time. It's data inconsistency. It hides the rework. And there's a growing distrust in the very system that is meant to create clarity. So we start to blame the system. It's too clunky. I don't like the way it works. I can't find anything. I think we're here to say it's not the system. It's the workflow design. And I think that's something that we've experienced. And I know I've experienced it myself, going into an organization, finding technology, and then recognizing that it seems to be a source of an input. Almost like getting a dishwasher and just putting the dishes in there to dry. I grew up on that. It's not really how it was intended to function. You know, there's hand washing and then they go into now this expensive drying rack. I think there's a few of us culturally that can speak to that experience. And that's something similar that happens in the workplace. We get a new technology, we learn the bare minimum, we create a workflow that is specific to the endpoint and not how work is typically done. We don't consider how we operate in the day-to-day and how the reporting can be married together with that day-to-day work.

SPEAKER_01 3:35

Yeah, I think we can get specific, right? So if let's just assume the situation is you are entering a team and you have a group of people that are using some sort of software or tool to manage some amount of work. I think a lot of times for the person coming in, usually the onboarding process isn't very straightforward. And so you're questioning like, why are we doing this? And like, what does this button do? And then you you get a sense of people within the team are using the system in a way that best fits how they would like to do their work. And so there's sometimes a lot of inconsistency with how people input data, and uh people sort of find ways to do their own thing, and so there's uh you know, some chance of of uh configuring the tool so that it matches the way that people do their work, so the the workflows better. Um I think there's a there's a lot of ways that we can kind of go about talking about this. One is whether you can even configure the software at all, right? So depending on what you're doing, like did you select the right tool for the job? Let's assume that you did select the tool that is highly configurable and that you can configure it for what your people are using it for. The other side of it is do you even understand how people are using the tool, right? Um, before you go ahead and make the purchase of whatever software. So I think the there's probably a lot of people and very popular application of such technologies is going to be managing projects, right? Let's just talk about, let's just go into you know why people uh love or hate Smartsheet. I think there's a whole community around you're either one or the other. I don't think people are usually like on the fence about it. They either hate it or they love it. And I I think from my experience, I think the people that love it understand the capabilities of the tool, and so they really have a good support system around not

Onboarding Chaos And Inconsistent Inputs

SPEAKER_01 5:30

only using the tool, but also making the changes that they need so that people can work better together. And I think the other side of the fence is when you have a very weak support system where nobody knows who's in charge of configuring the tool, and then you have people leave, they come in and out, and then nobody owns the sheets, and it becomes a a giant uh ball of yarn at some point because there's there's not enough thought that goes into design and and maintenance of the actual system. So yeah, we we can we can you know which adventure do we want to go on? Is is one of the you want the good news first or the bad news first?

SPEAKER_00 6:08

Is right, you know, I want this to go. I love that you pulled that out. You know, uh as many of our listeners know, we've been using Smartsheet internally. Personally, I've been using Smartsheet for over 10 years, and they're you know, aside from that adoption curve that you find in technology, you're pointing out some things. I I think the support system is such a huge component of it. I'm in a situation now where the IT does not claim ownership of the system in any way. However, they are listed as owners across the entire uh space. So if the enterprise business calls anybody, it's gonna be IT. However, they don't have the skill set to really understand the software. They're unwilling to relinquish ownership to the function, they want to maintain that. And what that's doing is it's also causing a number of bottlenecks related to access as well, because there are access to specific documents within the system, but then there are also seats, and these seats allow you to have free collaborators or people that are uh license holders that can do very specific work. And so you're starting you're starting to now get into this. If this is going to be our issue, well, the issue is not the software, the issue is the internal, you know, decision making, the internal ownership, the internal support, as you said, that's sort of creating this roadblock in order to become more efficient. So you're finding, you know, what happens in here is you're finding that the teams are blaming the tools. They're not blaming the support of it, they're not blaming the design of it, it's the tool itself. So what happens? We start to bypass these systems and start to look for solutions outside of that very system that has the capabilities. And I like that you talked about the capabilities because I think there's some distinction to the features. You know, oftentimes we get drawn in with the features. Uh you can uh, you know, click this button and it'll do a whole AI thing. You can type in what you need here and it'll organize it for you, you know. But the capabilities are, you know, the transparency, the you know, ability for widespread adoption. It's an enterprise uh piece. The flexibility is a capability because you're not so stuck on how that product was designed. Because the reality of it is we all have our own in any organization, we're gonna have our own signature, right? We're gonna have our own feel for how we work. Maybe we only do one meeting a month and everything else is done through uh you know virtual updates with reports and a video or something. You know, I think that is a blessing and a curse because you can look at that and say, wow, there's some flexibility here. And then on the other end, you might have folks that say, there's too much flexibility here. So when we're you know put up against these sort of roadblocks, especially in support of a system, what have you seen work to sort of bring back some of that report, some of that support in a way that allows really a marriage of the systems that

Support Ownership Makes Or Breaks Tools

SPEAKER_00 9:45

are being brought in and the way that you do the day-to-day work? What do you find? What's been your experience with that?

SPEAKER_01 9:54

Yeah, I think for the average user of the the tool, it's so if if you're really good at using the tool, obviously you you use less of the support and and you kind of know what you're doing. But I think for a lot of people that are new to maybe using a tool, it's very helpful, obviously, to have instructions and and have training on it. But you need a you need a human, you need somebody that like to that you can go and talk to. Uh you know, having a champion. A champion, right? Having at least some sort of like super user or some what we would call like a community of practice, especially for people that are using the system across the company, to be able to consult and even ask questions on like how do I do this or how do I set that up, just so that you're not reinventing the wheel every single time. And I think aside from having that community of practice and and the training and stuff, is the the management and leadership of the company has to be behind the actual tool itself, right? I think it you're sending a really bad message if you're requiring people to use this system, but you don't respect it or prioritize it enough to commit resources and time for that support structure to work, right? I think what you'll see is a lot of management and and leadership go, hey, I need you know, A, B, and C to make a decision on X. And that that information is within the system that they're supposed to be using. And a lot of times they'll ask, hey, like I I want to see you know these reports and then where are they? And but nobody asks the question, well, well, how do we how do how do we even like get that information to you? Like what exactly, like where is it? And you know, it's only something being asked when they need it, but not from the beginning, where okay, we use this system because we track these numbers or whatever data, and so that data becomes useful for this decision that management uses. I don't think that conversation usually happens. It's usually like, oh, we put all our information in here, and uh yeah, this is how we do things, and then you'll have that monthly steering committee where somebody goes, Hey, I need the numbers for this, and everybody looks around and says, uh, what did we do last month for this?

SPEAKER_00 12:09

Since when? Right, right. You know, I think what we're seeing or what we do see in these spaces is sort of this level of assumption that comes from leaderships that not necessarily having all of the details for the ground level is sort of more of this, like, you know, wishful ask, because the assumption is that this group has the data. And as folks that are receiving those requests, it's our duty to dig into that a little bit. And I've done that with you know clients in the past very often, where I want a dashboard, I want a report, I want this. Okay, well, what are you actually looking for? Well, I talked to that person and they didn't tell me what I was, you know, they didn't tell me what I was looking for. Well, that sounds like more of a communication problem, as opposed to like now being a system issue that has to go to a different function. So that's a different kind of problem to fix than we need this level of, we need this specific dashboard. In some cases, all you need is just a report that gets sent to your email every, you know, once every two or three weeks. But I think what happens is when we are looking at data and we're trying to make sense and understand whether it's scientific data, data on our facilities, on and sort of how our equipment is running, data on our programs or projects or research, you know, we're as humans, we're trying to make sense of it, right? So when we don't see something that we wish we could have had, the request goes, this data looks like in that area. So we should be able to get that information without really understanding like, do they even collect that type of data? Is that something that is even possible? It becomes sort of a mandate, and then you sort of leave your team, you know, scrambling to try to resolve that and pull up old PowerPoint slides to let's find the data so that we can support our message that goes out back to leadership. And they might only give it about five minutes of a look, and it took

Champions And Leadership Backing Matter

SPEAKER_00 14:10

you a week to put together. So, you know, I think we're in an age where technology is moving so fast, and the human ability to adapt to changing systems is so much slower, right? Because we have to understand it. It's very hard for us to do, you know, like we're working on an assembly line. I just click this button. You typically in in industries like biopharma, things are more complex than that, right? You have relationships, you have partnerships, you have cross-functional collaborations that have to happen. So there's a lot of things that you need to consider. And our role is not so much, you know, that the that role is not so much going to be just pressing a button when things happen. So the the speed to provide a lot of these things, I think, is directly related to whether or not your technology is matching your workflow, is matching the work that you're doing. And then on the other side of that, is there something that the technology is showing you that might cause you to adjust the way you do things day to day? Because if we're talking about improvement, if we talk about reducing risk, the only thing any of these things happen is through change. Change of our resources, our capabilities, our technology, change of our mindset and being more collaborative, being more transparent, leading with sort of forward thinking, you know, and it causes, and and in a in a sense, I made that comment earlier about um these things not being a behavior problem, but we do have to adjust our day-to-day behavior, how we are coming in to work every day. Now we may not be creating Word documentation, saving as PDFs, circulating. We might be doing something that's fully digital that once we get to the end of that workflow, all of those things become automated. So now your time is free to go and and, you know, honestly, probably make another PowerPoint slide, but hopefully have time to think and reflect on what's happening. You know, so there's, I think there's a lot of things to consider here, you know, going all the way back to the design of our workflows and sort of what are we, what are we at the end of the day saying that we are owning as a function, as a group, as an individual contributor? And then what are those resources that we have that perhaps we haven't yet leveraged, that we know have these capabilities, that we know once we learn those capabilities, and here's the thing, we have to learn these things before we can apply them consistently. If we're just we'll do them as a one-off and we don't create any kind of documentation, we don't hold any training, and you become the system expert, we're gonna find ourselves in a place where we're reworking and doing things, and it becomes harder. And like you said, what did we do last time? I don't remember what we did last time. Because now you start having these ad hoc requests that are almost like indoctrinated requirements, right? Now we are required to provide these things. Well, it's gonna be a lot easier if you can create that level of consistency and leverage the technology. The technology should not be a source of friction. But especially in the beginning, if you're not bringing people along the way, if you're not reconciling your workflows with what the technology is capable of, and understanding at what points. Very similar to AI. There's uh an article that um was just written by Smartsheets uh chief technology officer. And she talks about the challenges with AI are not based on policy, it's based on workflow design. You know, where are you putting in this tool and where are you putting in a person? Somebody has to be there. Somebody in the team has to be a part of this workflow. Now, how do you integrate the tool so that that happens consistently and fluidly across that group and then eventually across the organization?

SPEAKER_01 18:25

Yeah, and then back to the the point you made about the just change management in general. I think, you know, I think the majority of people are in a situation where you might have some sort of committee or group that meets routinely that maybe you go over some of these requests that people submit to update the system, depending on how they're working. And then it's up to management, your your IT business partner, and and probably the end users to be able to justify, like, hey, this is important. I think we should make the change. But evaluating that change and actually implementing that change, that takes time and it takes money, and you know, there's a whole bunch of other things that go into it, right? I think

Dashboard Demands Versus Data Reality

SPEAKER_01 19:05

a lot of times what's missing is like you said, you have the and and I'm not trying to bash the IT uh people here, but they're more concerned about the cost, right, of using such an application, and also on the cybersecurity side, making sure that you're in compliance with these these regulations that we have. And but you're you're really missing the the that that architecture of how the design of the workflow is supposed to be, right? So if you're gonna implement these changes, you need to understand the underlying relationships that exist already and whether or not these change, like you may change one thing, but you have to consider, okay, well, does this change all the other things that it's connected to? And I think a lot of times that's missing. And when you when you don't involve that particular person or that team in the conversation, then the design starts to collapse. And then now the more changes you make, you're like, why is it getting worse, right? And then from that end, people will stop suggesting things because they're like, this is making it worse. And yep, and it becomes this circle of uh every time you submit a ticket, things get fixed, and then you submit another ticket to address something else, and it becomes a circle of never-ending changes.

SPEAKER_00 20:16

I think you're you're you're hitting on that other topic that we almost talked about today, which is sort of when you're fixing localized problems, when you're fixing issues within your function, um, you know, what have we seen? Usually there's not this global, hey guys, we're going to take ideas across the organization, prioritize which changes or which fixes we want to make. You may find, hey, we want to speed this up. So every department, every function, you guys need to find a way to integrate AI. You need to find a way to show me efficiencies. You need to find a way to lower your operational risk, get better. Essentially, they're asking you find a way to do your job better than what you're doing today. And what happens when we take these requests or these goals and we sort of internalize them in our own space? Well, the most efficient groups are gonna be just that, their own group. Why? They talk to each other a lot more, they could have a lot more communication. And we know that change, communication is a big part of change. They're uh sharing practices with each other. These are things, these are relationships that happen within your department that do not necessarily translate or or go across borders into another function or department. Unless in the rare space you have, you know, a best you know, friend, a chum that is over there in this group, uh, that you've been sharing some tips and tricks because they're interested in the things that you're doing, or vice versa. You know, you're starting to see this, and and what we're doing is sort of we're actually Fortifying silos. When we are working really complex projects that involve multiple stakeholders with multiple levels of technology experience, scientific experience, you know, these are very technical people that need to be brought to the table. When we're sort of ignoring that and looking at, well, how can I create this as fast as possible? We're sort of changing the caboose in the middle of the train and optimizing it from one that used to haul coal to one that's now a dining cart. But now the end parts of it, and this is my parenting advice here: when you buy toys like Picasso tiles and magnet tiles and all of these tiles that magnet together, they are not all the same. They do not all stick together, and they're not all the same size. So you end up getting gifts across birthdays and things like that, and you try to build structures that just completely crumble. And that's a little bit of what happens here when you're sort of trying to create this Frankenstein approach. You start to come up with new ways to go around the problem as opposed to creating a solution through and through, using your software or changing. Sometimes we have to change. I think the hardest thing in this industry, I mean, you know, we've talked about it before, how difficult it is to stay really consistent in dropping projects or or initiatives that are not yielding things by the time you thought they were going to. A lot of, you know, often we think, well, uh, we've already put the money into it, we should keep going. This is a cost of the work that we're doing, that's a sunk cost. If it hit here, if it got to this point and it's not getting to those requirements you said, you need to sunset that project and put your resources into something else. You

Change Management And Workflow Design

SPEAKER_00 24:00

know, if if we're working on a tool, or if we're working on a new, you know, methods of working internally, new systems, look at what your old ones are doing. If you're, you know, using products that come on every computer that are not really built for cross-collaboration or collaborative initiatives. It's time to adopt. It's time to adjust the way that you're doing your work. It's time to adjust the software that we're using. And guess what? You might have to do that again in five years. Why? I don't think this industry is going to look the same in five years. You know, we're not building straws here. Yeah, the straw has looked the same for hundreds of years or however long a straw has been available. But when you're talking about research, I mean, look at the shifts that have happened. And we talked about it before. Our conversations used to be all about, you know, the platforms and CRISPR Cas9 and just like how all of the, you know, we had a client that was building a facility for that. And now folks are not placing bets on these long runways. They're trying to place bets on sure things because of a patent cliff that's about to happen across multiple large pharma. And now they're trying to pull in phase two, phase three. You know, there's a lot of things here for us to consider, especially when we're looking to uh combine our systems and really leverage those systems rather than introducing them and allowing them to become a source of friction.

SPEAKER_01 25:34

Yeah. And I think, you know, to your point, the this comes down to making sure the not only the workflow is aligned with both the people and the the obviously the system that you're using, but you've you've brought up a lot of questions that you need to be able to answer for each of those different uh stakeholders. And you have to be asking the same. Um maybe it's not the same question to evaluate some of these changes that you would need to make so that it's more aligned. But at least having the conversation, right? I think there are many organizations and teams that, like you said, they they have these workarounds and they do these things, but there isn't an effort put in to make sure that, okay, if we're gonna make an adjustment, like what are the questions that we need to answer? What are the things that we need to address so that if we're gonna modify the train in the middle, everything else is going to be okay, right? And and I think this we're kind of leading into the assessment, which is the the operational workflow alignment uh assessment that you that you've put together. And the assessment itself is is built around several different risk factors, right? Being the handoffs between different teams, whether or not you're duplicating effort across these teams, you're looking at how clear your your actual process is. There might be issues with like tool fragmentation that you need to consider as well. And then obviously the the last point with with which is what management and leadership care about is milestone visibility, right? So if you're not able to track progress on things that you're doing, then what are we like, what is the point of using the system if it's not going to help us make these decisions going forward? So, yeah, let's let's dive a little bit into like how organizations would be able to use that sort of practice of making sure their workflows are aligned and what that process typically looks like.

SPEAKER_00 27:28

You know, I think in the you mentioned something earlier that I think is super critical in the beginning. That relationship, whether IT is doing the hunting for you, or you as a function are doing the hunting for the next technology to answer and respond to leadership questions. I will tell you right now, you should never look for a piece of technology that is specifically answering the question that leadership brought to you for a few reasons. Number one, it might not have been a good question. These sort of requests that come from leadership, I find, happen to be filtered or modified views of something that already exists or something that we're exposed to. So as soon as we look at something, a slide deck or a visual or a dashboard, we're gonna assess what's in there and then ask questions. And when we cannot answer those questions through the view that we're looking at, the go-to is we need a new dashboard, we need a new report, we need new data. And it might only be just to answer a hunch. Does that need to be repeatable? Probably not. But these are sort of opportunities to expand that questioning. What else do you think is missing here? What else? What information could we provide that would make you feel more secure about the message that we're delivering you? And what that actually does is change your workflow. Because now, whether it's new leadership, whether it's we just got funding. So now these are the things that we care about, whatever the situation is, it's really

Don’t Buy Tech For One Question

SPEAKER_00 29:10

important to understand first, what do you have access to? I've had many people ask me, hey, can we get these reports to show here and to show here? That'd be great. That data is not managed by this group. That data is managed by the group over there that is short, three staff people, and don't have any money for additional resources or technology. So perhaps at that point, you might want to, you know, adjust some of your efforts in in a certain direction to either support that or maybe find that that data point is not as, you know, is not as important as you need. You know, what we're what you should always be considering when you take a look at your workflow and you say, okay, we need some technology. What we're doing, maybe we're doing things through Excel, it's becoming too slow, or you have documents that are in SharePoint and somebody checked it out and I can't update it. You need something that's cloud-based so that multiple people can work, whatever your situation is, you need to ask yourself, how easily is this workflow going to break down under pressure through change, through the complexity? If somebody's out on vacation, does this completely die? Visibility. How easy is it for people to understand what this workflow is? Who are in that blast radius, who are going to be on the receiving end, right? Because they should also be involved, as you mentioned before, they should also be involved in the discussions related to the software. Now, there's and there's a few other items in here, such as stakeholder load and resilience. Like how strong is your workflow in times of change? And you know, and how quickly does it recover? Leadership changes, you lose a couple members of the team. How easily can those things recover? So you have to think about each of those pieces and you know, question whether or not you need to adjust your workflow before you start looking for technology. A risk that I see out there and is often being sort of perpetuated is folks will look at the technology and try to create their process so that it fits in the technology. And I can't disagree with that enough because you are going to find so many restrictions. But we we do that, right? We go after the software that promises the world, but we're just getting a list of features. And the features are not how you perform your job. So we have to be really critical about what is it that we're trying to do? What's the value to outside people? Who are these stakeholders in this radius that if we change the way we're doing things, do we bring them on board early, or do we just tell them at the end and say, hey, this is what we're doing now? It's going to be the former. You should be bringing them in early on to have those discussions. And hopefully, at the same time, you have leadership support, a VP or a C-level executive that is supporting this move because they can also see the future vision. What I want to really caution our listeners and and everyone that's that's sort of going through this, don't just pick a piece of technology because it answers one question. You need to consider what is going to happen to the future of the business. Yes, you will more than likely need to adjust whatever technology you're using if the that technology is not releasing updates at a regular cadence. If they have a small support staff, which means any change that you need is going to take a week to implement. These, and I find these most often happening in very customized solutions. So you find yourself uh in a situation where you're sort of beholden to that program that you've decided two years ago that that was the one that we were gonna do. But now we've now we've grown from you know a hundred to you know eight hundred people, and that one software that we bet all of our money on or you know, took it to the bank, doesn't really work for the way that we're doing it, doesn't really scale. It's too difficult to make adjustments as our portfolio is growing. So these are things that you have to be very weary of and cautious of. And I think that there's some you know systems out there, again, I you know, there are pros and cons to everything, even Smartsheet. I'm I'm a big advocate of what it does, but there's also pros and cons. And it's not for everyone, it's not for every type of work. And we have to also understand that if your work entails a piece of technology, that might be the majority of the things that you do. But there's other space in there too, for how you're you know, recording documentation. Maybe you have to record video or sound or you know, some other type of medium to carry the knowledge, to make sure that you're able to convey messaging. Reporting to leadership is is obviously, you know, is kind of like the number one. You want to be able to distill all of these, you know, folks that are working and doing the day-to-day and distill that into here's you know, the 30,000-foot view that can help us start asking real questions on our strategy, on our approach. And then sometimes uh, you know, on our on our spending. Are we are we bleeding money? Are timelines getting busted? You know, and so our assessments, especially this one uh in particular, you know, looks at those unique factors within the operational workflow and aligning that with your organization through the lens of how fragile is it? How visible is that information? Does this rely on a small number of people, a large number of people, people in your group, people outside your group? And is it resilient? If things start to move or start to waffle, is this going to be really difficult? Because you can build out a system that any update requires individual updates across portfolios. That can be very tedious, very time consuming, and a sure way that you can expect there to be errors across your system. But you're right, there needs to be some support. There needs to be a champion in your organization that is that expert, that is that go-to person, in order to really fulfill the ROI that you intend with this technology.

SPEAKER_01 35:44

Yeah, I was I was thinking about, I guess, within an organization, who do you think would be the most appropriate person to sponsor the workflow alignment activities, right? And I I think but before I let you answer, I'm gonna give you my opinion on this. And I I think it's and I and I don't know if if uh the majority of companies have this, even though they should, uh, depending on how large or small you are, is there should be a team focused on digital strategy, right? So digital strategy kind of having some connection with obviously your IT business partners who are more in charge of information technology applications, but then the digital strategy person or team is connected to the business and how they're using the application. And so to your point about selecting the right technologies, whether or not this one is right for the organization, I think that is a is a key role in all

Workflow Alignment Risks To Assess

SPEAKER_01 36:40

this in understanding whether or not we need to make adjustments or we keep this or we move on. But I I think they they would be probably one of the stronger use cases, I think, for using such an uh an assessment. And it's because it's got to be someone who can take a look at the bigger picture, not just from one lens of IT or one lens from operations. It's usually a mixture of of the two.

SPEAKER_00 37:05

That's a great point. That's a great point. I think what what I'm confronted with most often is that there isn't or there aren't folks in that role. And if they are in that role, there's this sort of like hand extension in terms of helping support with with you know selecting uh a software or tool. But it's just like anything else, it's just like creating a timeline, it's just like creating a budget, it's just like creating a plan. All the work feels like it's in the beginning. And the work is really throughout the use, the maintenance, the you know, the practice of the work that you're doing. Because what we find often, or what I'm finding often, is that we sort of, you know, it's the shiny object in the beginning. We're all working towards it. We do a couple trainings, and then they move on. There's no training to the new people. Just go to this space and start clicking around. There's no curated systems or role-based training in a lot of cases. And it blows my mind because the single most powerful thing that you can do as a leader, as an organization, to someone who just came into your organization is to train the heck out of them. Because then in three months, you can have a rock star that gets it, that knows the system, that knows the people, that knows how these things are all put together. But when do we hire reactively? We hire reactively. We hire to get them to start working right away. So that learning ends up being very focused on the things that are right now because they're happening right now. I'm not saying you stop learning from there, but there's just a complete dismissal of the core things that need to be established so that you have smooth operations that workflows go from one end to the other. So I often see if it's not someone in the IT space, it is someone within a given function that had a couple phone calls with the enterprise and are gonna bring it in. And what happens is they become the owner. I don't know that they're always ready to do that, right? They may not know the questions to answer, they may just accept everything as like, hey, this is the this is the way that we're going. And, you know, where I started like that. I didn't know what to answer, I didn't know what to say, um, uh or what to question. I just, you know, little by little, I kept saying, How can I do this? Can we do this? And what if this is the problem? And I had to continue to learn and and doing it on my own, doing it on my own, working in a system when it wasn't work, when I wasn't actually like manipulating data, moving it around, working and trying new things to see how things broke was was really my goal of how quickly I learned. I would try combinations of things that were capabilities of a software, and then go, oh, you know what, that doesn't work, or that works pretty well. Let me see if I can you know scale this a little bit. So we're often missing people in those roles to really carry this out. So I think what if if you are a leader, if you are working in a small mid-space, even if you're working in a large biofarm and you have a fleet of people, you lack visibility, everyone seems to be working, but the progress feels very slow. It's our responsibility, it's your responsibility to look at the system. Do we have the things we need? You know, if I asked you, Lawrence, to paint me a mural, and the tools I gave you are those little paint brushes that are like this thin that come inside of a kit for you to paint a small mushroom. And I'm using this example because my wife gets those all the times for the kits. They're usually painted in one color, just aggressively painted one color. But how long is it gonna take you to paint the mural if I give you a paintbrush like that? We have to look at our resources, we have to understand our tools to a level that allows us to expand our way of thinking in terms of what are we doing? How do we do this? What is the it's not gonna look the same. We're not gonna have Word documents to do meeting minutes. We're gonna put something in the cloud that allows us callback whenever we need to, as quick as possible. It organizes when actions and sends us alerts and things like that. So we have to be the shepherds, leaders have to be the shepherds to say, guys, I want us to go in this direction. And there has to be someone on the team

Training, Sponsorship, And Brave Shepherds

SPEAKER_00 41:50

brave enough to take that on. Why do I say brave enough? You won't be everybody's friend right away because this is a new system and people feel uncomfortable and there's new technology. And I just like the way I do things. I like my way. Why do I have to do this? Because you don't work in a company of you. You work as part of a team, and that team is a cog amongst all these other cogs that make this business run, that develop medicines for patients. The organization itself is a system. We've talked about that. The people, the process, the technology, the culture, the guidances, all of that. Your space, all of that is part of your system. So you have to approach it as such. And it's not just as simple as let's change out a cog. Now the cogs don't even reach each other. So while it goes all the way up here, and it's and and your cog is still moving, you have a big gap between this, between you and the next group. Nice work. And I see that often when new technologies pop up and zero consultation across the organization, just specifically for them. What does that do? That builds an efficiency in one group. However, the role is cross-functional. So now everyone is scrambling to adopt or to adapt, excuse me, to adapt to some new technology that is not collaborative in nature, that doesn't have the visibility, that now you don't have access to.

SPEAKER_01 43:42

Obviously, people go into work not hoping to do a bad job and wanting to do well at their role. Um, but you're you're right. There there are some things that maybe are indirectly outside of your role, but this could benefit and make other your co workers like. Lives a lot easier. I think that that's very important too, is you know, to your point about you know, these companies are are uh working on these life-changing medicines for patients. It's it's also you're you're there to make work enjoyable for other people as well.

SPEAKER_00 44:16

Like we spend so much time, we spend so much time at work, and when I see people miserable, I used to I've been at work before in a professional setting, and it was not uncommon to hear loud voices, to see people rushing out of the office in tears. The most just why why why does it have to go to that level? We should be working, you know. When I hear I've heard before in my past when I first started, you know, doing this this type of work, why should I make things easier for other people? That's how you feel. You're not part of a team, you're in a team of you. That's a very selfish, a very fixed mindset. If I can make my work easier, I'll give you one even better. If my work becomes marginally more work to take on, however, the downstream impact is measurable, is repeatable, you become a hero. You took on this little bit, and now you enabled a fleet of people. That's also improvement. Your work changed a little bit, but all you had to do is instead of doing this format, you do that format. And because you do that format, we bypass two days of escalation to adjust something from a PDF to an Excel file or what have you. And now they can just drop it in and their system takes it away, and they've cut out now four hours of manipulation because you've decided to do those things uh upstream, right? So, you know, I challenge folks if you're if you're in a place that you're you want to make things better, you see where folks are bringing things down. I mean, honestly, have that conversation.

Fix Bottlenecks With Systems Thinking

SPEAKER_00 46:10

Hey, we're here trying to do the same thing. I don't want to come to work and be grunting and moaning, and I don't want you to have to do that either. How can we work together? How can we build something cohesively that we're both proud of that gets us out of our, I have to do it this way. I don't like that because it's just confusing to me. You know what that tells me? You don't understand it. That's not a growth mindset. That's a that's a very fixed. I just started listening again to a book to Mindset by Carol Dweck on uh Audible. So it's very fresh right now. But and I think, you know, for those that don't really know how to pinpoint it, our assessment looks across a number of risk factors. This particular assessment in operational workflow alignment. And those risk factors help us understand are these internal challenges within your function? Are they the cross-functional handoff that is being sort of stunted? Is your process clear? Do you have really great tools, but nothing talks to each other? So although you might be producing a lot of work, the next step is very, very slow because the translation is painful. And this is, you know, this is a great, it's a great example of sort of being so good at your role and then just having a stack sitting for the next person. Oh, I'm a great team worker. That's not working like a team. That's worrying about yourself. That's seeing, I'm gonna do as much as I can and leave it here because that's not my problem. The project is your problem. They're on your project. You better work with them to figure out how they can have a quicker output. Because if your throughput is through the roof and you're not the end of the process, you're in the middle, you're just now creating a new bottleneck. You hand it off the bottleneck from you to the next person. I've seen this with high throughput screening. We have one analyst. Oh, it takes a couple of hours. So the high throughput is in processing it. I'm sorry, the high throughput is in running the experimentation, but then when you go to process and analyze it, weeks, months, how relevant does that become now? Oh, these are experiments that we did two months ago. Awesome. Not relevant anymore. So if today resonated with you and you want to go deeper, the book is where this all started. So we're gonna put the link in the show notes. Uh, predictably broken is out. We have an audio book that is in planning stages that will be out hopefully uh by the end of August. That's our that's our goal. And if you're if you're in your organization, you're hearing what we are described in this organization, one of these operational assessments is a great natural next step. You can reach out to us directly. We'll have information in the show notes, but it's a really good way to sort of unload all of these things that have been weighing on your shoulders in terms of working faster, working more diligently, being more responsible, accountability, you know, understanding where these gaps really lie, and then pulling out those top three exposures. Because I'll be the first one to tell you, and Lawrence will be right behind me. It's not just one thing, it's a combination of things. So you need to address them

Book, Assessment, And How To Reach Us

SPEAKER_00 49:40

together. And if you're already past that point and you just want to talk it out, feel free to reach out to us. Our information is in the show notes, and we'll be more than happy to discuss these challenges with you and what they might mean for you in your organization, in your context, in your culture. Thank you, Lawrence. Until next time, we will talk to you all later.

SPEAKER_01 50:00

Bye.