Loosely Coupled - Mapping stakeholder chaos by slicing and dicing stakeholders

Good morning, good afternoon, and good evening, everybody, and welcome to another episode of Loosely Coupled by Bridging the Gap.

My name is Karol Skrzymowski, and I just brewed myself a fresh cup of coffee for this lovely evening just to survive to the end of the day because it's been a long day today.

But we do have a very, very interesting topic at hand, one that I don't really know that much about because I'm not a business analyst, although sometimes I have to be, and this is one of my biggest challenges and problems as an integration architect that I do actually have to do business analysis, and sometimes I have no idea what I'm doing.

So today, to shine some light on business analysis and especially stakeholder management and understanding your stakeholders, we have a lovely guest hailing to us from Canada, Pamela Patterson, and Pamela is a senior tech consultant with a very, very deep expertise in business analysis and project management.

Pamela works for a lot of organisations, wrote, I believe, two international bestsellers as books on the topic or relevant, and well, has been teaching stakeholder management and interviewing stakeholders for quite a while.

And I met Pamela a year ago before DDD Europe 25.

I was in an amazing conversation before and during a conference, so I want you guys to meet Pamela as well.

So, Pamela, welcome to the show.

Thank you very much for having me.

Ah, wonderful to have you.

I always enjoyed our conversation, so why not have a conversation on the show about business analysis, and more specifically, stakeholders at this point.

So, please do tell.

First of all, why are you even doing business analysis?

Why the drive in that field?

Because you're not only doing it as a consultant, you're also teaching, and you're a speaker at conferences, you wrote books, and this is all a lot of work.

So, what's the drive there?

Well, I think I love people, and I love doing solutions, and I love troubleshooting, and I love visioning, and I love the front-end work, working with the business and bringing in a new product or service.

And I also have a master's in IT and systems engineering, so I'm technically a systems engineer as well, but I really love the business analysis part of things, just because I think it's interesting.

I think working with people who are excited about getting a new product or service is exciting as well, and yeah, it's just a whole bunch of fun.

A whole bunch of fun.

Okay.

So, just a disclaimer, because I already see the comments, which unfortunately didn't land in our studio for some reason, but Annegret, our colleague from DDD Europe, really hopes that the stakeholders are not literally sliced and diced during the stream, so just to do this disclaimer, no stakeholders were harmed in the preparation for this session.

Just to be fair.

All are still alive and well.

It's a good disclaimer.

It's good to clarify that.

All right.

So, slicing and dicing stakeholders, so we're mapping the chaos.

So, what's the core problem with stakeholder management, and what's the chaos?

Can we just try to define the problem space where we're at?

Sure.

I think that it's the tools that most people have access to are very linear.

So, they'll list the stakeholder, like the stakeholder register, or they'll list the stakeholder roles and responsibilities, the area in a box, what they're responsible for and what they'll talk about, and in fact, it doesn't really work like that.

Stakeholders are not linear.

Stakeholders can't be put in boxes.

There's a lot of dynamics between stakeholders.

There's very few books or courses that will tell you what you need to know about stakeholders before you get into the room with them.

Sometimes we are just literally thrown into a room.

There's 20 stakeholders there we need to talk to, and somehow we need to figure our way through it, but nobody really tells us how.

So, I think of stakeholders as more of a web than a linear box on an org chart, and that's where it becomes difficult because where do we get this information from to think about stakeholders in a different way?

Right.

So, the way I always seen stakeholders through mostly from documentation, really, project documentation or something derivative of a contract, the biggest piece of information I got from these kind of documents was the RACI, Responsible, Accountable, yeah.

Consulting and Informed.

Consulting and Informed, yes, precisely, and other variations of that table because that table has variations to it with other roles in there.

So, mostly, it is from more of a legal perspective than actual usable stakeholder management perspective just to outline who is responsible for what, who is accountable for what, and who's going to be consulted, and that's it, and then I have a list of people that gives me absolutely zero meaning towards how I'm going to, how am I supposed to work with those people, right?

I only know that they're either accountable or responsible.

The difference is that they either oversee or do, right?

Okay, fantastic, but what are their goals?

What are their interests in this particular project?

What stakes they got going?

Is this a life-and-death situation for their career, or is this just another project in the company that nobody cares about?

This always was a problem for me, and I didn't even realise that this is a problem for me until I, well, started chatting with you last year and understanding more, a little bit more, digging into the business analysis side and then actually starting learning something, and that was like, oh, that actually makes sense.

Business analysis hat on.

Let's do this, right?

Yeah, people don't show up well on just a box, and what you're kind of alluding to is how well do I know the people that I'm working with?

Do I understand what their objections are to, you know, is it to be part of the project?

You know, are people, when they're apathetic or they're not that engaged, what's the root cause of that?

I mean, are they just, they're out of time, they're out of gas, they don't function well in the morning?

I mean, it could be something as simple as that.

They have a small baby at home, they have had bad experiences with that particular group of developers.

I mean, you need to really look at that person and all sides of that person and even how they absorb information.

I mean, most people are visual thinkers and visual learners, especially in IT and tech, and if our meetings are always verbal, I mean, I tell people when I do these workshops and conferences, I think, what if this entire conference was verbal?

No PowerPoints, no nothing, no handouts, nothing before, nothing after, how much would you absorb as an attendee?

And they say, well, probably not much, and I'm like, that's your stakeholder experience.

So, are your meetings entirely verbal?

You know, you could have the best stakeholder, the most willing stakeholder, you could have done so much research, you could be the best person ever in what you do, but they're not absorbing it.

So, it's stakeholder chaos and stakeholder mapping, it's part of the solution, you know, to map out your stakeholders, their roles and responsibilities on the RACI chart or, you know, whatever.

I mean, these are all good tools, but keep going, you know, keep going with getting to know your stakeholders.

Yeah, because when projects do this RACI tool, that's pretty much it, there's no iteration over it, unless somebody explicitly changes a role or leaves the company or leaves the project, right?

So, then nobody looks at it, nobody updates that, nobody touches that ever, and this is just a dead piece of data somewhere sitting in a work dock on the server.

So, it just doesn't contribute to anything other than, yeah, legal, maybe, aspects.

Legal.

Yeah, legal.

I mean, you have

this official RACI or your official stakeholder register, and then you have reality, you know,

you have the water cooler conversations, you have the best friends who go to lunch,

you know, you have the power differentials, you have one boss who's trying to, you know,

just trying to find their way, if it's a new position, trying to find their way, find their

feet, and maybe wants to talk too much in the meeting, and so his or her people are not talking

as much, like, there's so many different elements of stakeholder chaos to look at and consider,

and I mean, it's, the way that we start is we just start, you know, we just start

getting to know our stakeholders more than just a box on a chart.

Okay, so, let's make an assumption that a large number of our audience at Lucy coupled are actually consultants.

They're not in-house developers, architects, business analysts, they work as consultants, and they just hop into a company, help them for some time, and they move on to the next project.

So, they don't stay very long, and usually learning all that context takes quite a long time.

So, if I would be going to a new client as a consultant, how can I start with that stakeholder chaos to turn it into something actually usable?

Okay, this is a great question, because they're at a real disadvantage, the consultants, when they're going into a new environment, and that's been my life for 20 years.

I've been at a disadvantage.

So, you have plenty of experience to share about how to deal with that disadvantage.

Ah, yes, let's go.

So, the first thing that I do is I find out, I mean, you have a contact person who's inside who, before you start the project, and I start asking questions about the people who are going to be involved, and this might be kind of the beginning of that box on the chart.

So, for example, and I find out where they work, what department they work for, I go look them up on LinkedIn, because if you can see somebody's career progression, you know, if they can see that maybe they are a junior person that has just joined the team, just joined the company.

So, then if you have somebody else who's been with the company for 20 years, and they haven't moved, or they haven't switched departments from developer or sales engineer to accounting or whatever, people's jobs and people's education background and where they've been tells you a little bit about them.

You know, like if the person is in sales versus accounting, I mean, which one do we think is going to be more sticking to the rules?

You know, is it going to be sales or accounting?

We know the auditing people, they're really sticking to the rules.

And so, sales might kind of, you know, because you have to understand their realities as well, and their objections, which is that they don't earn commissions when they're in a room with you, right?

So, they might try and kind of get this over done quickly, you know.

So, it's about before you get into the room, before you take a step into that company's boardroom, find out as much as you can about these people.

And you know, your contact inside, and this is what I do, is I ask my contact inside, once I develop a good rapport with them and there's trust, is to say, okay, well, thank you for all of these names.

This is terrific.

Now, tell me about these people.

Are they supportive of this project?

Are they not?

How much experience do they have on tech projects?

Are they, do they have time for this project?

Or do they feel they don't have time for this project?

And I find out their strengths, their weaknesses, their objections from the perspective of one person.

You know, and one of the projects I worked on maybe a couple of years ago, I was told by my contact that this one person is really difficult.

She's very, very difficult.

And I was going to have problems with her.

And I just park that.

I don't believe that.

I just park it.

And then I might spend a little bit more time getting to know that person and developing that relationship and that trust than somebody else who was not labelled difficult.

Right?

So, and in fact, she wasn't difficult.

She was just feeling not heard and not appreciated by management.

So, that's a good starting point is I mentioned a lot of different things.

I mentioned going on to LinkedIn, Google their name, see what their career progression is, and talk to your internal contact and get their perception about those different people and also the dynamics.

Because, you know, we have, we start at the individual, you know, which is kind of like a dot, a free-floating dot, but then we're surrounded by people, which is the team that force constraints on people, right?

Impact them.

So, also ask at the team level.

So, ask at the individual level about this person and ask at the team level.

And that'll give you a really good starting point in, you know, you always want to know, have this information before you get into that room.

Those kinds of things will give you a good starting point.

I remember you told, first of all, the people labelled difficult and then ask the team and kind of triggered a memory of me watching one of the talks from Simon Sinek.

And he was talking about how Navy SEALs chose people to the team.

They were not basing that on KPIs, but on trust indicators.

So, performance versus trust, right?

And then they, if somebody was high performance, low trust, that was definitely not a go for that person to join the Navy SEALs team.

And it's like, well, this is normally where we, when we work in corporate environments, we're mostly looking at, unfortunately, performance, which is not something that we actually can indicate if somebody's good or not, because it's also about being trustworthy and being available to solve problems, helping solve problems, et cetera.

And then being labelled difficult, you mentioned that the person wasn't difficult.

That person was just frustrated.

Unheard, was voicing concerns, and the concerns probably were never addressed, which then means that most likely, they became problems for that person.

And then if I look at it, it's like, in the talk from Simon Sinek, he said, like, if you go to a team and ask who's the arsehole, every team has this kind of high performing, low trust person, they basically would dub an ale in the team.

And that's already some sort of an indication from perspectives of what to watch for.

And it not mean label that person, like you said, that it didn't label that person difficult.

But then that might be an indicator that there is a story behind that.

That there might be an indicator that there is something actually to dig into.

And not only relationship wise, human wise, but actually business wise.

At least that's my understanding of these kind of labels.

But then again, I'm a little bit educated on psychology, thanks to my wife, who's a business coach, that she's constantly saying to me, if somebody is acting out with emotions at you, it's not about you, it's about them.

Be gentle and ask yourself, what's the story behind that person?

Why are they acting out with those emotions?

So somebody being difficult is actually somebody who could probably show us a lot about the problems of the company.

If we're talking about the corporate setting or company setting, right?

Yeah, performance is a very interesting concept, because you can have a very underperforming team and change the coach.

And then the next year, they win the medal, right?

I mean, it's about systems thinking about that person, and that team and that organisation and all those levels that are piled on top of that person.

But trust is a deal breaker.

If you can't trust the person that you work with, you need to put up some protective barriers or keep email trails or whatever.

I mean, we're all told as consultants, you need to have accountants and lawyers that you trust.

That's the most important thing about the people that you surround yourself with.

I mean, I have seen some situations where you could turn around trust.

So there was maybe some situations that it looked like trust was the issue.

But it was, like you say, the story behind that, you know, what's going on underneath that?

How long has it been going on?

And what's the root cause of that?

And then you can have some hope of turning things around.

But that said, it's not only about the stakeholder chaos.

It's not only about hierarchy charts in a company, team compositions.

It's, like you said, a web, because it's about those interpersonal dynamics between all those various stakeholders, also those that are unseen, because they might not be on the org chart.

Right?

So let's dig into this a little bit.

What kind of stakeholders you might not see on an org chart, or not see as a dependency, because they're not visible through the org chart as a dependency in stakeholder mapping and stakeholder management?

Sure.

The ones with influence, and maybe the ones who are impacted, but have been left out of the game.

You know, they've been left out of the project.

So people with influence might be, they've been with the company for 20 years.

And they have a very good relationship with the executives.

And so you can have some backdoor influence on a project, or on decisions through that person.

Because there are people who are named to be on a project, but they're not necessarily the best people for that particular project at that particular time.

Maybe they are the ones who are available.

Maybe they're the ones who are not as busy as somebody else.

So they're not that available, but they're not as busy as somebody else.

Or maybe they're the ones who, well, we want to put this person on this project because they need experience.

And so they're kind of learning experience underneath you, which is fine.

I mean, we all need to learn and grow.

But as long as you're aware of that, that you might not get what you need from that person, but that your role with that person is more of a training role and a mentoring role, that kind of thing.

So it really does come back to, do you know your stakeholders?

Do you understand kind of the hidden dynamics and forces in the team and the company?

Do you know their background?

Do you know if they're supportive of this project?

And if not, why not?

What sort of constraints are they dealing with every day?

Okay.

So let's say we have dug into the background.

Let's say we asked that contact person at the company.

We started sourcing information, got a view of who are the key figures.

We did some background digging, let's say open source intelligence in my case, because I really like digging into things just to see what I can find, which sometimes bears very interesting results.

We're starting.

We're setting up in a completely new environment.

We just got the laptop because they mandate us to get the company laptop so we don't use our consulting equipment.

Okay.

We're there.

We're in the office.

We're saying hellos to all those people that we were noted out.

What now?

What then?

We're basically, okay, we have a bunch of information.

We have a, let's say cloud, word cloud chaos of info, some loosely attached strings to certain names because we did our research.

And we just walked into the office and we're actually meeting those people.

How are we now supposed to, well, on top of all the cognitive overwhelm of meeting people, what should we put our attention to stakeholder management wise?

Okay.

So I want to back it up a little bit.

Okay.

So you mentioned you're in the office, you're meeting people.

I want to back it up.

Okay.

I want to back it up to your personal planning process.

Um, so figuring out what artefacts you need to deliver and who's going to contribute to them and setting up those meetings.

And that comes with working with your contact internally in the company.

So I do a lot of process maps and I do a lot of requirements and user stories.

So I would want to be talking to my contact about who are the best people to provide input into these deliverables so I can set up, start setting up those meetings.

Right.

And I would also ask, what is their level of experience in doing this, in doing requirements and process maps?

And they might tell me, well, you know, they're, they've been with a company for a long time, but they've never been on a process project before.

So I say, okay.

So now the dynamic that I have is that some people in the room might not understand the deliverable.

They might not understand the process that happens with the deliverable when other people will.

And when you have that kind of a dynamic and you understand that, and remember, we're not even in the room yet.

Okay.

We're still figuring out who we've got.

And when we have that kind of dynamic, what I tend to do is take those less experienced people aside and have a pre-meeting and say, you know what, I understand this is your first time in creating process maps.

So I want to go through process mapping.

And so you have a good foundation and a good understanding of what we're going to do in the meeting so that you, it's going to be easier on you.

And coincidentally, it's also going to be easier on me because I'm going to now have an equal contributor in the meeting.

So this is that slicing and dicing of stakeholders that came into the title of this live stream.

How can you slice and dice them?

Which people are you going to put into the same room?

And which ones are like a cat and a mouse, and you should never have them in the same room because there's different dynamics.

Maybe people are struggling for resources, whatever it is, there's a history, whatever it is.

Would that pre-meeting, given their level of experience, would that be a good place to source further information about the dynamics between people?

When it comes to dynamics between people, as a consultant, I'm a little careful and I step a little lightly around asking questions like that.

I would ask my trusted contact for their perspective.

And I say perspective because other people have different ideas of what the dynamics are.

But I might ask a question sideways.

I might not ask a direct question, I'll say, what are the dynamics between these two teams?

But I might ask a question that's sideways of that person.

That maybe, have you worked with this team before?

How did that go?

Even if I have other information that tells me otherwise, I want to keep being objective.

I don't want to influence their answer.

So it's a good point that you raise.

Who can you ask for information?

And I ask the same question to multiple people without them even knowing about it.

And I'm still mapping out my stakeholders.

I might say, well, how did these two groups get along?

And somebody will say, great.

Somebody else will say, oh, there's been a long-standing problem between those two.

And my old journalism professor would be happy to hear that I ask one person, I ask another person, and then the third person is the tiebreaker, where I come to my, form my own reality about what is true.

True is always in quotes, of course.

Subjective, yes.

Because you still have just a partial view on the situation.

And there is, in relationships or in companies, there is very, very little to objective truth.

Most of the truth there is subjective anyways, unless it's written down and signed by all parties involved, then it becomes somewhat objective, somewhat given that they still might understand the things they signed differently, right?

Isn't that the case?

Do you know what they told us in journalism school?

And this was, I was in journalism and communications before I went into tech.

They said, you stop being objective the day that you're born.

It's pretty much true.

I thought it was the greatest quote, you know, what neighbourhood, what culture, what country, you know, you stop being objective the day that you are born.

Well, that's a fair point, because we all have our perspectives, we all have our backgrounds, we all have our problems that influence the way we work and interact with reality.

And that gives us different lenses on reality just by being.

I might have a headache, I didn't get enough sleep because my kids woke me up in the middle of the night, that already shifts my perspective.

Same for everybody else.

In that sense, they didn't get their morning coffee.

That's troublesome for some people.

Some people even should wear the shirt, don't talk to me before I have my coffee, right?

So that's the truth.

There's no objective truth in that sense.

It's relationships, it's messy, it's a messy chaos.

And this is even messier in companies, because there are layers of that chaos, I suppose.

Different layers.

Hierarchy is just one layer to it.

You know, what you're really looking for is a pattern, when it comes to interacting with somebody else.

And there's a trust ladder that I came across, which I really like.

I should have brought a slide for it.

But it's consistency leads to believability, which leads to credibility, which leads to trust, and then true collaboration.

And this is true, you know, so not the one-offs, but what kind of pattern are we seeing in somebody else?

And I don't even mean it from a blame perspective, you know, if they are not contributing, or they don't provide meaningful contributions, digging into the root cause of that pattern.

So is it because they are not a verbal person?

Is it because they're extremely introverted, and are anxious around people?

I mean, what are the root causes around that dynamic?

You know, where you see those patterns?

And there's plenty of patterns to look for, basically, in that sense.

But that to be able to spot patterns, you either have to be autistic to get that really quick, or really well trained in that sense, right?

Because it's patterns are not easy.

These patterns are not easy to spot.

Basically, they're usually very, very well hidden between the lines between conversations between meetings between reactions, sometimes very subtle.

Or sometimes somebody walks in the room and the vibe completely changes, right?

That's not very subtle at all.

But it is a pattern.

Yes.

And if you are a new consultant to an organisation, then you won't have the benefit of seeing patterns.

Yeah, that's I think that's one of the key problems of being a consultant in that sense, right?

That takes a while.

Okay, so let's say we made our observations, we maybe spotted a few patterns, because we already interacted with a bunch of people.

What can we do?

Well, we planned our meetings, and now we're going into interviewing, right?

So we already maybe done one or interview or two.

If we have those interviews, and we ask relevant questions, usually on the subject matter of the project at hand, not exactly about relationships and stakeholders, to be fair, right?

So how should we build upon all the information we gather when working with our stakeholders for the next interviews, sessions, workshops, requirements, gatherings, all those things, because, of course, people are rushing towards those, but this is like, like you already explained, we need to first understand the stakeholders to be able to do those things.

But my hint is here that during those sessions, also things happen that we can pick up on and actually make them usable, actionable information for our stakeholder management and further slicing and dicing.

So what would we need to watch for when interviewing when doing workshops when gathering requirements?

Well, that's again, depending on the role we might have, but these kind of aspects.

So you mentioned something very fundamental that all of us do really, which is interviews.

In one shape or another, we are doing interviews, we are, you know, kind of the definition of that is getting information, you know, it's a conversation with a purpose, kind of like now.

And so when you're putting together your questions, you know, a lot of people might just pull up a list of questions that they used before, and walk into that room, and ignore and not understand how to capitalise on all of that stakeholder information that you got in your interview.

And so, you know, some of the information you can get from that stakeholder directly, you know, you can ask, is this is does this time work for you?

Does this format work for you?

Is there a better way to get information?

If you need to think about an answer, and then give it to me later by email, that's okay, too.

So you're giving them options for input.

But here's where knowing about your stakeholder is really going to help you in your interview.

So let's say, for example, we have, we need to ask, I mean, this is a very simple example.

But we need to ask where they want the button on the screen.

Okay.

And you might, if we had two people, we had two stakeholders, one was a call centre agent, who uses the system, and needs to have that button there.

And, you know, for ease of use and accessibility and everything else usability.

Or so we have a call centre agent, or we have the CEO of the company.

And the gut reaction might be, well, of course, it's the call centre agent.

That's who you're going to ask where to put the button.

Like, of course.

But what if you knew a lot about your stakeholders?

What if you knew that the CEO was the CEO of this company that was only eight people big.

And the CEO is also the founder.

And the CEO is really involved in the usability of the system, because that's what he or she likes.

And so if you have information about stakeholders, you're going to it's going to inform the questions that you ask, even.

And so it's a very interesting, you know, it takes some practise, and it takes but the first place is to put your toe in the water and try and get this information about the stakeholders and understand the dynamics.

And then when it comes to the interview, and that's a whole different live stream that we can do together.

But it's about knowing which questions to ask.

Even the order of the questions can influence your stakeholder and make them more engaged or not.

And once you get all of this information, if you know about your stakeholders preferences for reviewing the content and the accuracy, and again, that comes back to knowing your stakeholder again, and, and working with them and who they are.

Right, I do recall your workshops at DDD Europe last year, I've been taking notes that I literally took notes about stakeholder interviewing and put them in.

Because again, not a business analyst, not an expert.

So I need to spar with something.

So someone, I literally created a chat agent in Gemini called Pamela.

And Pamela, the business analyst that wrote those, all those notes into that chat agent just to spar on preparing for interviews, just to be able to figure out what to do in a more dynamic sparring way.

And also so that I don't butter a bunch of business analysts asking questions, because they would be so annoyed by my questions.

Too many of them.

And I find myself right now actually taking notes again, which is extremely funny from from my perspective.

But yeah, this is just using that knowledge.

Because of course, we have a tendency at times, especially in bigger companies, because you mentioned a small one where the CEO is actually very involved, that happens, of course.

But then if you have a company the size of, let's say, the big four of consulting, or accounting more like, right?

Then the CEO is not really involved in the day to day of the employees, the line employees.

So asking him these kind of questions makes absolutely ridiculously no sense.

But then, on the other hand, we have people who actually ask his opinion, his or hers opinion.

And then we end up with something called CEO driven development, which is we're driving the product or the solution by the vision of the CEO, which has literally zero usability for the people that are supposed to use it.

And that becomes a problem.

From what I see already at the level of business analysis, not on the level of architecture or development or testing or training people, but as far as business analysis and actually defining the problem space in that idea.

So in that case, you have a problem stakeholder, and the problem stakeholder is the CEO, who is too over involved in decisions that other people should have purview over, right?

So like micromanaging, not delegating, these kind of things, the cardinal sense of management, so to speak.

Yes.

And it's difficult, isn't it?

Because if it's the CEO, then how do you have that conversation?

Sometimes I find the best way is to say things in a positive light and say things like, I know you're really, really busy.

So I'm going to do a lot of upfront work for you.

And I'm going to keep you informed if that's okay.

And getting their permission to, especially when there's that authority kind of element to work with, right?

This sums here to a question that actually Maxim asked quite a while ago in chat, but didn't flow into the conversation yet.

You mentioned problem stakeholders.

So basically, you already applied a bit of a category or a label there, right?

So Maxim's question is how to categorise which kind of stakeholder is...

I would ask it a little bit differently, how to categorise stakeholders in general, because from categorisation, we also can surface, my educated guess based on the books I read, that we can surface who is relevant and not relevant.

To, of course, to a certain extent, because if you have shadow stakeholders, hidden stakeholders, then of course, this is not going to surface through those tools.

But how to approach that kind of mapping and categorisation to try to make sense, organised sense of relevance of those stakeholders to our project.

And in case of Maxim, because Maxim is also an integration architect like I am, working for an iPaaS solution company, well, the example is integration, but let's, whichever works for you, just to get the point across.

Yeah, it's a difficult dance, you know, because you have your in-house project tools that you use, and you can, so you have the official understanding that is documented and distributed and reviewed and approved about the stakeholders that you're using in there.

Maybe you're using an interest influence grid or an interest impact grid, so mapping their level of interest or their level of perceived interest versus their influence on the project.

If they're not interested, and they don't have any influence on the project, then they're not engaged very much.

So you have these kinds of tools that you can use, but I always, especially as a consultant, I always have my unofficial version of stakeholder grid and dynamics and the web that I know that I'm going to be walking into, and that I keep in the back of my mind.

And it does inform how I interact with stakeholders, having my unofficial version that I keep to myself, versus the official one that, you know, everybody puts their stamp on it and says, oh yeah, it looks good, we've got our stakeholders.

Right, so just to, I'm going to throw some images on screen.

So if we're talking about, let me bring you back to the, oh, there we go.

So if we're talking about power interest, that's one of the grids, right?

Right.

This is one of the ideas.

So we have to manage closely, so high power, high interest, high power, low interest to keep satisfied, or well, yeah, so they don't become high power, high interest, right?

High interest, but low power.

These are usually, for example, line employees, a group like a call centre employees, which we're doing a project for the call centre, right?

That would be somewhere like that to keep informed, and then monitor those that are low power, low interest.

Is there, because this is a very static representation of stakeholders.

As far as I remember from the BCS course that I did two months ago, this is actually, while this is a static representation, there are actually some dynamics to these grids that suddenly you can have a shift.

So basically doing these grids, it's not a one-off exercise, it's a continuous exercise to keep looking at the stakeholders and see have they moved from one place in the grid to the other.

And also, it's not binary, it's left or right and top, bottom, it's also scale in that sense, right?

So what are, if we're looking at these kind of things, and just to drop a different example, this might be a little bit too small.

There we go, that's bigger.

So this is a three-by-three grid of the same power interest, a little bit different of an organisation, right?

And here, I think deliberately, on the left top corner, we have high power, little interest in red.

Because as far as I recall from the general discussions we had about these grids, this is a very dangerous place to be in as a stakeholder for us doing the project.

So if we have a stakeholder there, there's a lot of dynamic that could happen if we categorise somebody there.

And now, can you walk us through a little, why is that the danger zone, so to speak?

Sure.

So high power, little interest, what comes to mind is maybe a sponsor of the project who knows in their mind that they are leaving the company, and so they're just doing as little as possible before they get out the door.

They have very little interest in this project.

So here's a person who has all the power to make all the decisions, makes the budgetary decisions, decides ultimately if people are coming on and off the project, the future of all of these people underneath them, and they're not interested at all.

So that's a really dangerous situation, because everybody kind of reports to this person in a dotted line, and the project manager is needing to deal with this person who doesn't open up their calendar, perhaps, who has 10-minute meetings instead of an hour.

So it's a really, really difficult dynamic to deal with.

And what about if, in terms of moving between the specific elements of the grid?

Because as far as I recall, being high power, little interest is dangerous, because that person can suddenly become high power, high interest.

And that's a different dynamic, because then if we, of course, if we do the exercise iteratively and see that somebody is moving to the right side of the grid, how is that a danger?

Because that can be a significant danger to a project, or a significant boon, on the other hand, depending on the, I assume, depending on the attitude of the stakeholder towards the project, or towards the consultant, or towards the consulting company as a whole.

Sure.

What are they interested in?

If it's high interest, what are they interested in?

It's a really good point.

Are they interested in, and I mean, these grids, they tend to assume that people are interested in the project.

But I think you also need to look at a person's self interest, right?

So interest, it's your public interest in the project or not, but your own self interest.

And that comes into playing into, do you understand what people are motivated by?

Do you understand their objections?

You understand the barriers that they have?

What is their self interest in the project?

There's a lot going on.

So what about timing?

Oh, yeah, I mean, yeah.

So timing, they might have a high power, little interest, but the project just started.

But in a week, they have a high power, high interest.

So now it's good.

So timing, right?

Yeah, but also, if we have a long running project, for example, from timing perspective, I would, for example, imagine the situation that somebody is high power, little interest, they're aware of the project, and they don't really care.

But suddenly, from somewhere from the top, they get a executive command, you need to take care of this project.

And all of a sudden, we have a shift of that person that who had high power, very little interest.

Now, all of a sudden, they say high power, high interest.

And that person is completely changing the rules of the game on the project.

Usually, I see that kind of dynamics.

And this is, again, timing wise, because somebody had their, for example, year evaluation with the higher ups.

And suddenly, they get highly motivated.

Because otherwise, they'll, for example, lose their job.

Again, different motivations, right?

Because that's the that's the key issue.

Because they might have an interest in the project.

But it's not the interest to the project that's driving them to interact and engage.

And if we're looking at interest in the project, what is, I think that's a very good topic, because I think everybody would have a different interest in the project.

Some people are in the project because they're just trying to earn their pay cheque.

Others, because they want to actually want to make an impact and help the company or help a specific group in the company.

Others, because it's it's related to their bonuses.

Others, because they just want to annoy the hell out of their another director in the company.

I think that there are the reasons for the interest, there are probably as many as people or more.

I tend to joke about if you take four architects in the room and ask them about their opinion, you'll get five different opinions.

I think in terms of interest and sourcing interest, why that person is suddenly having interest in the project, I think that would be pretty much the same.

So, if we find ourselves with this dynamic shifting, and suddenly we have a stakeholder moving to, let's say, high interest or low interest from higher interest, for example, how do we approach understanding what happened?

Because we're a consultant, we're not internal, we're somewhat barred from the gossip at the water cooler.

We can have some, but my guess is, oh, you're external.

So, we're going to shut up about our things and talk about the weekend instead.

So, if you're already in, you did some interviews, you're working on defining processes, you have that kind of shift of stakeholders.

How do you approach understanding the motivation of those stakeholders?

How do you slice and dice then when that kind of shift happens or all of a sudden?

So, sometimes you don't need to.

You don't need to understand that they've had a performance review and now they're suddenly motivated to be part of the project.

What you really care about is inputs and contributions from the right people at the right time.

I mean, if they have done nothing for almost the whole project and then they're stepping in at the end, changing everything, well, because of their high interest now, then that's a problem.

And that's something that can be handled in a mitigation kind of a way at the beginning of your project or before you've started your project is because now this is a problem stakeholder, even though on paper they're highly interested.

The problem is in the process.

The problem is in coming on board late and wanting to change everything.

And so, how are we going to deal with those kinds of scenarios?

Well, you know, at the beginning when you're identifying your stakeholders, you have the list of people.

And if they're not performing, then we wouldn't wait until the end of the project to do something about it.

That would happen much earlier and we would have those discussions about what are we going to do in this scenario if I don't get the review back or the review is substandard or if somebody's not showing up to meetings.

And usually we have a backup stakeholder that comes into play, but that's identified at the very beginning.

But what if in that case, let's say we have, going back to the big four and how network companies, because the big four, that's not a single corporate environment, that's network of companies.

And these network of companies usually have partners, not directors, not explicitly, well, there is a C level, but in general, they're run by partners, which are kind of like directors of specific units, sometimes with very high independence.

What if we get ourselves in this situation where we did all that work on stakeholder mapping and understanding the stakeholders and at a certain point in the project, not necessarily by the end, all of a sudden surface, a completely new stakeholder that normally would have been in, let's say, high power, little interest.

And we might've disregarded that person because not relevant, not showing up on hierarchy, never mentioned in the conversations with the trusted contact for whatever reasons.

Where that person should have been high power, little interest on the grid mapped out for us and we should be watching that person, we did it.

And suddenly that person pops up and is high power, high interest for whatever reason, but has the impact and influence and is suddenly interested in making that impact and influence.

So how do we manage that stakeholder then where we're already in the middle of things, because we are, it's been already, let's say four months into the project and we've been dealing with things, we already mapped things, we already started doing things and things are happening.

What then?

So in any project I've been involved in where a new stakeholder pops up in the middle of the project, it's been because there's been some kind of a problem.

And if that problem is internal, I don't have any visibility to, or maybe it's because part of the project is sagging a little bit and they're not delivering or they're behind deadlines.

There's been some reason why that new stakeholder has popped up.

And so, and sometimes it's for a good reason and sometimes it might not be.

But I would, first of all, kind of put some lens on that, some personal lens and think to myself, why is that person popping up now?

And see if I can find out some more intel around that.

And even starting with asking the person themselves, so you're new to the project, I want to help you get up to speed on it and so I can get your contributions in the best way.

I'm just wondering how you came to be a new stakeholder on the project and see what their perspective is.

And then I would ask probably a couple other people and see if the perspectives line up.

Is everybody aligned in why this new person, and who put the new person there?

That might be telling.

And what if it doesn't line up then?

If it doesn't line up, then I dig a little deeper and I ask more questions because it might be a perception, an incorrect perception that there's a problem on the project or part of the project is, or part of the people, they're not performing in the way that we want, we're not getting the results that we want.

And so you need to kind of back that up and reverse engineer, where is that perception coming from?

It might come, and I've seen this, it might come from the steering committee are sitting around a table talking about the progress of the project and you're not there to correct any misperceptions or the real progress of the project is not being communicated upward.

And so therefore the CEOs, they think they need to do damage control and let's put in a real shooting star who's going to bring the project back online.

So that's what I recommend is that when there's a new person who suddenly is parachuted onto the project, who has a high level of interest and influence, I start asking why.

And then of course also projects are not linear.

So deliverables or outcomes of a project, they do not show it proportionally to time.

Sometimes the outcome of a project and the deliverables show by the end of the project very, very, very rapidly, but during the project, it's nothing.

We literally joked about this, I think today or yesterday that sometimes project management or management in general has this perspective of throwing resources or just people at problems, thinking that in this kind of twisted thinking, like thinking about a pregnant woman.

So it takes nine months for a woman to birth a baby.

So if you have nine women, that will take one month.

It's this twisted logic kind of thing, right?

That there is a proportion relationship between adding people to the outcomes.

And that's usually not that simple, hence perspective.

Okay.

Yeah.

That's interesting because they might be actually, you're right.

That might be very related to just miscommunication.

And now that I think of it, I actually seen that happen quite a few times, that there was a complete lack of communication or miscommunication.

And it goes both in problems and in successes of actual progress of the project.

Mostly, unfortunately, I've seen a lack of communication about the problems, resulting in later an explosion in the project because nobody communicated upwards sufficiently that there are certain problems that already need addressing.

And then they just accumulated to the extent that they become a nuke on the project rather than solvable, mitigatable risks, right?

But that's a completely different problem space that is not really solvable from consulting perspective than at times.

It's again, who has the influence over those stakeholders?

But that brings me to a good question because there are tools.

We already touched on the power interest or power impact grids.

But I think before jumping into tools, and we hinted at that so many times already, but I think it's very important to maybe properly acknowledge that stakeholders are a living system and touch upon that.

What is that living system?

What does that precisely entail?

Because we already touched upon that here and there.

But just like to list out and condense that.

Sure.

So yeah, stakeholders as a living system.

So when we look at a system, and if you look at systems thinking about having inputs and outputs and looking for patterns and the changes in the system and the emergent behaviour in a system, new behaviour that wasn't seen before by its individual parts and components, which are really the people, you really do see that people are not islands by themselves.

You see that they are impacted by so many things.

We talk about system boundaries.

What are the boundaries of a system?

Well, it's not the individual.

I mean, if they are doing work and there's always at the top of this system, at the top of anybody working is this information lifecycle.

And so we can both pull down information from this information lifecycle and contribute to it or be bypassed from it.

So when somebody is working on a task, like let's get out of the conceptual and go down to the ground.

So if somebody is working on a task, and the deliverable doesn't go well, I mean, a linear thinker would say, oh, that person did a really bad job, right?

That's linear thinking.

But a system thinker would say, hmm, let's dig into this.

Where did they get the information from?

Was it a reliable source of information?

Was it timely?

Did they get it from enough people?

Are they new at the job?

Are they experienced as a developer, an architect, but not in this company?

Or this is a new flavour of a project where they needed some more mentoring.

What are the communication channels like?

Are people giving them information?

And are they able to use the tools?

Are they new at using the tools?

You know, there was one, I worked for Red Cross for a little while in a few different contracts.

And the tools that if we were to impose Miro, which is a simple tool, I mean, people in tech know, I mean, it's just like writing, it's just, you know, but somebody who's out in the field, saving lives, doesn't know Miro.

And if we're going to impose a tool on somebody who doesn't understand it, or is not very, you know, very tech, then they're taking away headspace, and overloading them cognitively to learn this tool, and then to give information, and it's live, and how's that going to go?

You know, so it's systems thinking, when you talk about a person is talking about so many different ways that person is impacted and influenced by processes, people, technology, tools, timing, the way that they learn, you know, it's, there's a lot going on the interconnections among people, among the team.

I mean, that's why team building is so important, right?

Because we're this big web of interconnections.

And we need to get information, we need to know when somebody says A, do they really mean A?

Or do they mean B?

Oh, you know what, I know this person, they actually meant C, right?

Or just so basically, from systems thinking, we're looking at this as a first of all, nonlinear, second of all, with a multitude of variables, and analysing which variables are actually the key dependencies on whatever the action is done.

So somebody delivering a deliverable, or making analysis, or doing whatever, and what influences their day-to-day in that sense, including the lovely cognitive load, which we already talked about, I think, three different times on this stream.

So that's a heavy analytical load already, just to be able to consider those aspects and figure out, oh, maybe we should consider that somebody is overloaded, maybe somebody is new, maybe somebody didn't receive proper training.

Maybe somebody's constantly waiting on another team or person to deliver that input, because they're tightly dependent on that person.

Otherwise, they cannot do their job, which in my world of integration happens all the time, because we're always dependent on everybody around us.

Let's say the life of an integration architect, we need every system to align so that we can do our job.

So yeah, that's heavy.

And then how to, as a business analyst, or as an architect on the project, how to, what is the right question here?

How to communicate that?

How to surface that?

Or how to maybe also, on top of all that, help others communicate that?

Because I think that's, as an analyst or as an architect, there will be probably more value to help others communicate those dependencies than trying to surface them yourselves, because I would say I wouldn't be quite capable of doing that, because I don't have the right perspective.

Mm hmm.

So it can be a lot, like in a conceptual kind of discussion, it can be a lot to figure out.

And so I want to give some shortcuts here.

So I have a grid, which I'm happy to share with your audience.

I have a grid of about 16 different criteria that I just keep kind of off to the side, you know.

And when it comes to systems thinking, and you don't have to initially, out of the gate, know everything about it, and all the impacts on people and all that.

But if you're coming across a problem on the project, that's the shortcut.

So if you're coming across somebody who is not delivering, or somebody who is delivering substandard information, or who is not communicating to somebody else, that's your cue to kick off your systems thinking.

And the first point where I would probably look is to that person themselves.

And I would say, you know what, I noticed that you're late a lot on your deliverables.

And of course, I would say it in a nicer way.

But is there anything that we can do here to help you?

And they would say, no, no, nothing at all.

I say, okay.

Well, it is really important that we get those deliverables on time, because it affects somebody else and help them to understand the system's thinking about there, if you're affecting somebody else, and they get late information, and then they're late.

So what can we do to help you deliver on time?

Like, tell me, from your perspective, what do you think might need to happen?

And it could be the simplest thing, it could be the hardest thing.

But you start with what's going wrong on the project.

And you can have this systems thinking off to the side and in your back pocket about the kinds of questions you're going to ask to help them through what might be the problem from their perspective.

And I think perspective is a really key word here, because reality versus perspective, reality of somebody's reality versus somebody else's reality is based on perspective, which is based on a lot of things.

It's based on experience, it's based on how they woke up that day, it's based on so many things, right?

I mean, the truth is a tapestry, woven together of so many different things.

So that's probably where I would start is, you know, you don't need to necessarily pick up a textbook on systems thinking.

But just think about where are the problems in your project and start some root cause analysis techniques, like the five why's.

You read my mind, right?

Or the or the fish diagram, you know, it's, it's very fish, fish, whatever.

Yeah, it's very, it's those are simple tools.

One of the I gave a workshop about these kinds of topics.

And, and I was using the five why's as an example to get to the root cause of what the problem is with the stakeholder and, and somebody kind of shot up their hand and said, doesn't that sound aggressive?

You know, why?

Why did that happen?

Why did that happen?

Why did that happen?

Why did that happen?

You know, like going down to the five, you know, and it does when it sounds like that.

But you can also do it with the person, right?

So you can say, you know what, Carol, I noticed that your deliverable was late the last few times.

And I, I want to do an exercise with you.

If, if you're okay with that, it's called the five why's.

Would you like to participate in that with me?

And so you're getting their permission, and you're doing it together.

So it's not why, why, why, why, why?

That that the way we phrase things really matters to get that engagement.

Even if we're using tools, not tools, maybe sound, but if we use it wrong, with the wrong intonation and energy, this will not work, even though the tool is great.

Yeah, isn't that the case?

I mean, the difference between, you know, good morning, and good morning.

It changes the whole room.

Yeah, it does.

That's, that's very true.

From architectural perspective, I do enjoy the five why's, because it's, it's really a problem solving technique for architects.

Because quite often in companies, we encounter, you know, arguments like, because we've always done it this way.

That's the worst kind of argument to make for a specific decision in architecture.

So then if you start applying with curiosity, five why's, then you dig into the actual root cause of why things are done this way.

And then either you start understanding why this is relevant, and why it should remain that way, because it actually is relevant.

Or you surface that the reason for doing it this way is no longer relevant, and you should actually start adjusting.

So that's, that's, that's a great, different use of that.

And

I find myself when I'm reading, especially reading this, this book, because that's 123

techniques for business analysis, different aspects of it, I find that I can really translate

those techniques quite often to architecture problems, not stakeholder management, not

business analysis per se, but just understanding architecture and surfacing technical aspects of

architecture, because they're just analogous in the ways of working.

And that makes my life also easier.

So but it's not only about learning to work with stakeholders is learning also to

work with, within a group within architecture within development teams, because, quite frankly,

if I'm looking at it from the perspective of an architect, my dev team are my state stakeholders,

different kinds of stakeholders, different category, probably those with a low power,

high interest at times, but still stakeholders, right?

That's a that kind of balance there.

Well, it's interesting that you found business analysis, because a lot of people have not found business analysis, if they're an architect or developer, or, or they or if you ask them, do you do business analysis?

They say, yeah, of course.

But it's, it's something that I've always felt that business analysis has a PR problem.

And not a lot of people can define it, or say what it is and say what it isn't.

Because it's so many different things.

I mean, it goes into change management, and it goes into, you know, requirements and systems engineering, and it travels a lot of different areas.

But I've always found that if people do find out more about business analysis, I've always found that they find that it really benefits them, you know, in the way that you're talking about, like getting to know your stakeholders and how to capitalise on, on the dynamics and understand that and the right questions to ask.

And, you know, like, what do you feel is the biggest benefit that that you've got from learning about business analysis?

Yeah, my, my interest in business analysis stems really from trying to understand business processes and process thinking.

Because I quite often as an integration architect, I find myself in the area where I need to actually step into the shoes of a business analyst and define a business process, or help others define a business process, because there is no business analyst, there is nobody who's able to outline that business process clearly.

And usually it's up to the integration architect that is, you know, connecting all those systems end to end, to surface that those dependencies time wise, what happens in sequence, where we can parallelise things, where things are completely forked off, etc.

So from that perspective, just purely process perspective, just learning BPMN, and those tools around modelling processes, that was the starting point of learning business analysis and getting the benefit, because that helped me define integrations better.

But then I'm a curious person.

So I love to dig deeper.

So instead of just learning about my field and staying within the confines of integration architecture, software architecture, I love to dig into, oh, let's learn about scrum, let's learn about testing, let's learn about business analysis.

So I'm like, okay, tabula rasa, I don't really know that much, let's just see what that is and figure out for myself, how can I use it.

And that translates to, oh, now I have this lovely book that I understand half of the techniques from, the others I can read about and just figure out, are they relevant to my current situation, or maybe I could use them later.

And let's just try and experiment.

And this is the kind of learning where I just, and then again, integration architecture doesn't really have much of a books written about.

You can find a lot of books about microservices, about software architecture in general, we feature lots of these books on loosely coupled as well.

But for integration architecture, that's usually closed source materials with tech vendors.

So if I want to introduce certain concepts into integration architecture, I use, I need to create analogues from other books like about software architecture.

And we did that in bridging the gap for ecosystem architectural styles, we took the work of Mark Richards and Neil Ford and fundamentals of software architecture, and their classification of system architectural styles, and we made an analogue to ecosystem architectural styles for integration.

Right?

So I read, I find, can I make an analogue to my field from that?

Can I use it?

And kind of is the same with business analysis that, can I have this and use it as an analogue to whatever problems I'm solving in my field.

So happens to be that since I need to wear the business analyst hat at times, I don't even have to create analogues at times, because I directly use business analysis and stakeholder analysis and stakeholder management turns out to be a really, really a speed up for me to get onto projects as a consultant way quicker, because then I understand who to talk to.

But that's my autistic way of learning things, right?

So I want to, yeah, I want to touch on a couple of things that you say.

So what you're doing is innovation, right?

When you're taking from one area and bringing it into another and reshaping it.

I mean, that's innovation.

That's the fusion of, which is awesome.

And the other thing to go slightly off track, you mentioned about processes, and I want to give the biggest tip ever to do process maps, okay?

If that's okay with your audience and with you, I want to give the biggest tip ever.

So often what I see with process maps is one square contains a paragraph or one square contains like a bunch of different stuff, and it's not linear with the other.

The biggest tip ever is to have a verb and a noun structure.

Okay?

That's the biggest, easiest tip ever.

So one box should not say invoice management, because we don't know what that is.

We don't know if it's creating invoices.

We don't know if it's submitting them, approving them, reviewing them.

We don't know what it is, deleting them.

If we don't want to pay people, we don't know what it is.

So verb and a noun structure in your process maps will make your life so much easier and the lives of your stakeholders.

So that's process mapping, or you could translate that to BPMN to an extent, right, and draft it as a diagram.

Because I've been working with Philip over creation of a course for the last more than half a year, and I had to dive into his world of domain-driven design, and he had to dive into my world of integration.

I really started learning event-storming, which you probably know from DDD, and event-storming is very colour-coded, and exactly what you said is part of event-storming.

You have events, order placed, noun, verb.

You have commands, confirm order.

That's pretty much it.

And the rest of it are colour-coded additions to that, like green is always a query, a read from somewhere, so you don't have to say read order, you just say order, because you're reading it.

That's always self-explanatory, but the verb is implicit in the colour of the post-it.

And then there are questions, as in to check reactions, policies, so is order complete and acceptable?

That's a logic gate there.

And then actors, so who is working on that specific aspect, command, or policy?

Who is executing that?

And, of course, there are also commands leading to external systems or specific aggregates, and that pretty much very well maps into what you said with noun, verb, and a little bit of extra info on top.

Just a different visualisation tool just to outline the process, because it's not going to be a proper process map with a BPMN attached to it.

It's going to be messy, it's going to be probably missing a few pieces here and there, but it's going to be a start of building a process, or defining a process, or discovering a process, in that sense.

The start of a common understanding.

Common understanding, which is one of the biggest goals of domain-driven design on its own.

We weren't supposed to go into domain-driven design this session, but hello, here we go!

There we go.

Now, I think there is a very good question there, again by Maxim, that we didn't answer, but we moved past that topic to a certain extent, which is, what will happen if we don't map stakeholders?

What will happen if we completely ignore the topic and just let it be?

Chaos.

Chaos.

You won't know who to get information from, and when, who has strong points and weak points, you won't know who has a vested interest, a personal interest, who has a self-interest, whose job it is for you to get the information from.

You won't know who has impact, or interest, or influence in the project.

It's chaos, and this directly impacts the quality of any deliverable that you do.

Any deliverable.

You can name it.

Requirements, process maps, architectural deliverables, everything.

Absolutely everything, because you might get the right information from the wrong people.

You might get the wrong information from the right people.

It's chaos.

It's absolute chaos.

I would argue one thing, because looking at psychology, our brains are wired to build models, right?

Because we need the simplification of reality, because we're not capable of coping with the full extent of what reality is, so we simplify it into models.

Would you say that an individual is doing stakeholder mapping whether they want it or not?

Implicitly, by experiencing those stakeholders, by talking to them, by building relationships?

I love that question, Carol, and let me tell you why I love it.

Who hasn't organised a dinner, or attended a family dinner, and the person organising the dinner is like, oh, grandma and grandpa are coming.

Grandpa drinks too much.

Hide the beer.

Grandma doesn't want to sit beside her aunt.

They're fighting right now.

Put the children, set up another table in the room.

They're too noisy.

Who hasn't mapped stakeholders?

Whether you like it or not, we've mapped stakeholders, and it's to our benefit to do it.

But I think the key of stakeholder mapping on the project is that the map is available and

accessible to the team rather than the individual, because we still, on top of the stakeholder

mapping that we do on the project, we will still have our own individual stakeholder maps that are

not one-to-one to the map that we actually show and build that is available for the team, for the

project, for whoever, because of our personal perspectives, biases, and relationships within

the team, or within the project, or within the company.

But that stakeholder map and doing it is for the benefit of a team as a lowest unit rather than an individual as a lowest unit, or the project as a lowest unit even, so a bigger scope of people in that sense.

I think that's the key here to understand the scope, and then apply chaos to that level if

we don't do that stakeholder mapping, because then we actually show impact of the lack of a

stakeholder map, because that impacts the entire team project, specific deliverables,

specific dependencies, and the quality of those specific deliverables, while if we just put it

down to an individual, well, what's the impact?

That I will not be able to do my work for a week because I'll be waiting, because I got the wrong info?

That's little of an impact in the grand scheme of things, company-wise, let's say.

Oh yeah, sure.

I mean, it's like a snowball going downhill.

It picks up more speed the bigger it gets, and so if you have stakeholder mapping at the individual level versus having it communicated at the team level or the organisation level, I mean, it's to develop a common understanding, and it's kind of leaping into roles and responsibilities as well, if somebody has a high interest and high influence and a high impact.

And I think it's important to underscore as well that we have our official stakeholder maps, and we have our unofficial ones, because, you know, I do a lot of work in government, and we know that we can't say if a certain team is underperforming, and we can't rely on them, even though they have a high interest and a high influence.

So we have our official stakeholder maps, and then we have our personal unofficial ones.

And we cannot really voice them that loud, because that might be considered very inappropriate and at times dangerous for our being in that organisation at times, just to acknowledge voice that there is that dependency, right?

That might be thin ice.

All right.

So we touched upon dependencies, which touched upon lack of stakeholder maps, and what does that do to individuals and projects.

Should we dive into some tools to actually provide some help for people to what tools they can use to actually start mapping stakeholders, start analysing stakeholders?

Yeah, sure.

Sure.

Let's dive into that.

All right.

So we already covered the grid influence impact power.

Which one would you, because you didn't write down a few for me here.

So which one would you want to start with?

I think, you know, I think that's probably the one that people would want to start with, even though we've already covered it and talked about it.

That would be my suggestion is for people to start with that one.

I also think that there's some there's some other ones that, you know, and the main issue that I have with the tools that are commonly used is that they are just so linear, you know, they're missing out so much.

And I think that but it's a good place to start, definitely.

And impact power grid is a good place to start them.

It's a good place to start.

Yeah.

And a lot of people use the onion diagram.

I don't know if you have a picture of that.

Oh, I'll find it.

All right.

I do.

I do have a few, just let me find one that might be somewhat good to visualise things.

I think this one would be it wise.

Decent enough.

Let me let me put that on.

Oh, yeah, something like this.

Sure.

Is that the right onion?

That's as good as any.

Okay, so we're touching up to Shrek.

And that's, we have layers.

That's right.

So in the middle, this one says product, but it could also say, say you like me as an individual.

And it shows the people who are shows the inner circles, the outer circles, and maybe the inner ones are the people who are closest to you in developing that product.

Maybe it's your subject matter experts or your domain experts.

Maybe the outer layer is the regulatory agencies.

And I actually see in this image, there is the regulators and financial beneficiaries, maybe people owning the stock or the clients or the public.

So this actually is a nice representation of and what it shows is that these are the people I need to think about.

And this is the distance, the proximity from me.

And so if people are closer to my inner circle, what are the ways in which I need to engage them and get to know them and what their needs are, and their requirements, right?

I have a different one.

Yes, there's so many different varieties of the onion, more of a public sector, I suppose.

Okay.

I think this is healthcare in this, in this, in the US, I suppose, I guess, looking at Secretary of State and such things that Right.

Yeah, so we have public and patients as the focus point of the onion, the core.

And then we have, oh, that's probably UK, then GP, general practitioner services, dentists, home care, care homes, hospitals, mental health, community services, public health services.

So the actual actual closest thing to a patient or an individual being part of the public then.

And then on top of that, local organisations, so mapped variously with dots, those that are and then it's also colour coded, I see them empowering patients, improving public health, providing care, a commissioning care, supporting providers of care.

So yeah, these are and then grouped within the layers by by different groups.

So the outer layer has as actually groups like regular regulations, and education outcomes framework and Parliament being one.

So that's a very, very high level, I suppose, more of a dissecting a very large group of stakeholders.

And there are dependencies.

So looking at the dependencies of the public as a beneficiaries of a health system in this in this case.

So not that individual as as the previous one.

Let's see if I can find another one.

Very quickly.

There are some of them are very messy.

If I look at them, they're there.

Jackie Reed would have a comment about diagramming and showing information on those specific diagrams.

We need to invite Jackie Reed to the show sometime just to talk about communicating information over diagrams.

Jackie is the master in visual communication.

And even I mean, you know, if we were to save this diagram as a black and white image, we wouldn't be able to understand it, right?

There's only that would be probably quite problematic.

Yeah, either way.

Yeah.

So here, faculty, staff, advisors, students and administrators as they probably beneficiary and then internal, but indirect stakeholders as the middle layer, enrolment management, institutional assessment and research.

It's very hard to dissect those when they're out of context, and we don't know what the context of the diagram is specifically.

So maybe not the best examples, but that kind of conveys the idea of putting where they are in distance of, of the problem space that we're dealing with problem domain.

So to speak.

That's right.

It's a good place to, to start as well, having the onion diagrams and the real power I find of these tools is when you share them with your team and you develop them with your team, because then you're going to find out, oh, you know, what is another person I need to add on to the onion, you know, because when we do things in isolation and by ourself, we're not going to get the best result.

And what it does as well as it's, it's team building, but it's also consensus, and it's building a common understanding about who are the people that we need to map out.

That's where I find is the powerful because, you know, onion diagrams are, of themselves, they're very simple.

They're very simple to do.

They're simple to look at.

But when we start sharing them, and we build that common understanding of who our stakeholders are, and what are they going to do?

That's the power.

Because the power is basically in clashing that those perspectives, right?

Because we can use even the same terms and still have different semantic meaning to them, which means that we still are completely elsewhere.

And then when we clash them and talk about them and try to define them, that's that's bringing the actual value because it's building that shared understanding, which is, I think, one of the most challenging things in any field.

And not only it that's life in general is that because we have those different perspectives, and we think and we have different mental models.

It's very hard to align.

Oh, 100%.

And then it diverges from there, right?

It doesn't converge, it diverges from there.

I started a new project in the federal government.

And one of the first things that I did is say, okay, well, what are our artefacts going to be?

And I established that glossary was going to be the first one of the first ones that I did.

And then we do it on an ongoing basis.

Because, you know, you can, first of all, to understand the term, to have a common understanding over the term, and many legal terms are so technical.

But it's also to leverage that information into other artefacts, so that it's, it's accurate.

And I mean, whether that turns into the beginning of a data dictionary or not, or turns into something else.

But is the Are you speaking the same language, you know, let's start there.

We literally had a live stream on living language and maintaining ubiquitous language at the beginning of January with Chris Simon.

And we highlighted that there are even tools for that, that we can leverage as plugins in the browser is just a matter of preparing that glossary.

And then using that plugin, and all of a sudden, all of a sudden, the dictionary is right available as you browse through Confluence or whatever other page.

And it just highlights the terms and you can see the meaning of very easily.

So it that establishing the glossary is one thing, but then actually treating this as a living language and evolving language and having that iterative approach.

That's one of the biggest challenges there that that any field has.

And in it with all those various specialisations and different fields of architecture, that's already been challenging.

I know I have troubles talking to data architects, because our languages just differ so crazily that it's very hard to establish common terms.

Right, I have a glossary in my head that trans well glossary dictionary that translates from data architecture terms to integration architecture terms.

And I start using when talking to data architects, I start using their data, their terms to make my life easier.

But to get to that dictionary that took a lot of effort, and a lot of arguments, and a lot of misinformation passing through and misconceptions going by.

So that's a difficult one.

Okay, what about stakeholder map in terms of coverage?

How can we leverage coverage tools to see if we're missing some voices or have invisible contributors or overlooking problematic or risky stakeholders?

How can we do that tool wise?

I would say it starts with your contact, your main contact, whoever that is the project manager, the sponsor, whoever your main contact is, start there and get their perspective about the stakeholders that we need the coverage.

And, you know, we can.

And then I would actually talk to those stakeholders and say, Well, this is my list.

Is there anybody who's missing?

Is there anybody who, you know, maybe it's not even their official role, but they'd be very valuable for me to talk to.

So it's kind of like asking a lot of people a lot of questions.

And I think there's a tendency for people to go with the list that they're given, talk to these people, and that's it.

And I think that I rally against that a lot, or at least I try to.

And I say, Okay, well, this is my list.

But is there anybody who was on this project before, who might be able to give me some background information?

Oh, yes, yes, yes, yes.

Fred was on the project.

10 years ago.

He's still with us.

He knows everything in the company might be worth it to spend an hour with him.

That's an invisible stakeholder.

Invisible.

If you don't ask the question, you will not get that on the list that person, right?

So how can we how can we other than creating a list?

How can we visualise that?

Because you said yourself, people are visual beings.

We learn visually.

So how can we make that more tangible other than just a list?

Because these are not linear dependencies between those stakeholders or those topics and stakeholders.

I would start the stakeholder mapping, like the interest or influence grid, the onion diagram.

I would use those and replace a list.

Because for the reason that you pointed out, I mean, a list is, is very linear thinking.

It's, it doesn't show dynamics, it doesn't show a web.

It has a limited utility, other than do we have all the right names.

But you need to know the relationships, you need to know, you know, who am I going to interview versus who am I going to ask to review the material, right, that I that I gather that I elicit.

So yeah, I would definitely once you get this list of stakeholders, put them into a different tool and try to show those dynamics and get to know what those dynamics look like.

What about something like this?

So a bit of a type of a mind map.

I was trying to find stakeholder map in Google Images.

And most of these were impact power grid, or onion, literally.

And then I stumbled into this beauty.

Beauty, colourful, meaning is, again, out of context.

So basically, not exactly understandable.

But basically, what I see it maps different companies for in different sectors that may be potentially, let's say, impacted in this case, I'm guessing.

So the question is, would that kind of mind mapping be a relevant tool for stakeholder mapping?

You know, I haven't used mind mapping for stakeholder mapping, but I can see how it might be useful in some situations.

Definitely to show the connections.

I mean, if you think inversely, if you think, well, what if we just put this image here into a list, a list wouldn't show all of these connections.

You know, some of these bubbles are connected to some, but not to others.

Right?

So I think that it could have a role.

I haven't actually used it myself, a mind map for stakeholders, because I have those other tools that I use.

But I could see somebody having some, getting some value out of this.

I'm guessing probably depending on the complexity of the project at hand, and the level, the number of levels of dependencies between the different stakeholders.

So I think this could potentially be an extension of the hierarchical diagram of a company or a project.

I'm guessing that if we use a mind map, we start with that hierarchy, and then start mapping interdependencies, and basically creating that kind of web, instead of a tree like structure.

Well, especially if you also add in what their role would be or what artefact they would be involved in.

So if you, for example, this on this diagram here, I see the yellow is about construction.

So if it is, and it's a bit small for me, but if you were to attach the deliverables, the artefacts that would be related to this, you might have construction doing a lot of them, but then there's some dotted lines from some other stakeholders, stakeholder groups, right?

I mean, then you're increasing the utility of this diagram.

That would definitely make sense to have it as a kind of a stakeholder map in that sense.

What about, again, for mapping and mapping those different perspectives, I learned some time ago

about a tool called stakeholder wheel, which is basically something that Maxim also asked about

earlier about categorising the stakeholders, and the stakeholder wheels cuts the stakeholders into,

well, that's the proposed in the book, because, of course, you can add different categories,

but eight categories, and as I learned it, it was, first of all, it cuts into external, internal,

and then let's say you have owners, managers, employees, regulators, suppliers, partners,

customers, competitors, let's say this kind of list, so eight categories of different stakeholders,

and I tried it on a project, and we, because we're in consulting, I made two stakeholder wheel

diagrams, one looking at my key beneficiaries of the project, who's ordering my direct work,

and what is their stakeholder wheel, who are their owners of the work, managers, employees, regulators

for that work, etc., and then at the same time, I did that same exercise, but from consulting

perspective, from me as a consultant, or the company, consulting company, what are our stakeholders

on this project, and these are two different perspectives, and the lists were very, very

different from if, when looked at that angle, so then who I need to look out for from perspective

of me being a consultant, but then who am I supposed to look out for when working on that

specific project?

And was it useful tool for you?

To get a grip on reality when onboarding to that project, very useful, and to my amazement, nobody did any stakeholder management at that point, where the project was already running for two years.

Oh, wow.

So all the stakeholders were

managed in people's heads with their mental models, with their small mental stakeholder maps,

and some of the people I asked, the so-called trusted contacts, that I asked about

these things, who are the stakeholders, some of them really had problems naming those stakeholders,

and I had to ask so many people just to get a decent map that actually had overlaps of those

stakeholders named and described who are they, what are their roles, what's their impact,

where they land in the project, what's their interest in the projects, what's their motivation

for the project, are they very involved in the project, etc.

That took me at least two weeks to go through the people that I could reach directly very quickly and just ask them and get that information to get a grip on reality.

And then I still was surprised by certain stakeholders popping up on meetings just unannounced, and I have no idea who they are.

So I didn't know how to play the game against them, because suddenly somebody comes and the whole energy in the room shifts, they suck in all the energy, and it's like, what just happened?

Who is that person?

Why are they here speaking at this point?

And why everybody is listening?

What's going on?

What's going on?

So you discovered after two years that there was no stakeholder mapping done initially.

And I have a question for you.

How was that project going?

I would rather not comment.

Yeah, it's hard on the project team when there's no stakeholder mapping.

It's really difficult on the team.

To that extent, again, we still don't really know, because of the lack of stakeholder management, we still really don't know who actually calls the shots, who actually makes those decisions, decisions are just communicated, if even.

And it's very difficult to navigate, especially to have sensible and noted down requirements, like nailed down just to execute them.

They shift, and the shifts are at times drastic, because of that.

Yeah, it's big impact stuff.

Yeah.

And project went for over two years now, and it's still undelivered.

I mean, nothing hit production, and then still somewhat problematic.

And it's hard to say what the direction is, because, again, very hard to pinpoint who's making the decisions and who to ask about what the direction should be.

Yeah, it's not clear.

No, not clear at all.

And I think that one of the problems is that exactly was the lack of stakeholder management and addressing the right stakeholders, and building those relationships with them, or at least managing those relationships, because I believe that all of them want to have a relationship with the consulting firm at this point.

Because that's another issue about the willingness to work with external consultants.

That's a completely different ballpark of a problem.

It is.

Yeah, that's a whole new show.

That's a whole new show.

That's also part of stakeholder management, I suppose.

But solving that one is way, way beyond anything business analysis-wise, right?

Yeah.

It's a big monster problem.

Yeah.

Okay.

So I think we touched upon a lot of these things, but let's just sum up a few.

So when all the slices that we make, and all the cuts, and all the looking around the pieces come together, what do we get from actually glueing all that back together when we sliced it, diced it, analysed, looked under a microscope, a magnifying glass, and whatever else?

What's the outcome that we should get if we do it right?

We should get a well-run project.

We should get a project.

Yeah, seriously.

A project where people are happy to be on.

Things run smoothly.

Deliverables get done to the quality that people are expecting.

There's not a lot of issues.

And yeah, we should get a well-run project.

And this is through the tools also by exposing proximity, right?

So how far...

What's the interest level of those stakeholders as well as presence of those?

So do they contribute or not contribute?

And then whether it's the power of them, how much of a decision-making power they have, how much of an impact they can bring with that power to the project, right?

We get those dynamics in and understand those dynamics.

Yeah.

You get the right people at the table at the right time for the right thing.

That's what you get.

Fair enough.

So the outcome of stakeholder slicing and dicing would be the surfacing of the true dynamics between stakeholders to be able to benefit from those true dynamics to surface requirements, understanding of the scope, understanding of the problem space.

And all that is just that groundwork of establishing stakeholders and mapping them out.

Yeah.

It's powerful stuff.

You got it.

Well, at least I understand stakeholder mapping now.

So the importance of it, because it really does help.

I noticed that some time ago that it really does help.

And now we have it condensed into the live stream.

Just looking at the notes.

Oh, one thing we didn't touch upon, Pamela.

Resistance.

What to do if we have those stakeholders that are resisting, that we have resistance or we were predicting resistance?

What should we anticipate when we are actually dealing with stakeholders in interviews and meetings and workshops, requirements gathering, all of these processes?

So my go-to is root cause analysis and to figure out, well, first of all, what kind of resistance, right?

Okay.

What kind of resistance is it?

When did it start?

Is it still going on?

Is it a pattern?

Is this person always resisting or just on this project or just on this artefact?

Find all those different elements of resistance and identify them.

These are cues, right?

And then start asking questions from that person where there is resistance.

You know, I find a lot of resistance is people, it's miscommunication.

It's not feeling appreciated.

It's not being heard.

It's not being listened to.

It's not being understood.

That's where I found most of the root cause of resistance coming from, an apathy, right?

Well, they never listened to us anyway.

So why would I do anything now?

So resistance is a cue to bigger things, to other things.

And it's kind of up to us to figure out what that might be.

You know, I always think that apathy is one of the worst things that could ever happen on a project when it comes to a stakeholder because apathy is, well, I just don't care.

You know, like you've reached the point where you just don't care.

So what happened that preceded that apathy?

How long has that been going on and what happened and what was the triggers?

And, you know, it's, yeah, start digging.

That's what I would do.

So anticipate pushback and then dig into it and why, why, why, why?

Why, why, why.

Why, why, why.

So alongside the why, that does also mean that we need to be flexible and adjust.

So adjust our communication, adjust our angle of questioning.

So rigid forms to gather information are not going to work in that case.

We need to be, we need to be creative on the spot in that sense.

Yeah.

I think, you know, as a consultant, I'm a chameleon and I change for every company, every client, every project.

So if you put your feelers out and you understand what you're walking into, you understand the stakeholders, the dynamics and you change.

And as you say, you know, be flexible and adaptable.

That's the mark of survival, right?

Like, can you adapt?

Seen it in species and that's where we have to go as an external consultant and as an internal consultant, you know, as a worker for a company, it's to be adaptable and be a chameleon.

Yeah.

Chameleon.

And now the key question from Maxim is, who's actually going to be doing this work?

Who should be doing this work and solving those challenges?

And I think that's a, that's a bit of a question without an explicit answer, because I would guess the only right answer here is it depends.

Sure.

But let's, let's dismantle the it depends.

So it depends on what and how we can approach that and divide and conquer, because I suppose that would be the approach in general.

Sure.

So as a business analyst, I would be solving challenges related to business analysis, but not the budget of the project, right?

That's somebody else's.

So what is your role and responsibility on the project?

It can start there.

I think that even if it isn't your official job to map out stakeholders, and, you know, as we've talked about, the typical tools are so limited and so linear, that even if the project manager does it, it might not have a lot of real utility for us.

Because they're so linear and so limited.

And we've talked about so many different ways how to map out stakeholders.

So it's really not about, you know, who should do it.

But it's about do we want to benefit from it.

And in that case, I'm the one doing it from my purview around business analysis.

But that would mean also that everyone else should actually do it from their perspective of their role and their responsibilities.

They should if they want to benefit from it.

Well, yeah, fair enough.

Because if they don't, they're just not going to reap the benefits.

Is there a scenario where there, it makes no sense to map it?

I can't think of one.

In over 20 years, I can't think of one.

Because I just, I just, in my head just opened up and, you know, a storm of different roles in different companies.

And for a moment there popped a McDonald's restaurant.

And would there be sense for a McDonald's employee working at the cashier booth to map their stakeholders?

And at first I was like, yeah, not really.

But then I'm thinking like career-wise or progression-wise, and it's like, actually, that might actually make sense.

A lot of sense to map out stakeholders, even working as a cashier, if you want to progress in that company.

Of course, if it's a temporary student job, not really.

But for progression sake and just understanding the dependencies and how to move forward, or just how to network to know the right people to move forward, for example.

Sure.

I mean, that was one of my first jobs, working at McDonald's as a cashier.

And I knew some managers were motivated and interested.

I had other managers who didn't care.

Some managers you could learn from, some you couldn't.

I mean, I had everybody mapped out.

Even the team leads and my co-workers, I had them all mapped out, even without knowing what stakeholder mapping is.

Because it was to my benefit to know how do people show up on the chessboard, you know?

But then I'm guessing you did that subconsciously because that's the unique quality of how your brain works at this point.

I don't think that a regular, normal person, neurotypical person would actually do that, you know?

That's my educated guess.

That wouldn't probably happen.

That's interesting.

I hope people comment on that observation that you had, because I'd be interested in knowing, do other people do this subconsciously?

Or am I just the odd one here?

Because, I mean, subconsciously, probably to an extent, yes.

But to a very detailed level, probably no.

Just looking at my, I remember myself as a student, in my brain, very analytical, autistic brain in that case, literally exiting the apartment and going to the university, which was, say, about 10, 15-minute walk to my faculty from home.

My brain had an algorithm of different scenarios in the morning, where I need to go, how I need to go, which way to go, just optimise my route each morning.

Each morning, a fresh algorithm outlining what I need to do, what I need to get through the day.

Do I need to buy myself a sandwich at the shop before classes, et cetera?

When I compared that to my colleagues, most of them never did kind of thing.

They just went on, oh, I'm hungry.

Okay, I'm going to step into the shop just to buy something.

My brain had an algorithm.

So that might, you know, this is always an interesting thing, because being neuroatypical, you don't really know how other brains work and what other people think.

You assume you know, you assume that they do the same, until you learn that they don't.

And that's always funny, because we don't even understand which aspects were actually different than the majority of people.

That's, that's a completely different conversation.

I think this is, this is something to just have a few conversations with colleagues and figure out, do you actually do the same?

But then again, if we work in IT, and the majority of IT is actually neuroatypical, and they don't even know it, we might get that answer, yes, and that becomes the new norm.

Which is biassed at best, right?

So yeah, that's a different problem states, right?

Computer brain.

Computer brain.

Yeah.

Maxim, I have no idea what the BFS or a DFS is.

So you would have to explain.

I really, I really hate acronyms for that, because they mean so many things, and the same means so little.

Sorry, not acronyms, abbreviations.

I have no idea what you mean here, but if that was a BLT, then I would know that's a subway sandwich.

Still, still remember that one.

But otherwise, no idea.

All right.

So, stakeholder chaos, just to sum it up, because we're already over two hours in, I think it's a good, good moment to just put a bit of a summary.

So we talked about all the chaos, and that this chaos actually has a hidden structure to it.

We don't really know that structure from looking at the hierarchy of a company, or just reading what people tell us.

We need to discover it to an extent, but the structure is there, and the structure is, can be very dynamic.

In this structure, we have patterns, and those patterns vary in degrees and complexity and types.

Some of them are relationships, other are emotional, other are history, whatever that may be, those patterns are there, and it's a matter of training ourselves to spot them, and find out what is an actually recurring pattern in behaviour, in relationships, etc.

All of this can be mapped, and we do it somewhat subconsciously, and then all of this can be influenced, if you know how, and if you dig into the root cause.

Does that sum it up about right?

It does, and the only thing that I would add is that we have our official version of stakeholder mapping, and then we have our own personal one.

Okay, yes, fair enough.

Yes, and not always worth sharing the personal one.

Be very mindful about sharing your personal stakeholder mapping, because that might be a dangerous game that would actually influence other relationships, and possibly create more problems than solutions.

Could be.

Oh, there we go.

Maxime elaborated.

Breadth-first search, depth-first search graph.

See, I didn't study algorithms at university, because I was studying electrical engineering, so my basis is doing signal processing rather than graph algorithms.

That's why I didn't know those.

I think that was, in my case, when I was going out of the home, that was more of a breadth-first in scoping the options, and then outlining the depth of sequence of things that need to happen.

Not sure, but that's my educated guess of what was happening in my brain at that time.

So, yes, pathfinding algorithms.

Yes, so breadth-first algorithm for breakfast and getting to the university.

Brains are fascinating.

Yes, they are.

All right, everybody.

It's been a very informative session.

So, before we go offline, a few announcements.

So, we're not going to be having any more loosely coupled streams this month, because February is just so packed with all various things, and presentations, and trainings, and too much.

So, the next stream is actually on the 4th of March, and we're going to be talking to Hien Verschatsche, a consultant from Ardling, and we're going to be talking about decision-making.

That kind of sounds like something we can put into an algorithm, to an extent, and that this skill of decision-making is actually a little bit of a loss in all the tasks that we're doing.

I think the premise is that we're all running with wheelbarrows, and those wheelbarrows are quite empty at times, and statements like, we've always done it this way.

So, that will be probably a very, very, very, very interesting conversation.

Now, if you're new to Bridging the Gap, or new to the YouTube channel, well, QR codes on the sides.

Go and see upcoming events of Bridging the Gap.

Go and look at what we have on the YouTube channel.

There's plenty of live stream recordings there.

And also, with Philip Costera, we're now running an integration-specific training, strategic integration design with DDD at DDD Academy, and we're teaching how to design interoperability at an ecosystem scale.

So, it's a challenging piece of content, and we're trying our best to outline it as easy as possible.

Not always possible.

But if you're interested, again, and see what that's all about.

That's it.

Pamela, thank you for a lovely conversation.

Thank you for tonight.

And everybody, thank you for all the comments and questions.