Here’s A Wild Idea: Protect Your Map

Earlier this week a client told me a true story… it’s a simple one, but it’s one that should give you pause.

When he started at his current organisation just a few months prior he was told that “the staff here are highly critical and academic. They need sources for any new information or models you give them”.

Seemingly useful information to know upfront.

…However he’s now 6 months in, has rolled out several internal uplift programs across a few hundred middle managers and has not once been asked for his sources.

Cultural misperceptions are just as easy as gossip to pass on → but are often just as useless.

Without a doubt – getting a bearing on an organisational culture is a difficult thing to do, so when someone gives you a heads up, you listen. And that’s ok! But after you listen, you should then ask: “and where have you seen that in action? What does that typically look like here?”

There’s only two forms of answer to that. A specific one, or a vague one.

If specific, then you know it’s something to look out for and start testing for yourself.

If vague, then you can probably take it with a grain of salt.

So here’s the wild idea:

Next time you are told something about ‘how things are here’, ask them about their personal experience with it. It’ll help you build a more accurate map of the organisational terrain you’re traversing.

After all, as Hitchens’ Razor reminds us “what can be asserted without evidence can also be dismissed without evidence”.

Something To Ponder: Designed For Reality

This week I want you to take a moment and consider one question about your top priority change effort. Think back to its catalysing stages, and ask yourself:

What was figured out first – the solution to your problem, or how you would prove that the problem was solved?

We humans love to solve problems. It’s just so satisfying! – which is probably why we all love to run straight into figuring out solutions as soon as we think something’s wrong.

But what happens when you solve a problem that was known only vaguely in the first place? – well you build that vagueness into your solution. It’s this vagueness that causes scope creep, and scope bloat (after all – you’re really just throwing spaghetti at the wall and seeing what sticks).

If your team can’t consistently describe why you’re changing and what success looks like – then your problem is vague.

And that’s a good way to spend more time and effort than is needed.