The Most Important Thing I Built This Week Was a Boundary

I spent a decent amount of time this week looking at systems designed to give software more context. More documents. More history. More conversations. More company knowledge. More connections between things. Some of the projects being built around this right now are incredibly impressive.

My first reaction was: oh hell yes. Connect all of it.

That instinct lasted about five minutes, because I've already learned where that road goes. You don't end up with intelligence. You end up with a very sophisticated junk drawer.

The problem used to be access

This is one of the stranger lessons of building with modern software. For years, the hard part was getting access to information. Data lived in different systems. Documents were buried in shared drives. Customer history lived in somebody's inbox. Important decisions disappeared into meeting notes. Research got saved somewhere and never seen again.

So the obvious goal was to connect everything, and now we finally can. Which creates a new problem: you actually have everything. Congratulations. What are you going to do with it?

Every addition made sense by itself

I ran into this earlier with one of the systems I built. It kept getting more capable. More workflows, more automation, more screens, more things talking to other things.

That's the dangerous part. Every addition made sense on its own. Nobody adds a feature while saying, “This is pointless, but let's make the product worse.” Each decision sounds perfectly reasonable. Of course we should add this. Of course we should connect that. Of course it should know about this too.

Eventually you look up and realize you've built something technically impressive that needs an owner's manual to answer a simple question. I've become much more suspicious of that.

What does it absolutely need to do?

This week I found myself doing almost the opposite. I'm working on something new, and there are a dozen directions I could take it. I could make it broader, connect more sources, add more intelligence, make the scoring more sophisticated, build another workflow, pull another dataset.

For once, instead of asking what else can this do?, I've been asking what does this absolutely need to do? That's a much harder question.

Take something as simple as helping a salesperson decide where to spend their time. You could give the system every CRM record, every email, every website visit, every company announcement, every executive, every social post, every hiring change, every property record, every review, every industry report, every previous interaction, and every other piece of public information you can find. Very impressive. Also possibly useless.

Because the salesperson's actual question might be: who should I visit while I'm in this part of town Tuesday? That's a very different problem. They don't need everything the company knows. They need the few pieces of information that help answer that question.

Relevant context, not maximum context

I've started thinking about context the same way I think about packing for a trip. If I'm going to Florida for three days, I technically own a snow shovel. That doesn't mean it belongs in the suitcase. More possessions do not make me better prepared. The right possessions do.

Information works the same way. The goal isn't maximum context. It's relevant context. I came at a version of this from the other direction when I wrote about how you can drown in information.

Restraint is now a competitive advantage

That sounds obvious, but the incentives are backwards. Software likes accumulation. Databases like more records. Dashboards like more widgets. Builders like more capability.

And the cost of adding things has dropped so much that restraint is becoming a real advantage. Ten years ago, a dumb feature might have required a product manager, two engineers and six weeks. That friction forced prioritization. Now the conversation is, “Could we add this?” Yep. “How hard?” Not very.

That's dangerous, because “easy to build” and “worth building” are not the same thing.

I've caught myself making that mistake more than once. I can convince myself that another data source will finally make the picture complete. It never does. There's always another source, another relationship, another event, another signal, another thing we could know. At some point you have to decide that knowing more is no longer the objective. Making a better decision is.

A good system knows what it is not responsible for

That's where the boundary comes in. A good system should know what it is not responsible for. A good workflow should know when it has enough information. A good research process should have a stopping point. A good piece of software should occasionally say: “We don't need that.”

That's not a limitation. That's design.

A company brain is not a pile

I think the same thing applies to the idea of a company brain. I've used that phrase, and a lot of people are using it now. I understand why. Companies forget things. Information is scattered. People leave. Decisions lose their context. New employees have to rediscover why something works the way it does.

But if “company brain” just means dumping every artifact the business has ever created into one enormous pile, we've solved the wrong problem. A human brain doesn't consciously load every memory you've ever had before deciding where to eat lunch. Thank God. I'd still be standing in the kitchen trying to reconcile elementary school with Chipotle.

What matters is that the right information becomes available when it's useful. So the question isn't how much can the system remember? It's can it find the right thing at the right moment? Can it tell what matters from what doesn't? Can it keep the important decisions without keeping every scrap of noise around them? Can someone ask a question without dragging the entire company history into the answer? Can the system get better without constantly getting bigger?

Those feel like much more important questions. They are also close cousins of the idea that the score isn't the intelligence: a number, or a pile of data, only helps when it fits the decision in front of you.

Complexity is easy to see. Simplicity isn't.

There's a business lesson buried in this. I've spent enough time building things to know how seductive complexity is. Complexity feels like progress because you can see it. Another feature exists. Another integration works. Another screen appears. Simplicity doesn't produce the same dopamine hit.

Sometimes the work is deleting something. Sometimes it's refusing to build it. Sometimes it's deciding two systems should stay separate, or deliberately leaving a capability for later. There's no screenshot for that. But it may be the better decision.

The scarce resource is judgment

This becomes especially important as software gets easier to create. We're entering a period where almost any company can accumulate technology faster than it can absorb it. More software, more automation, more data, more agents, more dashboards.

The scarce resource won't be capability. It'll be judgment: knowing what deserves to exist, what belongs together, what should stay separate, and when you have enough information to act.

That's probably the biggest shift in how I'm building right now. A year ago, I probably would have asked, how powerful can we make this? Now I'm much more likely to ask, how little can we give someone and still dramatically improve the decision?

That's a different design philosophy, and I think it's a better one. The smartest system isn't necessarily the one that knows the most. It might be the one that knows what not to bring into the room.

Information used to be scarce. Now attention is. The systems that win probably won't be the ones that give us everything. They'll be the ones that know what to leave out.

Sometimes the most important thing you can build is a boundary. That's the thinking behind our company intelligence work: connect what matters to the decision, and leave the rest out. New to the series? Start with What Is an Intelligence Estate.

Questions people ask about this