Unblocking: the four blocker types

What it is

Unblocking is the lead's highest-leverage daily activity, and it depends on one classification. A blocker is one of four kinds, and each has a different fix. Applying the wrong fix is why teams stay stuck while everyone works hard.

Type          What is missing              The fix
------------------------------------------------------------------
INFORMATION   an answer that exists        find it, or find who
              somewhere                    knows it

DECISION      an answer nobody has         make it, or force the
              committed to yet             person who can to make it

DEPENDENCY    something another team or    escalate, negotiate a
              system must do               date, or route around it

SKILL         the person cannot do it      pair, teach, or reassign
              yet

What this is confused with: "blocked" as a status. In most standups "blocked" is a single flag with a single implied response, usually "the lead will chase someone." That response is correct for exactly one of the four types. Chasing a dependency for a problem that is actually a skill gap wastes a week and leaves the engineer feeling watched rather than helped.

Also confused: unblocking and doing the work. A lead who unblocks by writing the code has removed today's blocker and guaranteed tomorrow's, because the engineer is no closer to being able to do it and now has a reason not to raise it next time.

The problem it solves

Blocked time is invisible in every metric a team reports, and it dominates cycle time.

An item with a 14-day cycle time and 18% flow efficiency:
  2.5 days of active work
  11.5 days of waiting

Where the waiting goes, from a typical sample:
   4.1 days  waiting for code review        (dependency, on people)
   3.2 days  waiting for another team's API (dependency)
   2.0 days  waiting for a decision         (DECISION)
   1.4 days  waiting for a deploy window    (dependency, on process)
   0.8 days  waiting for an environment     (dependency)

Almost none of that is the engineer working slowly, and none of it
appears in a status update beyond the word "blocked".

And the failure has a specific shape: the blocker that nobody owns.

Monday    "I'm blocked on the auth team's endpoint."
Tuesday   "Still blocked."
Wednesday "Still blocked."
Thursday  the lead asks who they have spoken to. Nobody. They filed
          a ticket on Monday and it has not been triaged.

Four days lost, and the honest reading is that the lead lost them,
not the engineer, because "still blocked" was accepted three times
without a named owner and a next action.

Mechanics

Classifying, in one question each

INFORMATION
  "Does someone already know this?"
  Symptoms: "I'm not sure how X works", "I don't know if we
  already have a Y", "I can't tell what this config does".
  Fix: find the answer or the person, in minutes, not by asking
  the engineer to keep searching. Then WRITE IT DOWN, because an
  information blocker that recurs is a documentation gap.

DECISION
  "Who is allowed to say yes, and have they been asked directly?"
  Symptoms: "we're waiting to hear back", "product hasn't
  decided", "we don't know which approach they want".
  Fix: make it if it is yours. If not, go to the person with a
  RECOMMENDATION and a deadline, not a question. Most stalled
  decisions are stalled because nobody framed a choice.

DEPENDENCY
  "What is the other team's actual commitment, and what is our
   plan if it slips?"
  Symptoms: "the platform team hasn't shipped it", "we need
  access", "the vendor hasn't replied".
  Fix: a named person on the other side, a date, and a
  route-around option costed before you need it.

SKILL
  "Could this person do this today with help, or not yet?"
  Symptoms: repeated "almost done", a branch with no commits for
  two days, an engineer going quiet, work that keeps being
  re-scoped.
  Fix: pair, teach, or reassign. THIS IS THE HARDEST TO SEE,
  because the engineer will usually describe it as one of the
  other three.

Skill blockers masquerade as the other kinds, and that is the classification error worth watching for. An engineer who does not know how to approach a problem will report it as waiting for information or a decision, because that is a socially safer thing to be blocked on.

The tell: the blocker does not resolve when the stated cause is
removed.

  "I'm blocked on the schema decision."
  Decision made Tuesday. By Friday, no progress.
  -> it was never the decision.

The question that surfaces it without accusation:
  "If I gave you the answer right now, what would you do first?"
A crisp answer means the stated blocker is real. A vague one
means the blocker is the approach, and that is a pairing
conversation, not a chasing one.

Decision latency, measured

Track how long decisions sit. It is the one blocker type that is entirely inside the lead's control.

Keep a decision log: what, who decides, raised when, resolved when.

  Decision                     raised    resolved   latency
  --------------------------------------------------------
  Cursor format for v2 API     Mar 3     Mar 4      1 day
  Whether to backfill or
    dual-write                 Mar 5     Mar 19    14 days  <-
  Retire the legacy endpoint   Mar 11    Mar 12     1 day
  Which queue for the DLQ      Mar 12    Mar 12     0 days

RULE: a decision that has sat more than 48 hours is the lead's
failure, not the team's.

Fourteen days on a decision is fourteen days of an engineer's work shaped around not knowing, which usually means abandoned branches, defensive designs that support both options, and a rewrite when the answer arrives.

The three reasons decisions stall, and the fix for each:

NOBODY KNOWS WHO DECIDES
  -> write it down once. A one-page decision-rights list ("who
     decides API shape, who decides schema, who decides scope")
     removes most recurrence.

THE DECIDER HAS NO FRAME
  -> never take a question upward. Take a recommendation:
     "I recommend A. B is the alternative; it costs two extra
      weeks and buys us X. I need an answer by Thursday or I will
      proceed with A."
     A deadline plus a default converts an open question into a
     confirmation, which people answer.

IT IS ACTUALLY REVERSIBLE AND NOBODY NOTICED
  -> most decisions are two-way doors. Say so explicitly and
     decide fast. Reserve the deliberation for the ones that
     are genuinely hard to reverse.

The 24-hour rule

Nobody is blocked overnight without a named owner and a next
action.

Not "the platform team is looking into it."
But  "Priya on platform owns it, she has committed to an answer
      by 2pm tomorrow, and if it slips we switch to the
      file-based path, which costs us a day."

Two components, both required:
  a NAME (a person, not a team)
  a NEXT ACTION with a time

"A team is looking into it" is not an owner, and the difference between a team name and a person's name is usually the difference between two days and two hours.

The escalation ladder

Escalation is a tool, not an admission of failure, and the failure mode is escalating too late rather than too eagerly.

An explicit ladder, published, so nobody has to decide in the
moment whether escalating is acceptable:

  Hour 0    engineer asks the other team directly, in their
            channel, with the specific ask and the deadline
  Hour 4    lead asks the other team's lead, peer to peer
  Day 1     lead raises it in the cross-team forum, or to their
            own manager as information ("here is a risk")
  Day 2     manager to manager
  Day 3+    director level, with a written summary: the ask, the
            impact in days, what we tried, what we need

The ladder is a SCHEDULE, not a judgment. You do not have to
decide whether this one is worth escalating; you escalate on the
clock.

The reason to publish it: heroic absorption. A lead who quietly absorbs a two-week dependency slip protects the other team from the consequence of their slip, so it recurs, and their own team is blamed for the delay. Escalating on a schedule is kinder to everyone including the team you are escalating about, because it surfaces the constraint while it is still cheap.

The tone that works, and it matters:

Not: "the platform team is blocking us again."
But: "we need the token endpoint by the 14th to hit our date.
      Right now it is unscheduled. Can we either get it
      scheduled, or agree that our date moves by the same
      amount?"

State the ask, the impact and the two acceptable outcomes. Never
present an escalation with only one acceptable outcome, because
that is a demand rather than a decision request.

Routing around

For every dependency, cost the route-around BEFORE you need it:

  Dependency: the auth team's new token endpoint
  Needed by:  Mar 14
  Route-around: call the legacy endpoint and translate in our
    service. Costs ~2 days now, plus ~1 day to remove later.
  Decision point: Mar 7. If it is not scheduled by then, we
    build the route-around.

Having this written down does two things: it makes the
escalation concrete ("here is what it costs us if you slip"),
and it means the decision to route around is made calmly a week
early rather than in a panic the day before.

A worked example: a team that was busy and not moving

A team of six, three months into a platform migration. Every standup reported progress. The burn-up chart was flat. The lead's first instinct, which was wrong, was that the estimates had been optimistic.

Two weeks of logging every stated blocker, classified:

41 blockers recorded.

  INFORMATION   17   "how does the old system handle X?",
                     "is there an existing client for Y?",
                     "what does this flag do?"
  DEPENDENCY    12   9 on one team (identity), 3 on infra
  DECISION       9   4 of them the same decision, raised four
                     times by different people
  SKILL          3   as stated. Actual count, after review: 7.

The three findings, in order of size:

1. Seventeen information blockers were one problem.

15 of the 17 were answered by two people: the two engineers who
had worked on the legacy system. Median time to get an answer:
6 hours, because both were in meetings and the questions arrived
by direct message where nobody else could see them.

Fix, in order of effect:
  a) a public channel for these questions instead of DMs. The
     same question was being asked by different people, and now
     the second asker could search.
  b) a 30-minute daily "legacy office hour" from one of the two,
     rotating. Bounded, so it stopped being an all-day interrupt.
  c) every answer written into a running FAQ doc by the ASKER,
     not the answerer, which is the only version that happens.

After 3 weeks: information blockers 17 per fortnight -> 4, and
median time to answer 6 hours -> 40 minutes.

The asker writes it down, not the answerer, is the detail that makes documentation actually accumulate, because the answerer has already solved their problem and the asker has just paid the cost of not having it.

2. The same decision raised four times.

"Do we dual-write during the migration, or backfill and cut over?"

Raised Mar 5, Mar 11, Mar 18 and Mar 26 by four different
engineers, each of whom worked around it differently in the
meantime. Never resolved, because it was raised as a question to
a group and everyone assumed someone else owned it.

Fix: the lead wrote a one-page recommendation.
  "I recommend dual-write. It costs ~5 engineer-days and about
   3 weeks of running both paths. Backfill is cheaper by 3 days
   but needs a 6-hour write freeze, which the payments team
   cannot accept in Q1. I need a decision by Thursday; absent
   one I will proceed with dual-write."

Resolved in 26 hours, in favour of dual-write.

Cost of the 21 days it sat: two engineers had built partial
support for BOTH paths, which was discarded. Roughly 6
engineer-days.

Twenty-one days of latency cost more than the decision itself cost to execute, and it resolved in a day once someone framed a choice with a default and a deadline.

3. Twelve dependency blockers, nine on one team.

All nine were on the identity team's new token endpoint.
Status, when the lead finally asked directly: unscheduled, and
the identity team did not know anyone was waiting, because the
ask was a ticket in a backlog with no requester follow-up.

The lead had not escalated because escalating felt like
complaining, which is the heroic-absorption failure exactly.

What happened after the peer-to-peer conversation:
  - identity scheduled it for the following sprint, 8 days out
  - the lead costed a route-around (translate the legacy token
    in-service, ~2 days) and set a decision point 3 days before
    the deadline
  - it landed on time and the route-around was not needed

Elapsed time from "lead asks the identity lead directly" to
"scheduled": 90 minutes.

Elapsed time it had been blocked before that: 31 days.

Thirty-one days against ninety minutes is the cost of not having an escalation schedule, and the lead's own account of why was that it never felt like the right day to escalate. A published ladder removes that judgment from the moment.

4. The hidden skill blockers.

Three were reported as skill. Four more surfaced when the lead
started asking "if I gave you the answer right now, what would
you do first?"

All four were the same engineer, six weeks into the team, on the
streaming components. They had reported information and
dependency blockers because those are safer to say.

Fix: two weeks of scheduled pairing, 2 hours a day, with a named
partner, framed as "we under-invested in your onboarding to this
part of the system", which is true and puts the failure where it
belongs.

Their cycle time on subsequent items fell from a median of 11
days to 4.

Framing the skill gap as an onboarding failure rather than a performance issue is both accurate and the only framing that gets it raised next time.

Aggregate result over the following six weeks:

                              before      after
blockers reported per
  fortnight                      41          14
median blocker age            3.2 days    0.6 days
decisions older than 48h         4           0
flow efficiency                 18%         34%
throughput (items/week)         4.1         6.9
items with no owner named
  after 24 hours                 11           0

Throughput rose 68 percent with no change in headcount, hours or estimation practice, because the constraint had never been how fast people worked.

Production evidence

Little's Law and flow efficiency measurements (see capacity math and forecasting) are the general evidence that waiting dominates cycle time: measured flow efficiency across organisations typically falls between 5 and 20 percent, which means blocked time is the majority of an item's life.

Amazon's "two-way door" framing, articulated in Jeff Bezos's shareholder letters, is the standard argument for deciding reversible things fast and reserving deliberation for irreversible ones. It is the direct remedy for the stalled-decision category.

The DORA research programme's consistent finding that reducing batch size and work in progress improves delivery performance is the same result from the other direction: smaller items spend less time blocked because they depend on fewer things.

Google's Project Aristotle identified psychological safety as the strongest predictor of team effectiveness, which is the mechanism behind skill blockers being reported as information or dependency blockers: an engineer will report the blocker that is safest to report.

Documented "office hours" practice in platform and developer-experience teams, bounding expert availability to a fixed window rather than an open interrupt channel, is a widely adopted pattern for exactly the information-blocker concentration described above.

The debate

Should a lead unblock by doing the work? Rarely, and it is the most tempting failure. Writing the code removes today's blocker and guarantees tomorrow's, because the engineer is no closer to being able to do it and has learned that raising it produces rescue rather than help. The exception is a genuine emergency with a deadline, and even then the follow-up pairing session is the part that matters.

Is a decision log bureaucratic? Four columns is not bureaucracy. The argument for it is that decision latency is the only blocker category entirely within the lead's control, so it is the one where measurement most directly produces improvement, and nobody notices a fourteen-day decision without a log.

Should you escalate on a schedule even when the other team is trying? Yes, because the schedule is about information flow rather than blame. The counter-argument, that escalating damages the relationship, is real and is addressed by tone: an escalation that offers two acceptable outcomes ("schedule it, or agree our date moves") is a decision request, and one that offers a single acceptable outcome is a demand.

Do route-arounds create technical debt? Yes, and costing them in advance is what makes that debt a decision rather than an accident. The failure is building the route-around in a panic the day before the deadline, when it will be worse and nobody will have agreed to remove it. Cost it early, set a decision point, and write the removal ticket at the same time.

Is the 24-hour rule too rigid for deep work? It is about ownership, not about resolution. An engineer can be blocked for a week as long as there is a named person and a next action, because what the rule prevents is the blocker with no owner, which is the one that stays blocked indefinitely.

Should skill blockers be named as such? To the individual, yes, and framed as an onboarding or assignment failure where that is true, which it usually is. Publicly, no. The team needs to see that raising a blocker produces help, and the fastest way to stop hearing about skill gaps is to make one person's skill gap a topic in standup.

Follow-up Q&A

"What are the four blocker types and why does the classification matter?"

Information, where the answer exists and someone has it. Decision, where nobody has committed to an answer yet. Dependency, where another team or system has to do something. And skill, where the person cannot do it yet. They matter because the fixes are different and unrelated: finding an answer, forcing a decision, escalating or routing around, and pairing or reassigning. Treating everything as a dependency, which is what "the lead will chase someone" amounts to, is correct for one of the four and wastes a week on the others.

"Which type is hardest to see, and how do you surface it?"

Skill, because engineers report it as one of the other three: waiting for information or a decision is socially safer than not knowing how to approach the problem. The tell is that the blocker does not resolve when its stated cause is removed. The question that surfaces it without accusation is "if I gave you the answer right now, what would you do first?" A crisp answer means the stated blocker is real; a vague one means the blocker is the approach. Then frame the fix as an onboarding or assignment gap where that is true, because that is both accurate and the only framing that keeps people raising it.

"How do you unstick a decision?"

Never take a question upward, take a recommendation with a default and a deadline. "I recommend A. B costs two extra weeks and buys X. I need an answer by Thursday, and absent one I will proceed with A." That converts an open question, which people defer, into a confirmation, which people answer. In one case the same migration decision was raised four times over 21 days by four engineers and resolved in 26 hours once it was framed that way, after two of them had already built partial support for both options at a cost of roughly six engineer-days.

"What is the 24-hour rule?"

Nobody is blocked overnight without a named owner and a next action. Not "the platform team is looking into it" but "Priya owns it, she has committed to an answer by 2pm tomorrow, and if it slips we switch to the file-based path at a cost of a day." Two required components: a person's name rather than a team's, and a next action with a time. The rule is about ownership rather than resolution, so a week-long blocker is fine if it has both.

"Why publish an escalation ladder?"

To remove the judgment from the moment, because the common failure is escalating too late rather than too eagerly. A lead who quietly absorbs a dependency slip protects the other team from the consequence of it, so it recurs, and their own team gets blamed for the delay. With a published schedule, hour zero to the team, hour four peer to peer, day one to the cross-team forum, day two manager to manager, you escalate on the clock rather than deciding whether today is the day. In one case a dependency sat 31 days and was scheduled 90 minutes after the first direct peer-to-peer conversation.

"How do you escalate without damaging the relationship?"

State the ask, the impact in days, what you have tried, and two acceptable outcomes. "We need the token endpoint by the 14th to hit our date; right now it is unscheduled. Can we get it scheduled, or agree that our date moves by the same amount?" An escalation with only one acceptable outcome is a demand, and it is what makes people route around you afterwards. Costing the route-around in advance also helps, because it turns the escalation into a concrete trade rather than a complaint.

Common misconceptions

"Blocked is a status." It is four different statuses with four different fixes, and the default response addresses one of them.

"Chasing the other team is unblocking." It is the fix for one category. Applied to a skill gap it wastes a week and leaves the engineer feeling watched.

"Escalating is a failure." Escalating late is. Absorbing a slip quietly protects the other team from the consequence and transfers the blame to yours.

"The lead should jump in and write the code." That removes today's blocker and teaches that raising a blocker produces rescue instead of capability.

"A decision that is taking a while is just a hard decision." Most stalled decisions are stalled because nobody framed a choice with a default and a deadline, and most are reversible anyway.

"Documentation should be written by the person who knows the answer." They have already solved their problem. The asker just paid the cost of not having it, which is why the asker writing it down is the version that accumulates.

Interview delivery note

Say this verbatim: "Every blocker is one of four kinds: information, decision, dependency or skill, and each needs a different fix. Skill is the one that hides, because engineers report it as one of the other three, and the tell is that the blocker does not resolve when its stated cause is removed." It gives the taxonomy and the non-obvious part in two sentences.

The senior-versus-staff separator is measuring decision latency and owning it. A senior lead unblocks people. A staff lead keeps a four-column decision log, treats anything over 48 hours as their own failure rather than the decider's, and takes recommendations upward with a default and a deadline instead of questions. Saying "a decision sat 21 days and cost six engineer-days of work built against both options, then resolved in 26 hours once I framed a choice" shows the mechanism rather than the sentiment.

The second signal is naming heroic absorption as a failure. Recognising that quietly absorbing another team's slip protects them from the consequence, guarantees the recurrence, and moves the blame onto your own team, and that the remedy is a published escalation schedule rather than better judgment in the moment, is the systems-thinking version of an interpersonal problem.

The Staff & Team Lead Interview Reference