20: 1+1=5

My daughters’ favourite birthday presents are always cheap, sparkly and plastic.

But you know what endures?

Lego.

They're still playing with it years later. Whereas the pink crap occupies them for a matter of days.

And you know why?

Because the value of Lego compounds. After they’ve built the thing, the pieces go back into the toy basket and then emerge again on a rainy day. And on the next visit, they build something new - their creations limited only by their imagination (apparently, just six standard 2x4 bricks can be combined in more than 915 million ways).

And the reason this is possible is standardisation.

Whether you start with a fairy princess castle or the Millennium Falcon, you can combine the pieces to build whatever you want.

So, Lego didn’t succeed because we enjoy building the toy pictured on the box. They succeeded because of what we can build afterwards.

And it’s the standardised design of those bricks that enables this. No matter which design they release in future, those bricks will grow in value (a tub of random second-hand Lego bricks is extortionate!).

So, why are we discussing Lego?

Well, building a Lego toy is just like doing our work. The picture on the box shows us what we’re trying to build (the output), and the instructions give us a sequence of tasks to help build it (the workflow).

But can you see the difference? Lego doesn’t create a new type of brick for every toy - it uses the same standardised components.

Is that the same as our work? Nope. When it comes to work, we're all freestylin'.

Of course, there’s the odd process that’s documented and followed - but the vast majority of work is done on the fly. We try things. We ask a friend. We cobble together activities that get us to a satisfactory outcome.

And over time, we build experience. We figure out what works and develop our own systems - usually combining memory, pinned emails, saved documents and bookmarked websites.

We do get better at doing our work. But we rely on heroic effort.

And the improvements rarely compound.

We know this because when talented colleagues leave, they take most of their expertise with them.

So, the real opportunity is to design tasks that can be used across several workflows. Instead of forcing every team or individual to solve the same problem independently, we could identify and design the most important tasks i.e., define the context, write the instructions, establish the guardrails and create the blueprints needed for consistent execution.

And once an important task has been designed, it can become a reusable component. It can be leveraged in other workflows.

The more workflows using it, the greater the ROI.

So, how might this look in practice? We’ll get to that next.

Yours,
- Ant