Are you building a spaceship like a bunch of idiots?

As you may or may not know, there's a scene in The Lego Movie where everyone’s trying to build a spaceship.

Emmet’s following some rather old-fashioned instructions.

Wyldstyle’s going rogue with a “cooler” design.

Batman’s insisting on “black, or very dark grey” bricks.

And Unikitty’s adding rainbows because, well, why not?

The result? A chaotic, incoherent mess that barely holds together.

This is pretty much what happens on a lot of teams when they’re planning a technology roadmap.

Everyone has a different idea of what a “spaceship” ought to look like in the end. But because they’re discussing it conceptually, nobody realises until it’s too late.

If you don’t have shared understanding of what your spaceship is supposed to actually do once it’s launched, then it’s impossible to prioritise the Lego bricks you need to use.

• One engineer is prioritising all the lightest, most aerodynamic pieces.
• Another engineer is gathering heavy duty pieces for use in the thrusters.
• One designer votes for angular, futuristic pieces with cool gradients.
• Another designer is pushing for rounded ergonomic pieces for the crew’s comfort.
• Batman is hoarding the black bricks, planning cool extra features like shark-repellent bat spray and the mandatory secret bat cave.
• And the CEO just wants the damn thing in orbit by Friday lunchtime.

This is an impossible prioritisation problem. But the problem isn’t with the bricks. It’s with the fact that there are no shared boundary conditions for success.

Does your spaceship even fly, bro?

Let’s say that after enough debate and bunfights, the team above finally agrees on a design. And to be fair, it does look amazing. Angular and futuristic but comfortable and ergonomic. Lightweight but heavy duty. It’s even got a bat cave. And the CEO loves it.

There’s just one small problem: it can’t get out of the atmosphere.

This is what happens when you focus on aesthetics or features instead of operational success. A spaceship that looks cool, ticks all the feature boxes, and can’t fly.

The mistake here is thinking you can predict the “right” design at the start. You can’t. No one can. The right spaceship design will emerge through iteration and learning — not from a gorgeously rendered drawing that looks cool but doesn’t work.

Following the instructions can only get you so far... if there even are any instructions

If you’re building something you’ve built before, you can, to a degree, rely on a proven blueprint. This works for well-defined problems with clear solutions. In reality though, those sorts of problems are few and far between, because reality keeps changing.

In the Lego Movie, Benny is a spaceship obsessive and knows exactly how to build one. But his design is outdated. The others can sense this and rebel against it – which may well be the correct instinct – but unfortunately they don't know how to avoid to breaking the underlying physics. This is a complex problem masquerading as a complicated problem.

And if you’re doing anything that's innovative from the ground up, there are no instructions to copy. In those cases, there’s no Benny, and waiting till you find the right set of steps to follow is just wasting time.

The “what type of thing is it?” incoherence trap

Most teams fall into a trap where they’re worried mainly about what “type of thing” they’re building, and the sorts of features such a type of thing “should” have. This leads to the incoherence of innovation through direct copying.

This is why strategic alignment is so hard. It’s not about agreeing on the bricks, or even on which type of spaceship you should be building from the existing categories. It’s about agreeing on the non-negotiables – the irreducible set of conditions that must be met for whatever thing you end up building to succeed.

The way out of this trap is to zoom out to the broader context your thing needs to operate in, regardless of what type of thing it might be.

For instance, maybe you’ve been worrying about how to get your spaceship into orbit when the better solution is to construct it in orbit.

Or you might even find you’ve been fussing over how to build a spaceship when what you really needed all along was a hot air balloon.

How to avoid the above trap

1. Define the boundary conditions.​
   Before you start building, agree on the non-negotiables and the negotiables. What must the "spaceship" achieve? What hard constraints are we operating within (time, budget, resources)? What are we definitely not going to include? And what tradeoffs are we working within – where could we have more of A if we’re OK with less of B?
2. Start small and iterate.​
   Build extremely crappy little prototypes that push up against your boundary conditions. The prototypes shouldn’t be pretty. They should be blazingly fast to build, and just enough to work at the most basic level. Use the handiest Lego bricks, don't waste time finding beautiful matching ones. Then learn from the results. Use the feedback to better understand your boundary conditions and refine your designs. Using real signals from interacting with the real world can be messy, but it will align your team faster than any amount of debate or any prioritisation scoring spreadsheet. Avoid A/B testing at this stage. (As quoted in a recent Experimental History: “To get to the moon, we didn’t build two groups of rockets and see which group made it to orbit.”) Instead, remember Gall’s Law: “A complex system that works is invariably found to have evolved from a simple system that worked.”
3. Prioritise in context.​
   Once you have a clear understanding of the boundary conditions and have discovered a successful design through iterating your way to a working prototype, then you can prioritise the bricks and build it properly. Your spaceship needs to survive in the vacuum of space... but no prioritisation method can survive in a vacuum. You have to tie prioritisation back to your shared understanding of what it actually takes to get this thing into orbit.

The Lego lesson

The moral of the story in The Lego Movie isn’t just about teamwork or creativity or being careful with superglue. It’s about coherence.

You can’t prioritise the bricks when everyone’s imagining a different spaceship – only when you’ve determined what it will actually take for your spaceship to do what you need it to do.

To figure that out, use whatever bricks you can find as a means to an end. It doesn’t need to look good in the early stages. Use black bricks, very very dark grey bricks, rainbow bricks and any other gubbins that's lying around.

When you’ve understood what it’ll really truly take for the spaceship to succeed, then it’s relatively easy to figure out the rest.

Guaranteed: the resulting design won’t look like anything anyone imagined at the start. It will be better than they ever dreamed.

Tom & Corissa x