Create a risk management framework

The Real Problem Behind Management Issues

Most founders think they need more processes when they hit management problems. Revenue stalls, team members drop balls, customers complain — so they add approval layers, tracking systems, and oversight meetings. They're solving the wrong problem.

The real issue isn't missing processes. It's that your constraint moved. When you were smaller, you could manually route around problems. Now you can't. But instead of finding and fixing the actual bottleneck, you're adding friction everywhere.

This is the Complexity Trap in action. You pile on systems that feel productive but actually slow everything down. Meanwhile, the real constraint — the one thing limiting your entire throughput — keeps choking your business.

The constraint determines the speed of the entire system. Everything else is just noise.

Why Most Approaches Fail

Standard risk management frameworks fail because they try to protect against everything. You get massive matrices rating dozens of risks from 1-10. Color-coded spreadsheets. Quarterly reviews that nobody reads. It's security theater — it looks thorough but doesn't actually reduce risk.

Here's why this approach breaks: it treats all risks as equal. In reality, one constraint failure can kill your business while dozens of other "risks" are just expensive distractions. You end up spending resources on the wrong things.

The other common failure is building the framework before understanding the system. Teams create elaborate processes for hypothetical problems while ignoring the actual constraint that's already limiting them. They're optimizing everything except what matters.

The result? You get slower, not safer. Your team spends time on compliance instead of solving real problems. Meanwhile, the actual risk — whatever's limiting your constraint — grows unchecked.

The First Principles Approach

Start with constraint identification. What's the one thing that determines your throughput right now? Is it sales capacity? Product development speed? Customer onboarding? Operations bandwidth? There's always one constraint.

Once you find it, ask: what could break this constraint completely? Not slow it down — break it. These are your real risks. Everything else is secondary.

For a services business, the constraint might be senior consultant capacity. The real risk isn't that a project runs late (annoying but not fatal). It's that your lead consultant quits mid-quarter with no succession plan. That breaks the constraint.

For a product company, the constraint might be engineering velocity. The real risk isn't a minor bug (fixable). It's that your technical co-founder burns out and the codebase becomes unmaintainable. That breaks the constraint.

Risk management isn't about preventing all problems. It's about ensuring your constraint never breaks completely.

The System That Actually Works

Build your framework in three layers, all focused on the constraint.

Layer 1: Constraint Protection. What are the 2-3 things that could completely break your current constraint? Build specific safeguards for each. If your constraint is sales capacity and your top rep generates 40% of revenue, you need succession planning, knowledge transfer systems, and multiple relationship coverage. Not general "employee retention policies."

Layer 2: Constraint Enhancement. What would let your constraint handle more throughput with the same resources? This isn't about adding capacity — it's about removing friction. Better tools, clearer processes, elimination of non-essential work. You're making the constraint more resilient by making it more efficient.

Layer 3: Signal Systems. You need early warning when constraint performance degrades. Track the leading indicators that predict constraint failure, not lagging indicators that tell you it already happened. If your constraint is engineering velocity, don't track bugs found (lagging). Track code review cycle time and deployment frequency (leading).

Each layer should have one owner, clear metrics, and monthly reviews. No committees. No consensus building. Constraints move fast, so your responses must move faster.

Common Mistakes to Avoid

The biggest mistake is trying to future-proof the framework. You build protections for constraints that don't exist yet while ignoring the current constraint. Your constraint will evolve as you scale — today's bottleneck becomes tomorrow's strength. Build for now, then adapt.

Second mistake: treating all team members as equal risks. They're not. Losing someone who's not on the constraint path is manageable. Losing someone who is the constraint path can kill momentum for months. Your framework should reflect this reality, not pretend everyone's equally critical.

Third mistake: building the framework in isolation. Your constraint touches every department, so your risk management must too. But most frameworks are owned by operations or finance — departments that don't understand the constraint intimately. Put constraint ownership where it belongs: with whoever actually manages that system day-to-day.

Final mistake: over-engineering the system. You don't need software, dashboards, or automated alerts. You need clear ownership, simple metrics, and fast response loops. Start with spreadsheets and manual processes. Add complexity only after you've proven the system works.

The best risk management framework is invisible until you need it — then it's the only thing that matters.