The Load-Bearing Assumption

On the decisions nobody writes down, and the ones that quietly hold everything up.

There is a particular kind of silence at the start of building something. Nobody is arguing yet. Nobody has been let down yet. The whiteboard is full of arrows pointing toward a future everyone agrees on, and agreement, in that moment, feels like it will simply keep being true — the way the ground feels solid until the day you find out it wasn't.

I've come to think that almost nothing that goes wrong later in a system, or a team, or a company, was actually caused by the thing that finally broke. It was caused earlier, by a decision so small and so obviously "understood" that nobody thought to write it down. Not a bad decision. An unmade one. The kind that everyone in the room assumes has already been settled, simply because it hasn't come up yet.

The floor nobody audits

Every engineer knows the feeling of inheriting a system and asking, half-joking, "wait, what's actually holding this up?" You trace a call, and it routes through a function named after someone who left the company two years ago, and the function does something load-bearing that nothing in the documentation mentions, because at the time it was written, it felt too obvious to write down.

Organizations have the same layer. It's just made of agreements instead of functions. Who actually has final say when two people disagree. What happens to someone's stake if they leave in year one versus year three. Whether "we'll figure it out later" was a real plan or just the sound two people make when they'd rather be building than negotiating.

None of this looks like architecture while it's happening. It looks like momentum. It looks like trust, even — and it often is trust, which is exactly what makes it dangerous to leave unwritten. Trust is a fine reason to make an agreement quickly. It is a terrible reason to skip recording it. Those are two different acts, and founding teams — like engineering teams under a deadline — routinely collapse them into one.

Debt that doesn't show up in your codebase

We have a whole vocabulary for this problem in software. Technical debt: the shortcut you took because shipping mattered more that week than correctness, with the tacit understanding that you'd come back and pay it down. Everyone accepts this trade exists. Good teams even manage it deliberately — they take on debt with eyes open, log it, and revisit it before it compounds.

What we don't have as good a vocabulary for is founding debt — the equivalent shortcut taken with people instead of with code. The handshake instead of the contract. The "obviously you'd get equity for that" instead of the cap table entry. It compounds exactly like technical debt does: silently, invisibly, for as long as nothing forces you to look at it. And then one day something does force you to look at it — a disagreement, a departure, a moment where two people discover they were building on different foundations the entire time and had no idea, because the floor had never been poured, only assumed.

The cruelest part is that founding debt is usually invisible for the same reason it's dangerous: things are going well. Nobody audits the foundation of a building that isn't shaking. You only find the crack in the wall on the day you finally lean on it.

Writing it down is the refactor

There's a reason engineers who've been burned enough times insist on a design document before the first line of code, even when everyone in the room is certain they already agree. Not because writing changes what you believe. Because writing exposes what you only thought you'd agreed on. Two people can nod at the same sentence spoken aloud and mean two different things by it. A design doc — or a term sheet, or a founding agreement, or just a plainly worded email that says "here is what happens if X" — forces the ambiguity to the surface while it's still cheap to fix.

This is the uncomfortable part: doing this early feels like an act of distrust. It isn't. It's the opposite. Vague agreements are what you make when you're avoiding a conversation, not when you're confident in the relationship. The teams — and the founding pairs — who write the hard stuff down early aren't the ones who trust each other less. They're the ones who've done this enough times to know that trust doesn't hold weight; specification does. Trust is what lets you have the conversation. It was never a substitute for having it.

The specification, once it exists, does something else too — the same thing a good design doc does for a codebase. It becomes the thing you can point back to later, not as a weapon, but as memory. Six months in, when the actual situation looks nothing like anyone imagined on day one, you don't need to relitigate who meant what. You go back to the artifact. That's the entire point of writing anything down: not to be right forever, but to give a future disagreement somewhere honest to land.

What actually breaks

When a system finally fails under load, it rarely fails at the point of maximum stress. It fails at the point of maximum assumption — the joint nobody reinforced because everyone was sure it would never really be tested. Founding teams fail the same way. Not usually because ambition outpaced execution, and not usually because anyone acted in bad faith. Almost always because something genuinely unspoken — ownership, authority, what happens if this goes sideways — was left to be discovered under pressure instead of decided in calm.

You cannot pressure-test every assumption before you start. That's not the standard, and it was never realistic — plans, like architecture, have to leave room for what you can't yet see. But there's a difference between the unknowns you couldn't have specified and the ones you simply didn't, because naming them out loud felt unnecessary, or awkward, or like it might slow down something that was finally moving.

Build the layer you can't see

If there's a habit worth taking from this, it isn't paranoia. It's a small, specific discipline: before the second layer goes up, ask what the first one is actually resting on. Not what you assume it's resting on. What it's provably resting on — written somewhere, agreed to by name, revisitable without a fight.

It's not a glamorous instinct. Nobody starts a company, or a project, or a friendship-shaped partnership, dreaming about the paperwork. But the floor is the part of the building nobody photographs and everybody stands on. Pour it in daylight, while everyone's still smiling and it still feels unnecessary. That's the only time it's cheap.