0303. When Hard Work Isn't Enough in Complex Projects

Cross-functional projects don’t usually fail because people aren’t working hard. They struggle because accountability blurs, decisions stall, and execution discipline quietly erodes under complexity.

In this episode of Lean by Design, Oscar and Lawrence explore why managing complex, multi-stakeholder projects is more fragile than most teams realize. In matrix structures, individuals juggle competing priorities, roles become loosely defined, and governance often depends more on personalities than design. Work continues but consistency in delivery starts to drift.

Rather than framing this as a collaboration issue, the conversation reframes it as an execution health problem. The hosts unpack how unclear scoping, diffused accountability, and delayed decision-making create operational risk long before a project officially “fails.”

This episode also introduces the thinking behind the 3.1 Cross-Functional Project Execution Health assessment, designed to help teams diagnose how consistently they deliver complex initiatives and identify the structural gaps putting delivery at risk.

Complex projects demand more than effort. They demand execution discipline!!

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

SPEAKER_00 1:01

We are back with another season three episode of Lean by Design Podcast. My name is Oscar Gonzalez, alongside my co-host Lawrence Wong. And today, Lawrence, at its core, we are talking about the challenges and some of the issues that we see when running teams. And we're not, you know, as I started to look through uh what we had written down, it's not so much teams that we are a part of. Usually those teams they work, they define their own rhythm, their own communication style internally to their function, to their department. But when you start looking across functions where there are differences in experience, differences in technical expertise, differences in their history, in where they came from in biopharma, in academia, through their science, through their education. You start to hit a lot of friction points, especially when you might be on a team that has, you know, a set of 10 alphas, and you have a project lead or a program lead or a program manager and some associates and some technical leads that span different spaces. You know, who gets to make the final call? Who gets to decide which direction the project is going to go? Does everything have to go to leadership? What can be decided here? I think we have both been a part of very complex teams that are running multi-million dollar projects. And unfortunately, no matter how good your launch is, the success really comes in those thousand strokes in between the beginning and the end of that program.

Losing Sight Of Long-Term Goals

SPEAKER_01 2:49

Yeah, I mean, there's it gets very complicated when you have to coordinate with all these different groups and everybody's expertise is different. Um, I guess knowledge of what actually needs to be done, I think, is different too, because everybody has a different view of what the actual uh project is and the scope. And so um, you know, it just coordinating a bunch of human beings is very complicated to begin with. But um when you have a situation where the the end or the proposed state is very unclear, I think that just adds to the confusion. And then obviously, if we're gonna make this journey together to get to wherever we need to be, we all need to decide, you know, when to sequence certain things so that we're all in in lockstep with what needs to get done because they're obviously on a project schedule, certain things have to occur so that other things can occur downstream. And I I think people often think, oh, I'm in this department, so I just do this one thing, and then the other another group is probably looking for feedback or some sort of deliverable from another group, and so it gets more and more complicated as you you add to the the volume of people involved and the complexity of whatever the the project is actually going to be.

Defining Projects And True Execution

SPEAKER_00 4:00

It's when the uh the cross-functional becomes dysfunctional. That was something I wrote down here, and that's a lot of what happens where uh you know it you start off kind of hot, but then there's I don't know if it's sort of shiny object where you feel like all eyes are on you because you're getting started, and then as you get moving three, four, five months, the the end goal that is 18 months, two years away, you know, in this particular phase of the program or the project, it sort of fades away. It becomes like a distant memory, and the focus is on the next thing. What's tomorrow? What's the next meeting? What are the data points that I need to come up with for the next meeting? And I think this represents a risk where we're not aware, we're not aware enough of where we're trying to be. And so we're creating these checkpoints to again check yourself against your goals. But when you fail to sort of revisit these goals, not just when leadership is asking for, but with a regular cadence to make sure that you are embodying what your target actually is, not how you're gonna get there. Because how you're gonna get there, you're gonna have to pivot. Because no matter how well we plan, we can't plan for the unknown, especially the unknown of unknowns. We don't know if something's gonna change in regulatory space, we don't know if something's gonna change in the leadership space, we don't know if the research at our organization will just spontaneously change. You can't really think about those things, but you do have to have some level of expectation that there will be a pivot somewhere, understand what that pivot means in the context of achieving those goals. So it's really important. And I think you you you brought up a good point where we don't, it's it's often like we don't ever know what is at the end of the line. And there could be team changes that happen in here. So when you introduce those new people, are you going the extra mile to, and it's not even going the extra mile, it should be foundational. You got a new team member, here's what the goal is, here's where we have been, here's where we had to pivot, here's what we're trying to do now. You know, give them some assemblance to ground themselves in this larger project, especially if their particular function is not necessarily the most active one at this stage. But that information is probably going to be useful for them to plan the next stage that happens in that program. So, you know, we're talking about here cross-functional project execution. And so let's tease those pieces out, cross-functional. And that lends to multiple disciplines, multiple areas of technical expertise, and some areas of management expertise, because those are different, those are different things there. Uh projects, so we're talking about something that is has a beginning and has an end. And typically there is a goal for that particular project. It's not just to stop working. There is an endpoint that usually rolls into some larger corporate objective. If you're running projects that don't support your corporate objectives, I would challenge you to reconsider what your project is actually doing in the context of those objectives, or that might be something you don't want to spend resources on. And then execution. These things are not good enough to plan well. It's going to take the execution. And when you talk about kickoffs and having healthy kickoffs, those are critical to getting everyone aligned at a single point in time in the beginning. But the execution comes to the entire 18, 24 months that you're working on that project. But the only thing people can remember is at the end. Was it successful? Was it a failure? And they look at that point at the end of that time as a measure of what happened and less about how well the team was executing. Because you can get to the end and just have bad luck. Either it didn't translate well because systems beyond our understanding were at play. Perhaps the regulators wanted something different that you were unaware of. I don't know. But it's important for us to really, when we're talking about this, that we're not just talking about the front, we're not just talking about the end, we're talking about everything in the middle because that's where the dysfunction comes in.

Good Outcomes Vs Good Decisions

SPEAKER_01 8:42

Yeah, and I'll I'll add, you know, you you talked about the um the the the time piece and and having a start and end, and obviously the execution is important. I think the two other pieces I would I would add are these projects have a fixed budget, right? We don't have an unlimited well of of cash to keep throwing at a project. Right. And there's a finite number of people involved, right? We can't have the entire company focused on one project because that would be wildly inefficient and not possible to execute on other projects that are also going on on in parallel. So, you know, the the execution part is is uh that's a tricky one because you know for for somebody to get for a team to get from A to B, you have to, on average, make a series of good decisions to get to the end. And and to your point before, right? Like it's it's it's okay to make a good decision and have a not so good outcome, but to execute poorly and then somehow get lucky to have a great outcome, it confuses you, and it and people think that, oh, this is actually the right way to do things. But I think that's how can we do it again? Right, can we do it again, right?

SPEAKER_00 10:46

We did that on this project. I've heard that.

SPEAKER_01 10:48

Right. And and not actually looking at the the strategy and like, did we actually make the right decisions to get us to this point? That's where the very beginning of setting up the project and the coordination among the different groups, governance, right? How decisions are made, how those things are communicated are gonna be very important. And not just, you know, let's let's move progress even past when the project is created. There's that whole maintenance aspect that I think a lot of people forget is there is there's never a project where the people involved in the beginning are all the same people at the end. And so people are gonna be coming in and out. And so you got to really think about how you integrate those different parties that are that are involved in the project as well.

Onboarding New Members With Context

SPEAKER_00 11:29

You know, that's right. It's the way that projects are designed now in order to have the biggest impact of your resources, there's sort of this like, you know, coming in the door and leaving the door and coming in the door, well, you don't need somebody with this expertise until you get to this layer, and then they're there for six months to get you to this next space, and then they go off to something else. So if you're not, I completely agree with you, if you're not paying attention to the team changes that are going to happen and how you're gonna navigate that into bringing them into the group, bringing them into the culture, acknowledging what their role is gonna be and their expertise. And, you know, in some cases, like this person is more technically sound than you. So now that you have been speaking up on behalf of this type of function, you need to sort of back up because now the expert is here, and you need to take more in of what they're saying, of what their, you know, their decisions are, and and understand that in the context of what you have to do for that project. Because usually those individuals, you know, mostly a program manager, project manager, they're gonna be there for most of the time, if possible, because that that continuity is really key to having this execution of the project to be more fluid. You know, they have the historical knowledge from the beginning, you know, through any changes that have happened. So I think that's one of the key roles that is important to, and and it doesn't happen in every scenario, in every situation. Sometimes there are you know bigger projects that get pulled in, and that person might be more experienced, or they're gonna say, hey, we're gonna pull you out of this one that's just starting to run this one that we really need some serious help. So that kind of thing might happen. But you nailed it. The we forget so much how critical the maintenance is because it's boring. You know, it's not fun, it's not exciting. We have, you know, a year's worth of work to get through. And when you see that, I think a majority of us take a deep breath and go, okay, we have a year. Let's just move through and and and check the boxes that we need to. When there should be this sort of steady pace at which you are developing your assets. And to do that, there has to be that communication, there has to be that, you know, decision making, there has to be that sort of rallying around each other as a group to make sure that you're hitting these markers along the way. And so when these things don't really pan out, you see progress in the way of timeline, money spent, maybe we get to certain milestones, but it just feels hard. It feels sticky. It feels every time we make progress, we have to stop and go back. You know, I don't know if you've been a part of any projects that did this, but I know I've been a part of a few where we start off the project saying, okay, this is more of a waterfall approach. We're gonna run some experiments, check out this data. That is gonna allow us to funnel. You know, this happens very often with like high throughput. You have to funnel from screening thousands of possible um, you know, genomic signatures, and you want to try to get to five or ten at the end of the line. And as you're moving down, you see some of our favorites have fallen off. And then you'll see some folks that want to bring that one back in into play, even though the data has suggested otherwise. And what happens? You start to create exceptions. Well, it's not always a guarantee. So we want to do this, we want to do it. So now you are sort of going back on decisions that you made to move through the funnel. And so you're now interested, you're introducing variables that were not intended to be variables in this area of discovery. Have you experienced anything like that where there were decisions that were made, and then as you're moving through the project, it's like, well, let's go back and bring this in. Almost like a self-doubt on the decisions that were made previous.

Decision Logs And Accountability

SPEAKER_01 15:44

Yeah, I I I think I think I probably see less of that and more of decisions not being made, and then kind of leaving that up in the air, right? So there are things that come up on projects that I think the what usually happens is the group tries to come to some consensus on like how we should move forward, and then they go, Oh, yeah, let's put it on this raid log or something. And then what happens is it sits there and then nobody gets assigned. And there's so there's like zero accountability as to who is actually responsible for making that decision. Um and and I get it, right? There's people that are assigned. One scenario might be that it might be a lead of a work stream that is working on multiple different projects, right? And so their capacity is kind of constrained with I just have a backlog of things I need to decide on. And but they for often forget like that decision that you're not making is actually holding up a whole bunch of other group of people that I need to do their work. And so there's this like resource allocation problem, I think, that usually happens that is very closely tied to the the decision that is not had that has not been made. Now, back to your point about decisions that have been made, and then going back and like questioning that. Okay, well, you know, that there usually is if if you're on a good project, there is some sort of traceability on like the logic behind the decision being made, and you can kind of follow the breadcrumbs. And if you need to revisit that decision, then you would go to that point. Hopefully, right? You have that log, but if you don't, then you end up in this situation where you're having to go fact-finding and like doing an investigation on how did we get to this point?

SPEAKER_00 17:17

And like what did we present to leadership? This is a different version.

SPEAKER_01 17:21

Right. Yeah. So there's this ambiguity is like who made this decision, what were they considering at that point? And it's it's important, like you like we were talking about at the beginning, right? To really set the stage on this is where we are and like this is where we're going, and then be able to track those like key decisions as as you as you go through. And one of the other points um that I didn't get to mention as as you were talking was you mentioned project manager, right? So let's talk about the difference between a uh a project manager and a project lead, because I feel like sometimes the project lead may not take the accountability and responsibility to make decisions on how a project is supposed to go and and give that to the project manager. And then you have the other way around where the project manager goes, oh, well, that's the project lead's decision to make. And so there's this like confusion, right? Like who is the person that's gonna make the call on this?

Project Lead Vs Project Manager

SPEAKER_00 18:16

Right. I mean, there's and so if we're looking at those differences, you know, from I think you find project leads in sort of more mature project-focused companies. And in those, those project leads usually have more scientific background because they are sort of combining the experience of you know, whatever research is happening with the latest understanding of this area of science or research, how things might be changing. You know, I suggest that we start looking into, you know, oral, you know, can we make this into an oral therapy because we just saw the FDA struck down the latest injectable, blah, blah, blah. You know, they sort of have this more strategic lens. I think what I have noticed in my experience is that there is this sort of back and forth tug of war between project leads and project managers, where certain aspects of the project lead sort of live into a program manager, and then vice versa. And in certain cases where the project manager might surface something, the project lead might say, No, you have to get those things through me. So, you know, what are we talking about here? We're talking about unclear decision rights, you know, what can be decided by who versus what are those things that need to be surfaced? And when we give these descriptions, I think it's important to include examples as opposed to just being like, well, anything that has to do with strategy. That could be absolutely anything. You know, can we get a little bit more specific? Okay, if you guys are trying to, if you guys are thinking about the modality, or if we don't have a therapeutic and you guys want to explore specific therapeutics, yes, those are all strategic directions that we need to have conversations on, because obviously, depending on the therapy, depending on the patient population, you are gonna be directing your traffic of your research to go in a certain direction. Authority shifts, depending on the context. So, who should be speaking on behalf of the team to who? Who should be speaking on behalf of the science? Who should be speaking on behalf of the operations? How are we going to operate this project? How are we going to execute this project? And a lot of times we leave that up to you know the managers that put us on a team rather than the team itself. The team needs to have some level of self-governance. Hey, you know what? We know we have to do these 10 or 15 things. This person is an expert in XYZ, so we're actually going to use them to help us with X. It may not be the role that their function typically has. It might be another, you know, sort of side quest, if I want to, if I wanted to put that there. But it is indirect, in line with what needs to be done in the project. Um, and we haven't even talked about sort of rework, the normalization of rework and and meetings that begin to substitute for decision making. I saw just the other day it was somebody on Instagram, and they were like, so now I have a meeting. I had just had a meeting that didn't go from a decision. They wanted me to create a new scenario. So now I have to meet with all of my leads to create the scenarios to then surface this to a subcommittee to get buy in from them on the strategy or on the redesign of the plan that we did before we go to the governance to get their blessing that then we can go and ask for the money. And so when you talk about changing a plan, getting all those people in the same room, those things unfortunately can take you two to three months. Yet we look at what slowed the project down. We look at those one or two things. You know, there's I heard the term just recently, funny enough, of recency bias. You're just biased to what happened in the last like three months, five months, and you're forgetting that wow, we made a change, and it took us three months to get that change approved. So that's three months of work that you're not really doing. You're not really going at your capacity, it's going against what you budgeted because now these sets of people, they're not even really working. We're sort of exchanging ideas on the strategy and getting feedback probably from too many people. Because again, the goal, the goal doesn't have to change, but the way that you approach it can change. And those are the things I think those are some of the challenges that we face.

Meetings As A Substitute For Decisions

SPEAKER_01 23:15

Yeah, I I think so there's you know, we we talked about the difference between the the project lead and project manager. I think it's safe to say that normally what will happen is that you'll have multiple, I'll call them project leads or work stream leads that have to coordinate with the particular project manager, right? So, you know, they're they're probably much more involved in the the nuts and bolts and the technical details around how those different work streams are supposed to do things. And a good analogy, I think, of is like on a on a football team, if you're on offense, the the quarterback having to interact with the offensive line, having to interact with the receivers, and then the head coach drawing the plays, you got the guys in the booth who are looking at the defense. And like all of that has to be in synced for you to be able to execute on those four downs that you have. We can't, you know, go time out and then have a discussion here, have a discussion there. You'll you'll never you'll never get you'll never score. You'll you'll turn the ball over. Never get downfield. Never get downfield, right? And so I think we have for a lot of projects, there are mechanisms to escalate things and communicate issues, but I don't think we talk enough about what is the expected time to decide on when we resolve this thing. Because sometimes it's it's like, oh, I gotta meet with this person, then I gotta meet with this other person, then they gotta decide. But having that standard, I think, is very important, like we talked about in the beginning. What is what is the expectation? What is the standard for when we run into issues? How long are we gonna sit on something like this? And if it exceeds a certain time, then it deserves higher priority. And being able to look at the roadblocks that you have in decision-making ambiguity and prioritize those things, right? Not everything that comes up in a project will deserve the right amount of attention, right? There are certain things that come up that are much more important than other ones. I'm not saying that they should be ignored, but you you gotta have a way to prioritize them and to make somebody accountable. I think another hot take that I have here is like this idea, these matrix teams drive me nuts because you have all these people that work on like six different projects, and it's like, how can you have the the brain power and the bandwidth to execute, strategize, and keep on top of your work stream if you're doing six other things at the same time? It's it just like that always blows my mind, and it's such a like a generally accepted thing, not just in biotech, but in in in tech and in other industries as well, right? Multiple industries. And I I think that that's gotta be considered as as one of the factors that that play into people either not making decisions, making the wrong decisions, taking too long to make a decision, like all of these things come into play is thinking about the person on the other end who is ultimately accountable. What other things are you dealing with other than the task at hand, right? Is is uh something that needs to be talked about as well.

Decision Timelines And Escalation

SPEAKER_00 26:06

You know, it's uh I love that perspective on sort of the timing on decisions. If we can't make a decision within a certain amount of time, it has to automatically get escalated. Because you're right. I think we sit in this sort of limbo where it says we're supposed to surface these things to a committee or to leadership. And and just like any committee, they're gonna try to create a schedule. Why? Because typically there's leadership involved, and to do ad hoc committee meetings becomes very difficult. Calendars are very full. I have my own thoughts on that, but that's for another time. So I love the approach of you know, sort of like we have X amount of time to make decisions based on uh resources. So headcount, people, systems or or or technology, money, you know, and sort of that whole bucket, you know, and saying, okay, well, what can we decide on? How quick do we have to make these decisions? And then to that end, if we can't make the decisions, we need to escalate. I think part of what has grown in this culture is this um, and and and this is in all levels. This is not just small, this could be medium. This is also in, you know, we're seeing it in some large spaces where perhaps too many decisions are being made without considering other stakeholders or what the downstream impacts could be. But I find in those early days where you're bringing in, you know, there's every company has the best of the best, right? Except when it comes to decisions, I want everything to come up to me. Well, now you become the bottleneck. So why did we go slow? Because you wanted decisions to come to you. And I would be shocked to find the majority of people feeling that they get all the information they need to make a decision. And I think that gray area is a big area of discomfort for people. They don't want to make a decision that a leader will frown upon or come back on. But again, you have to understand what is the risk if you make the decision now? Well, the risk is that we run, you know, experiments for two weeks that they disagree with. Okay, that doesn't sound like the end of the world. What is the, you know, what happens if you make a bad decision here? Well, we might present something to a partner that they overwhelmingly disagree on and decide to shut down the project. Okay, that's probably something that demands some additional attention outside of just the group. So we have to always think about these decisions and where we feel the ambiguity and where we understand the line to be in terms of what we can decide in-house. And if you're having challenges, there should be an escalation path to say, hey, if we can't make the decision at the team meeting, and I have a one-on-one with my leads of that of that group, and we still can't make a decision, we have to agree that that's going to get escalated. Because then you need some third party, somebody in leadership. And it doesn't have to be going to a committee. There could be some other way to develop this level of governance because, like you said, you can't call time out on everything to get a decision or to get buy-in from everybody. Because the reality of it is number one, buy-in or weigh-in does not require everybody. Just a just a few, because no matter what, we are in a space that is going to make a lot of decisions that we will wish we had far more information to make that decision than we do. That is the nature of the work that we do. Otherwise, if you wanted to get all of the data you need to make all of the decisions you need, you're probably going to exceed that 10-year timeline to getting a drug to market by a lot.

SPEAKER_01 30:09

So Yeah, I think the um what you're getting at is the the value of perfect information versus the risk of actually making the decision itself, right? So, you know, the longer it takes you to find 100% of everything you need, the greater the risk is going to be for the project or whatever is involved. And I think you know the other thing that you're talking about, what I I'll I'll call them what they're supposed to be called. They're decision hoarders. And so they believe everything needs to come to them. But then when the decision comes to them, I think nobody really asks, like, are you actually the right person to make this call? Because like you don't know any of the technical, you know, background. Is the right person delivering?

SPEAKER_00 30:46

Is the right person delivering the question? Because you may get something that you know, somebody is so passionate about the science. Well, no, no, no, no, no, this and this. But you're looking at the data and it's like the data's telling me something different. My wallet is telling me something different that we shouldn't do this based on what the ROI is turning into, because now there are generics hitting the market. You know, these are things that like influence those decisions as well.

Risk, Imperfect Data, And Authority

SPEAKER_01 31:12

Right. So so the relationship between you the project manager and the project leads, you have to have some a high level of trust, right? So that if there are certain decisions that have to be made, give them the flexibility to make those decisions. But at the end of the day, look, yes, the project manager is accountable for the outcome of the project itself. But uh you there's gonna be risk involved. Like, yes, people will make wrong decisions, but at the same time, you you don't want to be the one holding up all the decisions because it's just not a sustainable model. And and having project leads own some of that, I think, empowers them to make better decisions too, so they take some of the risk on them as well, and and they're able to connect with the people that are involved in the work streams to figure out, okay, let's just get all the information here. Yes, we don't all agree on this, but I think this is the best path forward. Let's just go for it and then see what happens and then just report back to your project manager and really see how that method works versus, hey, I'm gonna send an email to so-and-so, and then I'm gonna set up another meeting with so-and-so, and then we're gonna have to wait for a few days for the PM to get back to us. And it's like we've been sitting on this for weeks. Like, what are we doing?

Matrix Teams And Split Focus

SPEAKER_00 32:23

You know, and and it's so quick to see how that timeline gets extended. I mean, we are in the middle of February. There were things that we were working on that I was working on personally back in December that have still not closed the loop two months later, you know, for things that probably have a low level of risk in totality. But we are right now, you know, you know, the there's a there's a saying that projects fail through decision ambiguity, not through incompetence. I mean, these are brilliant people, but being able to make decisions and make decisions on incomplete data, I think is a skill. And doing that with teams that have multiple layers of ownership and accountability within the team itself, within the cross-functional team, that that makes it a little bit more difficult. The this person's line manager says, this is your role on the team, and then you go into the team and go, Well, that's not really what everyone else thinks my role is supposed to be. You know, these are conversations that need to be rock solid and they need to have, you know, you're just like in in in in football, like you have to have trust that if we have the game plan, if we practice on what we're doing, if we're having the communication, we're not just talking about like what's the next thing to do. We're also reflecting on like, what didn't we do? You know what? It was really messy when we made that last decision to do X. Like, how do we get away from doing that next time? And trying to invite different opinions and different ideas, even from the people that are not leads. You don't have to make these decisions alone. That's not what we're saying here. We're saying that there needs to be better clarity, there needs to be better decisions on where the authority lies for what purpose, who can speak on the science, who speaks on the operations, and it's the responsibility of those leads to say, okay, how does this look, not just from my perspective, but how does this look from the expertise that I'm bringing, their expertise over there in the research, their expertise in the operations, and this person's expertise on the future market potential. Now, how do we make a decision? Let's give up our bias to, well, I want to do it this way because that is good project management. Well, I want to do this because, you know, I know this science like the back of my hand. Science doesn't care what you know, it's what you can show, it's how you can drive it, it's how you can execute it. Those are the things that are going to be successful. I mean, there's been plenty of successful going all the way through that haven't been the best, you know, medications or therapies, but because they were executed well, they had a consistent rhythm, communication, handoffs were clean, a process, right. I want to touch uh just briefly on the the the the multi-team. I forgot how you put it. It wasn't cross-functional, it was the um the matrix team. The matrix teams. And what we I think in theory, you want to, as a business, get value from the expertise that somebody holds. So you put them onto multiple programs to come in and to come out at different parts. It's kind of like having an assembly line. You know, these people are are putting the ingredients here, these people are mixing it up, these people are baking the pie, these people are getting the pie and cooling it, and these people are boxing it, and these people are driving the truck and shipping it off. They come in and they leave at whatever part of their project or that process that they're supposed to be doing. But when you're dealing with matrix teams and people that are on multiple teams, what you're now starting to do is instead of having somebody who's dedicating, you know, 80%, you know, even 50% if they had two, uh, two programs, you're now having them split between six programs. So now they're mentally they are 15% in on this project because I got all these other ones. And on these other ones, right now, I'm at a place where I have to write a plan for that one and a document for that one. This one, we're early on, so you're not even going to hear from me much. You know, we lose the value when we start to stretch where we're positioning people on our teams. And what's happening is that we're not taking into consideration what their priority is because of the work that they have to do that they're expected to be a part of, that they're responsible for or held accountable for. So we introduce people into teams early on that are on six other teams, and it seems like they could care less about what's happening because we're so early on when the value is that perspective. So we sort of shoot ourselves in the foot by saying instead of having this person really dedicated to these three programs, let's have them be a part of all these other ones and just be a sounding board, essentially being a sounding board. And what you find is do they get the same level of decision authority? Because they're not really in it. But they have this high level of expertise.

SPEAKER_01 37:42

Yeah, I think so. The the matrix team setup would work if the person was doing the exact same thing on the exact same type of project. But just because your role is this on a project does not mean you do the same thing on every project. I think that's pretty obvious for everybody, right? Is that yes, my title is this, but every time I go into this project, I find myself doing a it's not a large, I guess, deviation from what your typical roles and responsibilities are going to be, but it's that technically it might be that, but it's the interaction with all the different humans that you have to consider, right? It's like that takes a like you're interacting with a whole group of people, and to make decisions with them is not going to be the same if you take that and put it into another group because those individuals are all different, and those people are dealing with different constraints, pressures, whatever, right? Um, and and I think that's that's important to to note is no no individual is going to ever be doing the same exact thing on two projects. Like you it's even just just limited to two, is like your role is always going to be different. And and if it is, then good for you because I've you know been we've been in this industry for so long, and I haven't even seen seen that.

SPEAKER_00 38:58

No, not even. I mean, I'm very rare. I even see project managers that on this project, they're doing pretty much all of the administrative, all of the scheduling, all of the taking notes, keeping actions and decisions, keeping raid logs over here, because they have an external partnership, that group is going to be keeping their timeline, managing their timeline. And although we have a timeline, we're not doing the science, the collaborators doing the science. So now the work is a little bit different. But it in essence, what ends up happening is that when you see those things, it slowly you know pulls a little bit, it disconnects you a little bit. You know, if you can imagine, think about when I was growing up and I was uh you know playing baseball, I wasn't always, you know, it it took a while for me to get into my skill, whether it was um I was goofy, so I didn't, you know, run as fast or as you know controlled as other people, or I swung the bat at everything. But when I was not the person, I'll be the first to tell you, I was not the person for you to come and get me in the sixth inning to go and bat. Because I have probably not been paying attention for five innings. I mean, if you think about that, I mean, I was who knows, I was nine, ten, eleven. I've been sitting over there for an hour, an hour and 15 minutes, not doing much. And the coaches aren't gonna, you know, the coach, hey guys, pay attention. What does that do for me? So the less I was involved, the less likely I was to be ready to take things over when it was my turn. You know, so that's something, and I think that's just inherently like it's it's out of sight, out of mind, you know. I'm not actively in there, I don't know the players batting. I haven't been running around, my legs are getting cold, and now I have to go in there, swing the bat, and be ready to run. Well, okay, we'll see how that goes. And then obviously, as as my skill got better and I was playing all the time, it's a different perspective because I am needed at each part throughout the game for the entire two hours. I am in the defense, I'm in the offense, I'm you know, warming up somebody because they need to go into pitch and we're switching positions and blah, blah, blah. You know, part of the strategy. And so I think, you know, it can be a little challenging at times when these, you know, cross-functional teams also cross uh sort of responsibilities, you know, from one project to the next. Well, here now I don't have to do anything. So how do I stay engaged in the project where now I'm not doing any of the tangible stuff? Because that's right, that's what we think that work is down to. It's just to writing down on the paper. I need to take notes, I need to do this. But there's also a part of the work that involves digesting and synthesizing what in the world is going on beyond just the well, we're doing this and this and this. That's just listing out the tasks that are happening. Get higher than that. What is the whole purpose of the program that you're doing? Is there something that you guys are about to do that is going against what your goal is at the end of the day? What's the value there? Are you trying to find the negative? You know, are you trying to test against the null hypothesis or whatever? And I think so, so yeah, I think there's uh there's a little bit of uh self-preservation probably when you're going in these matrix teams and you don't have the brain capacity to do this, that, or the other because you have so many things that are just barking at you over here. And this one's more important because leadership is looking at it. Like this is where this is my first project. So this is my priority. I have priority here, but I have four people that are on other programs that leadership is most you know looking at with a fine microscope. So how do I get them to be on board with me when that's not this is not their priority?

Roles Shift Across Projects

SPEAKER_01 43:14

How do I I think what you're getting to is is is the perspective, right? From both the I think from a project manager level, understanding the the different individuals that are part of your team and kind of like what they're going through. And is it their first project? Is it their tenth project? Are they very experienced? Are they not experienced? And then at a you know, from from that point of view, you really have to demonstrate, like you said, right? When you were maybe let's say you were inexperienced, this is your first project, and let's compare that to when you were on a baseball team when you were younger. You're most likely an individual contributor. You're you're kind of essentially learning the ropes and trying to still build your view of how the company is working. I think when you're at a project lead or work stream lead level, you're being asked to demonstrate more of a leadership role, right? Where you're trying to build that trust among other people that are going to be putting together deliverables and executing. And then even higher above that is the project manager, right? So getting to understand the different project leads and how their relationships are with their different uh work streams is going to be important. And they that's that's a huge burden for a project manager to carry. But it's also, I think, one of the places where you can have the most impact in improving how projects go cross-functionally, right? Because they have the full expansive view of all these different work streams, who's struggling, who's not, who's talking, who's who's being silent, you know, what decisions are being made, what decisions are not being made. And it's it's really one of those like thankless jobs where like you get into this role and there's so many um intangibles that they're doing that are outside of just the tangible, like tracking metrics and like putting this stupid PowerPoint that like that's right.

Staying Engaged When Work Varies

SPEAKER_00 45:01

That's right. That was one of the first mentions that that I got when I transitioned from the lab into program management. My title was a program planning manager. They essentially wanted me to help them figure out how to plan these large-scale clinical trials. And there were project managers across the board, but doing it sort of together as succinctly as possible and as repeatable as possible. And one of the first comments that actually the founder said to me was Congratulations, you are now joining some something to the level of congratulations, you're now joining the ranks of one of the most thankless jobs in the industry. And it was a pivot because in the lab, you do experiments, you process the data, you show the data. Now here's the next experiment. Boom, and do it again and cycle again, all in context of. Whatever goals you have. But when it came to managing the projects, it was and being a program manager that had project managers. I was sort of this eagle eye on top to sort of create the perspective of like this is where everybody, this is where all the programs are different. This is where we can be the same. These are where we're challenging, you know, we're having challenges. And it's important because you want to be able to develop a portfolio of continuity where you can exchange somebody from one project to the next to either manage or to be a part of it and not have this super long onboarding because this project looks so much different than the other ones. It operates so much different than the other ones. But that can only be done when we take the time to really define who can make those decisions, what activities should we be concerned about? What is leadership looking for at these various stages? And if they are not clear, we have to hold their feet to the fire to get the clarity. Because what ends up happening is similar to what you find in any sort of software development. Oh, that's great. And can we add this? And can I have this? And you guys know this? And you guys, let's have that conversation from the beginning so that when we get to the end, we can deliver what is actually gonna enable the decisions to be made. You know, so what we've been talking about here, and and we can sort of start to wrap these things up, we've identified a number of uh sort of threats and and operational risk in cross-functional project execution, you know, at its core. You know, I would really put out there to the listeners, if you guys are on projects, if you guys are about to start a project, or if you're in the process of closing up, closing out a project, think about how healthy did you feel that execution. Not when you started, not right now, when you're finishing, the entire space in between. Because we focus a lot on let's have a good start, let's have a good finish. But the way that you're gonna win any race is gonna be in the middle. These are blips in time, and the middle is really how you can maintain your endurance, how you can maintain the consistency, and how you can maintain the energy of the team. With regards to cross-functional health, we're identifying things that are risk factors, and sometimes they're hard to see because we're only seeing the symptoms. But we are talking about delays and execution risks that trace back to a number of gaps, and those can be ownership gaps, decision, issue resolution pathways that are not clear, uh, the scope or your readiness to launch. We didn't talk about the beginning, but if you start off, you know, you ever had a morning where you just nothing was working out and it sort of created this stormy cloud over your head, and the rest of the day just kind of turned to crap, you know? So those things can be said also be true to projects. If you start with ambiguity, it's gonna continue. If you start with unclear expectations, unclear roles on this program, on this project, you know, it's gonna create more friction. You're just adding sand into the gears of your system that is your organization. Um, we're talking about communication, rhythm, and transparency. It is ever so critical for these leaders, for these team leaders that are part of these projects to maintain a level of transparency and communication. You know, there's no malice towards your direction, your strategy. You have a perspective. Tell me about it. I'm gonna tell you about my perspective. Let's work on absorbing each other's perspectives and find out okay, well, what is the best approach to this decision? And if we can't make a decision, or if we're at a stalemate, we should have an escalation pathway that doesn't take a three-week meeting to set up. That we can come have a 30-minute conversation. Here's how I feel, here's how they feel, here's the information we have to make this decision, and here's the risk or the value associated with making that decision. And then the handoffs and wrapping up. You know, we are doing projects that involve a lot of different hands and a lot of different people. And, you know, one of the things I learned about parenting is you will get a lot of feedback. If I could recommend something, if I we're having our third child now, and we will still get, hey, have you tried this? Hey, have you tried that? Don't be defensive. Let it come in. You can do whatever you want. But when you are the one that's in the project in the thick of it, you work with your team. My team is my wife, my team is my two younger kids, my team is our circle of families that help us, you know, babysit here and there. But that only works because we're communicating, because we understand our role, because we're making decisions together, because we're understanding and aligning what this looks like. Launch readiness. We're doing that now. We're getting ready. Hey, when we have to go to the hospital, the kids go here, we have overnight bags to go there. Then we're going to do X, Y, Z. Like all of this is a project, too. So, you know, there's so many areas that we gloss over because we just we start to point at people and say they don't know their job, they don't know their role. They don't. Unfortunately, the majority of people probably don't because it hasn't been written out, it hasn't been discussed. And that's what we're talking about. And that's, you know, we're we're fortunate that we have been spending our, you know, the the most recent part of our professional careers examining and understanding more about what it means to run good projects, have good data, have good governance, finding, you know, understanding more about facilities and manufacturing and how these pieces together work like a system. You know, I think it's it's important for us to recognize and understand what these things mean beyond symptoms of, well, we didn't get that document in time. Well, we didn't have the right vendor. Those are the symptoms that usually trace back to one of these five operational risk areas related to cross-functional project health and execution that we talked about today.

SPEAKER_01 52:33

Yeah. And then the the final thing I'll add is, you know, to your point about people. I think what's helped me and and probably you as well is this mindset shift of, you know, people aren't perfect. You know, we're not perfect. You're gonna make a bad decision, you're you're not gonna know something, it's impossible for somebody to know everything. And I think if you approach projects in in that sort of mindset and being open to communicating those things, I think people will reciprocate. And and you know, that flow of not just communication, but the the project has a change in feel to it as well. I feel like when teams are more open about those things, I think they they tend to talk more casually and it's a much lighter atmosphere. And yes, there's something very important that we have to do together, but it doesn't mean I personally attack you for like doing something wrong or missing a deadline. It's it's like focus on the problem, not the person, I think is what I'm trying to say.

SPEAKER_00 53:26

That's absolutely right. And I love that. You really do create when you execute and not just in the beginning throughout the entire project, and you have and you're addressing these areas that can become operational risk at your organization, you start to generate and develop a culture within that project of, you know, we are open with the things that are challenging us. We are, and and what does that mean? That means when you have something coming up, you don't just say, yeah, yeah, yeah. I'll take care of it. And it's something that's way in the back of your mind that you're you're stressed about, that you know, you can say, Hey, I have a lot of um, you know, deliverables here. I'm hearing this, I can't start on it until next week. I'd love to sit with you and tell you what I'm thinking so that when I do start it, we don't have any speed bumps. These are sort of that proactive thinking that when you're involved in a project team and you've really established that team feeling, you should be able to have these kind of candid conversations. And like you said, get it back to feeling like you're talking to colleagues and not like you're directing soldiers that can only act or respond to certain things. Everybody should be heard, everybody should be uh uh feel open to discuss and to say the things that they're concerned about. Um and those things should be taken seriously because, like you said, we're not all perfect and we're all trying to make things successful. If you're trying to crash things, this is not the company to do that. This or this is not the business to be doing that. You should be, I don't know, do demolition derby or something. That's where you can actually crash stuff.

SPEAKER_01 55:02

Go kick rock somewhere else.

SPEAKER_00 55:03

Yeah, exactly. Exactly. So yeah, thanks, you know, cross-functional project execution. So, how are we connecting with multiple disciplines, multiple technical expertise and management expertise and executing the projects? And what do those risks actually look like at its foundation? Not the symptoms, the actual operational risk. Thank you for spending your time with us today. Long day. Truly appreciate. Yeah, there we go. We truly appreciate you being part of the Lean by Design community. If this conversation resonated with you, we invite you to check out our new book, predictably broken, that launches February 25th. Launches in two weeks. The book launches. Pre-sale is now available, and we unpack these patterns of operational friction that quietly slow teams down and what to do about it. And if you're ready to take the next step, explore our operational risk assessments. We have everything that we've talked about today is captured in our cross-functional project execution assessment. These are hybrid engagements where you're going to actually work directly with Lawrence and I to identify, prioritize, and clearly, clearly communicate the friction points in your organizations so that you can move forward with confidence and alignment. So don't forget to follow us on Instagram at psyguy underscore insights at PsyGuyInsights with the underscore in between. And if you can, and you can now watch the podcast on YouTube at Lean by Design Podcast. All the links are in the show notes. We'll see you next time. Thanks, Lawrence.

SPEAKER_01 56:45

Bye.