The Infrastructure of Catching What Falls

Keenan called me on ZOOM last month with this look I've learned to recognize. He's thinking big. Really big.

He'd been talking to a hospital network—not a nonprofit, not a university, but a health system with 40,000 employees across 8 states. They had a problem that SMS could solve, but it would require us to build something we've never built before. A new capability. New compliance requirements. New integration points.

My first instinct wasn't "that's impossible."

It was: Okay. What do I need to build so that can actually work?

The COO Role Nobody Talks About

Everyone writes about the visionary founder. The scrappy hustler. The product genius. Those are real. Keenan can think bigger and bolder because I've built the infrastructure to catch what falls.

Here's what that actually looks like:

When Keenan says "let's go after healthcare systems," I'm not just going "great." I'm thinking about compliance frameworks, about data security reviews, about SLAs we've never promised before. I'm thinking about what happens when a hospital client has a question at 2 a.m. and Lauren's sleeping. I'm thinking about whether our onboarding process scales to a 400-person account. I'm thinking about where we're going to find the person who can manage that relationship.

And then I'm building those things before we sign the contract.

What "Catching What Falls" Actually Looks Like

The infrastructure of catching what falls looks like:

  1. Systems that don't depend on one person knowing everything. Checklists. Escalation paths. Documentation. So that if Lauren is out, if I'm at a conference, if someone gets sick, the client still gets the same experience.
  2. Standards, not improvisation. Every deployment looks similar. Every client onboarding follows the same arc. Every problem gets categorized the same way. Because inconsistency is where trust dies.
  3. Processes that anticipate what breaks. We know deployment is fragile in the first 48 hours. So we've built active monitoring into hour 1. We've built three separate check-in moments. We've built escalation triggers.
  4. Team structure that spreads the pressure. You can't have one person own client success and infrastructure and strategy. You need architecture. You need lanes.
  5. A communication framework for when things go wrong. Because they will. And how you tell a client what went wrong matters more than the fact that it did.

Most founders don't think about this stuff. They think about the vision and assume the operations will follow. But operations don't follow. They collapse under the weight of the vision.

Reacting to Growth vs. Designing for It

I think about this all the time: reacting to growth vs. designing for it.

Most companies react. They sign a big client, then they scramble. They add processes after something breaks. They hire after they're drowning.

We try to design ahead. When we're at $1M ARR, I'm building the systems for $3M ARR. When we're managing 40 clients, I'm designing for 200.

Is that sometimes paranoid? Sure. Do we build things we don't need yet? Absolutely.

But it means that when Keenan brings me a vision that scares him a little—the good kind of scared—my job isn't to tell him it won't work. My job is to figure out what needs to be true for it to work, and build that thing.

It's Not Hierarchy. It's Architecture.

The relationship between a visionary and an operator: it's not hierarchy. It's architecture.

One person pushes the ceiling up. One person reinforces the floor. Neither works without the other.

I've seen what happens when you have the visionary but not the operator: chaos. Broken promises. Clients who loved the pitch but got a delivery that didn't hold up. Teams that burn out because everything's ad-hoc and reactive.

I've also seen what happens when you have the operator but not the visionary: stagnation. Everything runs smoothly. Nobody's pushing. Nothing's growing. You become really good at managing decline.

The magic happens when you have both. When the visionary can think beyond what's currently possible because they trust the operator to make it safe. When the operator can build with confidence because they're building toward something worth building.

Why This Role Matters More Than People Think

Because every missed client email, every deployment that goes sideways, every policy that shifts and nobody updates the documentation—those moments are where trust gets built or destroyed. Those moments are invisible until they're not. And by then, it's too late.

The operator is the person who makes the vision safe to dream bigger.

Keenan can say yes to that hospital network because I've already started asking: what needs to be true

Join The Troop

Sign up for our mailing list for insights, perks, and more!

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.