How to build the thing [Part 2: Don't build what nobody needs]

The trap of building systems, tools, or workflows that serve themselves, not people.

Oct 28, 2025

It’s really tempting, especially if you’re working in a fast-paced environment, with resources to support you, to build something because you can build it. Stand up a new platform, write a new wiki, launch some AI tooling, create a design system. That’s what teams are supposed to do, right? Make stuff. And for systems and infrastructure teams, “stuff” is…more systems and infrastructure.

But a system that exists for its own sake, no matter how polished it is, is just a black hole. Drawing in time, attention, energy, resources…without any clear proportional value.

Goal collapse

If you don’t have a goal, that means there’s no definition of what the work is for. Which means the work itself starts masquerading as the reason for the work.

“We need a design system,” rather than what the design system enables.
“We’re implementing AI,” should be a project, not an outcome.

This is goal collapse. Infrastructure becomes the obsession, and eventually you’ll reach a point where you’re building somebody and genuinely nobody remembers why.

Honor desire paths

People already know how they work best. So if you come barreling in with something that breaks their natural flow, you create resistance. Or maybe even worse, surface compliance while they ignore you and work around things in the background.

So instead of asking “how should everyone work?”, perhaps start by asking “how does everyone work today?”

That includes the hacks and workarounds, hidden docs, side Slack conversations, team-specific shared templates. Those should be a starting point to build from, not an obstacle to destroy.

Don’t break desire paths, build on them.

It’s a tool, not a temple

You’re not building a monument to how great you are. You’re building a wrench for someone else to use.

That means creating something that people will use, not something that people will stand back and admire from afar.

If there’s any sense that the system you built is “sacred”, fragile, forced…then it probably isn’t doing what it’s supposed to do. The best systems are probably a little bit messy, a little bit lived-in, which makes them comfortable.

Systems are for people, not the reverse

People who do the work should have the capacity to shape the system. Not just through giving their feedback, but by how we observe their behavior and adjust.

Watch how teams successfully ship things.
Identify and realize that’s slowing them down.
Build what actually addresses that friction.
Let parts of the system stay informal and flexible, if the work demands.

A rigid, top-down system looks efficient on paper. I’ve seen design system teams in particular fall into this ivory tower trap many times - even with the best of intentions. It fails when reality intrudes.

Would you build it if nobody saw it?

If there was no deck for you to present what you were launching. No internal applause. If there was no roadmap to celebrate “we did the thing”…

Would it still be worth it?

If the answer is yes - it enables better work and smoother delivery, shipping things faster - build it.

If the answer is no - then maybe you don’t need to build it at all.

Robin Cannon | Stories and Signals