All posts

What Constraints Force You to Own

The systems that look solid often hide what they're borrowing. A practice that asks the hard question before an event forces it is worth more than any framework.

Comfortable systems hide their dependencies. You only find out what you were borrowing when it’s gone.

Constraints cut through that. The mental models I’ve built in risk management do this on a schedule: stress-test the assumption, name the single point of failure, ask what breaks if that link goes. Not because something is wrong. Because the question is the discipline.

What it surfaces: things you thought you owned but were only using. A process that runs because someone upstream hasn’t changed their mind. A decision that felt settled but rests on an assumption you never examined.

The constraint isn’t the problem. The constraint is the audit.

You don’t need an external forcing event. You need a practice that asks the question before the event answers it for you. Start here: What breaks if I’m not there? Fix the first thing that comes up. Ask again. Repeat until nothing breaks without you — or until you’ve consciously accepted the tradeoff.

Only then does the framework truly meet your standards.