Episode Transcript
[00:00:03] Speaker A: Hello, I'm Joseph Kasser, and welcome to this podcast where the AI team does a deep dive into some application of systems thinking.
[00:00:13] Speaker B: Welcome back, everybody, to the deep Dive. This time we're going to be tackling stakeholder engineering.
And I know, I know a lot of you out there, you're interested in how to, like, better identify and manage stakeholders. Stakeholders for sure. For your projects, for your systems. And we're using Tom Guild's research paper.
[00:00:33] Speaker A: Okay.
[00:00:33] Speaker B: It's. It's the same name as the episode Stakeholder Engineering. I gotta say, this is a dense one. This guy. Really. He goes deep.
[00:00:41] Speaker A: He does.
[00:00:42] Speaker B: But we're gonna pull out the most valuable stuff for you.
[00:00:44] Speaker A: Yeah, definitely. Challenges how. How we think about projects. Kind of the conventional wisdom.
[00:00:48] Speaker B: Right. Like, are you ready for this?
[00:00:49] Speaker A: Okay.
[00:00:50] Speaker B: Understanding stakeholder needs is sometimes more important than how the system is designed or operates.
[00:00:55] Speaker A: Hmm. It really changes how you think about it. Right?
[00:00:59] Speaker B: I know. It's like, wow.
[00:01:00] Speaker A: Yeah.
[00:01:00] Speaker B: Okay, so it's not enough to just build, like, a technically sound system.
[00:01:04] Speaker A: Right, Right. You have to consider the whole ecosystem.
[00:01:06] Speaker B: Right.
[00:01:07] Speaker A: All the people and even the things that are going to be impacted.
[00:01:10] Speaker B: Impacted by it.
[00:01:11] Speaker A: Wow. Yeah. It's like you almost need a special tool to be able to see all of that.
[00:01:15] Speaker B: Right. To see the landscape. Yeah. And he calls that tool.
[00:01:18] Speaker A: He does.
[00:01:19] Speaker B: He calls it the technoscope. Right, yeah.
[00:01:20] Speaker A: Interesting.
[00:01:22] Speaker B: So let's just start by defining stakeholder engineering.
[00:01:25] Speaker A: Okay.
[00:01:26] Speaker B: What is it? Well, the paper says a stakeholder is anyone or anything affected by a system or a project. So we're talking customers, employees, government regulations. Even the environment.
[00:01:41] Speaker A: Even the environment. Wow.
[00:01:42] Speaker B: Right.
[00:01:43] Speaker A: Yeah. So engineering in this case is applying a structured approach, you know, analytical, to identifying and analyzing and then actually managing all those stakeholders and their needs. Their needs, which a lot of times they don't even realize they have them.
[00:01:58] Speaker B: Yeah.
[00:01:59] Speaker A: Throughout. Throughout the entire life of a project.
[00:02:01] Speaker B: Okay, so I'm already seeing the challenge here.
[00:02:03] Speaker A: Yeah.
[00:02:03] Speaker B: He uses this phrase, eternal watch.
[00:02:06] Speaker A: Eternal watch.
[00:02:07] Speaker B: Hmm. Stakeholders, what they need. It's constantly changing.
[00:02:11] Speaker A: It's constantly changing. You can never stop paying attention.
[00:02:14] Speaker B: Never?
[00:02:14] Speaker A: Never.
[00:02:15] Speaker B: It's like a landscape that's just constantly shifting.
[00:02:17] Speaker A: Exactly. Yeah. Like a stakeholder who you think is minor now could suddenly become critical because of a change in the market or a regulation that nobody even knew about.
[00:02:30] Speaker B: Oh, gosh. Yeah.
[00:02:31] Speaker A: Could totally change the project.
[00:02:33] Speaker B: Throw a wrench in it.
[00:02:34] Speaker A: Yeah, yeah, totally. Those butterfly effects. The paper talks about.
[00:02:37] Speaker B: Butterfly effects. Right. And then there's this other concept, Subtle power.
[00:02:42] Speaker A: Subtle power, huh?
[00:02:43] Speaker B: Yeah. It's kind of unsettling when you think about it.
[00:02:46] Speaker A: Yeah.
[00:02:47] Speaker B: It really highlights how you can miss Crucial Power Dynamics. Right?
[00:02:51] Speaker A: It does. Yeah. Let's say you're building. You're building a new software platform, and you think you've got all the stakeholders.
[00:02:56] Speaker B: You got them all.
[00:02:57] Speaker A: Executives, the developers, the users. Yeah, but what if there's a junior CAB member who has, like, some really deep knowledge in a specific area, okay. That turns out to be essential to the success of the project. If you don't pay attention to their needs, you know, address their concerns, they can become a roadblock.
[00:03:18] Speaker B: Totally. Totally. So how do you start to even uncover these hidden needs? You can't just ask people, hey, what are your secret needs?
[00:03:27] Speaker A: Right. That's where the requirement solicitation comes in.
[00:03:29] Speaker B: Requirement solicitation?
[00:03:30] Speaker A: Yeah. It's not just about what people say they want, okay? It's about digging deep, figuring out their motivations, their fears, sometimes their assumptions, things they don't even say.
[00:03:39] Speaker B: Okay, but that sounds like a lot of guesswork. How do you do that? Systematically.
[00:03:44] Speaker A: Systematically, right.
[00:03:45] Speaker B: Yeah. The research paper mentioned something called planalysis.
[00:03:49] Speaker A: Planalysis. Okay.
[00:03:50] Speaker B: I don't even know how to pronounce that.
[00:03:51] Speaker A: Yeah, it stands for problem language analysis.
[00:03:53] Speaker B: Okay.
[00:03:53] Speaker A: Which is a fancy way of saying you got to pay attention to the words people use.
Think about it like this. You're planning a vacation, right?
[00:04:02] Speaker B: Okay.
[00:04:02] Speaker A: Family vacation.
And somebody says, I just want a relaxing trip. Well, what does relaxing even mean?
[00:04:11] Speaker B: Right. To one person it could be.
[00:04:12] Speaker A: To one person, it could be laying on a beach.
[00:04:14] Speaker B: To another, it's. Yeah. Exploring a city.
[00:04:17] Speaker A: Exactly.
[00:04:18] Speaker B: Yeah.
[00:04:18] Speaker A: Planalysis helps you see those ambiguities, okay. And figure out what people mean, even if they can't say it, even if.
[00:04:26] Speaker B: They can't articulate it. You know, that reminds me of those 12 tough questions in the paper. 12 tough questions that are designed to kind of get people thinking about what they need more deeply.
[00:04:36] Speaker A: Yeah. They're powerful tools.
[00:04:38] Speaker B: Yeah.
[00:04:38] Speaker A: For example, one of the questions is, why isn't this improvement quantified?
It forces people to be specific, okay. Instead of just saying, like, I want the system to be faster, they have to say, I want it to process transactions 20% faster.
[00:04:54] Speaker B: So you're going from vague wishes to.
[00:04:56] Speaker A: Vague wishes, immeasurable goals. Yeah. This is making sense.
[00:04:59] Speaker B: Yeah.
[00:05:00] Speaker A: Okay, but what if you've got, like, a ton of stakeholders?
[00:05:03] Speaker B: Okay?
[00:05:04] Speaker A: You all have different needs, Right. Sometimes they're conflicting.
[00:05:07] Speaker B: You can't make everyone happy.
[00:05:09] Speaker A: You can't make everybody happy. That's true.
[00:05:11] Speaker B: Can you?
[00:05:11] Speaker A: And that's why Prioritization is so important.
[00:05:14] Speaker B: Okay.
[00:05:14] Speaker A: You have to figure out which needs are most important.
[00:05:17] Speaker B: Yeah.
[00:05:18] Speaker A: What requirements are non negotiable and where you might have some flexibility.
[00:05:24] Speaker B: Okay. And the paper gives you a tool for this?
[00:05:27] Speaker A: It does.
[00:05:28] Speaker B: Called an impact estimation table.
[00:05:30] Speaker A: Impact estimation table, huh?
[00:05:32] Speaker B: It's a way to map out visually all your stakeholders, all their requirements and rank them based on things like how much power they have, how much value they bring to the project, how much.
[00:05:45] Speaker A: It will cost to keep them happy.
[00:05:47] Speaker B: To satisfy their needs.
[00:05:49] Speaker A: Yeah.
[00:05:49] Speaker B: I love that there's a visual component.
[00:05:51] Speaker A: Visuals are great.
[00:05:53] Speaker B: Okay. So we've identified them, we've analyzed their needs, we've prioritized them based on impact.
[00:06:01] Speaker A: Right.
[00:06:01] Speaker B: What are some practical strategies for actually managing them?
[00:06:04] Speaker A: Managing them. Okay.
[00:06:05] Speaker B: Throughout the project.
[00:06:06] Speaker A: Throughout the project. Well, communication is key.
[00:06:09] Speaker B: Communication.
[00:06:09] Speaker A: Yeah. You need a plan for how you're going to keep people informed.
[00:06:13] Speaker B: Yeah.
[00:06:14] Speaker A: Involve them in decision making, address their concerns. That might be meetings, email, updates, even using. Using tools like stakeholder tracker.
[00:06:24] Speaker B: Stakeholder track, what is that? Is that like a CRM but for stakeholders?
[00:06:28] Speaker A: Kinda, yeah. It helps you track all the info, document communication and manage all the interactions.
[00:06:35] Speaker B: So it's making sure you're not overlooking.
[00:06:37] Speaker A: And not overlooking anybody, not letting anything flip through the cracks.
[00:06:40] Speaker B: I can see how that would be valuable.
[00:06:41] Speaker A: It can be.
[00:06:42] Speaker B: So it's not just about gathering information, it's using it to.
[00:06:45] Speaker A: You actively manage those relationships.
[00:06:47] Speaker B: Yeah.
[00:06:48] Speaker A: Everyone feels heard and valued.
[00:06:51] Speaker B: Heard and valued. Yeah. And building those relationships is always crucial for long term success. Okay, so we're gonna keep digging into stakeholder engineering. We're gonna be right back after a quick break.
This is really fascinating. I mean it sounds like stakeholder engineering is more about people than technology sometimes.
[00:07:12] Speaker A: Yeah, definitely. It's. It's really about understanding that human element. Right. And the source material actually calls out some key principles for this whole approach. One that really stood out to me was the emphasis on digitization.
[00:07:26] Speaker B: Digitization, okay.
[00:07:27] Speaker A: Yeah. It's really crucial, I think, for managing complexity like documenting everything in a digital format. Everything about your stakeholders, their information, their requirements, all the interactions you've had, makes the whole process more transparent. Right. And it gives you a clear audit trail.
[00:07:45] Speaker B: Like a record of everything.
[00:07:46] Speaker A: Exactly.
[00:07:47] Speaker B: And you can actually analyze that data, can't you?
[00:07:49] Speaker A: You can, yeah. Over time you could see how needs are evolving.
[00:07:52] Speaker B: Yeah.
[00:07:53] Speaker A: Or you can spot patterns you might have missed. Yeah. And that kind of ties into another principle which is clear definition.
[00:08:00] Speaker B: Clear definition.
[00:08:01] Speaker A: Every stakeholder needs to be uniquely identified so there's no confusion.
[00:08:05] Speaker B: So if You've got two stakeholders named John Smith.
[00:08:08] Speaker A: Yeah, exactly.
[00:08:09] Speaker B: You need a way to tell them apart.
[00:08:10] Speaker A: You got to tell them apart. So you could use tags, you could use unique IDs, whatever works for your system.
[00:08:14] Speaker B: Okay.
[00:08:15] Speaker A: Right. And then you got to link those clearly defined stakeholders to their specific requirements.
The paper calls this principle tracking stakes held.
[00:08:28] Speaker B: Tracking stakes held, yeah. So you're making like a map.
[00:08:31] Speaker A: Kind of. Yeah.
[00:08:32] Speaker B: That shows who wants what.
[00:08:34] Speaker A: Exactly. Makes it much easier to track progress, to identify potential conflicts. Make sure that, you know, nobody's needs are getting overlooked.
[00:08:42] Speaker B: Yeah.
[00:08:42] Speaker A: And it's not just about individual stakeholders either. You need to understand the relationships between them too.
[00:08:47] Speaker B: Between stakeholders?
[00:08:48] Speaker A: Yeah. The paper calls this tracking related stakeholders.
[00:08:52] Speaker B: Tracking related stakeholders. Because sometimes those relationships, that's where the subtle power comes in.
[00:08:58] Speaker A: That's exactly where it comes in.
[00:08:59] Speaker B: Right.
[00:09:00] Speaker A: Think about it like a family.
[00:09:02] Speaker B: Okay.
[00:09:02] Speaker A: You might have a parent who's like the official decision maker.
[00:09:06] Speaker B: Yeah.
[00:09:06] Speaker A: But a child could have a lot of influence over that decision behind the scenes. Behind the scenes, exactly. Even if it's not obvious at first.
[00:09:14] Speaker B: This is really helpful. But I'm curious, we've talked a lot about analyzing stakeholders.
[00:09:19] Speaker A: Right.
[00:09:20] Speaker B: How does this actually inform the design and the development of the system itself?
[00:09:24] Speaker A: Well, you know, remember that key idea we started with, Understanding stakeholder needs is paramount.
[00:09:30] Speaker B: Yeah.
[00:09:30] Speaker A: So everything you learn through stakeholder engineering should feed directly into how the system is designed, how it's built.
[00:09:38] Speaker B: But it's not just about passively responding to what they say they want.
[00:09:43] Speaker A: No, it's much more iterative and proactive. You're constantly engaging stakeholders, you know, getting feedback, making adjustments along the way.
[00:09:51] Speaker B: Okay.
[00:09:52] Speaker A: The paper calls this incremental feedback.
[00:09:54] Speaker B: Incremental feedback. That reminds me of how software is developed these days.
[00:09:58] Speaker A: How so?
[00:09:59] Speaker B: You release a beta version, you get feedback, you make improvements, release another version.
[00:10:04] Speaker A: It's a great analogy. Yeah. And just like with software development, stakeholder analysis should be continuous.
[00:10:11] Speaker B: It's not a.
[00:10:12] Speaker A: It's not a one time thing.
[00:10:13] Speaker B: One and done at the beginning.
[00:10:15] Speaker A: Right. Because things are always changing, always changing. New stakeholders might emerge, priorities might shift, regulations could change.
[00:10:22] Speaker B: Oh, gosh.
[00:10:23] Speaker A: You gotta constantly be monitoring the landscape. Wow. And adapting your approach.
[00:10:28] Speaker B: Okay. All this makes sense conceptually. But do you have any like real world examples, Real world examples of how this actually works?
[00:10:33] Speaker A: Oh, yeah, definitely. Practice.
[00:10:35] Speaker B: Yeah. The research paper actually mentions a case study. Okay. Involving the McDonnell Douglas Aircraft Company. McDonnell Douglas back in the late 1980s. They were having huge problems with errors in their engineering drawings.
[00:10:49] Speaker A: Oh, no.
[00:10:50] Speaker B: And it was causing delays, costing them A lot of money.
[00:10:54] Speaker A: So a need for improvement.
[00:10:55] Speaker B: A big need for improvement.
[00:10:57] Speaker A: Yeah. And they brought in Tom Gilb, the author of this paper.
[00:11:01] Speaker B: Okay.
[00:11:01] Speaker A: As a consultant. And he used, you know, these principles of stakeholder engineering to really get to the root of the problem.
[00:11:09] Speaker B: So he started by identifying.
[00:11:11] Speaker A: Identifying the key stakeholders.
[00:11:12] Speaker B: Okay.
[00:11:13] Speaker A: Yeah. He talked to the engineers, the designers, the managers, even the people on the shop floor, you know, actually using the drawings.
[00:11:20] Speaker B: Wow.
[00:11:21] Speaker A: And he used his techniques like planalysis to uncover all those hidden assumptions and really clarify what people needed from the drawings.
[00:11:30] Speaker B: And what happened. Did it work?
[00:11:32] Speaker A: It did. Within a few months, they saw a dramatic reduction in errors.
[00:11:37] Speaker B: Wow.
[00:11:38] Speaker A: Which led to increased productivity, significant cost savings.
[00:11:41] Speaker B: That's pretty powerful.
[00:11:42] Speaker A: It is, yeah.
[00:11:43] Speaker B: Are there any other real world cases?
[00:11:45] Speaker A: Oh, tons.
[00:11:46] Speaker B: That demonstrate this.
[00:11:47] Speaker A: Yeah. The paper highlights one involving a large transportation system being built offshore.
[00:11:52] Speaker B: Offshore, okay.
[00:11:53] Speaker A: Yeah. And there was a big disconnect between what the customer expected and what the supplier was delivering. And it was. Oh, it was causing chaos. Delays, cost overruns.
[00:12:05] Speaker B: Nightmare.
[00:12:05] Speaker A: Total nightmare. And it all stemmed from a failure to really understand and manage those stakeholder needs from the beginning.
[00:12:15] Speaker B: So how did they use stakeholder engineering to get things back on track?
[00:12:19] Speaker A: Well, first they had to rebuild trust between the customer and supplier.
[00:12:22] Speaker B: Oh, yeah.
[00:12:23] Speaker A: Which. Which was no easy feat. Right, right. And then they really focused on clarifying the customer's requirements using tools like planalysis impact estimation tables to really get a clear picture of what they wanted, what they needed.
[00:12:38] Speaker B: And did this involve a lot of, like, communication?
[00:12:40] Speaker A: Oh, yeah. Back and forth, tons of it. They established clear communication channels, set up regular feedback loops, made sure everybody was on the same page.
[00:12:48] Speaker B: So it was a combo of fixing the communication breakdown and getting really specific about those requirements.
[00:12:53] Speaker A: Exactly. And it worked.
[00:12:54] Speaker B: It worked. It wasn't a quick fix.
[00:12:56] Speaker A: Right.
[00:12:56] Speaker B: But they were eventually able to deliver a system that met the customer's needs.
[00:13:01] Speaker A: That's encouraging.
[00:13:02] Speaker B: It is, yeah. These are pretty big, complex projects. Do you think these principles can be.
[00:13:07] Speaker A: Applied to, like, more everyday things?
[00:13:10] Speaker B: Everyday situations? Like if I'm planning a family vacation.
[00:13:13] Speaker A: Sure.
[00:13:13] Speaker B: Or if my community group is trying to organize an event.
[00:13:16] Speaker A: Absolutely. The fundamental principles are the same. Right. Identify your stakeholders, understand their needs, communicate effectively, and manage those expectations.
[00:13:26] Speaker B: So even though it's called stakeholder engineering.
[00:13:28] Speaker A: Yeah.
[00:13:28] Speaker B: It's not just for engineers.
[00:13:30] Speaker A: Not at all. It's. It's a way of thinking.
[00:13:32] Speaker B: Okay.
[00:13:33] Speaker A: That can be applied to any situation where you're trying to achieve a goal and there's multiple people involved.
[00:13:40] Speaker B: Okay. You know, one thing that struck Me?
[00:13:41] Speaker A: Yeah.
[00:13:42] Speaker B: In the source material was this emphasis on using templates and patterns.
[00:13:47] Speaker A: Ah.
[00:13:48] Speaker B: Can you explain why those are so important?
[00:13:50] Speaker A: Sure. Think of it this way. Templates and patterns, they provide a kind of blueprint or checklist. They help you make sure you're capturing all the essential information about your stakeholders, analyzing it consistently, and addressing those common challenges in a structured way.
[00:14:07] Speaker B: So it's like having a guide.
[00:14:09] Speaker A: It is, yeah.
[00:14:09] Speaker B: To help you navigate this whole stakeholder engineering process.
[00:14:14] Speaker A: Exactly. And the research paper actually provides some examples of templates you can use, like a stakeholder description template to capture basic info, a stakeholder requirements template to document their specific needs, and even templates for defining and measuring values like usability or security.
So they're very helpful.
[00:14:33] Speaker B: Especially if you're new to all this.
[00:14:34] Speaker A: Especially if you're new to it. Yeah.
[00:14:35] Speaker B: Take some of the guesswork out.
[00:14:37] Speaker A: Takes the guesswork out. Yeah. And patterns in a more general sense are like reusable solutions to common problems.
[00:14:44] Speaker B: Oh, okay.
[00:14:45] Speaker A: So if you run into a particular challenge, like a stakeholder who's not engaging, you can look to these patterns for guidance on how other people have handled those situations.
[00:14:54] Speaker B: So it's like a library.
[00:14:56] Speaker A: It is, yeah.
[00:14:56] Speaker B: Of best practices.
[00:14:57] Speaker A: Exactly.
[00:14:58] Speaker B: Are there any patterns that you found particularly valuable?
[00:15:01] Speaker A: One that comes up a lot is the stakeholder coach pattern.
[00:15:05] Speaker B: Stakeholder coach. Okay.
[00:15:06] Speaker A: It's based on the idea that stakeholders often need help articulating their needs.
[00:15:11] Speaker B: Okay.
[00:15:12] Speaker A: And understanding how the whole process works.
[00:15:14] Speaker B: So the stakeholder coach is like a guide?
[00:15:17] Speaker A: A guide. A facilitator. Yeah.
[00:15:18] Speaker B: Okay.
[00:15:18] Speaker A: They help stakeholders understand the process, make their voices heard, and make sure their needs are taken into account.
[00:15:24] Speaker B: Like having someone in their corner.
[00:15:26] Speaker A: Exactly.
[00:15:26] Speaker B: Okay.
[00:15:27] Speaker A: Another common one is the guidebook pattern.
[00:15:29] Speaker B: Guidebook pattern?
[00:15:30] Speaker A: Yeah. It's basically a collection of clear, concise information about the project or system.
[00:15:36] Speaker B: What kind of information?
[00:15:37] Speaker A: Oh, it could be things like project goals, timelines, key stakeholders, communication channels, decision making processes, anything that stakeholders need to know to understand what's going on.
[00:15:49] Speaker B: So it's like a one stop shop.
[00:15:50] Speaker A: One stop shop for stakeholders.
[00:15:53] Speaker B: And having that readily available can reduce confusion. You know, increase transparency, empower stakeholders to be more active.
[00:16:01] Speaker A: Yeah. It creates that sense of shared ownership and responsibility.
[00:16:04] Speaker B: Shared ownership, yeah.
[00:16:06] Speaker A: Yeah.
[00:16:06] Speaker B: Any other patterns you found particularly useful?
[00:16:09] Speaker A: Another one that's often helpful is the early warning system pattern.
[00:16:13] Speaker B: Early warning system.
[00:16:14] Speaker A: Okay. Yeah. It's all about identifying potential problems or risks.
[00:16:18] Speaker B: Okay.
[00:16:19] Speaker A: As early as possible. Right. Early on, so you can take action before they become major issues.
[00:16:24] Speaker B: So you're setting up mechanisms to monitor Stakeholder sentiment.
[00:16:28] Speaker A: Exactly.
[00:16:29] Speaker B: Track progress.
[00:16:29] Speaker A: Yep.
[00:16:30] Speaker B: Identify any. Any red flags.
[00:16:32] Speaker A: Any red flags? Yeah.
[00:16:33] Speaker B: Okay.
[00:16:34] Speaker A: That might be regular surveys, feedback sessions, or even just paying close attention to the tone and content of communication.
[00:16:42] Speaker B: Like having a radar system. Like a radar system for potential storms.
[00:16:45] Speaker A: Exactly.
[00:16:46] Speaker B: Like that analogy.
[00:16:47] Speaker A: It allows you to be proactive rather than reactive.
[00:16:49] Speaker B: Yeah. That can make a huge difference.
[00:16:51] Speaker A: Huge difference.
[00:16:52] Speaker B: Okay, so we've talked about templates. Templates, patterns.
[00:16:56] Speaker A: Any other key takeaways from this deep dive into stakeholder engineering that we should highlight?
I think it's important to remember that stakeholder management isn't free.
[00:17:06] Speaker B: Oh, that's a good point.
[00:17:07] Speaker A: It's easy to, you know, focus on all the benefits.
[00:17:10] Speaker B: Yeah.
[00:17:10] Speaker A: But we need to be realistic about the costs, too.
[00:17:12] Speaker B: Yeah.
[00:17:13] Speaker A: You know, the time, the effort, the resources it takes to do this effectively.
[00:17:16] Speaker B: So we have to think about the roi.
[00:17:19] Speaker A: Yeah.
[00:17:20] Speaker B: The return on investment of our stakeholder engagement effort.
[00:17:23] Speaker A: Yeah. We need to make sure that those benefits outweigh the costs.
[00:17:26] Speaker B: Right.
[00:17:27] Speaker A: And sometimes that might mean making some.
[00:17:29] Speaker B: Tough choices about who to engage with.
[00:17:31] Speaker A: Yeah. Who to engage with, how much time and resources to invest in each relationship.
[00:17:37] Speaker B: Makes sense.
[00:17:38] Speaker A: Yeah.
[00:17:39] Speaker B: Any other key takeaways?
[00:17:41] Speaker A: I think the most important takeaway is that stakeholder engineering isn't a one size fits all approach.
[00:17:47] Speaker B: Right.
[00:17:47] Speaker A: It's. It's a mindset, a way of thinking about projects and systems that emphasizes understanding and managing that human element.
[00:17:56] Speaker B: So it's about being flexible.
[00:17:58] Speaker A: Flexible.
[00:17:59] Speaker B: Experimenting with the different techniques.
[00:18:00] Speaker A: Right.
[00:18:01] Speaker B: And adapting your approach based on what works best.
[00:18:05] Speaker A: Based on what works best in that situation.
[00:18:07] Speaker B: In that situation. And. And constantly seeking feedback. Right.
[00:18:11] Speaker A: Constantly seeking feedback. Constantly learning from your experiences and refining your approach over time.
[00:18:16] Speaker B: So it's not a recipe. Right. It's more like a philosophy.
[00:18:21] Speaker A: Yeah, it is. Yeah.
[00:18:22] Speaker B: Okay.
[00:18:22] Speaker A: Yeah. A way of approaching things.
[00:18:24] Speaker B: Okay. Well, we've dug deep into stakeholder engineering. Deep dive from defining who stakeholders are to understanding those hidden needs to actually managing those relationships.
[00:18:37] Speaker A: It's been a journey.
[00:18:38] Speaker B: It has. And I always like to leave our listeners with something to think about, a question to help them apply these ideas to their own lives. What would you suggest?
[00:18:50] Speaker A: Well, I think it would be really interesting for them to think about a current project or system in their own lives. It could be something at work, a community initiative, even a family decision they're grappling with.
[00:19:05] Speaker B: Yeah.
[00:19:05] Speaker A: Put on their stakeholder engineering hat.
[00:19:07] Speaker B: Yeah.
[00:19:08] Speaker A: And analyze the situation.
[00:19:10] Speaker B: Analyze it? Yeah.
[00:19:11] Speaker A: Who are the stakeholders? Obvious. Hidden.
[00:19:15] Speaker B: All of them.
[00:19:15] Speaker A: What are their needs, their motivations? And how could applying these principles lead to a better outcome for everybody. For everybody.
[00:19:24] Speaker B: I love that.
[00:19:24] Speaker A: Yeah.
[00:19:25] Speaker B: I love that challenge.
[00:19:26] Speaker A: Yeah. It's a good way to bring it down to Earth.
[00:19:27] Speaker B: Bring it down to Earth.
[00:19:28] Speaker A: Make it relevant to everyone's lives.
[00:19:30] Speaker B: And who knows, you might even.
[00:19:32] Speaker A: You might discover some unexpected stakeholders along the way.
[00:19:34] Speaker B: Unexpected stakeholders.
[00:19:36] Speaker A: Yeah. That's one of the most exciting things about it, I think.
[00:19:38] Speaker B: Yeah.
[00:19:39] Speaker A: It encourages you to look beyond the surface, really understand those complex relationships.
[00:19:44] Speaker B: It's a web.
[00:19:45] Speaker A: It's a web. Yeah.
[00:19:46] Speaker B: Well, this has been incredibly insightful.
[00:19:49] Speaker A: It has.
[00:19:49] Speaker B: Thank you so much for sharing your expertise. My pleasure with us today.
[00:19:53] Speaker A: Always happy to talk about this stuff.
[00:19:55] Speaker B: Yeah. And to our listeners. Thanks for joining us. Thanks for listening on this journey. Yeah. We hope you found it valuable.
[00:20:02] Speaker A: We hope so.
[00:20:03] Speaker B: Be sure to check out the episode description.
[00:20:05] Speaker A: Yes.
[00:20:06] Speaker B: For links to the source material and other resources.
[00:20:08] Speaker A: All the good stuff.
[00:20:10] Speaker B: Until next time.
[00:20:11] Speaker A: Until next time.
[00:20:12] Speaker B: Keep learning.
[00:20:12] Speaker A: Keep learning.
[00:20:13] Speaker B: Keep exploring.
[00:20:15] Speaker A: Keep exploring.
[00:20:16] Speaker B: And keep diving deep.
[00:20:17] Speaker A: Keep diving deep.
