Helping organizations make better decisions through technology, observability, and complex systems thinking.
The boardroom was on the upper floor of a hospital group's headquarters in Central America. Eight executives on one side of the table. Me on the other, with a deck of network optimization results that had taken weeks to produce.
I had fifteen minutes.
I didn't open with a metric.
I opened with their business.
The number of hospitals in the group. Active beds per location. Daily patient volume. Critical care units running around the clock across multiple cities. The clinical systems, imaging, electronic health records, remote consultations that depended on the network we had just spent months optimizing. One of the executives, a few seats down the table, leaned forward.
If you can't measure it, you can't improve it.
Most people encounter that statement as a management principle, something cited in operational reviews and quickly nodded at before the meeting moves on. I used to treat it the same way. Then a mobile telecommunications operator asked me a question I could not answer. And I realized I had been solving the wrong problem for most of my career. That realization is why a CCIE ended up working in observability, artificial intelligence, and product strategy. Not because networking stopped mattering. The question simply evolved.
After two decades working in critical infrastructure, I have realized something unexpected.
The hardest problems were almost never technical.
That statement probably sounds counterintuitive coming from someone who has spent twenty years in telecommunications engineering, enterprise network architecture, and technology product management. Someone who holds a CCIE, has designed infrastructure for mobile networks serving millions of subscribers, and currently leads an observability and assurance portfolio at a global technology company.
But it is the most honest summary I can give of what two decades in this field have actually taught me.
The technology was almost always solvable. What was rarely simple was everything around it.
Downtime is a business problem disguised as a technical problem.
One of the most expensive decisions an organization can make is to underestimate downtime.
Not because servers stop. Not because networks fail. Not because applications become unavailable. Those are only the visible symptoms.
The real cost begins long before the first alert appears. And it continues long after every dashboard turns green again.
It took me years to realize that.
At some point, accumulating experience stops being the goal.
One of the most expensive decisions a senior professional can make is to keep accumulating experience without asking what it should become.
Not because experience stops mattering. It is the opposite problem: after enough years, the experience itself stops being the bottleneck. What replaces it is a quieter question that most careers never pause long enough to ask: once you have it, what do you do with it?
I did not arrive at that question through reflection. I arrived at it through two unrelated efforts, the same year, that turned out to be answering it from opposite directions.