The Best Engineering Managers Spend More Time Removing Ambiguity Than Writing Strategy
Most engineering managers believe strategy is their highest-value contribution.
I disagree.
Strategy matters. But in most engineering organizations, execution does not fail because engineers lack vision. It fails because engineers spend their days making hundreds of decisions that leadership should have resolved long before implementation began. Decisions about ownership. About priorities. About what readiness means. About whose alert matters.
Every unresolved question is a tax on execution.
After years leading platform and delivery programs across healthcare, financial services, and large-scale commerce, I have come to one conclusion: ambiguity is one of the most expensive forms of technical debt an organization carries, and removing it is an engineering manager’s highest-value responsibility.
Most people think technical debt lives in code. A significant portion lives in unclear decisions, undefined ownership, and priorities that were never ranked. The engineering manager who treats those gaps as background noise will eventually find them in the incident log.
Ambiguity Has a Price Tag
Every engineer has experienced the frustration of waiting days for an answer that should have taken five minutes. That wait has a name: organizational ambiguity. And it shows up everywhere.
Duplicate work happens when ownership is unclear. Conflicting assumptions surface during integration. Engineers wait because decisions sit above them. Teams over-engineer because they do not trust the surrounding systems. Meetings exist to answer questions documentation should have settled. Incidents last longer because nobody knows who owns the failing service.
Every one of those outcomes is measurable. The engineering manager who resolves ambiguity upstream removes an entire class of downstream expense.
The question is what kind of ambiguity to resolve first.
Three Kinds of Ambiguity
Here is what that looks like in practice. Ambiguity in engineering organizations falls into three categories. Each requires a different leadership response.
Technical ambiguity is the “we have not decided how this works” problem. Architecture choices left open. API contracts undefined. Ownership of shared components unassigned. Engineers make local decisions to keep moving, and those local decisions become the de facto standard whether or not they were the right call.
Organizational ambiguity is the “we do not know who owns this” problem. It appears most visibly at the boundaries of platform, SRE, DevOps, and security teams. Each discipline has a charter. Nobody has mapped where one charter ends and another begins. When an incident crosses those boundaries, resolution slows to the speed of a conversation that should have already happened.
Priority ambiguity is the most common and the most corrosive. Twenty priorities on a roadmap is the organizational equivalent of no priorities. Engineers make tradeoffs under the assumption that everything matters equally, which means the highest-visibility work gets attention and the foundational work gets deferred. Priority ambiguity is how technical debt accumulates while everyone is busy.
The goal is not eliminating uncertainty. Engineering is inherently uncertain. The goal is eliminating avoidable ambiguity before it becomes expensive.
Example 1: Eleven Monitoring Platforms and the Ownership Problem
At a federally regulated financial services cooperative, I inherited an observability environment with eleven monitoring platforms. Different teams owned different tools. Alert ownership was inconsistent across systems. On-call rotations reflected history, not current system ownership.
The surface-level diagnosis was “too many dashboards.” The actual problem was organizational ambiguity at scale.
Nobody could answer four questions with confidence: who owns this component, which alert requires a response, who responds, and which metrics define success for this service. Without answers to those four questions, every incident began with a coordination problem before it became a resolution problem.
My contribution was resolving the ownership layer first. I built governance around alert ownership, mapped SLIs and SLOs to accountable teams, established executive reporting that made ownership visible above the engineering layer, and created a standardized alert response structure so that when something fired, the right person knew it was theirs.
Tool consolidation became straightforward once ownership was clear.
The results: a 40% reduction in release failures and a 50% improvement in mean time to detect. Neither of those numbers came from a new monitoring product. They came from replacing ambiguity about ownership with documented accountability. Reliability improved because the organizational layer became as well-engineered as the technical layer.
Example 2: Black Friday Readiness at a Fortune 10 Health and Commerce Company
At a Fortune 10 health and ecommerce company, production readiness for peak commerce events, Black Friday and Cyber Monday among them, depended on the coordination of QA, infrastructure, engineering, operations, and release management. Hundreds of systems. Dozens of teams.
Everyone technically owned something. Nobody individually owned production readiness.
Production readiness had many contributors but no single owner. Every team optimized its own responsibilities. Nobody owned the collective outcome.
I drove the design and implementation of quality gates and release governance that embedded readiness criteria before deployment. The gates defined, in writing: what conditions constitute readiness, what conditions trigger a rollback, and who holds the go/no-go decision. Each of those answers previously lived in someone’s judgment. I moved them into documented, enforced criteria.
The biggest change was not fewer defects. It was fewer debates. Every team knew the readiness criteria, who made the go/no-go decision, and what triggered a rollback before deployment began.
The result was a 30% reduction in P1 incidents. The mechanism was shared criteria. Production readiness became a defined state with documented conditions, replacing the informal collective judgment that had governed major deployments before.
Example 3: Performance Engineering Is Ambiguity Reduction
The most instructive example comes from a state healthcare exchange platform operating under a federal compliance deadline with no schedule flexibility. The stakes were concrete: 300,000 users, zero downtime tolerance, and a peak load target of 10,000 concurrent users. No extensions available.
Under those conditions, the engineering team could not afford “I think.” They needed evidence.
The tool suite included Oracle AWR for database execution analysis, Wireshark for packet capture, JMeter and LoadRunner for load simulation, F5 for traffic management, and Splunk for log correlation. The interesting part was not the tools themselves. It was what they replaced.
Without AWR, the conversation was: “the database feels slow.” With AWR, it became: “this query consumes 62% of execution time and executes on every page load.” One of those statements produces a ticket. The other produces a debate.
Without packet captures, the conversation was: “the network might be the problem.” With Wireshark, the network either was or was not the problem. Ambiguity removed, root cause narrowed, resolution accelerated.
Load testing under realistic concurrency replaced speculation about scale behavior with data. Performance thresholds replaced judgment calls about readiness with criteria. Every tool in the stack served the same function: converting an assumption into a measurement, and a measurement into a decision.
The platform met the federal deadline, absorbed the concurrent user load, and maintained availability throughout open enrollment. Engineers acted on evidence, and evidence replaced the hedging that speculation produces.
Performance engineering, at its core, is a discipline for removing ambiguity about system behavior before production exposes it.
What Great Engineering Managers Actually Do
Different technologies. Same leadership problem.
Great engineering managers reduce ambiguity continuously across five dimensions.
Ownership. Every system, service, alert, and operational responsibility has a named owner. That ownership is documented, visible to leadership, and updated when it changes.
Priorities. The roadmap reflects a ranked order, not a list. When new work arrives, the manager names the displacement decision explicitly and communicates it before the team absorbs the cost silently.
Architecture. Technical decisions are recorded. The team can answer “why did we build it this way” without locating the person who was in the room when the decision was made.
Operational readiness. Go/no-go criteria are defined before the release begins. Rollback conditions are named. The decision-maker is identified. Nobody negotiates readiness under pressure.
Success metrics. The team knows what good looks like before it ships. SLIs and SLOs are agreed, documented, and tied to accountable owners.
When a manager maintains clarity across those five dimensions, engineering velocity increases without increasing headcount. Incidents resolve faster because ownership is unambiguous. Releases ship with fewer escalations because readiness criteria were pre-defined. Onboarding accelerates because decisions are documented. Cross-team coordination improves because boundaries are named.
Clarity does not eliminate difficult engineering. It eliminates unnecessary engineering.
Every unresolved ambiguity eventually becomes engineering work.
The best engineering managers resolve those questions before code is written, before systems fail, and before incidents become executive escalations.
Strategy determines where you are going.
Clarity determines whether you ever get there.
Nabeil Sarhan, MBA, is a dynamic technology delivery manager with over 15 years of experience in tech, cybersecurity, and computing scalability. He excels in leading diverse teams and delivering enterprise-class systems across industries such as healthcare, finance, and retail. Nabeil’s passion for solution design, systems architecture, and performance optimization makes him a sought-after consultant. He holds degrees from Harvard, MIT, and Bryant University. Connect with Nabeil on LinkedIn