Decision Making & Decision Logs

You've been making decisions your entire career. Every function name, every data structure, every "should I refactor this or leave it alone" — those were all decisions. But here's what changes when you become a team leader: the blast radius gets bigger.

When you picked the wrong variable name as an IC, you renamed it. When you pick the wrong sprint priority as a TL, six people spend two weeks building the wrong thing. That's the shift you need to internalize.

This guide is about making better decisions faster, and — just as importantly — writing them down so you don't have to make the same decision twice.

Your New Role in Decisions

As an individual contributor, your decisions lived mostly in your own code. You chose the library, you chose the pattern, you dealt with the consequences. The feedback loop was tight and personal.

As a team leader, your decisions ripple outward. You're deciding things like:

What the team works on this sprint
Which technical approach the team adopts
Who gets assigned to what project
Whether to push back on a deadline or absorb the pressure
How to handle a conflict between two engineers

These decisions affect people's day-to-day work, their growth, their morale, and ultimately what ships. That's not meant to scare you — it's meant to make you intentional. You can't treat every decision like picking a CSS class name anymore. But you also can't treat every decision like you're choosing a database for the next decade.

The skill you're building is knowing which is which.

Speed of Decision-Making

Here's something that will feel counterintuitive at first: most of the time, making a fast decision — even if it turns out to be wrong — is better than making a slow one.

Why? Because slow decisions have hidden costs that don't show up on any dashboard:

Your team is blocked, waiting for direction
Context gets stale — the longer you wait, the more the situation changes
People lose confidence in your leadership
Opportunities close while you're deliberating
The team starts making their own assumptions, which may diverge from each other

Amazon popularized the "two-way door" concept, and it's genuinely useful. Think of decisions as doors you walk through:

Two-way doors — You can walk back through them. If you try something and it doesn't work, you reverse it. The cost of reversal is low. Most decisions are two-way doors. Make them fast.

One-way doors — Once you walk through, you can't easily go back. These deserve careful thought, data gathering, and input from others.

The mistake most new leaders make is treating every decision like a one-way door. They schedule meetings, gather opinions, build spreadsheets, sleep on it — for decisions that could be reversed in an afternoon. Meanwhile, the team sits idle.

Your default should be speed. Only slow down when you've identified a genuine one-way door.

Reversible vs. Irreversible Decisions

Let's make this concrete. Here's how to categorize the decisions you'll face:

One-Way Doors (Deliberate)

These are hard or impossible to undo. Take your time. Get input. Sleep on it if you need to.

Architecture choices — Picking a primary database, choosing a message broker, deciding on a monolith vs. microservices split. Migration costs are enormous.
Hiring decisions — Bringing someone onto the team is a months-long commitment. Getting it wrong is painful for everyone, including the person you hired.
Deleting data — Once it's gone without a backup, it's gone.
Public API contracts — Once external consumers depend on your API shape, changing it is a negotiation, not a refactor.
Letting someone go — This affects a person's livelihood. It deserves thorough consideration and documentation.

Two-Way Doors (Move Fast)

These can be reversed, adjusted, or iterated on. Decide quickly and course-correct as needed.

Process changes — Trying a new standup format, changing how you do code reviews, adjusting sprint length. If it doesn't work, change it back next sprint.
Tool choices (for internal use) — Trying a new linter, switching task boards, adopting a new CI plugin. If it's bad, you swap it out.
Sprint scope — What you commit to this sprint. Next sprint is two weeks away.
Meeting cadence — How often you hold 1:1s, retros, planning sessions. Experiment freely.
Feature flags and rollout strategies — The whole point of feature flags is making deployment decisions reversible.

When you're unsure which category a decision falls into, ask yourself: "If this turns out to be wrong, what does it cost to reverse it?" If the answer is "a few hours of work and a brief conversation," it's a two-way door. Move.

Decision Frameworks

Not every decision needs the same process. Here's a practical framework for how to approach decisions based on their nature:

Decide Alone

Use this when:

The decision is low-stakes and reversible
You have the context and expertise
Speed matters more than buy-in
The team has explicitly delegated this to you

Examples: prioritizing a bug fix, choosing a meeting time, approving a small refactor.

Consult, Then Decide

Use this when:

The decision affects the team's work
Others have expertise you lack
Buy-in matters for execution
You want to pressure-test your thinking

How: Talk to 2-3 relevant people. Listen. Then make the call yourself. Be clear that you're gathering input, not seeking a vote.

Examples: choosing a technical approach for a new feature, adjusting team processes, setting quarterly goals.

Delegate

Use this when:

Someone on your team is closer to the problem
It's a growth opportunity for them
You don't need to control the outcome
The decision falls within their domain

How: Be clear about the constraints and what "good" looks like. Then get out of the way.

Examples: implementation details of a feature they own, choosing between equivalent libraries, designing a testing strategy for their component.

Seek Consensus

Use this when:

The decision is irreversible and high-impact
Everyone on the team will be significantly affected
You genuinely don't know the right answer
Alignment is critical for execution

How: Facilitate the discussion. Set a deadline. If consensus doesn't emerge, you make the call.

Examples: major architecture migrations, changing the team's core technology stack, defining team values or working agreements.

A word of warning: consensus is the slowest and most expensive decision mode. Use it sparingly. "Let's all agree" sounds democratic, but it often means "nobody fully commits because everyone compromised." Reserve it for the decisions that truly warrant it.

The RAPID Framework (Simplified)

If you want a more structured approach, RAPID assigns clear roles:

Recommend — Who proposes the decision? (Usually the person closest to the problem.)
Agree — Who needs to sign off? (Keep this list short.)
Perform — Who executes the decision? (Needs to be clear before you decide.)
Input — Who provides information or expertise? (Consult these people.)
Decide — Who makes the final call? (One person. Not a committee.)

The most important part of RAPID is the D: one person decides. If you can't name that person, you don't have a decision process — you have a meeting.

Architecture Decision Records (ADRs)

Six months from now, someone on your team (possibly you) will look at a piece of the system and ask: "Why on earth did we do it this way?"

If you don't have a written record, you'll waste hours trying to reconstruct the reasoning. Or worse, you'll undo a decision without understanding the constraints that led to it, and walk straight into the same problem again.

Architecture Decision Records solve this. They're simple, short documents that capture what you decided and why.

When to Write an ADR

Not every decision needs one. Write an ADR when:

The decision is about architecture or system design
It's hard to reverse
There were meaningful alternatives you considered and rejected
Future team members will need to understand the context
You had a contentious discussion and want to record the resolution

Don't write an ADR for choosing a variable name or picking a sprint goal. Use judgment.

What to Include

Keep them short. A good ADR fits on one screen. Here's a simple format:

# ADR-001: Use PostgreSQL as primary data store

## Status
Accepted

## Date
2026-03-23

## Context
We're building the order management service and need to choose a primary
data store. Our data is highly relational (orders, line items, customers,
inventory). We expect ~10K transactions per day initially, scaling to
~100K within 18 months. The team has strong PostgreSQL experience. We
considered DynamoDB for its scaling properties but decided against it.

## Decision
We will use PostgreSQL (via RDS) as the primary data store for the order
management service.

## Alternatives Considered
- **DynamoDB**: Better horizontal scaling, but our access patterns are
  relational. Would require significant denormalization and the team has
  limited DynamoDB experience.
- **MySQL**: Viable, but the team prefers PostgreSQL and our existing
  tooling supports it.

## Consequences
- We get strong relational query support and ACID transactions
- We accept the responsibility of managing scaling (read replicas,
  connection pooling) as we grow
- We can leverage the team's existing PostgreSQL expertise
- If we outgrow PostgreSQL, migration will be costly (one-way door,
  acknowledged)

That's it. No twenty-page document. No committee review. Just enough context that future-you can understand past-you.

Where to Store ADRs

Keep them close to the code. A /docs/adr/ directory in the relevant repository works well. Some teams use a wiki, but wikis tend to become graveyards. A directory of markdown files in the repo means ADRs go through the same review process as code and live alongside the system they describe.

Documenting Rationale

This is the single most important point in this entire guide, so let me be blunt:

The decision itself is far less important than the reason behind it.

Decisions are easy to read. "We chose PostgreSQL." Cool. But that tells future-you nothing about whether the decision still makes sense when circumstances change.

What future-you needs to know is:

What were the constraints at the time?
What alternatives were considered and why were they rejected?
What assumptions were we making?
What would have to change for us to reconsider?

When you document rationale, you give your future team a gift: the ability to revisit decisions intelligently rather than blindly.

Here's the difference:

Bad documentation: "We decided to use Redis for caching."

Good documentation: "We decided to use Redis for caching because our API response times were averaging 800ms and the primary bottleneck was repeated database queries for product catalog data. We chose Redis over Memcached because we anticipated needing sorted sets for the leaderboard feature in Q3. We chose a managed service (ElastiCache) over self-hosted because we're a team of five and don't have the bandwidth to manage infrastructure. If our caching needs become simpler or we drop the leaderboard feature, Memcached would be a cheaper alternative worth revisiting."

The second version takes three minutes longer to write. It saves hours of confusion later.

This applies beyond ADRs. When you make any significant decision — in a Slack message, in a PR comment, in a meeting — take an extra thirty seconds to write down why. Not just what you decided, but what led you there.

Dealing with Ambiguity

Here's an uncomfortable truth: many of the decisions you face as a team leader won't have a clear right answer. You'll have incomplete information, conflicting opinions, and time pressure. Welcome to leadership.

The temptation is to wait for more information. Sometimes that's the right call. But more often, waiting is just procrastination wearing a responsible-sounding hat.

Here's how to make decisions with incomplete information:

Set a Decision Deadline

"We'll decide by Thursday" is more useful than "let's keep gathering data." A deadline forces clarity. If you still don't have enough information by the deadline, that itself is information — it tells you the analysis is harder than expected, or that the data doesn't exist, or that nobody actually knows. Decide anyway.

Define "Good Enough"

Not every decision needs to be optimal. Sometimes you need a direction, not the perfect direction. Ask yourself: "Is this decision good enough to move forward, even if it's not ideal?" If yes, go.

Build In a Review Date

When you're uncertain, make the decision and schedule a review. "We're going with approach A. We'll revisit this in six weeks once we have real usage data." This removes the pressure of permanence from reversible decisions.

Use "Disagree and Commit"

Sometimes you'll consult your team and get split opinions. You'll have to choose one path over another, and some people will disagree. That's fine. The key phrase is "disagree and commit" — once the decision is made, everyone executes on it fully, even those who preferred a different option. This only works if the people who disagree feel genuinely heard before the decision is made.

Name Your Assumptions

When you decide with incomplete information, write down what you're assuming. "We're assuming traffic will grow linearly. If it grows exponentially, we'll need to revisit the caching strategy." This makes your reasoning auditable and gives your team clear trigger points for reopening the conversation.

When You're Wrong

You will make wrong decisions. This is not a possibility — it is a certainty. How you handle being wrong will define your leadership more than any correct decision you make.

Own It Quickly

The moment you realize a decision was wrong, say so. Don't hedge, don't blame the information you had, don't wait for someone else to point it out. "I made the wrong call on X. Here's what I think we should do instead."

Your team is watching. If you own mistakes openly, they'll feel safe doing the same. If you cover for yourself or deflect, they'll learn to do that too. The culture you model is the culture you get.

Separate Identity from Decisions

A wrong decision doesn't make you a bad leader. It makes you a leader who made a decision with the information available at the time. Get comfortable with this distinction. If you tie your self-worth to being right, you'll start avoiding decisions altogether — and that's far worse than occasionally being wrong.

Learn, Don't Punish Yourself

After a wrong decision, do a quick personal retro:

What did I know at the time?
What signals did I miss?
Was the process flawed, or was it just bad luck?
What will I do differently next time?

Then move on. Ruminating on past mistakes doesn't make future decisions better. Adjusting your process does.

Changing Your Mind Is Strength

New information should lead to new decisions. If you said "we're doing X" last month but the data now points to Y, change course. Some people will call this flip-flopping. It's not. Flip-flopping is changing direction without reason. Adapting to new information is called learning, and it's exactly what your team needs you to do.

The key is to communicate clearly: "When we decided X, we assumed A and B. We've since learned that B isn't true. Based on that, we're switching to Y." That's not weakness — that's the scientific method applied to leadership.

Real-World Examples

1. A Fast Decision That Saved Time

Situation: During a sprint, the team discovered that the third-party payment API they were integrating had a poorly documented rate limit. Two engineers spent half a day debating whether to implement client-side throttling or switch to a different payment provider entirely.

Decision: The team lead stepped in, spent ten minutes reading the API docs, and said: "We'll implement client-side throttling with exponential backoff. It's a two-hour fix. If the rate limit becomes a real problem in production, we'll evaluate switching providers then. But we're not burning a week investigating alternatives for a problem we might not actually have."

Outcome: The throttling was implemented that afternoon. Six months later, the rate limit had never been hit in production. If they'd spent a week evaluating payment providers, they'd have wasted four days solving a non-problem.

Lesson: The cost of deciding quickly (two hours of work that might get replaced later) was dramatically lower than the cost of deliberating (days of lost productivity and a missed sprint commitment).

2. A Slow Decision That Caused Delay

Situation: The team needed to choose a message broker for an event-driven architecture. The team lead wanted everyone to be on board, so they scheduled a series of meetings: a brainstorming session, two comparison workshops, a proof-of-concept sprint, and a final vote. The process took five weeks.

Decision: Eventually, the team chose Kafka — which was the option the two most senior engineers had recommended in the first meeting.

Outcome: Five weeks of delay, and the final decision was the one that was obvious from week one. Three team members felt the process was a waste of time and said so in the retro. Morale dipped.

Lesson: This was a one-way door and deserved deliberation — but not five weeks of it. The team lead should have set a one-week deadline, gathered input from the senior engineers, and made the call. Seeking consensus on a deeply technical decision where two people had clear expertise was the wrong approach.

3. A Well-Documented Decision That Prevented a Repeated Mistake

Situation: A team chose to build their own authentication system instead of using a third-party identity provider. They wrote an ADR documenting the reasoning: the available providers at the time didn't support their specific multi-tenancy requirements, and building in-house gave them full control over the auth flow.

Decision (documented): Build custom auth. Reviewed and accepted.

Outcome: Eighteen months later, a new engineer joined the team and immediately suggested migrating to Auth0. Instead of relitigating the decision from scratch, the team lead pointed them to the ADR. The new engineer read the constraints, did some research, and came back with: "Auth0 now supports multi-tenant configurations that didn't exist when this decision was made. I think it's worth revisiting."

The team reopened the decision with full context, evaluated the new capabilities, and decided to migrate — saving months compared to the original build. Without the ADR, they either would have dismissed the suggestion ("we already decided this") or spent weeks reconstructing why they built it in-house in the first place.

Lesson: The ADR didn't just document the decision — it documented the conditions under which the decision should be revisited. That's the real power of writing down your rationale.

Common Mistakes

These are the traps new team leaders fall into most often. Knowing about them won't make you immune, but it'll help you catch yourself faster.

Analysis Paralysis

You keep gathering data, scheduling meetings, and building comparison matrices — but you never actually decide. The pursuit of the "perfect" decision becomes an excuse for not deciding at all. If you've been thinking about a two-way door decision for more than a day, you're overthinking it. Decide now.

Not Documenting

You make a great decision with sound reasoning, but you don't write it down. Three months later, nobody remembers why you chose approach A over approach B, and the team starts questioning it. The decision was fine. The failure was not recording the context. It takes five minutes to write a paragraph in a decision log. Do it.

Deciding by Committee

You put every decision to a team vote because it feels collaborative. What actually happens: the loudest voice wins, quieter team members disengage, and decisions take three times as long. Collaboration means gathering input. It doesn't mean everyone gets a vote on everything. You're the team lead — lead.

Flip-Flopping

You decide on Monday, reverse on Wednesday, and change again on Friday. This isn't adaptability — it's indecision. If you're going to change a decision, have a clear reason and communicate it. Otherwise, commit to your original call for long enough to actually see if it works.

Not Involving the Right People

You make a decision that affects the database team without talking to anyone on the database team. Then you're surprised when they push back. Before you decide, ask yourself: "Who will be affected by this? Have they had a chance to provide input?" You don't need everyone's permission, but you do need the relevant people's perspective.

Revisiting Settled Decisions Without New Information

Someone raises the same objection to a previous decision for the third time, and you reopen the discussion. If the circumstances haven't changed and no new information has emerged, the decision stands. Protect your team's time by being clear: "We discussed this, we decided, and unless something new has come up, we're moving forward."

Making Irreversible Decisions at Reversible Speed

This is the inverse of analysis paralysis. You rush through a one-way door decision because you're proud of being "decisive." Speed is a virtue for two-way doors. For one-way doors, thoroughness is the virtue. Know the difference.

Business Value

This isn't just about being a better leader. Fast, well-documented decision-making has direct business impact:

Speed of execution. Every day spent deliberating on a reversible decision is a day your team isn't shipping. Across a quarter, the cumulative cost of slow decisions is staggering. Teams that decide fast and iterate ship more, learn more, and deliver more value. Period.

Reduced rework from undocumented decisions. When decisions aren't documented, they get revisited. New team members question old choices without context. Engineers rebuild things that were intentionally designed a certain way. Stakeholders re-litigate settled debates. Each of these cycles wastes hours or days. A five-minute decision log prevents all of it.

Team autonomy. When your team understands your decision-making framework — when they know which decisions they can make, which ones need your input, and which ones need broader alignment — they stop waiting for permission. They move faster. They grow as decision-makers themselves. This compounds over time: a team where every engineer can make good decisions is exponentially more productive than one where everything funnels through a single leader.

Organizational trust. Leaders who make decisions transparently — explaining the why, acknowledging trade-offs, owning mistakes — build trust with their teams, their peers, and their leadership chain. Trust buys you autonomy, which buys you speed, which buys you results. It's a flywheel.

Risk reduction. Documented decisions with clear rationale make it easy to audit past choices when something goes wrong. Instead of blame games and finger-pointing, you have a record: "Here's what we knew, here's what we decided, here's why." This shifts post-incident conversations from "whose fault was this?" to "what can we learn?" — which is where they should be.

Putting It Into Practice

Start this week:

Identify one decision you've been sitting on. Is it a one-way door or a two-way door? If it's a two-way door, make it today.
Write one ADR for a recent architectural decision your team made. Even if it's retroactive. Get the muscle memory going.
Create a decision log — even if it's just a markdown file in your team's repo. Start recording non-trivial decisions with a sentence or two of rationale.
Tell your team which decisions they can make without you. Be explicit. This alone will speed things up.

Decision-making isn't a talent. It's a practice. The more you do it intentionally, the better you get. And the better your documentation, the less you'll have to redo.

Make the call. Write it down. Move on.

Common Pitfalls

Treating every decision like a one-way door. Scheduling meetings, gathering opinions, and building spreadsheets for decisions that could be reversed in an afternoon creates unnecessary delay while the team sits idle. Most decisions are two-way doors; make them fast.
Not documenting the reasoning behind decisions. Making a sound decision but not writing down the context, alternatives considered, and assumptions means future team members will waste hours reconstructing the reasoning or will undo it without understanding the constraints.
Deciding everything by committee. Putting every decision to a team vote feels collaborative but means the loudest voice wins, quieter members disengage, and decisions take three times as long. Gather input, then decide. One person must own the final call.
Flip-flopping without new information. Changing direction on Monday, reversing on Wednesday, and changing again on Friday is not adaptability. It is indecision that destroys team confidence. Commit to decisions long enough to see if they work.
Revisiting settled decisions without new evidence. When someone raises the same objection for the third time with no new information, reopening the discussion wastes the team's time. Be clear that decisions stand unless circumstances have changed.
Rushing through one-way door decisions at two-way door speed. Speed is a virtue for reversible decisions, but thoroughness is the virtue for irreversible ones like architecture choices, hiring, and public API contracts. Know which type you are facing.

Key Takeaways

As a team leader, the blast radius of your decisions is bigger. The skill you are building is knowing which decisions need careful deliberation and which need speed.
Most decisions are two-way doors that can be reversed. Your default should be to decide quickly and course-correct. Only slow down for genuinely irreversible choices.
Match the decision process to the situation: decide alone for low-stakes items, consult then decide for team-affecting choices, delegate to the person closest to the problem, and seek consensus only for the most impactful irreversible decisions.
Architecture Decision Records (ADRs) are short, simple documents that capture what was decided, the context, the alternatives, and the consequences. Keep them in a /docs/adr/ directory alongside the code.
The decision itself is far less important than the reasoning behind it. Documenting rationale gives future teams the ability to revisit decisions intelligently rather than blindly.
When making decisions with incomplete information, set a deadline, define "good enough," build in a review date, and name your assumptions explicitly.
When you are wrong, own it quickly. Your team watches how you handle mistakes, and modeling honest course correction builds a culture where everyone feels safe doing the same.