Tech Lead Decision Making Framework: Make Better Calls, Faster

A tech lead makes 30 to 50 decisions per week. Should we use REST or GraphQL? Can this refactor wait until next quarter? Do we hire a backend specialist or a generalist? Should we block the release for this edge case? Most of these decisions are individually small but collectively define the trajectory of your team, your product, and your architecture.

The best tech leads I have worked with are not the ones who make perfect decisions. They are the ones who make good-enough decisions quickly, document their reasoning, and course-correct when new information arrives. After 22 years and two company exits, I have distilled my decision-making approach into a framework that I teach every tech lead I mentor.

Step 1: Classify the Decision

Not all decisions deserve the same process. The first thing I do with any decision is classify it along two dimensions:

Reversibility: One-Way Door vs Two-Way Door

A two-way door decision can be undone cheaply. Choosing a logging library, picking a code formatting style, deciding which developer works on which feature. If you get it wrong, you change it next sprint with minimal cost.

A one-way door decision is expensive or impossible to undo. Choosing your primary database, defining a public API contract, picking a programming language for a new service, or letting someone go. These decisions lock you in and require much more deliberation.

Impact: Local vs Global

A local decision affects one team or one service. A global decision affects multiple teams, the entire system, or the company's direction. Local decisions can be made by the person closest to the problem. Global decisions need broader input.

Most tech leads waste time treating every decision like the bottom-right quadrant. Your goal is to spend 80% of your decision-making energy on the 20% of decisions that are irreversible and high-impact. Everything else should be fast.

Step 2: Gather Just Enough Information

For the decisions that warrant deliberation, you need information. But there is a diminishing return curve. The first 70% of information is easy to gather. Getting to 90% takes three times as long. Getting to 100% is impossible. I aim for 70-80% information before deciding.

Here is what "gathering information" looks like in practice:

• Talk to 2-3 people who have relevant experience. Not a committee of 10. Two or three people who have actually dealt with a similar problem.
• Run a time-boxed spike. If the question is "will this technology work for our use case?", spend 1-2 days building a proof of concept instead of 2 weeks debating in meetings.
• Check what other teams or companies have done. You are rarely the first person to face this decision. A 30-minute research session can save weeks of trial and error.
• Identify what you would need to know to change your mind. If the answer to "is PostgreSQL the right choice?" depends entirely on whether we will need to handle more than 100K writes per second, go find that number instead of debating the abstract merits of databases.

Step 3: Make the Call

Here is where most tech leads stall. They have the information but cannot pull the trigger because they are afraid of being wrong. Two truths that help:

Truth 1: A good decision made today is almost always better than a perfect decision made next month. The cost of delay is real. Your team is blocked, context is being lost, and the problem is not getting any clearer while you deliberate.

Truth 2: You will be wrong sometimes, and that is fine. In a 22-year career, I have made thousands of technical decisions. I estimate about 70% were right, 20% were irrelevant (either option would have worked), and 10% were wrong. Of the wrong ones, most were caught and corrected within a few weeks because we moved fast enough to learn quickly.

Decision-Making Modes

Not every decision should be made the same way:

• Unilateral: You decide, you inform. Use for small, reversible, time-sensitive decisions. "We are using Prettier for code formatting. Here is the config."
• Consultative: You gather input, you decide. Use for medium-impact decisions where expertise matters. "I have talked to the database team and the SREs. We are going with PostgreSQL for this service."
• Consensus-seeking: The team discusses, you facilitate, the group decides. Use for decisions that need broad buy-in. "We need to agree on our API versioning strategy. Let us discuss the options and align."
• Delegated: You assign the decision to someone else. Use for developing your team's judgment. "Sarah, you are closest to this problem. Make the call and let me know what you decided."

Step 4: Document the Decision

Every significant decision should be recorded in an Architecture Decision Record (ADR). This is not bureaucracy. It is a gift to your future self and to the next person who asks "why did we build it this way?" A good ADR has five sections:

1. Context: What situation prompted this decision?
2. Options considered: What alternatives did we evaluate?
3. Decision: What did we choose?
4. Reasoning: Why this option over the others?
5. Consequences: What are the known trade-offs and risks?

This takes 15-20 minutes to write. It saves hours of repeated explanations and prevents the institutional amnesia that plagues every engineering organization. Good documentation practices are one of the highest-leverage investments a tech lead can make.

Common Decision-Making Traps

Analysis Paralysis

You keep researching, discussing, and evaluating because the decision feels scary. The fix: set a deadline. "We will decide by Friday end of day. If we don't have enough information by then, we go with our best guess and revisit in 4 weeks."

Hippo Effect (Highest Paid Person's Opinion)

The VP says "I think we should use Kubernetes" and suddenly the technical evaluation becomes a formality. The fix: collect opinions independently before discussing. Written proposals before meetings. Anonymous polls for contentious choices.

Sunk Cost Fallacy

"We've already spent 3 months building this microservice, we can't throw it away." Yes, you can. The 3 months are gone regardless. The question is: what is the best use of the next 3 months? Past investment should not determine future direction.

Consensus Addiction

Waiting for everyone to agree before moving forward. True consensus is rare and often produces watered-down solutions that satisfy nobody. Aim for "disagree and commit": everyone's input is heard, the decision is made, and the team moves forward together even if some people would have chosen differently.

The speed of your decisions determines the speed of your team. Every day a decision is delayed is a day your team is either blocked or working on assumptions that might be wrong. Be fast on small decisions, thorough on big ones, and honest about which is which.

Teaching Your Team to Decide

The ultimate goal is not to be the decision-maker for everything. It is to build a team that can make good decisions without you. Share this framework with your team. When they come to you with a decision, ask "what quadrant is this?" and "what do you recommend?" Over time, they will stop bringing you every decision and start bringing you only the ones that genuinely need your input.

That is when you have truly scaled your leadership: not when you make all the right decisions, but when your team makes them without you.