How to make the right decisions under pressure 

Estimated reading time: 15 minutes

Making the right call when there’s not much time on the clock can be a stressful experience. Here are six tactics to remember and a helpful decision tree to follow in your hour of need.

Making technical decisions at scale is rarely straightforward. Priorities shift. Data is incomplete. Teams are working across different layers of the system with different goals. As an engineering leader, you are expected to move fast and make the right call, often with limited clarity.

I have led projects on AI, data platforms, and large enterprise systems. Some decisions went smoothly. Others were messy. But over time, I have built up a few simple habits that helped me navigate uncertainty, build alignment, and keep teams moving forward even when the path wasn’t fully clear. These practical tools and the right mindset have ultimately led to better technical decisions in complex environments.

1. Anchor on what matters

When you are in the middle of a high-stakes decision, everything can feel urgent and equally important. I’ve been in situations where multiple teams are pulling in different directions, data is incomplete, and pressure is building to act quickly. Here, the best thing to do is to clarify what is pressing right now. It helps cut through the noise and bring focus before diving into solutions. 

When everything feels important, step back and ask:

• “What’s the real outcome we are aiming for?” – Start by zooming out; look at how the decision connects to broader company goals or current team priorities. If it’s unclear, talk to your manager or key stakeholders to understand what success looks like in this specific context. This helps you figure out whether you need to move fast and build for the long term or take time to explore. Asking this early prevents misalignment later.
• “Is this decision about speed, scale, or learning?”– Each of these has a different shape. If it’s about speed, lean toward proven tools and simpler architectures that can ship fast. If it’s about scale, bring in teams early to plan for growth and reliability from day one. Opt for a low-risk pilot, track results, and leave room to pivot.
  For example, when choosing a back-end framework for a new internal tool, we realized speed was the priority. We picked a stack that the team already knew well so we could ship quickly, even if it wasn’t perfect for scale. If the goal had been long-term growth, we might have made a different call.
  Once I have clarity on the outcome and whether the decision is about speed or scale, I capture those insights in a quick priorities doc. Nothing fancy, just a few bullets to guide the team and make trade-offs more visible.
  • What’s fixed: The constraints we can’t bend. In one project, that meant a regulatory deadline we had to meet. No amount of technical creativity was going to move that.
  • What’s flexible: Areas where we have room to adapt. The internal rollout date could shift slightly as long as customer impact stayed minimal.
  • What trade-offs are okay? Here, we are intentional about scope. We delayed analytics reporting for a few weeks to protect the core experience.

By pinpointing these specifics, you’re able to give the team a North Star. It’s also helpful later, when questions come up about why we made a specific call, which can be noted in a shared doc or decision log that tracks the priorities we aligned on. 

Practical tip: Use kickoffs or pre-work sessions to define what matters early, like the key outcomes and priorities. Include cross-team stakeholders, such as product leads, to ensure everyone is aligned from day one.

2. Accept the unknowns – then act anyway

When you’re staring down the barrel of a big decision, it usually isn’t accompanied by all the information you need. There will be gaps in context and unanswered questions looming. This is a fact that used to slow me down. Now, I work with it.

Recently, when choosing an emerging cloud platform feature, we didn’t have enough data to feel 100% confident in making a decision to go with it. Waiting meant missing a delivery deadline. So, we ran a pilot with one service, built a fallback path, and shipped. In doing so, we were able to learn about the feature and move forward without betting the whole system. 

If you’re faced with a similar situation, here are some steps you can take:

• Run small experiments or short technical explorations to test assumptions. This could be a spike ticket, a prototype, or even a quick proof of concept to better understand the unknown before committing fully.
• Create a paper trail of the assumptions you’ve made in relevant documents. For example, “We assumed X; revisit after launch.” 
• If you do run an experiment, set review checkpoints: “We’ll re-evaluate the results in two sprints.”

This keeps the momentum high without being reckless.

3. Bring people in early

Cross-team decisions often fail because alignment happens too late. The simple solution is to bring key partners into the room sooner. 

In one project, we started building a platform layer before involving security, which eventually meant we had to redo critical pieces. Even if you’re in a stage where your team is still figuring out parameters, it’s still important to hear other relevant thoughts. 

Having learned from my mistakes, I now run short pre-alignment sessions. These are 20-minute syncs with product, infrastructure, and security teams to walk through early ideas. No slides, no polished doc. Just a space to flag concerns early.

If you’re unsure of where to start with this, here are some things you want to address:

• Share rough diagrams or decision flows during pre-alignment meetings with other teams. This helps surface unknowns before ideas are set in stone. 
• Ask cross-functional partners – like product, infrastructure, or security teams – “Is there anything missing here?
• Capture and address feedback before the full build begins.

This saves time later and builds trust across teams.

4. Keep it simple (especially early on)

I have seen massive feats of overengineering for problems that never materialized.  For example, my team and I once built a custom queuing service to handle load spikes that never actually came. 

To make sure you don’t fall into the same trap, outline the simplest path to a useful outcome. 

To apply this mindset, I always start with one full end-to-end flow that touches all parts of the stack. When we built our queuing system, a better approach would have been to test real-world demand by running one core flow with existing infrastructure. Instead of jumping into complex queuing logic early on, we should have hard-coded the essentials first, then replaced them as the business needs became clearer. 

Another approach I now rely on is using toggles and feature flags. These let us test risky components in production without fully committing, and allow fast rollback if something goes wrong. 

Simplicity is not cutting corners. It’s building what is needed now and saving headspace for future iterations. That said, it helps to explain this to the team early on; otherwise, starting simple can be mistaken for being rushed or incomplete.

5. Make decisions visible

We have all seen decisions get lost in Slack threads or informal chats. My approach to minimizing siloed information is to keep lightweight project decision logs. This consists of a running list in a shared doc that stakeholders can dip into when needed. Each entry lists the decisions made, the reason behind them, the individuals involved, and when we will revisit it to determine if it’s still the best course of action. If someone disagrees or has questions, the decision log gives us a place to talk it through and adjust if needed. This also creates shared memory and helps new team members ramp up fast.

Other helpful tactics include:

• Running 15-minute “decision retros” after big technical calls or when the team takes a risk. I usually include the core team and anyone involved in the decision. We talk about what worked, what felt unclear, and whether we’d make the same choice again.
• Normalize changes to the plan. I tell teams: “This is our best guess right now. We’ll improve it as we learn.”
  

A decision-making tree to use in the moment

Sometimes, visualizing your next move helps. Here’s a simple decision tree I use when things feel messy:

I bring this decision tree during design meetings when things are not clear. It helps teams feel safe moving forward, especially when direction is unclear.

You can customize this by adding layers like:

• Known vs. unknown tech: Is the team using familiar tools, or are we trying something new that carries more risk?
• Internal-only vs. user-facing: Does this impact just internal systems, or will it be immediately visible to customers?
• Short-term vs. structural impact: Are we making a quick fix, or does this decision shape the architecture long term?

6. Build habits, not just one-time wins

Making good decisions consistently takes practice. I focus on building habits that reduce friction:

• Document key trade-offs for major decisions, or anytime direction shifts in a meaningful way.
• Use async tools (like Loom or Miro) to share early ideas.

When these behaviors become normal, the team starts making faster, better calls without always needing a formal meeting.

Final thoughts

Making decisions at scale isn’t about having all the answers. It’s about creating structure when things are messy, making thoughtful bets, and helping your team feel confident moving forward.

You won’t get everything correct, and that’s perfectly okay. If your team understands the “why” and sees how to course-correct, they will move with more energy and less fear.