Don't Take Their Legos Away

A long time ago, a CTO I worked for pulled me aside and gave me one sentence of advice:

Don’t take people’s Legos away. They just want to play with their Legos.

I nodded. I thanked him. I ignored him.

Then I spent the next stretch of my career being technically correct and quietly alienating every team I touched.

What I Did Instead

I saw a team with problems. Fine. I solved the problems. I drew the diagrams. I wrote the plans. I presented the finished thing and said “here you go, ship it.”

The plans were sound. The architecture was defensible. On paper, on the whiteboard, I was right. On every axis that actually mattered for outcomes, I was wrong.

The team didn’t ship faster. They shipped slower. Every small decision, the kind I used to trust them to make in five minutes, became a half-hour conversation about what I really wanted. I’d optimised the answer and uninstalled the people.

What I Got Wrong

The CTO’s advice wasn’t about Legos. It was about the fact that the interesting part of engineering is the building, not the built. I’d skipped to the end, stolen everyone’s Saturday afternoon, and handed them a finished model with a look that said you’re welcome.

The original idea is Molly Graham’s “Give Away Your Legos” from her time at Facebook: as the company grows, voluntarily hand off parts of your job or you become everyone else’s bottleneck. That’s the employee version. My CTO gave me the manager’s inversion: don’t be the one walking up mid-build and taking the bricks out of someone’s hands because you reckon you can assemble a better ship.

I was taking Legos away. I thought I was helping. I was not.

The X-Wing, the Tie Fighter, and the Millennium Falcon

Joe is building an X-wing. Bob is building a tie fighter. Nigel is building the Millennium Falcon. I’m Nigel’s manager.

A couple of things Nigel’s manager does not do:

• Nigel’s manager does not steal the X-wing and the tie fighter off the other desks to recreate the Battle of Endor on Nigel’s behalf. The other two were in the middle of something. They were enjoying it. You just demolished both of their afternoons and called it leadership.
• Nigel’s manager also does not build a Lego assembly line that delivers bricks, one at a time, in the exact order and orientation required to produce the Millennium Falcon to spec. That isn’t engineering. That’s a factory line dressed up in a hoodie. Nigel is bored. Nigel will leave. Nigel’s replacement will be bored too.

Nigel’s manager picks the theme. We are building Star Wars. We are not building Technik fire trucks today, sorry, different bag. Beyond “we are building Star Wars,” the details are Nigel’s.

If Nigel’s cockpit is purple, and it flies, ship it.

Why This Matters More in 2026

I want to say this was a lesson about leadership in a simpler time, but it isn’t. It’s a lesson that matters more now than it did when the CTO said it to me.

Andrej Karpathy’s framing of 2026 is that engineers are not writing the code directly 99% of the time and are instead orchestrating agents. The product engineer role absorbs the PM layer, the architecture layer, sometimes the design layer. Judgment is the skill, not typing speed. The bricks are cheap. The bricks come out of a tap. The last thing you want to be is the person standing between your team and the tap.

Clean Code Is Lace Now

There’s a deeper version of the same mistake, and it’s the one I’m catching in myself the most these days.

When mechanical watches got industrialised, the finest watchmakers in the world were still sharpening a craft the market had already stopped buying. The Nottingham lace-makers put decades into a skill whose economic floor collapsed the moment the looms caught up. The Luddites saw the same shift and smashed the machines. History remembers exactly one of those three groups as heroes, and it isn’t the skilled ones.

Here’s the uncomfortable claim. Uncle Bob’s whole canon rests on the premise that code is read far more often than it’s written, so you optimise ruthlessly for the reader. That was true and it was load-bearing. When the reader is increasingly an agent that doesn’t care about your file structure, the economics that justified the craft start to wobble.

And the target keeps moving. The model you’re optimising for today is one quarter from being replaced by one that prefers a different shape. Today’s clever refactor is next quarter’s wasted effort, because next quarter’s agent regenerates the same surface with a different grain. Hand-stitching code this sprint is a watchmaker’s instinct in a quartz economy.

Taste doesn’t disappear. Security boundaries, data contracts, the shape of the interface all matter more than ever, because agents will gleefully cross whatever line isn’t drawn. What’s changing is the scrutiny we can still afford to spend inside the box: the thousand tiny craft judgements about function length and file shape and naming purity. Your instincts about “good” code were forged in a world that’s one model generation out of date. Letting them drive reviews is how you become the person taking everyone’s Legos away, not out of malice, but out of craft.

We’re in the business of shipping products. Not agonising over how the product gets built.

The Shape of Not Taking Their Legos

The practical version of the advice, translated for the agent era:

• Pick the theme, not the build. “We are building Star Wars” is a manager’s job. “Use a 2x4 green brick here” is not. In code terms: the constraints and the outcome are yours. The implementation path is theirs, even if theirs is an agent.
• Trade a brick when they’re stuck. Don’t finish the ship. If Joe’s X-wing has a structural problem, hand him a different hinge piece. Don’t assemble the wing for him and hand it back complete.
• Let the ship be weird. If it flies and it’s Star Wars, it’s fine. Purple cockpits are not a defect. In 2026 where the code is cheap and replaceable, most of what you’d “correct” is taste tax.
• Zoom out on the how. If an agent produced the first draft and it works, resist the urge to rewrite it to match the shape of the code you would have written by hand. Nobody is reading it. It will get regenerated next sprint.

There’s still a place for the architect who draws the hard lines. Security boundaries, data contracts, the shape of the Star Wars universe as opposed to the fire truck universe. That work is real and necessary. It just isn’t most of the work, and it isn’t most of what leadership mistakes for its job.

What This Doesn’t Solve

I’m writing this in 2026 and I can see, right now, a handful of people doing exactly what I did. They’re sure they’re right. The plans are sound. Their teams are quiet in a way they read as respect. They will keep doing it until they can’t.

There is very little I can say that will land. I know because I got the sentence, clean and direct, from someone whose opinion I already respected, and it didn’t land for years.

Some advice you can’t argue someone into. You can only leave it in their pocket and trust that the world will eventually hand them the lesson itself. Old-me had to walk old-me’s path. So will the people I’m watching now. Probably so will you.

Play With the Legos

At some point in the last couple of years I stopped being the person who grabs bricks off other people’s desks. Partly because I got older and partly because the bricks stopped being the interesting part. In a world where agents will print bricks all day for anyone who asks, the only thing left worth doing is the part I was skipping: help people enjoy building something, keep it pointed at the right galaxy, and get out of the way.

Chill out. Play with the Legos.