Engineering Speed: Technical Decision Making Leads to Clarity

Master the art of making technical decisions to create focus and constraints to drive better execution

This is part two on engineering speed, if you missed the first post you can check it out here 

---

Frustrated Engineers and Uncertain Execution

One of my roles, besides helping get solutions from 0 to 10, as a mostly cross-functional T-shaped multi-faceted enabler, is to airdrop into stuck areas. Almost every time I have airdropped into a stuck program or problem area, I have noticed a pretty consistent trend.

Lack of technical decision-making slows down engineers, frustrates them, and makes them uncertain whether they are executing well or on the right work.

Late in 2024, I honed in on an area where a cross-functional virtual team (let’s call them Team Alpha for this post) was working on a migration to a solution they provided for “thing”. The solution worked fantastically for teams who were on our engineering paved road [Appendix], but required a lot of work for teams who were operating on more legacy or off-road systems. Some of these application owning teams had to make a choice: migrate to the paved road and adopt “thing” which may result in postponing other priorities, do nothing, or enable an alternative method “thing” that may pose a security risk.

At first, Team Alpha leaned into empowering the local application teams to make calls. But soon after, the virtual team could see that the application owners were making local decisions that could have a global impact, broader than their charters. Furthermore, team members were unsure whether the level of risk of doing nothing was appropriate given the company’s threat model. As a result, application owner teams felt stuck deciding between postponing work or possibly putting other services at risk with an alternative solution. Team Alpha members weren’t sure if we were making the right risk tradeoffs, and had a hard time aligning internally and with their stakeholders. The risks felt bigger than their scope, and as a result, they were stalled on making any decisions.

It was slow and frustrating for everyone.

The first thing I did to ease that frustration was to find a way to create clarity. There are many tools we’ll cover on the Engineer Setlist, such as strategy bets, project constraints, and technical visions. But today, I want to walk you through a template for ‘stuck decisions’ that I have had great success with.

Technical Decision Runbook

At its core, a technical decision runbook creates a time-bound set of decisions with recommendations and works with the decider to get them made. Often, decisions get stuck because the team's scope is larger than the decision's, they aren’t setting a deadline, and they haven’t done enough due diligence on the total costs of the decision or the recommendation they would make.

1. Determine the scope of the decision and who the informed captain (or sometimes referred to as the decider in other MAANG+ companies)

2. Clearly define the scope, supporting technical details, and tradeoffs of the decisions

3. Create a clear timeline for reaching a decision, and holding everyone accountable for it (so the decisions don’t linger forever)

Scope/Deciders

What is in-scope and out of scope for the decision? You may find yourself surprised that the biggest bottleneck is often a lack of clarity on scope. If it’s a scope issue, you may be able to quickly provide guidance, capture it in writing, and help the team get unstuck. If it’s more than scope, the next most common issue is related to the decider:

• Lack of a Clear Decision Maker: Sometimes, no one is sure who actually owns the decision, so it lingers unresolved.

• The Decision is Larger than the Current Team: The decision’s impact or risk extends beyond the team’s authority, which means it needs to be escalated to broader leadership.

• The Decider is Clear but Everyone Disagrees with Them: Even when the decision-maker is known, a lack of alignment or buy-in from the rest of the team can stall progress.

If you are air-dropping in, your first question should be: Who is the decision maker? If you don’t get a clear answer, your first job is to figure out who that is. It may be you, someone on the virtual team, or a more senior leader, especially if the decision is bigger than the current team. If there is a clear decision but everyone disagrees with it, your job is to determine if the decider has heard enough dissent or feedback and may need to make a call without consensus. In this case, emphasize the importance of “disagree and commit,” especially if due diligence was done. If there was not enough diligence, encourage the decider to revisit the decision and gather more feedback.

In my example, there was a lack of a clear decision and a decision larger than the current team. As a result, I identified that more senior leaders would need to weigh in, and after I collected enough context, I could provide a recommendation to inform our leaders.

Define Scope, Technical Details, and Tradeoffs

Once you have identified the decision maker and clarified the scope, the next step is to lay out the details that will inform the decision. Make sure everyone understands what is being decided, what technical facts are relevant, and what the potential impacts are.

• Technical Details: Gather all relevant technical information, such as requirements, constraints, dependencies, and any data that supports the options being considered. Make sure this information is accurate and accessible to all stakeholders.

• Tradeoffs: List the pros and cons of each option. Be transparent about what might be gained or lost with each path, including impacts on timelines, costs, risks, and long-term maintainability.

• Recommendation: Actually make a recommendation even if you aren’t the decider. You are most likely well informed, but the scope may be bigger than you. Having a recommendation helps the decision-maker (especially if it’s a senior leader) be more informed. 

If you are facilitating, ask the team to write down their assumptions and the reasoning behind each option, then bring the group together in person. Encourage open discussion about risks and benefits, and ensure that all voices are heard. Time box this (e.g., 1 to 3 weeks). In my example, it took us roughly 3 weeks, start to finish, to get everyone on board with the decisions/recommendations and ensure we had enough supporting data.

Set a Clear Timeline and Accountability

Along with defining the scope and details, establish a specific timeline for making the decision. Share this with the virtual team and decision-makers, and also plan when to communicate the decision to the impacted teams.

• Decision Date: Set a firm deadline for reaching the decision. Set it ambitiously; it’s better to receive pushback than have something linger longer than it needs to.

• Milestones: Identify any intermediate steps, such as gathering feedback, reviewing technical data, or holding decision meetings. Assign owners to each step so responsibilities are clear.

• Accountability: Make it clear who is responsible for each action and who will ultimately make the call. Follow up regularly to ensure progress, and remind the group of the timeline if things start to slip.

When we discuss accountability, we may start to see things slip for decisions that tend to fall into the “one-way door camp.”

One Way versus Two Way Door Decisions

You may be thinking, Scott, this seems like a lot of work! Often, this level of rigor is only needed for one-way door decisions. Not all decisions carry the same weight or risk.

• One-way door decisions are high-impact and difficult or impossible to reverse. Examples include choosing a new foundational technology, deprecating a major platform, or making irreversible changes to data models. Because these decisions are hard to undo, they require more rigor, careful analysis, and broader alignment. You should expect to spend more time gathering input, documenting tradeoffs, and ensuring that the right stakeholders are involved before moving forward.

• Two-way door decisions are low-risk and easily reversible. Examples might include trying a new process, deciding between prioritizing feature A or B, or rolling out a change to a small subset of users. For these decisions, speed is more important than perfection. You can (and should) move quickly, make the call, and adjust if it turns out to be the wrong choice.

When you set timelines and assign accountability, consider which type of decision you are making. By matching the level of rigor to the type of decision, you reduce unnecessary delays for reversible choices while ensuring that the most consequential decisions get the attention they deserve. This approach keeps teams moving quickly where possible and carefully where it truly matters. For the example I was working through, there were some one-way doors, so we ensured we had enough rigor and then moved forward with hosting a decision meeting.

The Decision Meeting and Communications

It’s time for the decision meeting. You have the decision memo, context, and recommendations ready, and you have shared any pre-reads with the deciders at least one week in advance. Book a one-hour meeting and, right at the start, set the expectation that decisions will be made today. Be confident, but not arrogant. Your recommendations are likely the most informed, but remember that decision-makers, especially senior leaders, may have additional context or priorities that could lead them to a different decision. The most important part is to capture the discussion and outcomes in writing, no matter which way the decision goes, and share the results quickly so everyone can move forward.

Getting Unstuck Is a Superpower

I have received a lot of positive feedback that my ability to get technical decisions made and projects unstuck is a superpower. I hope you see how this type of approach may help you in your engineering role. If you are an early career professional, you may practice this type of pattern on a team level. If you are in a senior role, on a cross-functional project. In a staff+ role, you may be doing this across a large cross-functional team, or multiple teams/orgs, and sometimes in an ‘airdrop’ capacity. Just ensure that you are taking everyone along with you, leveling up, and sharing this pattern with your colleagues like I’m doing with you today. And make sure that the level of rigor is proportional to the total cost of the decision (e.g. if it’s two way door, move faster).

This Week’s Band Practice: Case Study and Template

For practice this week, I want you to hone in on how a lack of decision-making is impacting you in the project you are working on.

I built a template and a ‘pseudo’ case study that uses the pattern we talked about this week. My recommendation for rehearsal is:

1. Review the Technical Decision template

2. Read the Stateful Migration decision example

3. Try to use the template for your stuck decision, and then spend the next few weeks getting it made.

Ping me on Substack if you try this out or have questions. I’d love to hear if it helps you get moving!

Appendix

Paved Roads - If you aren’t familiar with paved roads, in the simplest terms, they are well-supported preferred technology choices that provide leverage. For more on paved roads, check out this excellent talk with previous Netflix CISO Jason Chan.