Make Technical Decisions — Engineering Leadership, Part 4

Contributor
3 days ago
3 min read

Engineering Leadership · Part 4

Teams don't usually stall because they make bad technical decisions — they stall because they make no decision, circling the same question in meeting after meeting while the work waits. A tech lead's job is to break that loop: engineers want the call made, and the org needs it. This walks through deciding well and fast — separating reversible doors from irreversible ones, gathering input without drowning in it, and getting real commitment even from the people who disagreed.

Tech leads decide. Engineers want it. The org needs it. Hesitation costs more than wrong choices.

Step 1: Decisions Are Cheap (10 min)

The expensive thing isn't a wrong decision. It's a delayed decision.

A team waiting for "should we use Postgres or Mongo?" wastes weeks per week of delay.

A wrong decision can be revisited. Indecision can't.

Default: decide today.

Step 2: Two-Way vs. One-Way Doors (10 min)

Jeff Bezos's framing:

Two-way door — reversible. Decide fast.
One-way door — irreversible. Take time.

Most technical decisions are two-way:

Library choice — swap later
Service design — refactor later
API shape — version later (with discipline)

True one-way doors are rare:

Public API contracts with external consumers
Database choice once you have terabytes
Architectural decisions baked into everything

Decide two-way doors quickly. Reserve deliberation for one-way doors.

Step 3: Gather Input Efficiently (15 min)

For most decisions:

1-hour discussion with 2-4 people closest to the work
24-hour async comment period for broader input
Done

Not:

5 meetings over 3 weeks
Slack threads spanning a month
Steering committee approval

Speed beats process for two-way doors.

For genuinely big decisions: write an RFC (Path 40 Part 5). Open for comments. Decide in a week.

Step 4: State the Decision Clearly (5 min)

Decision: We'll use Postgres, not Mongo.

Reasoning: Strong joins matter for our access patterns; team is
familiar with Postgres; no documents requirements that JSONB can't
handle.

Open to revisit in: 12 months, or if scaling characteristics change.

Specific. Documented. Bounded.

Vague decisions ("let's lean toward Postgres") get re-litigated forever.

Step 5: Disagree and Commit (10 min)

After the decision is made, dissenting voices should:

State their concern (already did)
Acknowledge they don't agree
Commit to making it work

Not:

Keep arguing in PRs
Sabotage the decision
Block forever

You as lead enforce this norm:

"Alice, you've voiced concern. We're going with B. Going forward,
let's make B work. We can revisit in Q4 if data shows we should."

Step 6: Decisions Sometimes Need Re-Decisions (10 min)

New info arrives:

Performance data wasn't what we expected
A new tool changes the trade-off
The use case shifted

Don't be married to a decision. Update.

But don't constantly re-litigate either. Decision fatigue is real.

Quarterly: review key decisions. Are they still right?

Step 7: Decide Who Decides (10 min)

Some decisions aren't yours. Some are.

API contract → architecture council
Library choice within a service → service team
Hiring decision → hiring manager
Cross-team standard → leadership

When asked, sometimes the answer is "Sarah owns this; ask her." Clarify ownership.

For your team's decisions: you're often the decider. Don't punt.

Step 8: When to Punt (5 min)

"This needs an RFC and broader input. Let me set that up; decision
in 2 weeks."

When it's bigger than your team. When you genuinely don't have info.

Punting < deciding badly. Punting > endless meetings.

But: be honest. Don't punt because the decision is uncomfortable.

Step 9: Document the Decision (10 min)

Recap from Path 40 Part 2:

# ADR 042: Use Postgres for Primary DB
Status: Accepted (2027-06-23)
Context: ...
Decision: Postgres.
Consequences: ...

ADR in the repo. Future engineers see the trail.

Without docs: same decision keeps coming up.

Step 10: Reflect on Your Decisions (5 min)

Quarterly look back:

Which decisions did I make?
Which were right?
Which would I redo?
What's my pattern?

Some leads bias toward analysis paralysis. Some toward gut. Knowing your tilt helps you correct.

The goal isn't perfect decisions. It's a steady stream of good-enough decisions, made promptly.

What You Just Did

Technical decisions: cheap, two-way doors, gather input, state clearly, disagree and commit, re-decisions, ownership, punt judiciously, document, reflect. The leadership lever.

Common Failure Modes

Endless discussion. Costs more than wrong.

Vague decisions. Re-litigated forever.

Decide and forget to communicate. Team doesn't know.

Override later by stealth. Erodes trust.

Punt everything. People stop bringing decisions to you.

Continue the Engineering Leadership path

Previous — Part 3: Run Effective One-on-Ones
Next — Part 5: Set Team Direction

Part of the Engineering Leadership learning path.

ShiftQuality