The technical roadmap dependency mapping decision record: why the dependency visibility model you chose determines your cross-team delivery predictability and your sprint planning assumption failure rate

A 38-person developer tools company building a CI observability platform had two engineering teams with hard quarterly delivery commitments to an enterprise customer whose contract included a service-level clause requiring specific features to be delivered in Q3. The product team was responsible for the Q3 commitment: a distributed trace visualization feature that would render multi-service CI pipeline traces in a timeline view, enabling customers to identify which service in their CI run was producing the latency that was failing their build SLAs. The feature required a tracing SDK maintained by the platform team — a lightweight agent that would instrument CI services and emit trace events to the observability backend. The product team's engineering lead had reviewed the platform team's roadmap in the prior quarter's planning session and noted that the SDK was listed as a Q2 deliverable. She recorded the dependency in her own team's planning notes. The platform team's roadmap was committed in a quarterly planning session where each team presented their deliverables for the quarter; there was no structured mechanism in the planning process to surface what other teams needed as inputs from the presenting team, only what the presenting team intended to produce as outputs. The tracing SDK was on the platform team's Q2 roadmap, the product team assumed it would be ready, and no one asked the platform team to confirm that they were aware that the SDK was on another team's critical path or that the Q3 customer commitment depended on it.

In week four of Q2, the platform team's engineering lead made a unilateral priority decision to defer the tracing SDK to Q3 in order to address a production reliability issue in the event ingestion pipeline that was generating customer support tickets and creating churn risk. The decision was correct in isolation: a reliability issue with visible customer impact outweighs a roadmap item whose downstream dependency was not communicated. The decision was recorded in the platform team's internal sprint log, updated in the shared roadmap document used for quarterly planning, and not communicated to the product team. There was no mechanism that would have caused the platform team to identify the product team as a stakeholder in the SDK timeline, because the dependency had been noted only in the product team's own planning document and had never been formally registered in a shared dependency record that the platform team could consult. In week eight of Q3, the product team's engineering lead opened the shared roadmap document to confirm the SDK's availability for the sprint beginning the following Monday and found it listed as a Q3 deliverable rather than the Q2 deliverable it had been when she recorded the dependency five months earlier. The SDK was not complete. The product team's sprint plan for weeks nine through twelve encoded five stories that assumed the SDK's trace emission API was available, tested, and deployed to the staging environment. Three weeks remained before the quarter-end delivery deadline specified in the customer contract.

The product team's engineering lead spent the next two days attempting to negotiate an expedited SDK delivery with the platform team. The platform team's engineering lead was willing but constrained: the SDK could be partially delivered — the basic trace emission API without the advanced sampling controls and retry logic — within one sprint, but the partial implementation would require the product team to write compensating logic for the missing retry behavior, adding an estimated week of work to stories that had been scoped assuming the complete SDK. The final outcome was a partial feature delivery: the trace visualization shipped but displayed only single-service traces rather than the multi-service correlation the customer contract specified, with a written commitment to deliver multi-service correlation in the first sprint of Q4. The customer accepted the modified delivery under protest and placed the contract renewal at risk. Two product team engineers who had worked consecutive extended weeks to attempt the compression gave notice in the following month. A post-quarter retrospective identified the root cause in two sentences: the planning process required teams to document what they would deliver but had no mechanism to surface what they needed from other teams; and the roadmap document was a pull resource that teams consulted when they chose to, with no trigger that alerted dependent teams when upstream plans changed. Connect this to the sprint planning format decision record: the sprint planning model specifies the inputs each team requires before a sprint can be committed — acceptance criteria, design documents, API specifications, deployed upstream changes; if the sprint planning model does not include a dependency confirmation step that validates whether each story's external inputs are ready and scheduled before the story is placed in the sprint, the sprint plan will consistently encode assumptions about inputs that have not been confirmed ready; the product team's sprint plans for weeks nine through twelve were internally valid — each story was scoped correctly for the work the team needed to do — but they were constructed on an unvalidated assumption about an external input that had changed eight weeks before the sprint began and had not been communicated.

A 52-person B2B SaaS building an HR automation platform for mid-market companies had three engineering teams sharing a common authentication and authorization service. The auth team maintained the service, the accounts team built the core HR workflow product on top of it, and the integrations team built the third-party connector ecosystem whose 40 connectors authenticated through the same service. The organization's approach to dependency tracking was a shared Google Sheet with a tab for each team, updated by each team's planning coordinator after quarterly planning sessions and after any mid-quarter plan changes. The sheet listed each team's output deliverables for the current quarter and a brief note on any known dependencies. The process had been in place for two years and was considered adequate: major cross-team dependencies were visible in the document, and the engineering director reviewed the sheet at the monthly all-engineering meeting.

The auth team's Q2 roadmap included a breaking change to the token validation API to support a new compliance requirement from a customer in the financial services sector whose contract was worth $340,000 annually: OAuth 2.0 PKCE enforcement for all API authentication flows, which would require client applications to send a code verifier on every token request rather than a static client secret. The change would be backward-incompatible for any client that had not been updated to send the code verifier before the deployment date. The auth team's engineering lead updated the shared Google Sheet on the day the roadmap was committed: 'OAuth PKCE enforcement — Q2, breaking change to token validation API, all clients must be updated before deployment.' The accounts team's planning coordinator read the sheet at the following month's all-engineering meeting and noted the dependency in the team's internal Notion workspace. The integrations team's planning coordinator did not attend that meeting due to a scheduling conflict and did not review the Google Sheet between the quarterly planning session and six weeks later, when the auth team's engineering lead sent a Slack message to the engineering-general channel announcing that the PKCE enforcement deployment was scheduled for the following Friday. The integrations team had 40 connectors using the token validation API, each making authentication calls with the old static-client-secret flow. The accounts team had 23 service-to-service calls in the HR workflow product that used the old flow. Neither team had a sprint plan that accounted for the migration work.

The accounts team had three sprints of work in flight that assumed the existing token validation behavior. Stories in those sprints were not themselves making authentication calls — they were building HR workflow features that used a shared authentication utility library — but two of the three sprints' worth of work was scheduled for deployment before the PKCE enforcement date, and the deployments would fail integration testing if the authentication utility library had not been updated. The integrations team faced a different problem: 40 connectors, each requiring an individual authentication flow update, estimated at two to four hours per connector depending on the connector's complexity, for a total engineering estimate of 80 to 160 hours — three to six sprint-weeks of work — with three weeks until the deployment date. The integrations team's engineering lead escalated to the engineering director the same day the Slack announcement arrived. The deployment was delayed by four weeks to allow both teams to complete the migration. The accounts team completed the utility library update in the first week; the four-week delay was driven entirely by the integrations team's connector migration work. The financial services customer, whose compliance requirement had driven the PKCE change, received a written explanation of the delay and expressed concern about the organization's cross-team coordination reliability. The auth team's post-incident analysis found that the Google Sheet had been updated correctly and completely on the day the roadmap was committed. The failure was not in the quality of the documentation but in the propagation model: the sheet was a pull resource, and downstream teams' awareness of its contents was determined by whether they happened to consult it, not by whether the upstream change affected their sprint assumptions. Connect this to the engineering manager span of control decision record: the span model determines how much bandwidth each engineering manager has for cross-team coordination work beyond their direct team's sprint execution; a manager carrying 12 direct reports in a Tier 2 team configuration — mixed seniority, moderate ambiguity work — has effective bandwidth of approximately 20 to 30 minutes per report per week after non-direct-report organizational load is subtracted; cross-team dependency coordination — attending the dependency review meeting, reviewing the shared tracking document, sending and receiving plan change notifications — is overhead that competes with that per-report bandwidth; organizations where engineering managers are operating at or above their effective span threshold will consistently produce pull-based dependency coordination because managers do not have spare bandwidth for proactive push notification; the dependency model design must account for the manager bandwidth constraint, not assume unlimited coordination capacity.

A 67-person enterprise SaaS building financial reporting software for publicly traded companies had invested significantly in cross-team dependency management. The organization ran four engineering teams — platform infrastructure, data pipeline, reporting engine, and customer-facing UI — with hard dependencies between all four in the product's critical rendering path. The VP of Engineering had instituted a weekly cross-team dependency review meeting three years earlier after a pair of quarter-end delivery failures that each traced to undiscovered inter-team dependencies. The meeting ran every Wednesday for 45 minutes with the VP of Engineering facilitating; each team's engineering lead attended; a shared Jira board tracked all identified cross-team dependencies with labels, target dates, and owning teams; and any engineer on any team could file a dependency ticket at any time. The process was mature, well-maintained, and culturally accepted — no team skipped the Wednesday meeting, the Jira board had 100% of roadmap-level dependencies documented, and the VP of Engineering reviewed open dependencies at each quarterly planning session before commitments were finalized. By the organization's own metrics, the dependency process was functioning correctly. By the delivery metrics that mattered to the customer, 37% of sprint-planned features were blocked by external dependencies in at least one sprint per quarter — a rate that had not changed in three years of running the dependency review process.

An analysis conducted by the newly promoted engineering director found the cause in the dependency model's granularity. The Jira board and the weekly meeting operated at the team level: 'Platform infrastructure team needs to deliver the query execution cache module before the reporting engine team begins the batch rendering work in Q3.' The team-level dependency was visible, tracked, confirmed, and in most cases delivered on schedule. The execution-phase blockages were not team-level dependencies. They were work-item-level dependencies: story #4471 in the reporting engine team, 'Implement incremental render for large report sets,' assumed that an API endpoint added in story #3892 in the platform infrastructure team — 'Add cursor-based pagination to query results API' — was deployed to the staging environment. Story #3892 was on the platform infrastructure team's sprint plan for the same two-week sprint in which the reporting engine team had planned to begin testing story #4471. The platform infrastructure team completed story #3892 on day 11 of the sprint. The reporting engine team's engineer working on story #4471 had estimated testing starting on day 8. Three days of testing time were lost; the story spilled into the next sprint; the next sprint's plan had assumed story #4471 was complete and included two dependent stories that now had to be deferred. The team-level dependency record between the two teams correctly noted that the platform infrastructure team needed to deliver the query cache module before the reporting engine team could begin batch rendering. It did not capture that story #4471 needed story #3892 deployed to staging by day 8 of the sprint, because the dependency tracker operated at a granularity coarser than the granularity at which the actual blocking relationship existed. The Wednesday meeting was well-attended and well-run. The Jira board was complete and up to date. Neither addressed the execution-phase blocking at the work-item level because neither was designed to operate at that level. Connect this to the incident postmortem action item accountability decision record: both the dependency mapping decision and the postmortem accountability decision share the same structural failure pattern when the tracking model's granularity is coarser than the granularity at which the actual failure occurs; the postmortem model that tracks action items at the aspiration level — 'improve observability' rather than 'add p99 latency dashboards by a specific named engineer by a specific date' — produces the same outcome as the dependency model that tracks at the team level rather than the work-item level: the model captures the correct category but misses the specific blocking condition that produces the execution-phase failure; fixing the aspiration-level action item requires the same structural solution as fixing the team-level dependency: a specification standard that forces the tracking record to the granularity at which the actual blocking condition exists.

Structural properties set by the dependency mapping decision

Two structural properties are determined by the founding decisions about dependency capture timing, dependency granularity, change propagation model, and governance cadence. Neither is visible in per-team sprint velocity or in each team's individual roadmap completion rate — a team can have 95% sprint velocity and 90% quarterly roadmap completion and still produce a high cross-team delivery failure rate if the items it completes are not the items the adjacent teams needed, or if the items it does deliver arrive later than adjacent teams' sprint plans assumed. Both properties become visible only through the lens of the inter-team delivery relationship — the gap between what teams commit to and what adjacent teams receive at the time they need it — rather than through the per-team delivery metrics that most engineering planning processes use as their primary health indicators.

Property 1: Cross-team delivery predictability and the dependency capture threshold. Cross-team delivery predictability is the accuracy of the organization's delivery forecast at roadmap commit time — the degree to which quarterly commitments made by teams that depend on other teams' outputs are actually delivered in the committed quarter. The property is controlled by a single threshold: whether input dependencies are identified and confirmed before roadmap commitments are made, or after. A dependency identified after commitments are made is not a risk that can be managed prospectively; it is a constraint that has already been encoded into a committed delivery schedule that may not be achievable given the constraint. The CI observability company's Q3 customer commitment was structurally at risk from the moment the quarterly planning session ended without the product team's tracing SDK dependency being registered in a shared record that the platform team could see — the risk was invisible in the roadmap, both teams' sprint velocity was high, and the failure mode was guaranteed by the structure of the planning process itself, independent of any subsequent execution quality. Cross-team delivery predictability decreases monotonically with the fraction of input dependencies that are captured after rather than before commitment. An organization where teams commit roadmap items without confirming that the inputs those items require are on the upstream teams' committed roadmap will consistently produce delivery predictability below 80% regardless of per-team execution quality; the failures will be attributed to cross-team communication problems, priority changes, or unexpected complexity when the actual cause is a planning model that permits commitments to encode unconfirmed assumptions about other teams' work. The dependency capture protocol — the specification of when and how input dependencies must be surfaced and confirmed during the planning cycle — is the single design decision that most strongly controls this property, and it must specify a sequence: identify outputs committed to customers or business stakeholders; identify for each committed output the inputs required from other teams; confirm that each required input is on the upstream team's committed roadmap for the required date; resolve any gaps before the downstream commitment is finalized. Connect this to the sprint planning format decision record: the sprint planning model specifies how sprint commitments are formed and what inputs must be confirmed before a story is placed in a sprint; the dependency capture protocol operates at the roadmap level, confirming that input dependencies exist at the strategic planning horizon; the sprint planning model extends that confirmation to the work-item level, confirming that the specific upstream outputs required by sprint-level stories are ready or will be ready by the day the story begins; together they form a two-level dependency confirmation cascade that prevents roadmap-level assumptions from flowing unexamined into sprint-level plans that encode the same assumptions at finer granularity; an organization that runs the roadmap-level capture without the sprint-level confirmation will produce a lower roadmap-level assumption failure rate but the same execution-phase blocking rate that the 67-person financial reporting company experienced with its team-level Jira board.

Property 2: Sprint planning assumption failure rate and the granularity mismatch effect. The sprint planning assumption failure rate is the rate at which sprint-level work items, once committed to a sprint, are discovered during execution to depend on work in another team that was not ready, scheduled, or visible to the planning team at the time the sprint was committed. It is the execution-level complement to cross-team delivery predictability: where delivery predictability measures the accuracy of quarterly forecasts, the assumption failure rate measures the accuracy of two-week sprint plans. The two properties are coupled but not identical: an organization can improve its quarterly delivery predictability — by requiring roadmap-level dependency confirmation — without reducing its sprint planning assumption failure rate, if the team-level dependency tracking does not resolve to the work-item level at which execution-phase blocking occurs. The 67-person financial reporting company demonstrated this exactly: three years of quarterly delivery improvement driven by the team-level dependency process, with no change in the 37% sprint-level assumption failure rate, because the quarterly and sprint-level failure modes had different causes that required different interventions. The sprint planning assumption failure rate is controlled by three factors. Dependency granularity: team-level tracking captures strategic scheduling constraints but misses work-item-level blocking relationships; the failure rate decreases only when dependency records are resolved to work-item level for any upstream output that directly gates a sprint-level story in the dependent team's current or upcoming sprint. Upstream timeline precision: a dependency record that specifies 'available in Q3' is insufficient for a sprint plan that needs the upstream output by day eight of a specific two-week sprint; work-item-level dependencies require sprint-week-level timing precision to produce valid sprint plans. Change propagation speed: even a correctly captured, precisely timed work-item-level dependency produces a sprint assumption failure if the upstream team changes the delivery timeline and the dependent team learns about the change after the sprint has been committed; the failure rate is bounded below by the change propagation model's speed — the faster upstream plan changes reach dependent teams, the smaller the window in which a changed dependency can produce a committed sprint plan that is already invalid. The failure rate is not visible in standard sprint velocity metrics: a sprint that completes 90% of its stories, with the 10% spilling due to a dependency blocker, appears as a high-performing sprint with minor slippage; the pattern of which stories consistently slip — always the stories that touch inter-team interfaces — is visible only in a per-story analysis that tracks the cause of each slip, and most sprint review processes do not conduct that analysis.

The technical roadmap dependency mapping ADR: five sections

Section 1: Dependency capture protocol. The dependency capture protocol specifies when and how inter-team input dependencies must be surfaced during the planning cycle to prevent them from becoming sprint-time blocking conditions. The protocol is the sequence: it defines the order of operations in quarterly planning so that dependency confirmation happens before commitment rather than after. Three elements. Capture timing: input dependencies must be identified before the quarterly planning session produces committed roadmap items; the mechanism is a pre-planning dependency elicitation step, run in the week before the planning session, in which each team's engineering lead produces a list of the external inputs their Q-plus-one roadmap will require, including the team responsible for each input and the date the input is required; the list is shared with all teams before the planning session begins, so that the session can surface and resolve gaps rather than discovering them after commitments have been made. Capture completeness: the elicitation step is complete when every committed output in the downstream team's roadmap has been traced to its required inputs and every required input has been matched to a committed output in the upstream team's roadmap; items that cannot be matched — required inputs for which no upstream team has committed the corresponding output — are unresolvable dependencies that must either produce a scope change in the downstream commitment or produce an explicit upstream commitment before the downstream commitment is finalized; the downstream team's engineering manager signs off that all unmatched dependencies have been resolved before the downstream roadmap is considered committed. Confirmation format: a dependency record must contain five fields to be considered a confirmed dependency rather than a noted assumption: the required output (a specific deliverable, not a team or a system); the required date (a sprint-week-level target date, not a quarter); the upstream team (the named team owning the output, confirmed by that team's engineering lead); the consequence to the downstream commitment if the output is late (scope reduction, schedule slip, or customer commitment impact, stated in terms the upstream team's engineering manager can evaluate when prioritizing the output against competing sprint items); and the downstream team's named contact for change notifications. The five-field format prevents the pattern where a dependency is acknowledged but not specified — 'we know we'll need something from Team B in Q3' — which produces the same planning failure as an undocumented dependency because the upstream team has no specific commitment to manage against.

Section 2: Dependency granularity standard. The dependency granularity standard specifies at what level of resolution the dependency model must operate — team level, work-item level, or both — and the trigger that requires resolution to finer granularity than the quarterly planning cycle naturally produces. The standard exists because team-level dependency tracking and work-item-level dependency tracking address different failure modes: team-level tracking prevents the quarterly delivery failure mode, where a team commits to an output in a quarter when the inputs it requires are not on any upstream team's committed roadmap for that quarter; work-item-level tracking prevents the sprint execution failure mode, where a team's sprint plan encodes an assumption about an upstream work item's availability that turns out to be incorrect at sprint time. Two granularity tiers. Roadmap-level dependencies: captured at the quarterly planning cycle, tracked at the team-output level, confirmed by the upstream team's engineering lead; scope is strategic — which team needs which team's output in which quarter; change propagation requirement is five business days after any upstream plan change affecting a roadmap-level output. Work-item-level dependencies: required for any roadmap-level dependency whose upstream output feeds directly into a specific sprint-level story in the downstream team's current sprint or the immediately upcoming sprint; captured at sprint planning time, tracked at the story-level with both upstream and downstream story identifiers; confirmed by the upstream team's engineering lead acknowledging the sprint-week target date; change propagation requirement is same business day after any upstream plan change affecting a work-item-level dependency. The trigger for resolving to work-item level is the sprint distance: any roadmap-level dependency where the upstream output is required within the downstream team's current quarter, and the downstream team is within one sprint of needing the output, must be resolved to work-item level before the downstream team's sprint planning session commits the dependent story. This trigger prevents the 67-person financial reporting company's failure mode: the team-level board was correct and complete at the roadmap level; the missing layer was the sprint-level resolution that would have surfaced the story #4471 / story #3892 timing dependency before the sprint was committed. Connect this to the engineering manager span of control decision record: the work-item-level dependency resolution requires the upstream and downstream teams' engineers or engineering leads to have a direct conversation about the sprint-week timing of specific stories, which is a coordination interaction that consumes manager and engineer bandwidth; the frequency of required work-item-level resolutions increases with the number of cross-team interfaces in the architecture; organizations with dense cross-team dependency graphs need to account for the coordination overhead of work-item-level tracking when sizing teams and setting manager spans, because a dependency model that requires work-item-level resolution for dozens of interface points per sprint will overwhelm the coordination bandwidth of engineering managers operating at the upper end of their effective span range.

Section 3: Change propagation model. The change propagation model specifies how upstream plan changes reach dependent teams before the change produces a sprint assumption failure in the downstream team's committed plan. The model defines who is responsible for propagating a change, how quickly, to whom, and what the notification must contain to enable the downstream team to assess the impact before its next sprint commitment. The model must be push-based, not pull-based, because a pull-based model produces discovery lag that is structurally uncorrelated with the urgency of the upstream change: a breaking API change scheduled for three weeks from now may sit unread in the tracking system for two weeks before the dependent team's planning coordinator consults it, at which point the downstream team has one week to complete migration work that was not in any sprint plan. The propagation model has four components. Trigger definition: the upstream team is responsible for initiating a notification for any plan change that affects a committed output in the roadmap-level or work-item-level dependency record; the triggers are: a committed output's delivery date changes; a committed output's scope changes in a way that alters the interface or behavior the downstream team depends on; a committed output is deprioritized, deferred, or cancelled; the triggers apply regardless of whether the upstream team believes the downstream team has already noticed the change through the tracking system. Notification timing: roadmap-level changes must be communicated within two business days of the upstream team identifying the change; work-item-level changes must be communicated the same business day, because the downstream team's sprint plan may be encoding the old assumption in a sprint that is currently executing or that begins within the next planning cycle. Notification content: the notification must contain four elements — what changed (the specific deliverable and how its scope, timeline, or availability changed), the new target date or availability status, the upstream team's assessment of what the downstream team needs to do as a result (adjust their sprint plan, redesign their implementation, re-scope a committed customer deliverable), and a request for explicit acknowledgment from the downstream team's engineering lead that the impact has been assessed; a notification without a requested acknowledgment is a document update, not a communication, and produces the same discovery risk as a pull-based model in the window between notification and downstream acknowledgment. Acknowledgment requirement: the downstream team's engineering lead must acknowledge the notification within one business day, confirming that the sprint plan impact has been assessed and describing what adjustment is required; if the acknowledgment confirms that the downstream team's sprint plan must be re-scoped, the acknowledgment initiates the blocking dependency resolution process (Section 4) rather than ending the exchange. The acknowledgment requirement creates the mutual confirmation that neither the auth team's Google Sheet update nor the CI observability company's roadmap document update produced: the upstream team knows their change has been received and assessed; the downstream team has a record that the change was communicated before they were required to act on it; and both parties have a documented exchange that can be referenced in the blocking resolution process if the impact cannot be absorbed within normal sprint operations.

Section 4: Blocking dependency resolution process. The blocking dependency resolution process specifies the escalation path and timeline when a dependency becomes a blocker — when the upstream team's plan change or delivery failure prevents the downstream team from completing a committed sprint item or quarterly roadmap commitment within the agreed schedule. The process exists because blocking dependency resolution requires organizational authority that neither the upstream nor the downstream team's engineering lead necessarily has: rescheduling a committed customer delivery requires VP Engineering or product leadership involvement; reprioritizing a platform team's sprint to unblock a product team requires the shared engineering manager's involvement; determining whether a partial delivery (the tracing SDK without advanced sampling controls) is acceptable to the customer commitment requires business stakeholder involvement. Five escalation tiers. Tier 1 — same-team resolution: the upstream and downstream teams' engineering leads attempt to resolve the block through a direct synchronous conversation within one business day of the blocking condition being identified; resolution options include scope reduction (delivering a subset of the upstream output that satisfies the downstream team's minimum requirements), timeline negotiation (the downstream team adjusts its sprint plan to accommodate the upstream team's revised delivery date), or parallel implementation (the downstream team implements a temporary compensating behavior that allows their sprint to proceed without the upstream output and reverts when the output is delivered). Tier 2 — shared manager resolution: if Tier 1 fails to produce a resolution within one business day, the shared engineering manager (or the VP of Engineering if the teams have separate reporting chains) is included; the shared manager has the authority to reprioritize the upstream team's sprint items to unblock the downstream team and to communicate the schedule impact of the reprioritization to the teams whose items are displaced; this tier must be entered within two business days of the blocking condition being identified, not after the downstream sprint has failed and the post-sprint retrospective is attempting to trace the cause. Tier 3 — product-business stakeholder resolution: if the blocking condition produces a risk to a customer commitment, the engineering manager escalates to the VP of Engineering and product leadership within one business day of identifying the customer commitment risk; the escalation must include a written impact assessment with three elements — what the customer commitment is, what the dependency failure produces in terms of scope reduction or schedule slip, and what options are available with their respective costs (compressed delivery with engineering overtime, partial delivery with a documented second-phase commitment, schedule slip with customer notification); the escalation produces a decision within two business days, not a discussion that extends across multiple stakeholder meetings. Tier 4 — cross-team architectural resolution: if the blocking condition recurs across multiple quarters and involves the same architectural interface, the blocking resolution escalates from a schedule negotiation to an architectural design review; the engineering director convenes a review of the interface design between the two teams and produces an architectural decision record specifying how the interface should be redesigned to eliminate the recurring blocking dependency; recurring cross-team blocks are architectural signals, not coordination failures, and addressing them through Tier 1-3 escalation indefinitely produces a dependency management overhead that grows with the organization's velocity rather than decreasing as the teams mature. Tier 5 — governance retrospective: all Tier 2 and above blocking resolutions are reviewed at the quarterly cross-team dependency review (Section 5) as a leading indicator of the dependency model's effectiveness; a Tier 2 resolution that required the shared engineering manager's intervention is a signal of a dependency capture failure — the block should have been visible at roadmap planning time and resolved before the sprint was committed; a pattern of Tier 2 resolutions involving the same two teams or the same architectural interface is a Tier 4 escalation trigger regardless of whether any individual instance reached Tier 4 criteria. Connect this to the incident postmortem action item accountability decision record: the blocking dependency resolution tiers mirror the postmortem action item accountability tiers — quick fixes owned by the teams involved, structural changes requiring the shared manager's authority, infrastructure-level changes requiring VP-level organizational commitment; in both models, the critical design choice is the escalation trigger and timeline, not the resolution content; a block or an action item that spends three weeks in informal negotiation at Tier 1 before escalating to Tier 2 has already produced the schedule impact that the escalation was designed to prevent; the two-business-day Tier 1 limit is not arbitrary — it is calibrated against the two-week sprint window, within which a one-week delay in escalation removes half the sprint's capacity to absorb the impact before the sprint ends.

Section 5: Cross-team dependency review governance. The cross-team dependency review governance specifies the cadence, ownership, and metrics of the organizational process that monitors whether the dependency model is producing cross-team delivery predictability or producing sprint planning assumption failures. The governance section is the feedback loop that converts the dependency model from a planning artifact into a continuously calibrated system: the dependency record is the input, the delivery outcome is the output, and the governance review is the mechanism that closes the loop by identifying where the model's design is producing gaps between the planned dependencies and the actual blocking conditions that appear during execution. Three governance components. Weekly dependency check-in: a 30-minute meeting, owned by the engineering director or a designated dependency coordinator, attended by each team's engineering lead or a delegated sprint lead; the agenda covers three items — open roadmap-level dependencies with target dates within the next four weeks (confirming on-schedule status or initiating Tier 1 resolution), new work-item-level dependencies identified since the last check-in (reviewing the sprint-level trigger condition and confirming the upstream sprint-week target date), and any open Tier 2 or above blocking resolutions (reviewing status and escalation timeline); the weekly check-in is calibrated for the work-item-level dependency failure mode rather than the roadmap-level failure mode, because roadmap-level dependencies are confirmed at the quarterly planning cycle and only require monitoring for plan changes, while work-item-level dependencies emerge and resolve at the sprint cadence and require weekly visibility to catch blocking conditions before they produce sprint failures. Quarterly dependency model review: a 90-minute retrospective, owned by the VP of Engineering, run within two weeks of each quarter end, analyzing three metrics — the quarterly roadmap assumption failure rate (what fraction of quarterly commitments required a scope or schedule change due to an unconfirmed dependency that was visible in hindsight at planning time), the sprint planning assumption failure rate (what fraction of sprint stories experienced a dependency-related blocker, tracked per-story in the sprint review rather than aggregated into the team velocity number), and the Tier 2-and-above blocking resolution count by team pair (which teams' interfaces produced the most escalated dependency blocks, which is the leading indicator for Tier 4 architectural review); the quarterly review produces two outputs: a written assessment of the dependency model's current calibration against the failure rates, and a list of adjustments to the dependency capture protocol, granularity standard, or change propagation model that the current failure rates indicate are needed. Dependency model calibration authority: the engineering director has the authority to adjust the dependency capture timing, the work-item-level trigger threshold, and the notification timeline between quarterly reviews if a blocking pattern emerges mid-quarter that the current model parameters are not addressing; adjustments are documented as amendments to the dependency mapping decision record with the date, the failure mode that triggered the amendment, and the expected impact on the sprint planning assumption failure rate; the amendment record is the input to the next quarterly review, which evaluates whether the mid-quarter adjustment produced the expected improvement or whether a further adjustment is required. Connect this to the performance review calibration decision record: both the dependency model and the performance review process share the same governance design requirement — the metrics that reveal whether the model is calibrated correctly are not visible in the aggregate statistics that most organizations report; the aggregate sprint velocity hides the per-story dependency failure rate; the aggregate rating distribution hides the per-manager divergence rate; effective governance in both cases requires disaggregating the aggregate metric to the resolution at which the failure mode actually occurs — per-story for dependency failures, per-manager for calibration failures — and building a review cadence that operates at that resolution rather than at the aggregate level that the failure mode is invisible in.

FAQ

Further reading

• Sprint planning format decision record — the sprint planning model is where roadmap-level dependency assumptions become sprint-level commitments; a sprint planning model that does not include a dependency confirmation step — validating that each story's external inputs are ready and scheduled before the story is placed in the sprint — allows roadmap-level dependency assumptions to flow unexamined into sprint plans that encode the same assumptions at finer granularity; the dependency capture protocol ensures that roadmap-level inputs are confirmed before quarterly commitments are made; the sprint planning model extends that confirmation to the work-item level, confirming that the specific upstream outputs required by sprint-level stories are ready or will be ready by the day the story begins; both mechanisms are required: organizations that run the roadmap-level capture without the sprint-level confirmation produce a lower quarterly delivery assumption failure rate but the same execution-phase blocking rate that arises when team-level dependency tracking misses work-item-level blocking relationships.
• Engineering manager span of control decision record — the span model determines how much bandwidth each engineering manager has for cross-team coordination work beyond their direct team's sprint execution; push-based dependency change propagation, work-item-level dependency resolution conversations, and weekly dependency check-in attendance are all coordination interactions that consume manager bandwidth; the dependency model design must account for the manager bandwidth constraint — organizations where engineering managers are operating at or above their effective span threshold will consistently produce pull-based dependency coordination because managers do not have spare bandwidth for proactive push notification; a dependency model that requires work-item-level resolution for dozens of interface points per sprint will overwhelm the coordination bandwidth of managers at the upper end of their effective span range; the span model and the dependency model must be designed together so that the coordination overhead the dependency model generates is achievable within the coordination bandwidth the span model provides.
• Incident postmortem action item accountability decision record — the blocking dependency resolution tiers mirror the postmortem action item accountability tiers: quick fixes owned by the teams involved, structural changes requiring the shared manager's authority, infrastructure-level changes requiring VP-level organizational commitment; in both models, the critical design choice is the escalation trigger and timeline — a block or an action item that spends three weeks in informal negotiation at the lowest escalation tier has already produced the schedule impact or the recurrence that the escalation was designed to prevent; the two-business-day escalation trigger in the dependency resolution process and the postmortem's three-day action item routing window both reflect the same calibration logic: the escalation timer must be short enough that escalation precedes the sprint failure or incident recurrence, not follows it; the two models also share the granularity mismatch failure pattern — team-level dependency tracking produces the same outcome as aspiration-level action item tracking: a model that captures the correct category but misses the specific blocking condition at the resolution where the failure actually occurs.
• Performance review calibration decision record — the governance design requirement shared by the dependency model and the performance review process is the need to disaggregate aggregate metrics to the resolution at which the failure mode actually occurs; the aggregate sprint velocity hides the per-story dependency failure rate in the same way the aggregate rating distribution hides the per-manager divergence rate; effective governance in both cases requires building a review cadence that operates at the disaggregated resolution — per-story for dependency failures, per-manager for calibration failures — rather than at the aggregate level where both failure modes are invisible; an organization that reviews only team-level sprint velocity and company-level rating distributions may be operating both models correctly at the aggregate level while producing persistent failure at the level that matters: individual engineers blocked mid-sprint by undiscovered dependencies, individual engineers receiving systematically inflated or deflated ratings from managers whose calibration has never been compared to the cross-team distribution.
• Open-source extractor — the roadmap dependency mapping decisions — why the dependency capture protocol requires input dependency identification before quarterly commitments are finalized rather than after; what the analysis was behind the five-business-day notification window for roadmap-level changes versus same-day notification for work-item-level changes; why the work-item-level trigger is calibrated to sprint proximity rather than to an absolute organizational threshold; what evidence from the blocking resolution retrospective justified the two-business-day Tier 2 escalation trigger rather than the five-day window that seems more operationally practical; why the dependency granularity standard requires both team-level and work-item-level capture rather than committing to one level for simplicity; what failure mode drove the decision to require upstream acknowledgment receipt in addition to upstream notification — these decisions are made in conversations: a VP of Engineering and two engineering leads analyzing a quarter-end delivery failure and designing a dependency model that would have surfaced the blocking condition at planning time; an engineering director and a platform team lead debating whether the five-field dependency record format is operationally achievable given the platform team's current sprint overhead or whether a lighter-weight format produces sufficient visibility for the failure rate the organization is experiencing; a product leader and an engineering manager working through the tradeoffs between strict dependency capture enforcement that delays quarterly planning by one week and looser enforcement that allows commitments to be made with unconfirmed assumptions; the written output is the dependency mapping decision record; the reasoning behind those specific threshold choices — what historical blocking patterns they were calibrated against, what alternatives were evaluated and why they were rejected, whether the blocking frequency that justified the strict format has decreased enough to warrant relaxing the enforcement — lives in the conversation history that preceded the documentation, and that is exactly what WhyChose's extractor recovers from AI chat export history and makes findable when the new engineering director needs to understand not just what the dependency policy says but why the two-business-day Tier 2 escalation window was set where it was and whether the delivery failure rate that justified it still describes the organization it governs.