Show don't tell - why it's the secret key to project success

You may be familiar with the guidance: "show don't tell". It's good advice – do it. That said, let's explore why 'showing' is the path to consistently successful projects.

First, it's important to understand what show don't tell is really about, because it's why 'showing' improves projects and business outcomes.

It's also powerful to know what showing actually is – a slide show, a demo, a play-act, or something else?

Then it's crucial to grasp when show don't tell should be used, given a showing takes more effort than "telling".

When you understand those three views, you'll be half way to grasping how adopting a show don't tell way of working is the secret path to project success.

So, let me tell you about 'showing'. Because sometimes, telling is the right way.

What's "show don't tell" really about?

So firstly, it's important to understand what Show Don't Tell is really about. This is because it's the reason why 'showing' improves projects and business outcomes.

Action > Reaction > Result

The key to understanding "Show Don't Tell" is the phrase: "seeing for themselves". It's how the action (showing) gets the desired result "Show Don't Tell" is aiming for.

'Themselves' in the phrase 'seeing for themselves' is your audience of course. You knew that, but it's good to be clear.

To understand best, let's explore 'seeing for yourself' for a moment…

You're in the market for a house and there's one for sale. Which would you prefer?

a) Being told the house is great, or…
b) Seeing the house for yourself.

The answer is obvious: you'd prefer to see it for yourself, yes? 'Show' has won, 'tell' has lost.

The reason you'd prefer to see for yourself, here, reveals what 'Show Don't Tell' is really about.

The reason you'd want to see the house for yourself is: a house is a big complicated investment, with a lot at stake, and a lot to digest and weigh‑up.

All business projects, inevitably, involve big investment too. The most difficult to obtain is management and worker's time.

The colleagues who need to be involved also have a lot at stake, and a great deal to understand and assess, before committing to investing their time.

This is why 'telling' often gets tokenism. Where contributions are slow and minimal at best, and designed to obstruct real change, under a cloak of 'being on board' at worst.

'Showing', means colleagues see it for themselves (the need and benefit), and are motivated to invest.

Investment is at the root of the "Show Don't Tell" advice. Investment is what 'show don't tell' is really about.

And if colleagues can't see for themselves they won't invest. Unfortunately, the only way they'll see is if you show them.

That's the chain of action and reaction that's 'Show Don't Tell'.

You're never going to want to invest in that house no matter how great it sounds, are you?

If someone shows you it, so you can see it for yourself – well now, that gets exciting.

What actually is the 'show', in "show don't tell"?

There can be some confusion about what showing, rather than telling, involves.

It's not 'painting a picture with words' in the way writers of fiction do.

We're not in the world of escapism and entertainment, we're in the world of business and getting stuff done.

It's not about 'pretty' bullet point slides, with a photograph of a van because the topic is a delivery service… you've seen that one haven't you? †

Get rid of words – yes, 'do away'* with words. Ideally, minimise the number of numbers, too.

And please drop the photographs of happy people, and branded products, stores, and adverts, yawn. They're everywhere, bore your audience, and add nothing at all in terms of useful information.

Apologies, I know people invest a lot of effort in these things, and it's a heart breaking waste of everyone's time.

Show information, show it visually. Use drawn diagrams, maps, and convert data into something highly visual. Use artwork that passes the "Point n Grunt" test.

The what test?

The "Point n Grunt" test involves asking a question: If I put this visual in front of people, do I have to explain it, or can I just point, say one short sentence, and be confident everyone will 'get‑it'?

The visual will only pass the test with a 'yes' if the audience can do two things unaided – if they can see for themselves, the following…

1) They can instantly recognize what they're looking at from a metre or two away.

And, 2) they can immediately see what's broken, confused, or to be decided.

The ideal is: [points] "You can see the problem, yes?" [Waits a few moments] "Questions?"

That's showing without any telling.

(I'll be honest, that ideal is hard to get to, but the nearer you get – the better).

None of this is made-up, or theory. For 9 years, a UK PLC's major strategic transformation projects, involving £70m-£1.2b businesses, benefited from everything I'm describing here. The Group CEO said of us: Everything they touch turns to gold.

When is it important to show don't tell?

I've already touched on when applying 'show don't tell' is important (big investment, with lots to weigh-up and assess). It's useful to add some clarifications though.

Telling is okay

When things are simple, words and telling do just fine.

For example, a simple walk through like you're reading right now (with an audience of one) is okay as a 'telling' exercise. This exercise is close to a simple ABC: What is this definable thing; when to use it; and how we did it.

The moment things get complicated – 'telling' fails. And there's no 'kind‑of' fails, it fails.

Projects fail at an alarming rate

The rate of failure for strategic projects is widely reported as being high.

Projects involving long processes, lots of people, several products sold to several market segments, fuzzy unclear behaviours, and/or deep root causes (any or all of these) are more likely to fail than succeed. That's reality.

Witnessing the failure rate of a client's other projects over 9 years was heart breaking.

Customer journeys / experiences, and any sizeable transformation or operating model design project is in the lap of the gods when telling, not showing, is the main approach to their execution.

So there's a list of criteria that makes it important to apply 'Show Don't Tell'.

This adds to the lists above… Big investment from people in the organisation needed; cross-disciplinary cooperation critical, with likelihood of conflicting priorities and interpretations;…

…lots to assess; lots of moving parts; complicated for people to understand; processes that cross over silos; lots of unknowns and 'fuzziness'; deep obscure root causes at work requiring a lot of digging. You've probably thought of a few too.

I put the "Show Don't Tell" approach at the heart of real-world projects for more than 10 years.

I came to understand what the hidden power of a "show" discipline is: discipline. It takes discipline, a thoroughness, to be able to 'show'.

It's way easier to manufacture words. Showing is harder, there has to be more investigation and coordination in order to 'show'.

That's why it's not applied when it really should be: it's hard to do. It's not impossible though. We did it…

If you can't explain it simply enough for a 6 year old to understand, then you don't really understand it yourself
Often wrongly, but not inappropriately, attributed to Einstein**.

The secret path to consistently successful projects

Fully and clearly describing things is really hard. But good descriptions are key to clarity, which in turn is the secret to success.

The more complexity you're dealing with, the more imperative clarity is.

I often describe what I do as Making the complex simple. Make complexity simple, and everyone gets to see for themselves, no matter their expertise or involvement.

For 9 years, we put "show don't tell" at the heart of major transformation initiatives for a £6.4b UK PLC. These projects were full life cycle, involving diagnostic, feasibility, and implementation. And we did it this way…

The Show Don't Tell way of working

From the very beginning of our projects, we made everything visual.

Think of it as diligently describing and documenting a project in real time ('live').

Findings from everything we investigated were immediately translated into a visual map, diagram, chart or other visual description. Paragraphs, sentences, bullet points, and tables of numbers, were avoided.

These descriptions were then reviewed by – shown to – the whole team. This was often on the next day, because the review meetings could be ad-hoc.

No one needed to read-up, or study, because the visuals passed the Point n Grunt test. It took seconds to understand a visual description (especially for a team living and breathing the project).

Regardless of specialism, or familiarity with the process or business operation, everyone in the team could question and challenge the accuracy, truthfulness and oddities, of what they saw.

They could identify things that they'd not known, revealed in the visual. Theories could be formulated about why something was unexpected, or better/worse than was widely thought.

Rich discussions identified next actions, and the visuals were revised, or tagged with alerts (the good old sticky note). The need to pull-in other parties could be actioned immediately because the visuals were show‑ready

This is 'agile working'. The visual descriptions were tested with the team, and revised (iterated) as many times as needed until there were no challenges or questions remaining.

At any point in the project or time in the working day, the documentation could be presented – shown – to visitors so they could see for themselves what was being uncovered or proposed.

Anyone could challenge and question what they were seeing and their input included in a revised view.

No matter someone's familiarity with the business, its market, its products and its process, they could recognise what they were looking at moments after arriving and critique it (the power of the Point n Grunt test again).

This was how 'Show Don't Tell' doubled turnovers and added millions to the bottomline of a series of businesses for a UK plc.