Decision-Making in High-Stakes Security
With Carlos R. Gomez

From an operations standpoint, I was constantly deciding what datasets we needed to address opportunities and challenges within our daily operations—such as which MITRE ATT&CK tactics to prioritize, how to assign severity ratings consistently, and how to measure response efficiency. These weren’t just technical decisions—they shaped how we protected millions of users. The challenge was that while I had access to enormous amounts of security telemetry from thousands of internal AWS accounts, I didn’t always have a systematic framework for determining which data points truly mattered. I needed a better methodology for transforming complex security challenges into practical, actionable solutions our builder teams could implement to protect real people.

When data was incomplete, I engaged subject-matter experts for insights, but that sometimes caused delays. Working across time zones made near-real-time responses difficult, which is critical in incident response. Security incidents don’t wait for the right person to come online.

That often left me making gut decisions without the full picture—or waiting too long for information that might not even be essential. I lacked a systematic way to determine: What do I truly need to know? What can I infer? When is waiting for perfect data more costly than deciding with what I have?

Managing incident response at scale means analyzing massive datasets to identify what actually matters for security decisions. The challenge isn’t a lack of data—it’s cutting through the noise to focus on genuine risks.

I was drawn to Leadership Intelligence in the Era of AI program because it focuses on making better decisions under uncertainty and pressure—exactly what incident response requires. I wanted a structured framework that helps bridge quantitative analysis with executive-level decision-making and allows me to translate complex data into actionable recommendations for both technical teams and senior stakeholders.

Honestly, I felt in my element. Incident response often happens at a moment’s notice, so high-pressure decision-making is familiar territory. In the simulation, I took on a leadership role to help my team summit Mt. Everest. We communicated clearly and shared goals, but in hindsight, I realized I should have ensured we collectively defined success at the outset.

While we didn’t reach the summit, I received great feedback on earning trust, demonstrating ownership, and actively seeking insight from every team member—skills that directly translate to how I lead incident response. The exercise reinforced that even with strong instincts, having a clear decision framework and shared success metrics makes all the difference.

The most powerful takeaway was learning how to frame problems effectively. Framing keeps you focused on what needs solving and prevents you from getting lost in tangential data. Coupled with that is the “I Wish I Knew” (IWIK) approach, which forces you to state explicitly what questions must be answered before you can make a confident decision.

As a security engineer, we often see a challenge and immediately want to start building or solving for the technical problem. This program taught me to pause and ensure I fully understand whether I’m facing an adaptive challenge or a technical challenge first. That distinction changes everything about how you approach the solution. Now, before diving into any security investigation or tool development, I start by clearly framing: What decision am I trying to make? What do I wish I knew? What’s the minimum viable data needed to move forward?

The program struck a well-balanced approach. Our instructors used relevant, real-world examples from top Fortune 500 companies, making the concepts immediately applicable. Being exposed to both business context and technical data helped me understand how to craft executive-level summaries that earn buy-in and support.

What really clicked for me was realizing that executives don’t need to see all the data—they need to understand the decision being made and the confidence level behind it. The program taught me how to synthesize complex technical security findings into clear decision options with associated risks and trade-offs. This has been invaluable when communicating with stakeholders such as Ring’s Founder, CTO, VP of Software Engineering, and our Amazon Legal and Public Relations teams, where I must translate thousands of data points into a single, actionable recommendation they can trust.

Absolutely. Since completing the program, my team has adopted IWIKs as a standard practice. We now begin by framing the problem, opportunity, or challenge through a series of essential questions that must be answered, followed by deliberate planning for data collection. To support our decisions, we also examine adjacent information to uncover corollary insights that complement our primary data, and then synthesize everything into a clear picture.

This shift has fundamentally changed our workflow. As security engineers, we often see a challenge and want to start building or solving the technical issue immediately. The Quantitative Intuition™ framework taught me to pause and first determine whether we’re facing an adaptive or a technical challenge. That distinction informs whether the right solution is a policy change, a tool enhancement, or an entirely new approach. The result is that we’re not just responding faster—we’re responding smarter, focusing our engineering efforts on solutions that address the root decision at hand.
 

It’s still early, but the most tangible change has been how the team now applies IWIKs systematically. We’ve found it especially valuable because it allows peers and stakeholders to surface deep-rooted questions that might otherwise remain unspoken. This approach ensures we identify the data truly needed to answer those questions and, critically, helps us avoid introducing information bias.

A clear mindset shift is taking place—our team is moving from “show me all the data” to “what do we need to know to make this decision?” That subtle change is reducing analysis paralysis and helping us move from investigation to action more efficiently. We’re also seeing stronger collaboration across teams because everyone is aligned on the questions we’re trying to answer, rather than debating which dashboard or metric to look at first.

This shift also changed how I think about intuition and data. I realized through the program that I naturally lean toward the intuitive side when solving challenges—I tend to make gut calls based on experience. What the Leadership Intelligence in the Era of AI program taught me wasn’t to suppress that intuition, but to tune and validate it with the right quantitative inputs.

The biggest shift has been moving from data-driven analysis to decision-driven data analysis. Instead of letting alerts and dashboards dictate our focus, we now start by defining the security decision we need to make, then work backward to identify only the essential data points that inform that decision. My intuition helps frame what matters; the data helps validate and refine that intuition. It’s not about choosing between gut instinct and spreadsheets—it’s about combining both to make faster, more confident decisions under pressure.

This was a revelation. I’ve learned that intuition isn’t the opposite of analysis—it’s the starting point. My intuition frames what matters; the data validates and refines it.

I’ve moved from data-driven analysis to decision-driven analysis. Instead of letting alerts and dashboards dictate focus, I now start by defining the decision, then work backward to identify the essential data points. It’s not about choosing between gut instinct and spreadsheets—it’s about combining both to make faster, more confident calls.

The biggest behavioral shift for me has been moving from data-driven analysis to decision-driven data analysis. Instead of letting security alerts and telemetry dictate our focus, I now start every investigation or initiative by defining the security decision we need to make, then work backward to identify only the essential data points that inform that decision.

It sounds simple, but it has fundamentally changed how I work. I spend less time drowning in dashboards and more time focused on what truly matters. I’m also more comfortable saying, “We have enough information to decide,” rather than waiting for perfect data. When I present to stakeholders, I’m clearer and more confident because I’ve framed the decision explicitly from the start. This shift has made me a more effective leader—and a more efficient engineer.

I think programs like Leadership Intelligence in the Era of AI represent a critical evolution in how we develop technology leaders. Traditionally, technical training focuses on deepening domain expertise—learning more programming languages, mastering new security frameworks, or understanding emerging threats. That’s important, but it’s not enough for leadership.

What’s often missing is the decision-making framework that bridges technical expertise with strategic leadership. In security engineering, we’re dealing with increasingly complex systems, massive datasets, and high-stakes decisions that need to be made quickly. Programs like this teach you not just what to think about, but how to think—how to frame problems, ask the right questions, balance intuition with analysis, and communicate decisions clearly to diverse stakeholders.

As technology becomes more central to business strategy, leaders need to be bilingual: fluent in both technical depth and quantitative decision-making. This program addresses that gap. I believe we’ll see more technical leaders seeking this kind of training because the job isn’t just about being the smartest engineer in the room—it’s about making the best decisions for the organization under uncertainty and pressure.

If you’re managing security at scale, you know the challenge: it’s not a lack of data—it’s cutting through the noise to focus on genuine risks. You’re analyzing massive datasets every day to identify what actually matters for security decisions. You’re making high-stakes calls under time pressure with incomplete information. Sound familiar?

This program gives you the framework to do that better. You’ll learn to frame security problems effectively, ask the right questions before jumping into solution mode, and balance your technical instincts with quantitative validation. More importantly, you’ll learn to make faster, more confident decisions without waiting for perfect data—which, in security, you never have.

The best part is learning alongside leaders from completely different industries. I gained as much from hearing how a healthcare executive or financial-services leader frames decisions as I did from the core curriculum. That cross-pollination of perspectives is invaluable.

If you feel like you’re drowning in alerts, struggling to prioritize what matters, or finding it hard to translate technical findings into executive-level recommendations, this program will transform how you work. Don’t wait for the perfect time—in security, there never is one.

A transformative experience where collaborating with peers from diverse industries helped me frame the right questions, guesstimate effectively under uncertainty, and observe different leadership styles in action—all while sharpening my ability to make better decisions faster.