Published: May 30th, 2026 - 8 min read
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.
"How do you know all of this?"
He wasn't hostile. He was genuinely curious. And a little surprised.
I told him: for me, and for this project, your business is what matters most. If we touch a single cable in your network, I need to understand exactly what we are putting at risk. That responsibility is even greater when the network supports patient care, when downtime is not an inconvenience but a potential clinical event.
He nodded slowly. Confirmed that the numbers I had cited were accurate. And something shifted in the room. The conversation stopped being a presentation and became a genuine discussion about digital infrastructure as a strategic asset.
We ran long. Nobody checked their phone.
That moment confirmed something I had been learning slowly,
across fifteen years of building and managing critical infrastructure:
"The network was never the real subject."
Over two decades working across banking, telecommunications, consulting, enterprise architecture, and product strategy, I have arrived at a conviction I did not have when I started:
My career was never about networks. It was about complex systems, and the human decisions made inside them.
The Illusion of Technical Problems
Early in an engineering career, most challenges appear technical. A routing issue. A capacity limitation. A service outage. The natural response is to search for a technical fix, and usually, one exists.
But over time, a pattern emerges that no certification program explains clearly enough.
The largest incidents rarely originate from a lack of technology. They emerge from the interaction between technology, people, processes, incentives, and decision-making. Technology is only one variable, the visible one, the easiest to blame, and the easiest to replace. Yet rarely the actual root cause.
One incident illustrated this with particular force. A telecommunications provider I was supporting began receiving escalations from internet customers across multiple regions, intermittent disconnections, severe performance degradation during peak hours, symptoms that seemed random and widespread. Some customers were affected. Others were not. No clear pattern.
Engineering teams from multiple disciplines joined the troubleshooting sessions over several days. We reviewed routing, transport infrastructure, access layers, and traffic patterns. Every hypothesis seemed defensible. Teams pointed in different directions. Each day produced a new theory. Each theory failed to explain the full scope of what we were seeing.
The root cause, when we finally identified it, was almost embarrassingly contained: a single capacity component that had reached saturation far faster than forecasted, triggered by an unexpected traffic surge nobody had modeled. The fix took hours. The days of troubleshooting happened because the symptom, widespread, multi-region, intermittent, was pointing away from the actual constraint.
Complex systems rarely fail in ways that reveal their cause.
The visible symptoms point in one direction.
The actual constraint hides somewhere else entirely.
Understanding interactions is more important than understanding individual components.
Many organizations invest heavily in infrastructure modernization while leaving untouched the organizational behaviors that created the problem. Others deploy sophisticated monitoring platforms while continuing to operate with reactive decision-making. The technology changes. The underlying system dynamic remains.
What Architecture Actually Teaches You
As responsibilities expanded from operations into engineering and architecture, my perspective changed in a specific way. The challenge shifted from restoring service after failure to preventing failure before it occurred, and designing systems that remained functional when prevention failed.
Architecture is fundamentally an exercise in anticipation. Good architectures assume growth, assume change, assume uncertainty, and most importantly assume human imperfection, because humans will always misconfigure, misunderstand, and misjudge at some point in a system's lifetime.
The goal is not to create systems that never fail. The goal is to create systems that fail gracefully.
I returned to this principle repeatedly in healthcare network environments. Nobody in that hospital boardroom cared whether a routing policy was elegant, whether the BGP design was technically optimal, or whether we had followed a particular architecture framework. What mattered was whether clinicians could access the imaging system when a patient was on the table. What mattered was whether the electronic health record was reachable when a physician needed it at 3 AM.
Resilience is not the absence of failure.
Resilience is the ability to absorb disruption without losing purpose.
A system optimized to never fail is usually the most fragile when it does.
That clarity of purpose, understanding exactly what the system is protecting, is what separates architects who build for compliance from architects who build for outcomes. The hospital taught me to ask that question before touching anything.
The Shift That Changed Everything
At some point, a different realization emerged. Technical excellence alone does not create value. Business outcomes create value.
This sounds obvious. Yet many technology organizations continue to optimize metrics that have little connection to organizational objectives, celebrating infrastructure milestones while struggling to explain how those achievements changed anything the business actually cared about.
The transition into product management and customer-facing strategy clarified this permanently. The conversations changed. Success was no longer defined by what was deployed. It was defined by whether adoption grew, decisions improved, risk decreased, and the organization moved faster. Technology became less central. Impact became the only measure that mattered.
The lesson from the hospital boardroom applied here too. The executives in that room didn't care about packet loss percentages. They cared about operational continuity and patient safety. My job was to translate one into the language of the other, to build a bridge between the technical reality and the strategic concern. That translation is not a communication skill. It is a leadership skill.
Observability Is About Decisions, Not Systems
This evolution eventually led me toward observability. Not because dashboards are interesting. Not because telemetry is fashionable. But because observability addresses a challenge I had been circling for years without having the right language for it.
Most people think observability is about understanding systems. I increasingly believe it is about understanding decisions.
The distinction matters. Systems can be observed in isolation, you can instrument every service, collect every metric, build every dashboard. Many organizations do exactly this. They end up with enormous volumes of telemetry and the same reactive operating model they had before. The data is there. The insight is not.
The organizations that extract genuine value from observability are the ones that connect telemetry to decision-making processes. They ask not just "what is happening?" but "what should we do differently because of what is happening?" They treat observability not as a monitoring function but as a decision-support capability, one that enables leaders to move from reacting to events toward anticipating conditions.
In the hospital environment, this distinction was literal. The network carried clinical decisions. A degraded imaging link was not a performance issue, it was a diagnostic delay. Understanding the system meant understanding the decision it was supporting. The technical signal and the human consequence were inseparable.
Observability is not a tool you buy.
It is a commitment to understanding what your systems are enabling,
and what decisions become impossible when those systems degrade.
That commitment has to be cultural before it can be technical.
AI and the Speed of Decisions
Artificial intelligence adds urgency to everything described above. Every major technological shift in history has increased the speed at which organizations operate. AI is doing the same , at a scale and pace that previous shifts did not approach.
But faster decisions are not inherently better decisions. Poor decisions executed faster simply create larger problems. This is why I believe AI's value is conditional: it depends entirely on the quality of the observability and data foundations underneath it. AI-assisted decision-making built on poor telemetry, untrusted data, or disconnected processes does not accelerate performance. It accelerates error.
The organizations that will lead the next decade are those that build deep observability, trusted data foundations, and AI-assisted decision-making as a single integrated operating model, not three separate technology initiatives with separate budgets and separate teams.
Why Latin America Requires a Different Lens
Much of my professional life has been spent working across Latin America, not passing through, but operating, building, and making decisions inside its specific realities. And that experience has taught me something global frameworks consistently overlook:
Latin America is not a smaller version of North America. It is not a delayed version of Europe. It is its own environment, with its own constraints and its own opportunities.
Building infrastructure here means working with international connectivity asymmetries that fundamentally change the latency assumptions behind standard cloud architectures. It means navigating data sovereignty requirements that vary not just by country but by sector within a country. It means making CAPEX and OPEX trade-offs against economic realities that most vendor ROI calculators don't model.
"Cloud-first" is a legitimate strategic choice in some contexts and a poorly-researched decision in others, sometimes within the same country, in adjacent cities. The talent pipeline is narrower and more unevenly distributed than global benchmarks assume. Regulatory environments change faster and less predictably than in mature markets.
None of this is an argument for lower standards. It is an argument for locally-grounded thinking. The same principle from the hospital boardroom applies at regional scale: you cannot walk in with a global playbook and expect it to land. You have to understand the specific environment, its constraints, and what is actually at stake.
The future of digital transformation in Latin America
will not be built through imitation.
It will be built by people who understand the environment from the inside
and are willing to adapt global innovation to local reality.
That principle drives my doctoral research, focused on predicting international network connectivity degradation between Latin American infrastructure and major cloud providers using machine learning models. Every enterprise in the region running hybrid cloud workloads faces this problem daily, usually without the tools to anticipate or quantify it.
It also drives descubre.pe. healthyCar explores how telemetry and predictive analytics can help vehicle owners identify mechanical failures before they become costly incidents, the same observability logic applied to a different physical system. universidad.descubre.pe shares the practical knowledge, roadmaps, and lessons I wish I had access to earlier in my own career.
What This Insights Series Is Actually About
The technologies I have worked with have changed continuously over two decades. The industries changed. The responsibilities changed. The scale changed.
What remained constant was the challenge: understanding increasingly complex systems, and helping people make better decisions inside them.
Whether in a hospital boardroom in Central America, a network operations center in Peru, or a research seminar at the university, the underlying question is always the same. How do we turn information into understanding, and understanding into action that matters?
Technology matters.
But technology alone is never enough.
Technical depth without strategic clarity is just expensive maintenance.
The future belongs to those who can understand systems,
translate complexity, and help organizations make better decisions.
That is the journey I intend to explore over the next weeks.
I hope you find it worth following.
Some posts will be technical. Others will be strategic. A few will be personal. All of them will be grounded in practice, not theory. Push back when you disagree, the best conversations begin with friction.
Edwin Martin Salazar Vega
Helping organizations make better decisions through technology, observability, and complex systems thinking.