Published: Jun 6th, 2026 - 8 min read

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.

The Problem Wasn't the Network

The operator was not starting from zero. They had monitoring infrastructure, dashboards, alert thresholds, and network operations teams that knew exactly how to respond when something broke. By the standards of most carriers in the region, they were reasonably well-instrumented.

The challenge they brought us was something more subtle. Every planned maintenance window (the routine changes, optimizations, and network expansions that any mobile operator runs continuously) required a service validation cycle. Before each change, teams manually verified services across multiple systems. After the change, the process repeated.

Calls between departments. Engineers waiting for status confirmations. Escalations when something was unclear. The process worked. But it consumed hours that nobody had planned for, slowed down the pace of change, and created operational friction that accumulated across every maintenance cycle, every week.

And even when the validation was complete, after every team had confirmed their slice of the picture, nobody could confidently answer the question that actually mattered from a business perspective.

I remember the moment the question was first put to us directly, in a working session with the operator's leadership team. Someone on the business side, not from the technical team, leaned across the table and asked:

"What is the real experience of our users right now, from every location where we have coverage?"

The network was green. Routing had converged. Core services were operational. KPIs were within thresholds. But were subscribers hundreds of kilometers away experiencing the same service quality as users in the capital? Were the customers in recently optimized regions actually noticing an improvement, or were they silently experiencing degradation that no infrastructure dashboard was designed to capture?

The technical team had visibility into the network. What nobody had was visibility into the outcome. Those are two different things. And until that moment, I had not fully understood the distance between them.

The Gap That Changed My Perspective

There is a gap between "the network is working" and "users are having a good experience." That gap is where my career started to change.

Until that engagement, I had spent most of my professional life operating on the first side of that equation. My training, and the CCIE in particular, had taught me to ask technical questions with precision.

The questions I had been trained to ask:

•   Is the network available?

•   Is latency within thresholds?

•   Is packet loss acceptable?

•   Are routing protocols stable?

•   Is capacity sufficient?

The questions business leaders actually ask:

•   Are customers satisfied?

•   Can employees do their jobs?

•   Are critical services delivering?

•   Are we keeping the experience we promised?

•   What is the user actually seeing right now?

These are connected questions. They are not the same question. The infrastructure team could explain precisely what the network was doing. The business wanted to understand what users were experiencing. The two perspectives were related. But translating between them required something that neither networking expertise nor standard monitoring platforms were designed to provide.

What the CCIE Taught Me. And What It Did Not.

The CCIE Service Provider certification is one of the most demanding technical credentials in the networking industry. Passing it requires deep knowledge of carrier architectures, routing protocols, traffic engineering, and service design at scale. The discipline required to earn it taught me how to think systematically, isolate variables, troubleshoot ambiguity, and make consequential decisions under pressure. I use that foundation constantly.

But the CCIE was not designed to answer questions like these:

•   Is this change safe to proceed, not just for our infrastructure but for the users depending on it?

•   Did this optimization actually improve the experience of real subscribers?

•   Can we validate service quality in minutes instead of hours, at the scale of our entire coverage footprint?

•   Can we make operational decisions with confidence, speed, and less human coordination overhead?

Those are not networking questions. They are observability questions. And embedded inside them are data questions, product questions, and increasingly, artificial intelligence questions.

The CCIE taught me how to build networks that work. What it could not teach me was how to know what thousands, or millions, of users were actually experiencing as a result. Those are two different problems. For a long time, I was only solving one of them.

What Observability Actually Means

This is where many conversations about observability take a wrong turn. They focus on tools and platforms. The question becomes: which observability product should we deploy?

That is the third question. The first two are more important.

The first: what decisions are we trying to make, and how fast do we need to make them? In the operator's case, the answers were specific. Is a planned change safe to proceed? Did the completed change improve service quality? Can we compress the validation cycle from hours to minutes, at the scale of our full geographic footprint?

The second: what would we need to measure to make those decisions confidently? This is where the real work begins. User experience at the scale of a mobile network cannot be inferred from infrastructure metrics alone. It requires a different measurement layer: active testing from the user perspective, signals from multiple geographic points, correlation between network events and service experience in terms that non-technical stakeholders can act on.

Most organizations think observability is about understanding systems. I increasingly believe it is about understanding decisions. System instrumentation is the input. Better decisions are the output. If the observability initiative is not changing how decisions are made, how quickly, how confidently, with how much less organizational friction, then it is a monitoring upgrade. Not a transformation.

Then Came Artificial Intelligence

Years later, working increasingly close to AI initiatives, I discovered something that should not have surprised me as much as it did. The same lesson appeared again.

Most organizations approach artificial intelligence as a technology initiative: how do we deploy models, how do we automate tasks, how do we reduce costs? Those are useful questions. They are secondary. The organizations creating the greatest value with AI are treating it as a decision-making initiative. Not "how do we deploy AI" but "how do we improve the quality and speed of our decisions."

Just as observability requires trusted telemetry, AI requires trusted context. Just as observability fails without meaningful data, AI fails without meaningful data. Different technologies, same underlying challenge: understand systems well enough to reduce uncertainty and improve judgment.

The mobile operator engagement eventually evolved to reflect exactly this progression. Having established the observability foundation, the next phase is embedding that layer directly into the change control process, not as a manual validation step, but as a continuous capability that compares pre-change and post-change user experience signals automatically, surfaces anomalies, and gives the operations team a confident answer in minutes rather than hours.

That is the convergence point: observability, product thinking, and AI. Not because the technologies are related, but because the business problem is the same. Make better decisions faster.

Looking Back

When I think back to that operator engagement, I no longer remember the exact metrics, the utilization graphs, or the capacity reports.

What I remember is the question.

What is the real experience of our users right now?

At the time, it seemed like an operational concern. In reality, it introduced a much larger idea: the network was not the destination. It never was. The destination was always better decisions, better outcomes, and better experiences for the people who depend on the technology we build.

Looking back, I do not see networking, observability, artificial intelligence, and product strategy as separate chapters. I see them as successive attempts to answer the same question:

How do we understand increasingly complex systems well enough to make better decisions inside them? The technologies changed. The question did not. And that question continues to shape my work today.

If you can't measure it, you can't improve it. And without measurement, you cannot make decisions: not good ones, not confident ones, not ones made at the speed and scale that modern infrastructure demands.

That is not a management principle. That is the entire point of observability.

What technical skill did you have to unlearn to move toward more strategic roles? I would genuinely like to know.

Edwin Martin Salazar Vega

Helping organizations make better decisions through technology, observability, and complex systems thinking.