Foreign.

Welcome to Consulting for Humans here with Mike and Ian.

And in each episode we're exploring a new topic that gets to the heart of what makes consultants how happy and successful.

That's right on the Consulting for Humans podcast.

As you know, it's our mission to add just a little more humanity to the lives of consultants and just like we're doing today, to bring some of the skills and perspectives of consulting to regular civilian human lives too.

So if you're a consultant who's trying to be more of a human, or even a human who's trying to be a little bit more of a consultant, then welcome, because we think you are just our kind of person.

Yeah, it's so true.

And for you humans trying to be a little bit more of a consultant, and there's some tips for you consultants as well in this part four of our Strategic Partner series.

Now we're mainly addressing this to business professionals who find themselves in influence or advisory roles, perhaps without formal consulting background or training for functional area practitioners, mid level managers, senior individual contributors, project managers, program managers.

Maybe you know who you are and that's why you're here.

And consultants as well.

In the last episode, we discussed asking better questions, a foundational skill for all strategic partners and consultants at all levels of the Strategic Partnership pyramid, which we've talked in a couple prior episodes.

We have.

And we're going to talk about ways to take ourselves up and along that pyramid this week.

We'll be diving deeper in this episode into problem diagnosis and opportunity identification, that crucial middle section of the pyramid.

You'll recall that understanding the problem lies right above answering questions, but just below provoking thinking.

So where beyond answering, but we're not yet provoking this week's topic.

We're going to call it Understanding before Being Understood.

Mike, I'm really excited to get into this.

We're going to talk about diagnosing a problem using our brain and our insight, gathering information systematically and ways for thinking about how we go about doing that, identifying root causes versus chasing symptoms and framing challenges differently so that our work and our problem solving process resonates with different stakeholders.

Mike, remind me, where does this thing come from?

Understanding before being understood.

Yeah, I mean, obviously we've got to go back to Stephen Covey's the Seven Habits of Highly Effective People.

Habit number five.

Yeah.

Seek first to understand, then to be understood.

So, Ian, get us started here.

What should our listeners be thinking about?

With pleasure, Mike.

Well, let's start with thinking back to a memory that lots of us might have.

I Know, I have.

Think about the last time someone asked you for help with what seemed like a straightforward request, only for you to discover later that you'd solved the wrong problem entirely.

Maybe you spent hours on an analysis, digging into the details, only to learn that the real issue was something completely different.

Maybe you got frustrated by the experience, because that certainly illustrates why diagnostic thinking and problem diagnosis sits at the heart of our model of strategic partnership.

This mid level of our pyramid represents this important transition from being reactive and just giving answers to being proactive and ultimately seeking out new problems to solve.

So at this middle level, you move beyond simply responsible, responding to what people ask for, and you begin looking harder to look behind what they actually need and understand that with a bit more depth.

And this shift doesn't only change the way that you work, doesn't only change your attitude, and also the learning that you get from your work.

I think it changes the way people see you because this shift transforms you from being a valuable resource into an indispensable strategic partner and mate.

Who doesn't want to be strategic?

More importantly, who doesn't want to.

Who doesn't want to be indispensable?

Absolutely.

I think I put my hand up.

That's exactly where I want to be.

I want to have a seat at the table, and I like getting in before the 12th hour when the answer's due at the 12th.

Yeah.

And I don't want to be sitting there at the 11th hour thinking, if only they'd called me.

I want to be kind of shaking the tree a little bit beforehand.

So maybe that's where we are with this.

Understand before being understood more.

Mike, what can we do to make sure people are solving the right problems rather than just addressing the symptoms on the surface?

Well, definitely we've got to use a systematic approach to problem diagnosis and opportunity identification that goes deeper than that initial request.

We've talked about it in a couple of these parts here.

It also means learning to see patterns that others miss, actually helping get others on board to spot patterns that we might have missed, asking questions that reveal root causes and as kind of mentioned earlier, Ian, framing insights in ways that resonate with different stakeholders.

You know, we want their involvement, we want them on board, we want them motivated, and we want them to see their win in all of this.

This level of strategic thinking, Ian, as you said, is what separates good functional experts from.

From great strategic partners.

And, Mike, there's something interesting for us, especially if we're in big organizations.

I don't think it's an Unalloyed, easy, kind of beneficial step to elevate our thinking to this kind of strategic level.

I think that people can end up thinking more like an outsider, and that has good sides and it has some challenges as well, this idea of taking an independent point of view.

I think we talked about it last time in the episode that we got into question types.

Just asking questions, just pushing back and challenging can make you look like a pain in the ass.

And it seems like we might be about to double down on the pain in the ass quotient this week.

Mike, what do you think?

Yeah, well, I think it's true, but if we're thinking about how this benefits others, if we're thinking about other stakeholders perspectives, if we can do this in a way that starts to add value rather than seeming to just be slowing down progress, why, you know, why don't you just get on with it?

You know, I told you what I did.

Just move forward.

If we can involve them that way, we can do it.

And, and it's been shown to have a lot of payoffs.

Right, right.

So, so what are the payoffs?

What's the benefit in slowing down our thinking and delaying the moment that we start to engage with the problem?

Well, you know, let's go to, you know, we had some great minds, Stephen Covey, you know, Maybe we invite Mr. Albert Einstein to the party.

We cannot solve our problems with the same thinking we used when we created them.

And so many times just answering questions.

We're staying in that same way of thinking mindset.

Or to quote Malcolm Forbes.

Welcome, Malcolm.

Always glad to have you here.

Friend of the show.

Yeah, exactly.

It's so much easier to suggest solutions when you don't know too much about the problem.

So sometimes it's also a little more comfortable that way.

Ah.

So Mike, how can we take a leaf out of Einstein's book and the leaf out of Forbes book and do all of this in service of Stephen Covey's advice?

Maybe we should start with the way that we go about defining a problem in the first place.

What happens when we look there?

Yeah, Ian, I think that's exactly right.

So let's talk a little bit about strategic problem diagnosis framework.

And you know, this varies according to where you put the emphasis here or the emphasis.

Right, right.

Is it a strategic problem diagnosis framework or is it a strategic problem diagnosis framework?

I'd suggest probably the latter because the latter works for the former as well.

So effective problem diagnosis is about following a structured approach.

We've talked about checklists before and ways of doing that, and it prevents us from immediately jumping to conclusions or accepting surface explanations.

So think, Think about this framework as our systematic method for understanding what's really happening before we start recommending solutions.

It's got four components that build on each other and that we'll continue to build upon as we go further here.

First, gathering a comprehensive context about the situation, the stakeholders, the constraints.

Now, we keep coming back to this every week.

So important.

Second, distinguishing between symptoms that people observe and the root causes that drive those symptoms.

So often we find ourselves really just trying to mitigate symptoms rather than getting at root causes.

Third, identifying the stakeholders who are affected by or who influence and can influence the situation.

Keep coming back to stakeholders again.

And finally, framing the problem opportunity, and sometimes both in language that resonates with each stakeholder group while maintaining accuracy about the true underlying issues.

Interesting.

So we're talking about being able to describe it in different ways without fundamentally blurring or kind of generalizing what it is that we're talking about.

That's quite a challenge.

It is a challenge.

I think it's a challenge, but it's a challenge worth taking one.

We'll see a lot more of the world, will get a lot more perspectives involved and will prevent that most common mistake that functional experts often make when trying to be more strategic.

They are often relying on their experience and intuition, which usually is really awesome.

And there's good reasons for doing that.

But because we come, you know, we've grooved that path so much, building on our own experience and intuition, building on our group's collective experience and intuition.

Sometimes we use it to diagnose problems quickly but miss important context nuances that could change our recommendations entirely, like you started the whole program with here.

So this framework ensures that you gather comprehensive information before moving forward and starting to draw those conclusions.

So, and how do we.

How we get to solve the real problem?

So I think we need to figure out what structured thinking, what systematic thinking really means.

And I want to introduce a word here that I use a huge amount when I'm coaching and teaching and leading people.

I want to talk about thinking diagnostically because thinking diagnostically is about looking for those patterns of cause and effect.

And to diagnose a problem is about being systematic rather than being random or than taking shortcuts.

As you said, Mike, lots of people approach information gathering a little haphazardly often because they think they know where to reach for, like, the information that's going to be helpful often because, like you say, the groove has been worn by Previous work where we think we know the sources that we're going to use and we know the analysis that we're going to run.

And we tend to focus on parts of the problem that make us comfortable or even, you might say, make us look good strategic partners people are who are trying to climb the pyramid.

You are a little bit more careful to use a structured approach to make sure that we're looking at the whole picture, looking at the whole situation before we jump in and form an opinion.

I've got a name for this technique of pre problem definition.

I'm going to call it the context canvas technique.

And think about a painting.

A canvas is an entire thing.

It's not an individual figure or an individual color or an individual line.

It's the entire image including all of the details represented, but also including the.

The whole thing.

What does it represent and what's it heading towards?

So thinking about context canvas means painting ourselves a picture that covers the different dimensions of any potential problem situation.

And as you can see here, there's.

There's going to be some overlaps with some of the stuff that we've talked about before and what's going to come later.

Now, one of the risks facing us with that, well, trodden groove that you talked about, Mike, is that today's version of the problem is likely to be different than the one that we last encountered.

And that's maybe something for us to challenge ourselves with before we get into saying, oh, this is a type X or a type Y problem, to take a moment and say, hold on, let me just test that assumption.

Is it really so similar to what I've encountered before?

And our expertise might be off in terms of relevance or in terms of being a reliable path if we're relying on expertise to frame the problem.

The world is changing, the world changes around us.

We've talked about that in previous episodes of the show.

There are different stakeholders around our organization.

They might be a different bunch of stakeholders than the ones that we are used to dealing with.

And again, that's going to come back to us later on in this episode.

If you work in life sciences, there are different therapy areas and domains.

If you work in tech, there are different verticals, there are different use cases.

People have different backgrounds, people, people with advice and information to bring often have different expertise and context of their own.

So what would it mean to do a good job with this canvas, this looking at the whole picture?

I think it means we understand a bit about history.

Like we understand what got us here.

What was the Timeline that led to the situation.

What do we know about what's happening now and what, what's the urgency in the deadline about this thing that we've been asked to do?

This canvas approach means that we paint a picture of all the different stakeholders.

We'll talk about how we do that in a moment in a bit more detail.

That means that we understand the constraints, not only budget limitations, but also resource availability, political small p considerations like who needs to look good coming out of this and what's the agenda that's been set, what are the promises that have been made?

What about regulation?

There are regulatory requirements.

And moving from a highly regulated to a less regulated part of the business can kind of jump out and bite you with surprising changes to the constraints that are either added or taken away.

And defining success, thinking broadly about the different ways that we can define success, understand what everybody would consider a successful outcome, how they'll measure progress, and understand how this is connected to other projects or analyses or questions or initiatives or programs or opportunities inside the organization.

So good canvas, good broad analysis of the problem means that we understand the timeline, we understand who cares about it, we understand the constraints, we know what good looks like, and we understand the points of connection.

And this put together helps us get a really comprehensive picture.

I'm using the visual metaphor again, a comprehensive picture.

Before we move to hone in on the detail of solution development.

Mike, you and I were talking about examples that we've come across in the past.

Some of the names changed to protect the guilty.

I mean, to protect the innocent.

What was the one you were talking about?

Tom?

Right?

Yeah, Tom, right.

An operations manager at a manufacturing company.

So we use a lot of life sciences.

Let's talk about manufacturing here.

He was asked to investigate why production efficiency had declined over six months.

And he was kind of steered in the direction and at an initial analysis that suggested that it's equipment maintenance issues.

And Tom felt under a little pressure, the way this question was asked, to update some of the equipment and get permission to spend some of the particular plant's capital budget.

That had often been done successfully in the past.

So it's kind of that grooved way.

But Tom, step back, used a systematic problem diagnosis to understand the situation more completely and adopted the context canvas.

So he discovered in painting that fuller picture that the efficiency problems they were facing coincided with the implementation of a new scheduling system and changes in the shift patterns.

Two things he wasn't tasked at looking at at all.

But looking at these further, Tom found that workers were struggling to adapt to new processes without adequate training, and that the new scheduling system created conflicts with the maintenance ro.

So his discussions with floor workers, supervisors, maintenance staff, again expanding that stakeholder map, brought this to light at the real root cause was inadequate change management, which was impacting worker performance and maintenance, not problems with the equipment themselves.

So his insights directed investment, far less investment we might add into the right solution.

Whereas he could have bought a bunch of new equipment and doubled down on this problem on new equipment.

Right.

And it happens a lot.

Right.

You think who would be crazy enough to just recklessly spend capital like lots of people do it.

People's favorite thing is to acquire assets or to.

To leverage their own position in the organization to get permission to do something big and eye catching.

Famous books have been written about this.

Eli Goldratt's book, the Goal is all about people recklessly over.

Over solving problems that are not the real problem.

So I think this is a great example.

Mike, thank you to.

Thank you to you and thank you to Tom.

Well, Ian, so you know, this is great.

Tom had a real breakthrough here, but I think some of us, you know, need a little help about distinguishing root causes from symptoms.

So it's funny, different ways of digging beneath the surface here.

Thinking about Tom's situation, we were kind of digging for the real underlying problem, like what's really been going on here.

Part of the reason for that is that we are too quick to jump to solutions, as was the case nearly with Tom.

It's also sometimes the case that we just accept a surface definition of what's been happening.

We just look at the symptoms, we look at an outcome, and we don't take the time to really find out what's leading to that outcome of root causes.

And I think engineers and scientists are great at thinking about root cause analysis that has a shadow zone that we'll talk about in a second.

But I want to talk about what it means to be really good at careful diagnosis and digging beneath the symptoms.

Our ability to distinguish between symptoms that people can observe and root causes is a big part of us being a great advisor to our colleagues.

Most people see symptoms because they're busy and they're short of time.

Symptoms are visible and immediate.

But addressing symptoms without fixing the root cause leads to recurring problems and leads to wasted resources from repeated superficial solution attempts.

The symptoms are generally what people can see.

And in an organization that means things they can measure, things they experience.

Sales numbers, customer sat, customer complaints, missed deadlines, employee turnover, employee lack of satisfaction.

And these are things that get measured and these are for sure real symptoms.

I'm not saying that they're fictitious, but they're usually the result of something deeper, something more underlying.

And thinking about root causes forces us to think about the fundamental issues that might mean a little bit.

As we talked about in the, in the Tom example, there's not just a problem with the performance of the machine that we're looking at.

There's a perform, there's a problem with the performance of the people.

Misaligned incentive systems that drive the wrong behaviors, inadequate training that leads to performance problems, unclear or absent decision making processes.

Which means that things end up dragging along in confusion and iteration and delay.

So thinking about root causes means being willing to look for what's less visible but more impactful than the symptoms.

Because the benefit to us is that when we fix one root cause, we might find that we fixed a whole bunch of symptoms at the same time.

Now Mike, I, I'm selling this right, like it's a universal good thinking, diagnostically thinking about root causes.

And lots of scientifically and technically educated people are really good at this.

And it can even feel like our superpower.

Especially when you've spot and when you spot a root cause that was hidden, that is counterintuitive and you can kind of whip it out in a meeting and go, aha, I found the real thing that's going on here.

However, just being focused on diagnosis is a weakness for us as well.

We're also going to need some empathy for the people who are affected by what it is that we're analyzing.

We need to be able to practice a little bit of what people sometimes call disparagingly politics, but we straightforwardly would call stakeholder management, understanding people and what they care about.

Yeah.

Ian, can you think of a good example there?

Well, I'm going to go past Tom and I'm going to talk about somebody else, let's call him Tim, who he used to work with.

This was a guy who was a very technically minded person.

He was in a role looking after a subject called health economics, which is very arcane if you don't work in the life science industry.

And he was working, supporting a team that was planning the launch of a new drug.

And he was giving a briefing to non technical colleagues about his work.

It was a briefing that they had asked for.

They basically said what's the latest situation on events leading up to this launch of this new drug and how is your economic analysis going?

Their context here was that there were high stakes.

A good or a favorable analysis meant Everything can go ahead.

A bad or questionable result could mean a major roadblock, like a delay not only to that technical process, but all sorts of plans and resources that other people had put in place at a critical moment in the launch in, as it turned out, one of their biggest markets, a country that was really important to them.

And this guy Tim gave a must have been a 20 or 30 slide presentation about the ins and outs of his analysis, highlighting lots of problems, doing a bit of diagnosis, and I won't bore you with the details, but it was not a comfortable 20 or 30 minutes because he raised lots of problems and lots of insight into potential weaknesses and potential flaws in this analysis, getting more and more challenged from the group until he got to slide 29.

And he finally said, here's my conclusion.

Despite all of these problems, when you add it all up, the analysis is still okay.

And at that point, I think a couple of people reached to throw something at this guy.

His meaning on slide 29 was, guess what?

The launch can go ahead as planned.

And he was genuinely puzzled.

Why?

He got really vehement criticism from his audience for taking their time and, you know, shattering their illusions temporarily in this really potentially very doom laden presentation.

From his perspective, the quality, and I'm air quoting here, the quality of his analysis was perfect.

It was spot on.

It was all factually correct.

But if he'd had a bit more understanding of the context, he could have been more helpful to the group for sure.

He would not have got anything thrown at him.

He would have made people more inclined to ask his advice in the future.

And that's an important one for us to remember when we're the ones who sometimes grouse about how people don't bring in my expertise or ask me to take a look until the last minute.

Well, maybe you haven't done a great job in the past at giving them advice in their context.

So this is a great example of being over diagnostic, a great example, by the way, of not understanding the stakeholder context.

And that by great coincidence happens to be the focus of our next section.

Right, Mike?

Yeah, exactly.

And this idea of stakeholder specific problem solving, that once we understand the real problem and we may well be working with multiple stakeholders to get there, we've got folks that are kind of helping us to solve the problem.

Also folks that are going to be impacted by the solution we come up with in all these stakeholders.

We want to make sure that we frame this in ways that resonate with different stakeholder groups.

Each stakeholder cares about different aspects of Problems or opportunities.

They respond differently to different types of information and language and they stand to benefit in different ways.

All of these are important pieces of the context and the communication that we need to pick up on.

So strategic partners learn to translate the problems and opportunity understanding into terms that motivate action from specific audiences.

Here, you know, just very high level example.

Let's talk about differences between senior executives and middle managers, frontline employees.

So three huge overarching stakeholder groups.

What would we think about?

Senior executives typically care about things like strategic implications, competitive advantage, financial impact, organizational capability.

So if we're talking to an executive audience, we want to focus on how this issue affects organizational performance, what it means for strategic objectives, what the cost of inaction might be, all using business language rather than technical jargon and connecting our analysis to outcomes that they care the most about.

And some people might say, well this is just a matter of jargon and maybe it is really, you know, business speak, technical speak, they're all jargon.

But we need to learn each other's tribes jargon, particularly this if we're trying to help another tribe here.

Right.

Language matters.

Right.

Words matter, ideas and associations matter.

It's what people remember.

It's how people share loads of non technical information with their colleagues and their family.

I think we can't be disrespectful about the need to think about language.

And I think it's a great underutilized skill that technical people have to be able to communicate clearly in someone else's terminology, simple terminology especially.

Absolutely.

And making sure that this particular stakeholder group understands why are you telling me this and what's in it for me?

If we're talking to middle managers rather than the senior execs, we might focus more on operational efficiency, team performance, resource allocation, implementation, feasibility.

So you know, how does what we're talking about affect their ability to deliver results?

What resources might be needed to address this?

How would the solutions impact their team?

So practical implications, actionable next steps, real good, important things in communicating with middle managers.

Now let's step again to another stakeholder group, frontline employees.

Right.

Well, typically what does this mean for me?

Talk about my daily work experience, tools, resources, make sure expectations are clarified, make sure I understand personal impact, because that's what I'm going to be wondering about the whole time.

So framing problems, opportunities for this audience emphasizes how this impacts their ability to do good work, what change might mean for their daily experience, how solutions could make their jobs easier and or more effective for the company, for their group, for Them.

So, Mike, we're really talking about taking what might be a simple or a common idea and translating it for these three different groups.

Right.

We've got the seniors, like you said, we've got the middle managers and we've got the frontline employees.

That's quite the linguistic challenge if you think about it, especially in a big organization with lots of structure and lines of demarcation.

Yeah.

And part of that, Ian, is that we're kind of taking different versions of our problem diagnosis and translating it for these different audiences.

So starting with this comprehensive understanding of root causes and implications and then developing these distinct framings that emphasize the aspects most relevant to each stakeholder group while maintaining the accuracy about the underlying issue in its entirety here.

We were talking about this the other day and you mentioned.

I think that was really cool, this idea that sometimes just starting with the assumption that there's three stakeholder groups could be really helpful.

Rather than say, oh, I need to stop and make a list of 17 stakeholder groups, let's just assume that they all fall into one of three types.

Kind of pretty prejudge a structure and force yourself to just create a structure.

I think it's a really great way of getting started.

I've seen so many people pause before thinking about stakeholder information because they think, oh, I have incomplete information, or it's, it's partial or it's messy or I don't know how it works.

Just assume there's going to be a structure, you know, I don't know, like the simple one you've already come up with Senior, middle and frontline, or maybe there's a friends, enemies and undecided.

There's going to be some kind of three box model that might at least help you to start putting things down on paper.

And putting things down on paper and talking about them is like half of the battle here, I think, when it comes to eliciting what's going on with stakeholders.

Yeah.

And if we think back to last week and the kinds of questions that we were asking and how we were asking, thinking earlier about the context canvas, we are starting to gather the information that allows us to make that translation already.

How does this impact?

Impact?

What would it mean to you?

How are you measured?

What success in your terms?

What are your timelines?

What are the impacts?

What are the, you know, all of those things helps us to then bring that back to address those.

And Mike, again, we were talking about this before the show.

You had a particular example in mind.

Somebody in the kind of customer experience and Marketing end of the world, I think.

Yeah.

Jennifer was a marketing analyst.

Name changed to protect the.

This.

I actually love this one.

So Jennifer, you know, Tag said, you know, we have declining customer retention rates, and our analysis suggests that this is pricing pressure from competitors.

So, you know, come on, Jennifer, you know, what do we need to do with our pricing to get through this?

Well, Jennifer didn't just do that pricing analysis.

She went to sales, customer service, product development teams and found something interesting.

In addition to looking at pricing, she found that the, you know, what it was really about was that retention showed up differently with different customer segments and that she found it was related more to product feature gaps than pricing issues.

Really interesting.

So once again, we could have made a decision that probably would have had much less impact, probably not as positive, much more negative.

So from her perspective, she saw these gaps existed because product development priorities had been driven by new customer acquisition rather than satisfying existing customer needs.

Ha.

Hence the retention issue.

Right.

And, you know, pricing, if you're not meeting needs, isn't going to necessarily change that.

So she framed this insight differently for the executive team.

She said, this is a strategic issue about balancing growth and retention need both.

Right.

This is the.

Let's look at how that works for product managers.

She talked about a prioritization and resource allocation challenge.

How do we suss through this?

And for sales teams, it was an opportunity to improve customer relationship management.

It's a lot cheaper to sell to people you already have than it is to sell to the new people.

So, you know, a great way of not only getting to the root cause and not just jumping to that.

Hey, here's a. Yep, I'm giving you a softball answer that you can just kind of give me some numbers to support and we can roll right on and make life easier for all of us, but let's actually get to a difference that makes a difference and show everybody involved how it relates to them.

Right.

It's a great way for somebody in Jennifer's position to, like we said before, to change the way that they are seen as well, because Jennifer stops being seen as just the customer retention person, they get to be seen as somebody who deals with problems at a bigger level.

It's a really great example.

Yeah.

Thank you, Mike.

We've had some great thoughts so far on diagnostic thinking, context reframing, and stakeholders.

We should think as well about what could go wrong.

I've already mentioned the pitfall of being over diagnostic.

I want to get into some more pitfalls more generally, if that's okay.

So here's one that is a bit of a trap for us.

We talked about this a little bit in the previous episode, but I want to get back into it.

One of our traps is the solution.

First trap.

At some point our brains are going to suddenly switch back to the meat eating, red blooded carnivores that we really are and we're going to go, I have a solution.

And that's a real problem for us.

We undermine our diagnosis.

We undermine the independence of the position that we've taken.

If we jump to solutions too quickly and if you find yourself drawn by who knows what instinct to jump into solutions before you fully understand the problem, you're likely then filtering information out.

You're likely stopping yourself from considering all of the fact based.

You're biasing yourself basically towards confirmation of something that's already in your head.

You look for signs and information points that support the approach that you've got in mind rather than gathering a comprehensive understanding.

We need Mike, especially when we've got a bit of experience and we've seen a few solutions and we can reach for them really readily, we need to resist the urge to propose solutions when they're in the diagnosis phase.

I've sometimes given this as a coaching tip to people working on problem solving.

I'm like, if you've got a good idea for what to do, then write it on a post it and stick it away somewhere where you can't see it and feel good that you've got it, but ignore it and keep going with your diagnosis.

We should be focused at the beginning entirely on what's actually happening and why it's happening.

That's the diagnostic part.

If we can stick to that discipline, we get more accurate diagnosis.

I think we get to bring people along with us as well because it's going to take our stakeholders a little time to understand the diagnosis that we've made and usually reveals better solutions.

We'll reveal solutions that are going to solve more of the problem rather than solutions whose main virtue is that they are familiar.

And it sounds a really easy thing to say, Mike, but I think it can be a real trap, a real hurdle for teams and individuals.

Yeah, I can't even count how many teams I've seen get stuck and waste a lot of time and resources jumping too quickly to solutions.

It's one of those aphorisms that works at multiple levels.

We never have time to get it right, but we always somehow find time to do it over right.

So let's take that time and push it a little earlier.

We Won't have to do it so much.

And I've seen so many people, including me, get stuck in their own specialist expertise as well.

You know, it's just that, well, groove path we talked about earlier.

Which brings me to another pitfall, another groove that we get stuck in.

That's the language barrier, the technical language barrier.

And technical experts often undermine their impact, their strategic impact, by framing problems using language that only other technical experts understand.

And it creates barriers between our insights and the stakeholders who need to act upon them.

So, you know, I'm thinking back to your great example of the technically minded health economists, you know, addressing the commercial audience.

That happens all the time, that kind of thing.

So we really have to practice translating our problem diagnosis into business language that emphasizes outcomes and implications rather than technical details, and find peers around you that do this well, listen to presentations and discussions and spot where this is happening and pick up on that.

Focus on what the problem or the opportunity means for each stakeholder group success and for the organization's success overall, rather than just the technical mechanisms that create it.

This translation makes our insights more accessible, more actionable, and therefore infinitely more valuable for different stakeholder groups.

Yeah, it's great.

I think we need to learn to be able to spot that moment when we are relishing and kind of rolling around in our technical language.

And it feels great to us and it creates that sense of interesting otherness for us, but it's a distraction.

So, Mike, we spent some time now talking about the power of doing better problem definition.

Basically, we've really focused on understanding the setup and the context of a problem before we leap in and try and solve it.

I think if we can do well at problem definition, we have a better chance of acting on Stephen Covey's advice about understanding rather than being understood.

In fact, going back to our little quote jam that we had going on at the beginning, there's another quote that I've often heard is attributed to, to Einstein, which summarizes the power of problem definition.

Einstein is alleged to have said.

I'm not sure that he did, but never mind.

He's alleged to have said, if I had an hour to solve a problem.

Or in some versions of the quote, it says, if I had an hour to save the world, I'd spend 55 minutes defining the problem and then 5 minutes actually solving it.

So there is value, like there's worth in investing the time and in really characterizing the problem.

The more gnarly and interesting and unfamiliar the problem, the more there's benefit in really making sure we characterize it before we leap ahead into the next part here.

Yeah.

You know, our colleague Ann Frazier does a lot of great coaching and great training around problem definition.

Just problem definition.

Yeah.

And I remember hearing from her about a dog shelter and this, you know, Einstein's idea applied this idea that they were going to have to.

They were looking at this incredible ramping up a while back of the need for more dogs, more homeless dogs, more homeless pets, cats and dogs.

And you know, the problem was how are we going to raise enough money to build the increasing capacity that they need.

What they ended up finding out though, because of a couple folks that dug under this one, seeing the magnitude of the quote unquote solution to that problem, was that there were great ways to develop ways to keep pets from becoming homeless or to find other to solve that homelessness problem beside bringing them into the shelter.

So it led across, you know, many parts of the country and the world to pet retention programs, surrender prevention programs that really, rather than building more capacity built ways to help fund and support and organization support for people to keep their own pets or to go through temporary crises like medical problems or housing things.

And it just was an amazing thing where the win, win, win, win, win all the way around was huge rather than this huge capital investment that would have perpetuated something that meant a lot more pets being removed, a lot more pets being put down because they couldn't be rehomed.

A of lot all the.

I mean, this is just one of these things that just makes you feel so good.

And it was all problem definition.

Right.

In fact, to stay in quotation mode for one more round here, there's another great quote from friend of the show, Stephen Covey, also in his book 7 Habits, which says the way we see the problem is the problem.

And that's.

I think I'm going to get the tattoo that says that somewhere.

Now, Mike, we've got some great ideas and frameworks.

We've identified some really important pitfalls.

I think we're getting to the time in the show where we can pull it together and think about what listeners can do in practice to employ some of these ideas.

Well, what can we do?

You're out there listening here.

Let's talk about one exercise.

It's a great way to start putting these ideas into practice.

Root cause mapping practice.

So take a current problem or challenge you're working on and apply systematic root cause analysis.

So just start by clearly describing the observable symptoms.

You know, what can people see or measure?

What do we got there and bring some other folks in, get that out.

Then create a visual map showing the relationship or potential relationships between symptoms and root causes.

So draw connections between different causes to identify what root causes contribute to multiple symptoms.

This mapping often reveals leverage points where addressing one root cause could eliminate a number of symptoms simultaneously.

So you might spend some good time with this and then start to share this with somebody else you know who understand the situation.

Ask for their perspective.

They might identify additional causes that you miss.

They might challenge assumptions that you're making.

And this collaboration improves not only the accuracy of your diagnosis, but also build stakeholder buy in for eventual solutions.

Great, Mike.

I love the visual theme there.

I think it's a really great part of collaborating and sharing ideas.

I also love the idea of bringing in someone else's perspective and sharing our thinking before it's kind of complete and polished.

My suggestion for an exercise is similar, but it relates to the stakeholder perspective.

Thinking about multiple people with multiple angles.

And we've talked about that a lot already in the show.

Take a problem that you're currently working on, that you're currently analyzing and identify those three different stakeholder groups.

It doesn't matter if it's a complete list or not, doesn't matter if they're kind of perfectly well defined.

Identify three archetypal sets of stakeholders who are either affected by or who can influence the situation that you're talking about.

And for each group, do some research, find out what they care about most.

Find out what kind of language and words and associations are important to them.

Find out what outcomes matter to them.

Don't take your own intuition as enough.

Go and talk to some people, have an open agenda conversation with some people who represent these stakeholders.

You will almost always learn something by going and asking people to talk in an open ended way about their work and their perspective on it.

And you could then generate for the work that you're doing for three different stakeholder groups, therefore three different problem statements, different ways of framing the underlying issue, and finding ways to use language that emphasizes the aspects that are relevant to that particular part of the audience whilst also being straight and accurate about root causes.

This is a really interesting language challenge.

Can you keep the core of the problem unambiguous while finding ways to define it that look appealing from these different perspectives?

Practice explaining a diagnosis, practice explaining your problem definition to people using their language and sharing examples that resonate nice.

And I think this multiple stakeholder kind of iteration practice is really useful.

Even a very simple analysis, a very simple piece of project work can be fascinating when you look at it from three different perspectives.

Find out whether your framing resonates with the concerns that your colleagues have.

Find out whether the language is motivating to them to for to get them to engage or to get them to buy into your solution.

And use this as a vehicle for getting feedback from them as well.

So do something practical with your stakeholder perspective rather than just kind of worrying about it or denying it.

That's my tip, I think.

Mike, what would be your remaining top tips for how we can seek to understand a little bit better and a little bit sooner?

You know, I think, you know, you tagged it earlier in the show.

Just committing to this understand first protocol in daily work.

So before responding to any significant request or challenge, commit to spend time understanding the full context before developing recommendations here, even before developing a diagnosis, especially if there's a diagnosis being handed to you.

Just show me that this is right here.

And remember that this idea of understanding before being understood isn't about delaying action.

It's not creating analysis paralysis.

It's ensuring that the eventual recommendations address the right problems and resonate with the people who are needed to implement the solutions here.

You know, it's going to solve the problem for the people who have them.

It's going to create the problem for the people who could address those.

And we're going to get the people on board that are needed to be on board to make this happen.

So the upfront investment in understanding usually accelerates the implementation and improves the outcomes because we're solving the right problems and people come to agreement that it is the right problem in ways that stakeholders can support.

It's the essence of moving up into that strong middle level of the strategic partner pyramid, transforming from simply answering questions into helping others understand what questions we should all be asking and different people need to be addressing because we get to a definition of the problem, an understanding of the problem, or the opportunity here.

So mastering problem diagnosis skills make for indispensable strategic partners who add genuine value to every situation they encounter.

And like we said before, Mike, who wouldn't want that?

Hey, yeah.

Well, Ian, let's pull some final thoughts together here.

So, Mike, my final thought here is that this is for me, for myself as much as me, for a listener who's listening.

We're gonna need to be good at spotting the moments when our mind races towards a solution.

You know, we smell blood in the water, and all of a sudden our good and independent and careful thinking process just gets scared off and our mind races toward doing the thing that we think is most urgent.

I think learning to spot those moments, it needs a bit of self awareness.

It needs us maybe also to have, you know, friends and colleagues around who can give us a little bit of feedback as well.

But spot the moments.

Remember what it feels like when you succumb to this desire to rush to a solution.

I think that's going to be a really great thing for all of us to take away.

Yeah.

And for me too.

I want you to know and acknowledge, I think, and this is my thinking back to personal reflection.

Pausing might be uncomfortable, especially if this is something new to you.

You know, you're trying something new here, you're learning, you're walking before you're running here.

And some people will push back, some people won't understand at first.

So again, uncomfortable.

But nothing succeeds like success.

Yeah.

Yeah.

Thank you.

My final thought is I'm kind of thinking back about all the language that we've used about, not only about understanding strategic context and stakeholders.

I've talked about slowing things down.

I've talked about being a kind of low key pain in the ass.

I've talked about taking an independent perspective.

I want to try and remember that you don't have to be arrogant to be a good strategic problem solver.

You can do this with humility.

You need to be able to have some self respect as well.

But you can do this without being a jerk, basically, and you'll be valued for it as a result.

So, Mike, I think we've had a really great discussion of how to understand first before we seek to be understood.

I want to thank friend of the show, Stephen Covey for bringing us that quote.

I want to thank you, Mike, for bringing that quote up to get us started on the show.

I want to thank the listeners as well for being with us.

We really hope that it's being useful.

You've heard our contact details in the little break in the middle of the show.

Please do reach out to us if you've got anything new that you'd like us to be talking about in this series.

Meanwhile, please join us next time when we'll dive deeper and climb further into becoming a strategic partner.

We're going to move from critical thinking to define a problem to critical thinking to diagnose and develop a solution.

So one more step along the pathway.

We hope you'll join us then on the Consulting for Humans podcast.

The Consulting for Humans podcast is brought to you by P31 Consulting.