How to build the thing [Part 4: Codify your intuition]

Turning collective experience into shared, scaled momentum

Nov 25, 2025

Every team in the workplace has some layer of quiet, underlying knowledge. Something that rarely, if ever, shows up in decks or documentation. People tend to know some patterns that work, shortcuts that can avoid pain later, legacy structures that have proved reliable, and behaviors that lead to good outcomes. Within a team dynamic, not all of this is formally taught - it’s also absorbed through shared experience.

Good systems don’t override that intuition.

Instead, they try to capture it, scale it, make it available to more people, without getting in the way.

That’s the fourth principle in our series. Part 3 was about making our system vanish. Part 4 is about making the shared knowledge - institutional understanding - visible. Quietly, and usefully.

Encode what already works

The best systems aren’t the ones that are invented from scratch. They’re the ones distilling the best of what teams are already doing successfully, and building on that.

That means noticing the patterns that show up again and again, giving them a stamp of approval, and making them more easily available.

Layouts that reliably communicate hierarchy
Writing that demonstrably reduces back-and-forth questions
Coding practices that reduce recurring bugs
The workflows that ship more consistently on time.

Codifying intuition means you’re not the one creating the rules - it’s the capture of behavior that already produces good outcomes. Not only giving others access to those behaviors, but giving rigor and metrics to them, too.

Defaults, not rules

When building systems, the best way to get adoption is to make adoption the path of least resistance. Codifying intuition supports that by making sure that people have a better starting point.

Opinionated defaults can making doing the right thing the easiest thing to do. They:

Reduce cognitive load
Help new contributors, and support their growing effectiveness
Provide consistent quality without artificially enforcing uniformity
Are flexible enough to override when it’s justifiable to do so

These defaults are your scaffolding - light, helpful, and removable. It’s about supporting success, rather than forcing compliance.

“If you build it, they will come…”

Strange how lines from old movies can stick with you. In Field of Dreams this whispered mantra was a little more mystical than we’re talking about. But ultimately it was about creating a place that people wanted to come to.

A system becomes frustrating - often to the point of failure - when it demands a particular behavior instead of merely providing support. People might comply in public, but work around it in private (this is why top-down mandates aren’t ever enough by themselves). Intuition can become accepted ceremony.

Better systems surface guidance that happens in the moment:

Snippets that are clear and visible when you begin using a component
Panels that offer context only when it’s relevant
Automation suggesting steps forward rather than blocking actions

If your system is behaving like your partner and not your supervisor, you’re more likely to trust it, and to use it naturally. This “partnership” model is one of the reasons why I think AI and product design and delivery systems are a naturally beneficial pair - LLMs, with context, can lend themselves to this sense of working together.

Keeping the spirit of the law

A common mistake here is to document the expression of intuition and think that successfully captures its true essence.

Someone does something clever because it works. It gets documented. It gets formalized. It gets followed.

It still gets followed even when everyone has forgotten why it existed in the first place.

The codification of intuition needs to include the reasoning, not just the ritual steps. If we lose a record of the why, then the system can start to become brittle.

Intuition means adaptation

Any system that is codifying intuition needs to be adaptive. Intuition, by its nature, will flex and change over time as circumstances do.

That means leaning into:

Local variation
Overrides and escapes
Flexible boundaries
Places where the work is shaping the system, not the other way around

This is an important measure that should be monitored. The intuition itself can flex. But if you need to regularly break your system to do any good work, then the system is constraining intuition rather than effectively capturing it.

Shared intuition is acceleration

We want to make collective experience part of our natural infrastructure. If we do that, everything can move faster. New joiners ramp quickly and naturally, even though senior contributors also spend less time explaining. Teams don’t need to reinvent solutions that already work.

Quality becomes consistent because we’re working within the boundaries of a system that guides people towards that quality, rather than because it artificially enforces it.

Codifying intuition isn’t about perfection, or achieving uniformity. Velocity is much more important than perfection.

Then the thing that gets you to the thing becomes easier for people to trust, easier to use, and easier to build with.

Robin Cannon | Stories and Signals