For years, I’ve fixed things before they've had a chance to break. I’ve also broken things, then scrambled to fix them. In either case, success often looks like nothing happening at all.

Take the formal presentations I (regularly) help prepare for and give. Many times the narrative is smooth and flows well/okay, the transitions are clean, and every figure ties to the decimal. What the audience almost never sees: the system fixes, the updated/cleaned records, or the urgent data repair that made that presentation accurate - and possible. They didn’t need to. When an operations team succeeds, there is little to no trace of the work, only the illusion that things were always going to work out the way they did. The output is quality; it's craftsmanship.

One way to judge "Operations" is through the absence of problems[1]. We measure success by and through non-events: system downtime that never occurred, the customer who had no reason to complain, a sprint that completed without interruption with a goal delivered. This is not the work of breakthrough insights but of persistent, deliberate maintenance - creating spaces where other people's ideas can take root and grow.

After a decade, I've internalized a particular stance toward systems. I've stopped asking if something might fail and instead map out how it will fail, then try to build around those inevitabilities. Which to me isn't pessimism, it's pattern recognition compressed into a necessary instinct. Cleverness without reinforcement becomes tomorrow's technical or process debt. A solution that cannot be maintained isn't a solution.

I didn't train for Operations. No one does, usually. I was capable and gradually became the person who remembered why we'd built things a certain way. I knew which tools ran hot, which workflows had hidden dependencies, which customers needed a particular type of handling. Reliability accumulated around me through the slow, gradual accumulation of context. Responsibility is built on trust and effectiveness.

But there's a paradox in preventing problems: operational excellence means becoming functionally invisible over time. The meeting starts without delay. The quarter closes without escalations or problems. These non-events rarely warrant celebration - they're the expected baseline, the simple structure of the work; not the creation of something new, but careful and continual stewardship.

Operations teams will develop a specific lens through which they see everything - not the product vision or metrics - but the substrate that makes both possible. It's our role to map dependencies that others don't see. We anticipate edge cases that haven't (yet) emerged. Sometimes this means saying "slow down" when everyone else wants momentum. It can look like resistance but is really just care - the difference between moving fast and moving sustainably.

This kind of attention - proactive, quiet, and systemic - is hard to depict, and I've never felt I've gotten it quite right visually. But, preventative attention is precisely what defines operations at its best: knowing when, where, and how failure might appear, and building just enough buffer in the right places.

This perspective carries costs. You notice weak points during celebrations and flag risks while colleagues high-five. You carry a perpetual background process that scans for entropy. Present in the moment but simultaneously running failure simulations and calculating paths to recovery.

Yet, despite those constant scanning tendencies, many of us stay in these roles not from obligation but because there's quiet satisfaction in understanding how everything connects. You hold blueprints in your head.

I sometimes think about the Roman aqueducts[2], massive engineering projects that delivered water across impossible distances. The builders didn't receive glory like generals or emperors, yet their work outlasted the conquests, the empire. They created infrastructure so fundamental that it disappeared into the background of daily life.

That's the paradox of operational excellence: the higher and better the excellence, the less visible the contribution. But, there's a quiet dignity in building systems that makes something possible.

And on rare occasions, when looking at the full complexity of what hasn't fallen apart, you allow yourself a moment of recognition that no one else will offer: this can work because of my work. Which is more than sufficient.

1. ↩

This essay is largely about stability as a prime goal of Operations (e.g., reliability of core systems or data), and whether processes function without issue, but there are many more goals in real life - discipline (e.g., time to resolve, time to triage), enablement and translation (in other words, do functions work together better, and do key things translate across different groups), scalability (i.e., growth without the same growth in overhead), decision-making ability of the org, institutional knowledge management, etc., etc.

2. ↩

...and one aqueduct in particular. I was lucky enough to see Pont-du-Gard, still standing today in southern France, somehow - one of the most impressive sights of my life.
Pig Island, Exuma, Bahamas
Pig Island, Exuma, Bahamas