TeamStation AI / Research / Team Topology / What Blocker Age Says About Team Topology
Map blocker age to dependency ownership and decision authority. A practical engineering review before changing team topology or adding headcount.
Read blocker age beside dependency ownership and decision authority before changing engineering team topology. A practical, bounded review for CTOs.
Blocker age can help an engineering leader locate a dependency that needs attention, but the age alone can't explain why work stopped. Read it beside the blocked condition, the dependency owner, and the person authorized to make the next decision before changing team topology.
I'd rather examine three old blockers with the people who can clear them than redraw an org chart from a dashboard. A timestamp tells us how long we've waited. The useful question is what would let the work move, and whether the current team can make that happen.
Start the clock at a defined condition
In this proposed review, blocker age means elapsed time since a specific unresolved condition prevented the next agreed step. Record that condition and its start time. Keep the clock running until evidence shows the condition cleared, not merely until the ticket changed columns.
Keep a separate clock for the age of unfinished work, measured from the team's agreed start event. A task may have started several days before it became blocked. Mixing those clocks makes a long implementation look like a long dependency wait. These definitions describe the proposed review, not a new industry standard.
Use a consistent time basis and state it. Calendar hours and working hours answer different questions. Preserve separate blocked intervals when work stops more than once, and record unknown timestamps as unknown instead of assigning a convenient date.
The definition is an operating proposal, not a validated predictive model. No universal age threshold or improvement percentage is claimed here.
Map the dependency, not the person to blame
For each unresolved condition, keep a short record close to the approved work item:
- Blocked step: what cannot happen yet, with evidence of the condition.
- Dependency: the access, review, information, or service the step needs.
- Decision owner: the person or team authorized to settle the next question.
- Next check: what would prove the condition cleared, and when to look again.
Connect those records across a small sample. Do separate items keep reaching the same decision owner? Does each request arrive without the same information? Is a team waiting for a service it should be able to use independently?
DORA's loosely coupled teams guidance examines independent testing and deployment, external decision approvals, and waits for other teams. Our narrower proposal adds individual blocker records to that discussion. The records suggest questions to investigate; they don't establish that a particular team structure caused the delay.
The engineering team topologies context matters here because a reporting line and a delivery dependency aren't the same thing. The chart can look tidy while the actual decision path remains unclear.
Follow one stalled release through the map
Consider an illustrative release waiting for access approval. Its code review is complete, but nobody named the authorized approver in the request. A second release reaches the same condition. Both blocker clocks grow while their engineers work on other tasks.
Adding another engineer wouldn't answer the missing approval question. First identify the authorized owner, supply the required request evidence, and verify the access state. If a repeated pattern remains after that repair, examine whether the approval process or team interaction needs redesign.
That distinction is why access friction and review latency need separate records. They can both leave work waiting while requiring different actions. This example is hypothetical, not a client result or a measured savings claim.
Test a smaller change before moving the boundaries
Choose one recurring condition rather than reorganizing around the oldest ticket. Agree on the expected change and preserve the original record so the team can check whether the intervention helped.
1. Confirm the blocked condition with the people doing the work. 2. Trace the dependency to the owner who can act on it. 3. Check whether the request supplied the context that owner needs. 4. Make the smallest authorized process or ownership change. 5. Inspect subsequent comparable work, including cases that didn't improve.
A shorter wait afterward is an observation, not automatic causal proof. Work size, request quality, staffing availability, and the type of dependency may also have changed. Keep those differences visible before turning a useful local result into a policy.
Engineering telemetry should support that investigation. Don't turn blocker age into an individual performance score, and don't expose private repositories or customer records to explain a public status.
Apply the same question to nearshore capacity
Before buying more nearshore engineering capacity, ask which stalled decisions the added role could actually resolve. For React engineering teams and Python engineering teams, the relevant dependency might sit outside the technology skill being purchased.
Our Mexico engineering and Colombia engineering pages describe regional hiring context. Location still doesn't identify the access owner or settle an architecture decision. Use the LATAM salary and quality-of-life index for its stated planning context, separately from dependency evidence.
When reviewing operating models, bring the same ownership questions to the TeamStation and Turing comparison or the TeamStation and EPAM comparison. Those comparisons aren't evidence that a named provider caused a blocker. They are places to examine responsibility before committing to a model.
TeamStation AI's Distributed Engineering OS and Nearshore Control Plane supply the operating context. The immediate job for a CTO or CIO is smaller: find one old blocked condition, name the decision it needs, and verify that the authorized owner can act.
Does an old blocker prove the team topology is wrong?
No. It identifies a wait worth investigating. Dependency ownership, request context, decision authority, and comparable work are needed before drawing a structural conclusion.
How does blocker age differ from the age of unfinished work?
For this review, the unfinished-work clock starts at the team's agreed start event. The blocker clock starts when a specific unresolved condition prevents the next agreed step.
What should the next delivery review include?
Bring a small sample of blocked conditions with their timestamps, dependencies, authorized decision owners, and clearing evidence. Use the sample to choose a bounded change, then check the result.
