bridge light consulting
Articles
What Military Intelligence Taught Me About Leading Through Ambiguity
A lesson in separating signal from noise and making decisions when certainty isn't available.
AI Isn’t Just Changing Technology - It’s Changing How Organizations Operate
Why creating value with AI may depend less on the technology than on redesigning how organizations work.
When Everything Seems Important, What Comes First?
Why enterprise prioritization is ultimately a leadership problem, not simply an analytical one.
Technical Debt Is Not Just an Engineering Problem
How accumulated technical compromises eventually become constraints on organizational execution.
What Military Intelligence Taught Me About Leading Through Ambiguity
Early in my career, I served as an Arabic linguist and cryptanalyst in U.S. Army Military Intelligence. Like many people entering that field, I thought our goal was to provide leaders with certainty.
But … no. Working in intelligence, and later studying decision analysis at Stanford, I came to understand a critical reality: certainty does not exist. Every important decision concerns the future, and the future is inherently uncertain. No amount of analysis, data collection, or expertise can completely eliminate the uncertainty.
Now, after leading complex enterprise initiatives across large organizations, I've realized that the same principles applies in business. The job of analysts, program managers, intelligence officers, and staff organizations is not to eliminate uncertainty - it is to equip leaders make better-informed decisions despite uncertainty.
Three lessons from Military Intelligence continue to shape how I approach ambiguity today.
1. The Information Will Never Be Complete
One of my first observations in intelligence work was that there was always another piece of information we wanted. There were always unanswered questions and competing interpretations. The problem is that certainty is never available – and the same is true in business.
The challenge is not overcoming uncertainty; the challenge is recognizing that uncertainty is part of the foundation of every important decision. Whether the question involves military operations, business strategy, or a major enterprise initiative, leaders are ultimately making judgments about possible future states.
Organizations often respond to ambiguity by asking for more analysis, more planning, or more discussion. Sometimes that additional effort is valuable. More often, however, it reflects an erroneous belief that sufficient certainty is possible if we can just collect enough information.
In reality, the purpose of analysis is not to create certainty. It is to improve understanding in the face of incomplete information. Good analysis narrows the range of possible outcomes, clarifies assumptions, and exposes risks that might otherwise go unnoticed. It improves judgment, but it does not eliminate ambiguity.
2. Learn to Distinguish Signal from Noise
Once one accepts that certainty is impossible, the challenge changes. The objective is no longer to gather as much information as possible. The objective becomes understanding which information actually matters.
This was one of the most valuable lessons I learned in Military Intelligence. The difficulty was rarely the absence of information. More often, the difficulty was determining which information genuinely changed our understanding of the situation and which information merely added volume.
The same challenge exists in large organizations.
Enterprise initiatives generate an enormous amount of data, analysis, reporting, and discussion. Yet despite this abundance of information, many organizations still struggle to make timely decisions or recognize emerging problems before they become serious.
The reason is that information and insight are not the same thing.
Insight comes from recognizing patterns, understanding relationships, and identifying the factors most likely to influence outcomes. It requires context, analysis, and judgment. Most importantly, it requires the discipline to focus on what is important rather than what is simply available.
This is one of the most valuable contributions a program leader can make. The goal is not to produce more information for its own sake. The goal is to help the organization focus its attention on the decisions, dependencies, and risks that will ultimately determine success.
3. Progress Comes From Decisions, Not Certainty
We often refer to senior leaders as decision-makers, and for good reason. Organizations entrust them with the responsibility of making consequential decisions despite incomplete information and competing perspectives. This ability to act in the face of ambiguity is one of the defining characteristics of leadership.
At the same time, the toughest decisions are never a solo activity. Several years ago, I led a team of analysts, project managers, and change leaders responsible for assessing our organization's performance and identifying strategic options for senior leadership. Our work involved gathering data, evaluating outcomes, and developing recommendations that would ultimately influence major decisions.
I expected leadership to focus primarily on our recommendations. Instead, they consistently focused on our assumptions.
One of the first slides in every workshop outlined the assumptions that underpinned our analysis. Before discussing options or debating recommendations, the leadership team would examine those assumptions carefully. They understood that if an assumption proved incorrect, the conclusions built upon it could change dramatically.
What struck me was that these discussions rarely weakened the decision-making process. They strengthened it. Leaders brought perspectives, experiences, and information that our team did not possess. By challenging assumptions, they reduced uncertainty and improved the quality of the decision that followed.
That experience reinforced the message: effective decision-making is not about achieving certainty. It is about combining expertise, judgment, and the best available information to understand a situation well enough to move forward.
Looking back, I realize that my role has been remarkably consistent throughout my career. In Military Intelligence, my job was to help leaders understand complex situations and make difficult decisions under uncertainty. Today, as a program leader, my role is much the same.
Whether the discussion centers on intelligence assessments, strategic initiatives, or enterprise transformations, the process is remarkably similar. Gather the best available information. Examine the assumptions. Challenge the conclusions. Reduce uncertainty where possible.
Then decide. Because certainty was never the goal. Better decisions were.
Join the discussion on LinkedIn
AI Isn’t Just Changing Technology - It’s Changing How Organizations Operate
I see much conversation around AI transformation centering on the technology itself: models, copilots, agents, prompts, platforms, and performance. Of course those things matter, but they can also obscure the deeper organizational challenge.
For the purposes of this discussion, I am defining AI transformation not as the deployment of AI tools, but as the new ways work gets executed through AI capabilities.
The distinction matters because many organizations are approaching AI transformation primarily as a technology implementation effort when, I contend, it is more fundamentally an operational transformation effort.
The real challenge will rarely be whether the AI can technically perform a task - increasingly, it can. The harder challenge is integrating those capabilities into complex operational environments shaped by workflows, decision structures, governance models, communication patterns, organizational incentives, and human behavior.
AI transformation will succeed or fail far more on operational execution than on technical sophistication.
Why AI Failures May Actually Be Workflow Failures
One of the more interesting realities about AI is that it tends to amplify operational conditions that already exist inside the organization.
If workflows are fragmented, inconsistent, overly manual, poorly documented, dependent on tribal knowledge, or burdened by unclear ownership, AI can magnify the dysfunction rather than solving it. This might be one reason some AI initiatives struggle to generate durable business value, despite impressive demonstrations. The technology itself may work quite well in isolation – but enterprise work rarely occurs in isolation.
Real operational environments contain approvals, escalations, exceptions, competing priorities, governance constraints, incomplete information, and ambiguous decision rights. Organizations often discover that the limiting factor is not the model’s intelligence, but the surrounding operational system.
An AI assistant may dramatically accelerate document generation, for example. But if downstream review cycles, approvals, and ownership structures remain inefficient, overall execution speed may improve only marginally. Similarly, AI-driven customer support tools may perform impressively in controlled environments, while struggling inside organizations where escalation paths, knowledge management, and operational accountability remain unclear.
AI can expose operational dysfunction faster than it resolves it.
This is why I would advocate beginning AI transformation with operational simplification: clarifying workflows, reducing friction, standardizing processes, improving data flow, defining ownership, and streamlining decision-making.
The organizations realizing the greatest AI value might not be the ones with the most advanced models, but rather, the ones with the clearest operational architecture.
The Measurement Trap: AI Activity Is Easier to Measure Than AI Value
Another major challenge is that AI activity is often much easier to measure than AI impact.
Organizations can quickly create dashboards showing prompts submitted, tokens consumed, copilots deployed, workflow automations created, and AI adoption rates. Those metrics create visibility and reporting structures. They create the appearance of measurable transformation.
But they do not necessarily demonstrate meaningful business value. This creates a familiar organizational risk: activity begins substituting for outcomes.
The more difficult questions are operational:
-
Did execution become faster?
-
Did decision quality improve?
-
Did customer outcomes improve?
Those outcomes are much harder to measure than token consumption or AI adoption percentages, so organizations naturally drift toward the metrics that are easiest to operationalize rather than the ones most tightly connected to business impact.
This pattern is not unique to AI (see, Why Business Organizations Can Still Fail to Execute). Large organizations have long struggled with the difference between visibility and value. AI simply introduces a new set of highly measurable activity indicators that can unintentionally distort organizational behavior.
Once leadership begins rewarding visible AI activity, organizations will optimize accordingly. AI will get deployed where visibility is highest, usage metrics become performance indicators, and “AI-first” branding begins substituting for meaningful operational improvement. Meanwhile, the harder work of simplifying execution and redesigning workflows may receive less attention because it is slower, more ambiguous, and more difficult to quantify.
This is where organizations risk drifting into AI theater: highly visible AI activity without proportional operational improvement.
Ultimately, the value of AI is not determined by how extensively it is used. It is determined by whether the organization executes more effectively because of it.
AI Transformation Is Ultimately a Change Management and Operating Model Challenge
Perhaps the most underestimated aspect of AI transformation is the degree to which it requires organizations to rethink how work itself is structured.
AI changes how decisions are made, how information flows, how teams collaborate, how expertise is accessed, and where human judgment gets applied. That creates operational and behavioral disruption far beyond a typical software deployment.
Organizations are not simply introducing a new tool - they need to be redesigning portions of the operating model itself. That requires difficult organizational adaptation: redefining roles, clarifying human versus machine responsibilities, redesigning workflows, updating governance structures, establishing trust boundaries, and training teams to work differently.
This is why AI transformation often resembles large-scale change management more than a traditional IT implementation.
And like most operational transformations, success depends heavily on leadership alignment, execution discipline, organizational clarity, communication, prioritization, and adoption behavior. Technology alone does not create transformation. Organizations transform when people change how work gets executed.
Final Thought
AI transformation is being discussed as though it were primarily a technological revolution. In reality, it probably needs to be a large-scale operational redesign effort, enabled by the new technology.
The organizations that succeed will likely not be the ones deploying the most AI tools or consuming the most tokens. They will be the organizations that most effectively redesign workflows, simplify execution, reduce operational friction, and integrate AI capabilities into coherent operating models.
Because ultimately, AI does not transform organizations on its own. People, processes, and operational systems do.
Join the discussion on LinkedIn
When Everything Seems Important, What Comes First?
Some time back I completed the Strategic Decision and Risk Management program at Stanford. We spent considerable time learning decision analysis: evaluating uncertainty, understanding tradeoffs, and using analytical tools to compare competing alternatives. It was excellent training, and I've relied on those principles throughout my career.
What I may not have fully appreciated at the time was that enterprise project prioritization is a different kind of problem. Discussions of decision analysis often assume there is a decision-maker - singular. Enterprise organizations have leadership teams. The distinction is enormous.
Organizations strive to prioritize their most worthy project investments, typically on a regular cadence – annually, quarterly, possibly monthly. We often talk about prioritization as though somewhere in the portfolio are projects that clearly deserve funding and others that do not.
That’s actually somewhat rare. By the time we get to a leadership strategy workshop, everything being presented should already have a compelling value case. We aren't separating worthwhile initiatives from unworthy ones. Pretty much everything on the list is worth doing.
We have to deprioritize genuinely valuable work in favor of work that, given everything we know at that moment, appears even more valuable.
If prioritization were purely an analytical exercise, that might be true. But consider who is sitting around the table - Engineering, Finance, Sales, Operations, Legal, Product - each leader is accountable for different outcomes. Each sees different risks. Each has legitimate reasons for wanting particular initiatives to move forward. They aren't disagreeing because someone misunderstood the data. They disagree because they are accountable for different forms of organizational value.
Prioritization certainly requires sound analysis, but it is fundamentally a leadership exercise. Analysis helps us understand tradeoffs. It gives us a common language for discussing value, risk, cost, and uncertainty. But it can’t replace judgment, because judgment belongs to decision-makers, not spreadsheets.
Prioritization also isn't a queue where projects patiently wait their turn. Every portfolio review reflects the realities of that moment. Markets change. Customers make new demands. Technologies evolve. New risks emerge. An initiative that isn't selected today may be reconsidered next quarter - or it may be passed over again - not because it lost its value, but because the surrounding environment has changed. There is no guarantee that patience alone will eventually move an initiative to the top of the list.
That's one reason I believe the scarcest organizational resource isn't budget or staffing - it's attention.
Organizations can almost always identify more worthwhile investments than they can actually deliver. Leadership attention, engineering capacity, stakeholder engagement, and organizational focus are all finite. Every additional initiative competes for those same resources.
Eventually, the challenge stops being one of budgets and staffing - it becomes one of organizational commitment.
I remember having this conversation more than once with senior executives at Cisco. Their highest-priority initiative hadn't made the organization's final portfolio, and they would quietly talk about delivering it within their own organization anyway. It seemed like a reasonable proposal. To them, they genuinely believed it was the highest-value investment available.
But, the portfolio only works if we commit to it collectively. A "shadow project" doesn't create new capacity. It quietly consumes engineers, managers, funding, and leadership attention that the organization has already committed elsewhere. The project itself may be valuable, but its true cost extends far beyond its own budget - it also reduces the organization's ability to deliver the priorities we had already agreed were even more important.
Those conversations reinforced another lesson: there is almost always more than one way to deliver an initiative. Exploring alternative delivery models often creates more value than arguing over where the original proposal belongs in the ranking.
Looking back, one lesson from those years of studying decision analysis has become even more meaningful through experience. When I first began facilitating executive strategy workshops, I was surprised that senior leaders were usually less interested in my team's recommendation than in the assumptions behind our analysis. After some reflection, it made perfect sense.
Recommendations are the conclusion. Assumptions explain why a conclusion makes sense. If leaders are aligned on the underlying assumptions, they'll often reach similar decisions. If they don't, the recommendation itself becomes far less interesting than understanding where their perspectives begin to diverge.
I've come to understand that discussion of the assumptions was where the real executive prioritization began - around a table where capable leaders, acting in good faith, work through competing priorities, challenging one another's assumptions, and ultimately deciding where the organization will place its collective attention.
The purpose of prioritization isn't to prove which projects deserve to succeed. From someone's perspective, pretty much all of them do.
The goal is helping the organization commit its limited attention to the combination of work most likely to create the greatest overall value - knowing that reasonable leaders, acting in good faith, will often disagree about what that combination should be.
Join the discussion on LinkedIn
Technical Debt Is Not Just an Engineering Problem
Technical debt is often discussed as an engineering concern.
The conversation usually revolves around aging systems, outdated architecture, accumulated workarounds, and the growing effort required to maintain existing applications. Those are important considerations, and engineering teams are often the first to feel their impact.
But technical debt was not created by engineering alone, its consequences are not confined to engineering, and it cannot be resolved by engineering alone.
Most technical debt begins as a tradeoff. An organization chooses to prioritize speed, delivery, or near-term business outcomes over a more durable technical solution. In the moment, the decision may seem entirely rational because customers are waiting, commitments have been made, and opportunities are time-sensitive. The issue is that while the benefits of the decision are immediate, the costs are deferred. Over time, those deferred costs begin to shape how the organization operates.
This is why technical debt deserves attention far beyond engineering.
Technical Debt Becomes Organizational Friction
Technical debt becomes an organizational problem when it begins to increase the cost of execution.
In healthy systems, change is relatively straightforward. Teams can introduce new capabilities, modify existing functionality, and respond to emerging business needs without excessive effort. As technical debt accumulates, however, the cost of change begins to rise.
What makes this dynamic particularly insidious is that the impact is rarely dramatic at first. Technical debt does not usually announce itself through a major failure. Instead, it gradually changes the amount of effort required to accomplish routine work. As the cost of change increases, teams spend more time navigating complexity and less time creating new value.
The organization may continue delivering results, but it does so with decreasing efficiency. Work becomes harder to estimate because the effort required is increasingly difficult to predict. That uncertainty then spreads beyond engineering, affecting planning, commitments, and stakeholder expectations. What began as a technical constraint gradually becomes an execution constraint.
At that point, technical debt is no longer simply a technical issue - it has become organizational friction.
Organizations Habitually Build on Top of It
If technical debt creates so many challenges, why do organizations continue accumulating it? Because the forces that created the technical debt don’t just go away.
Organizations are constantly balancing present demands against future consequences. The benefits of delivering a feature today are visible and measurable, while the benefits of reducing technical debt are often indirect and may not become apparent until much later. As a result, immediate priorities almost always feel more urgent than addressing existing debt. This creates a pattern that is surprisingly difficult to break.
Each new initiative is planned within the constraints of the current environment. Teams adapt to those constraints, find ways to work around limitations, and continue delivering value. Because progress remains possible, there is little incentive to pause and address the underlying condition.
The irony is that every workaround increases dependence on the very systems creating the friction. Over time, the organization becomes increasingly optimized around its constraints rather than removing them. Complexity grows not because anyone intended to create it, but because continuing forward appears easier than stepping back.
Many organizations eventually find themselves applying what amounts to band-aids on top of band-aids. Each workaround solves an immediate problem, but also adds another layer of complexity that future teams must navigate. The result is a system that continues functioning, yet becomes progressively harder to change, understand, and maintain.
The debt accumulates through the repetition of reasonable decisions. Viewed individually, each decision makes sense. Viewed collectively, those decisions gradually reshape the organization's ability to execute.
Program Leaders Must Treat Technical Debt as a Strategic Constraint
Program leaders are responsible for translating strategy into execution.
That responsibility requires understanding the constraints that shape execution, even when those constraints originate outside the program itself—and technical debt is one of those constraints.
Organizations routinely account for constraints during planning. Leaders understand that strategy must operate within the realities of budgets, capacity, and competing demands. Technical debt deserves similar consideration because it directly influences what the organization can realistically deliver and how quickly it can deliver it.
The mistake many organizations make is treating technical debt as a technical detail rather than an execution variable.
This distinction matters because technical debt often remains invisible during planning discussions. Leaders focus on desired outcomes, delivery dates, and business commitments without fully accounting for the environment in which the work must occur.
When technical debt is overlooked during planning, commitments are often based on desired outcomes rather than operational realities. Plans may appear achievable on paper, yet become increasingly difficult to execute because they fail to account for the true cost of change. What ultimately appears to be an execution problem is often the predictable consequence of planning that underestimated the constraints already embedded within the environment.
Strong program leaders recognize this dynamic and help make those constraints visible.
They do not need to become architects or engineers. They do, however, need to understand how technical debt affects organizational capacity and execution risk. More importantly, they need to ensure those realities are reflected in planning, prioritization, and decision-making discussions.
Ignoring technical debt does not eliminate the constraint. It merely postpones the moment when the organization is forced to confront it.
Final Thoughts
Technical debt is often discussed as if it were a purely technical issue, but its effects are fundamentally organizational.
As the cost of change increases, technical debt begins influencing how quickly an organization can adapt, deliver, and execute. Organizations then compound the challenge by continuing to build on top of existing constraints, gradually reducing the flexibility they need to respond to future opportunities.
This is why technical debt cannot be viewed solely as an engineering issue - it is a strategic constraint that affects the entire organization.
And like any meaningful constraint, it becomes far easier to manage once leaders recognize its role in shaping execution.
Join the discussion on LinkedIn