And one of the many things I learned through the medium of LEGO.

Sometime around 2010 or 2011, a major UK broadcaster decided it was going to improve its relationship with suppliers. It had been under scrutiny for how it selected partners, some of that criticism came from me. In response, it introduced a set of initiatives that looked sensible on a slide, but created friction in the real world.

One change was simple: instead of awarding each small project to one chosen company, they started inviting five companies to pitch. On paper, that sounds virtuous. In practice, it was an industry tax.

A decent pitch is not an email and a nice slide – it is usually a week of work from at least two people, sometimes three. Multiply that by five suppliers and you are asking for 60-plus days of free labour for a project that might only be worth 50 days of paid delivery. You can call it openness if you like, but the arithmetic does not care what you call it.

Still, that was not the part that stuck with me.

The LEGO lesson

The part I still tell as an anecdote happened at a one-day supplier event held at their offices. About twenty-five representatives were invited in. There were talks, workshops, and a lot of content that was supposed to help us become ‘better suppliers’. It was well meant, but it had the faintly familiar tone of being done to us rather than with us.

We broke for lunch. When we came back, there were piles of LEGO on every table and a white envelope. We were put into teams of five and told not to open the envelope until the timer started. I think we had forty-five minutes.

When the timer began, we opened the envelope and found the instructions for what we were meant to build. I was nominated as the ‘leader’ because I had the most project experience, so I did the obvious thing: I read the brief, translated it into tasks, and started delegating.

Our instructions told us to build a house. It specified the shape, floors, the number of windows and doors, and a few details about the surrounding garden, possibly the number of rooms too.

As we built, I glanced around the room. Most tables had LEGO sets that looked similar to ours, but the outputs were wildly different. Some teams were building something that looked like abstract art. Others were hunched in a group over the instructions and you could feel the stress rising by the minute.

We got our heads down and built. As the timer approached the end, I checked our build against the requirements. I was happy that it looked like what we’d been asked to build and conformed to the spec, I felt the familiar satisfaction of a job well done.

Then came the reveal.

Every team had been given exactly the same LEGO set – but a different set of instructions. One team had a single paragraph. Another had a little more. One had several pages. The last team had the official LEGO booklet.

My team – however – had a single page with clear, bullet-pointed requirements.

The workshop had been organised by the legal team. The lesson they were trying to teach was that detailed specification in a contract is important. More detail means less ambiguity. Less ambiguity means fewer disputes. Fewer disputes means better outcomes.

It was a neat story. It just was not the story the room experienced.

The teams with the shortest instructions produced something creative, but unusable. The teams with the longest instructions did not finish at all.

Not because they were incompetent or dysfunctional – they simply could not identify what mattered quickly enough, or delegate effectively, because the instructions were too complex and too hard to communicate.

Anyone who has built a LEGO set with a child already understands why. The official instructions are fantastic if you are building alone and you can keep your place. They are terrible if you are trying to split the work between five people under time pressure. They’re not naturally summarisable and you can’t easily separate them into tasks, so you can’t divide and conquer. At best, one person builds while someone else hunts for pieces – everyone else hovers.

The only team that finished cleanly was ours. We had enough detail to align on what mattered, but not so much detail that “reading the instructions” became the work.

When documentation turns on you

That’s the thing about documentation that organisations miss. It is not that documentation is bad. It is that there is a point where documentation stops reducing risk and starts creating it.

As a document grows, it becomes harder for a human to review it properly and hold it all in their head at once. That makes estimation worse, because you cannot see the full shape of the work. It makes risk management worse, because you cannot see where the weak assumptions are. It makes delegation worse, because nobody can translate it into a shared plan without losing nuance, momentum, or both.

Then, inevitably, the document becomes harder to maintain.

The heavier the documentation, the less likely it is to be updated regularly, because updating it becomes a job in itself. Scope drifts, reality changes, the team learns things but the document remains unchanged. You end up with a tragic kind of waste: smart people carefully building the wrong thing because the paperwork said so.

And, even when documents are kept up to date, too often they’re not revalidated. They are written at the start of a project, when uncertainty is highest and confidence is often misplaced. Months or years go by and meanwhile the market, audience or platform shifts or constraints change. Assumptions that were shaky at the start become actively wrong and yet the document still sits there with the quiet authority of a frozen decision.

Problem-first specs

This is why I increasingly prefer problem-first specs.

A good spec, in my experience, is not a novel about the solution. It is a clear statement of the problem, the constraints, the success criteria, and the things we are explicitly not trying to do. It gives a team a way to make good decisions as reality changes, rather than a list of steps to follow even when reality is shouting that the steps are wrong.

In other words, the best documentation is often the kind that can be explained.

The LEGO workshop is an old story, but the lesson has stuck with me. If your documentation cannot be shared, summarised, and delegated, it is going to slow you down, no matter how well intentioned it is.

AI arrives on the scene

Interestingly, this is where that story becomes remarkably current, because AI has changed what it feels like to work with documentation.

There is an obvious risk – AI makes it easier than ever to generate documentation quickly, and therefore easier than ever for people to ship words they have not properly checked. It can create a kind of synthetic certainty: a thick document, written fluently, that nobody has really interrogated.

But the reverse is also true.

Used properly, AI is exceptionally good at making long-form documentation workable again. It can digest documents that are too large for a human to comfortably hold in their head. It can summarise, compare, and surface inconsistencies. It can take something sprawling, make it legible and act as a productivity partner in exactly the way a good colleague would. By taking the first, boring, “read this and tell me what I missed” pass.

For example, a feature of the kind of work I do is that I get exposed to a lot of legal documents. Licences, terms, partner agreements – all the usual stuff. It’s not difficult work but when the documents are lengthy the time cost of reading them properly adds up fast.

AI has become very useful here. I can ask it to summarise a document, read it from the other party’s point of view, and sanity check it against a short brief of what we are trying to achieve. I still do the final review myself, but AI makes the first pass quicker and more structured, which means I can spend my time on judgement rather than page-turning.

That is the opportunity here.

AI does not make documentation more correct and, used badly, it will let you produce thicker and thicker tomes that feel like progress. But used well it does the opposite – it makes it cheaper to interrogate, easier to compare, and faster to keep aligned with what the work is actually doing.

Conclusion

Whether you use AI or not, the takeaway is simple: don’t let documentation lock in a solution before you have validated the problem. Once it does, it stops helping coordination and starts resisting change.