Published: Jun 15th, 2026 - 7 min read
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.
My career has taken me through four very different organizations, in different countries, at different scales, with different technologies.
At Banco de Crédito del Perú, I worked in IT operations during a period of rapid system growth in Peruvian banking. The infrastructure was demanding. The business pressure was constant. And the most critical moments were not the ones where the technology was most complex. They were the ones where the business impact was most immediate and the people involved were most stressed.
At Entel Peru, I moved into mobile telecommunications, eventually leading network engineering teams during the LTE expansion in Peru. A mobile network is, by definition, infrastructure that cannot afford to fail. Millions of subscribers. Real-time services. A single miscalculation in a maintenance window could affect an entire region. The technical problems were solvable. I had the training for that. But the moments I remember most clearly are not the routing issues or the capacity optimizations. They are the moments when a room full of engineers, operations leaders, and commercial stakeholders all looked at the same situation and saw completely different problems.
At Telefónica Global Solutions, I worked on satellite infrastructure for enterprise clients across multiple countries. The stakes were different again. Satellite links are not forgiving. You cannot iterate quickly. Every decision has consequences that take time to reveal themselves, and clients who depend on that connectivity for business-critical operations have very little patience for ambiguity. What I learned there was that the most valuable thing I could provide was not technical precision. It was the confidence that came from having a clear process for making decisions under uncertainty.
At Cisco, across roles in the Global Center, the Americas, and now in product management, the scale changed. The customer base became global. The problems became more complex. The stakeholder environment became more layered. But the pattern was the same.
The stakes changed. The systems changed. The countries changed. The moment of truth was always the same: a room full of people with incomplete information, competing priorities, and a decision that could not wait.
I spent years improving my technical depth, believing that the path to greater impact ran through greater expertise. And technical depth matters. The CCIE required it. So did the work.
But the inflection point in my career did not come from knowing more protocols. It came from understanding that the bottleneck in most critical situations was not technical knowledge. It was the human capacity to produce clarity, create alignment, and make a defensible decision when the data was incomplete.
Three things kept appearing as the real differentiators in high-pressure situations.
When a critical system fails, the organizational instinct is to wait for a definitive diagnosis before communicating anything. The reasoning is understandable: you do not want to say the wrong thing, create unnecessary alarm, or commit to an explanation that later proves incorrect.
But organizations in crisis cannot survive on silence. What they need, before they need answers, is a clear picture of the situation as it actually stands: what is known, what is not yet known, and what the immediate next steps are.
I learned this slowly, through a series of incidents where the technical diagnosis took longer than the organizational patience. The teams that stayed aligned were not the ones that communicated certainty. They were the ones that communicated clearly about uncertainty. They said: we do not know the root cause yet, we have isolated it to this domain, we expect to have an update in this timeframe, and here is what we need from each of you in the meantime.
That structure, maintained consistently, is what keeps a complex situation from becoming a chaotic one. It does not require knowing the answer. It requires having the presence of mind to frame the situation precisely when precision matters most.
Clarity is not the absence of uncertainty. It is the ability to structure uncertainty so that others can act within it.
One of the most costly mistakes I have seen in infrastructure operations is treating misalignment as a soft issue. Something to be addressed eventually, through better communication, team-building, or leadership development.
In my experience, misalignment is a systems problem. It has a structure that can be diagnosed and addressed with the same discipline you would apply to a routing failure.
Different teams operating on the same incident often have different definitions of what success looks like. The operations team wants to restore service as fast as possible. The engineering team wants to understand the root cause before applying a fix that might mask a deeper issue. The business team wants to know when they can communicate to customers. The security team wants to ensure the incident is not a vulnerability before they allow the environment to be restored.
All of those positions are legitimate. When they are not explicitly surfaced, they compete silently, producing fragmented decisions, slow escalations, and sometimes contradictory actions that extend the incident beyond what the technical problem alone would have required.
The skill of bringing those positions into the open, not to resolve them immediately but to make the tradeoffs visible, is not a facilitation skill. It is precision work. It is the most important precision work in a critical incident.
Misalignment is not a communication problem. It is a systems problem. It has a structure. It can be diagnosed. And it can be fixed, if someone is willing to do the work explicitly.
I have observed two patterns in people under operational pressure, and they diverge sharply in the moments when the data is incomplete.
The first pattern: wait for certainty before committing to a position. This feels responsible. It is often framed as prudence. But in high-stakes situations with time pressure, waiting for certainty is itself a decision, one that transfers the cost of uncertainty to everyone else in the room, and often to the customer or end user.
The second pattern: make a defensible recommendation based on the best available information, state clearly what assumptions that recommendation rests on, and remain accountable for the outcome as new information arrives.
The second pattern is harder. It requires accepting that you might be wrong, and being willing to revise publicly when new data changes the picture. It requires the confidence to commit, and the honesty to revise publicly when the picture changes.
I have watched technically brilliant people become invisible in critical moments because they could not bring themselves to commit under uncertainty. And I have watched less experienced people become indispensable because they were willing to say: based on what we know right now, here is what I recommend, and I will own this recommendation.
That willingness: to commit, to stay accountable, to revise when wrong. That is what separates technical expertise from technical leadership.
If there is a single principle that has emerged from two decades across banking, telecommunications, consulting, and enterprise technology, it is this:
Technology almost never fails because of the technology. It fails because of the decisions made around it: what to prioritize, when to act, who owns the outcome, how to communicate when the answer is not yet clear.
That principle has shaped how I think about observability: the goal is not better dashboards, it is better decisions. It has shaped how I think about AI: the question is not how to deploy models, it is how to improve the quality of judgment. It has shaped how I approach product strategy, customer success, and organizational transformation.
Critical infrastructure is an extreme environment. The consequences of poor decisions are immediate and visible. The feedback loop is short and unforgiving. It teaches you, faster than almost any other context I know, that the technical layer and the human layer are inseparable.
You cannot engineer your way around the human problem. But you can develop the discipline to address both, simultaneously, under pressure.
Looking back, I now understand why I became so interested in observability. It was never about collecting more telemetry. It was about helping organizations make better decisions before uncertainty turned into disruption. The infrastructure that generates signals matters. What matters more is whether those signals inform better judgment: faster, with less noise, and before the situation becomes a crisis.
That connection between visibility and decision quality is what ties the technical work to the leadership work. They are not separate disciplines. They are the same problem, approached from different angles.
The first twenty years taught me the difference. The next chapter is about applying it at greater scale.
What is the most important lesson you have learned while operating mission-critical systems?
Edwin Martin Salazar Vega
Helping organizations make better decisions through technology, observability, and complex systems thinking.