Enterprise engineering organizations invest heavily in the things that make reliability legible: incident management platforms, SLO frameworks, observability pipelines, postmortem processes, runbooks. These investments are real and they matter. They also share a common boundary: each one is owned by a specific team, operated within a specific domain, and accountable to a specific reporting structure.
Reliability outcomes are produced across domains. An SLO initiative requires SRE, Platform Engineering, Application Engineering, Security, and Product to move in a coordinated sequence, with each team’s output serving as a prerequisite for the next team’s work. When one dependency in that chain lacks a named owner and a committed delivery date, the program stalls. Every team reports green. The outcome does not move.
The missing capability is ownership of the dependencies between teams. Technical dependencies that cross organizational boundaries are visible on architecture diagrams but absent from accountability structures. A Technical Program Manager closes that gap by converting those dependencies into operational commitments with named owners, measurable acceptance criteria, delivery dates, and executive visibility. The three incidents below show what happens when that work is not done.
Two Dependency Graphs, One Blind Spot
Every engineering organization maintains two dependency graphs simultaneously. Most actively manage only one of them.
The runtime dependency graph receives sustained investment. Architecture reviews, service catalogs, distributed tracing, and dependency scanning all keep this picture current. When a runtime dependency breaks, the failure is immediately observable through monitoring systems designed for exactly that purpose.
The organizational dependency graph receives no equivalent investment, and the reasons are structural. Runtime dependencies produce observable signals when they break: latency spikes, error rates, availability drops. Organizational dependencies produce no automatic signal when they are unmanaged. A team waiting on another team’s deliverable looks, from the outside, indistinguishable from a team making progress. Program dashboards aggregate team-level status, which means a program can appear healthy at the reporting level while individual dependency chains have already stalled. There is no alert threshold for “the database team and the maintenance team have not jointly modeled the risk at their shared boundary.”
This asymmetry explains why capable engineering organizations with mature tooling still produce the class of incident described below. Maintaining the organizational dependency graph means tracking which team must deliver before another team can proceed, which roadmap commitments are prerequisites for others, and which cross-team decisions sit on the critical path. Program plans reference this implicitly when they list dependencies, but listing a dependency and owning it are different things. A Jira ticket noting “Platform team will provide centralized logging” has named a dependency. Ownership requires a named provider, a named consumer, an agreed acceptance criterion, a committed delivery date, and a defined escalation path when the date slips.
Google Cloud, June 2025
On May 29, 2025, Google released a new feature to Service Control, the component responsible for authorizing and quota-checking every API request across Google Cloud and Google Workspace. The feature deployed region by region and completed successfully. Service Control continued operating normally.
The new code path required a specific policy change to activate. No such change occurred during the rollout. The code sat dormant across all regions for two weeks.
On June 12, 2025, a separate team inserted a policy update into Google’s regional Spanner tables. The update contained unintended blank fields. Service Control, now running the new quota-checking code in every region, attempted to process the update. The blank fields triggered a null pointer dereference in a code path that had never been exercised in any environment, because the feature deployment and the policy change that would activate it had proceeded through entirely separate pipelines with no shared activation gate. The Service Control binary crashed. Because the corrupted policy data replicated globally through Spanner within seconds, the crash loop propagated to every region simultaneously. Google Cloud and Google Workspace experienced a disruption lasting approximately seven hours and twenty-seven minutes, affecting Compute Engine, Cloud Storage, BigQuery, Cloud SQL, Cloud Run, Vertex AI, Gmail, and Drive.
The software rollout team owned the code change. The policy team owned the policy update. The activation dependency between them had no accountable owner: the condition under which the new code path would first be exercised in production, and what validation needed to happen before that condition could be triggered safely. Google’s own incident report noted that feature-flag protection would have caught the issue in staging. Two delivery chains, each correctly executed within its own scope, intersected at a point where responsibility stopped at the organizational boundary.
Meta, October 2021
On October 4, 2021, a Meta network engineer ran a maintenance tool designed to assess global backbone capacity. The tool triggered a bug that invalidated all BGP peering sessions across Meta’s backbone network, severing connectivity between its data centers. Facebook, Instagram, WhatsApp, and Oculus went offline for six hours.
The BGP failure was the initiating event. The organizational dependency failure determined the recovery timeline. Meta’s internal management systems, including authentication, remote access tooling, and the network interfaces engineers would use to issue recovery commands, were hosted on the same backbone that had just failed. When the backbone went down, it removed every remote path to remediation simultaneously. Engineers drove to a data center in Santa Clara to access routers physically, and hardened security protocols slowed their entry when they arrived.
Each team’s work was correct within its own domain. What the organization lacked was someone accountable for validating the complete recovery path across every team that depended on the backbone: whether authentication, remote tooling, and physical access would remain viable under the same failure condition that would require all three simultaneously. That question spans network engineering, infrastructure, internal tooling, and physical security. Accountability for the answer was never assigned across them.
GitHub, October 2018
On October 21, 2018, at 22:52 UTC, GitHub engineers replaced a failing 100G optical link between their US East Coast network hub and primary data center. Connectivity was lost for 43 seconds.
During those 43 seconds, GitHub’s database orchestration tool, Orchestrator, detected the network partition and promoted a West Coast database cluster to primary, redirecting write traffic across the country. When connectivity restored, the East Coast clusters had accepted writes during the partition window that were never replicated West. The two data centers had diverged.
Reconciling that divergence required rebuilding East Coast MySQL clusters from backup while GitHub’s engineering, database, and infrastructure teams coordinated across databases, storage, networking, application services, and replication tooling simultaneously. Over five million webhooks and eighty thousand Pages builds required reprocessing once clusters were restored. The 43-second initiating event produced 24 hours and 11 minutes of service degradation.
GitHub’s own post-incident analysis identified that Orchestrator’s cross-region failover behavior had not been modeled as a risk in their maintenance planning process. The maintenance team owned the optical link replacement. The database team owned cluster orchestration. The interaction between those two domains, specifically the risk that Orchestrator would treat a planned interruption as a cross-region failover trigger, had no evident owner responsible for governing it before the maintenance window opened.
What Dependency Ownership Requires
Each failure contains the same structural condition: a dependency between organizational domains where the technical components were visible but accountability for their interaction was unassigned. The activation boundary between Google’s deployment and policy teams had no governing owner. Meta’s cross-domain recovery path had no accountable owner. The interaction between GitHub’s maintenance planning and database orchestration lacked governance at the team boundary.
Ownership requires answers to a specific set of questions for every cross-team commitment: who provides the capability, who consumes it, what constitutes successful delivery, when is it required on the critical path, who carries escalation authority if the date slips, and what is the downstream customer risk if it does not arrive. A program plan that lists “Platform team will deliver centralized logging by Q3” has named a dependency. It has not answered any of those questions.
A Technical Program Manager builds and maintains the organizational dependency graph with the same discipline that platform engineers bring to the runtime graph: mapping dependencies at program inception before teams commit to delivery dates, surfacing cross-domain questions before they surface as incidents, and converting every cross-team dependency into a tracked commitment with executive visibility.
What Gets Measured
Reliability programs without dependency ownership produce metrics that measure activity. Tickets close. Postmortems are filed. The same failure modes recur because the accountability structure governing the dependencies between teams was never built.
The metrics that reveal genuine dependency ownership include: the percentage of cross-team dependencies with named accountable owners; the rate at which corrective actions are validated after implementation rather than simply closed; and the frequency with which a future incident involves a failure mode a previous corrective action was supposed to eliminate.
One metric deserves particular attention: Executive Decision Latency, the time between a dependency stall appearing in program reporting and a leadership decision being made to address it. Most reliability dashboards track time to detect and time to restore. Almost none track how long leadership allows a dependency to remain unresolved. When stalls are visible only inside team-level backlogs, leadership sees a green program dashboard while individual delivery chains have stopped. Organizations that track Executive Decision Latency tend to discover that decision-making speed on cross-team blockers is a more significant reliability variable than their detection tooling.
Google’s activation boundary was two weeks old when it produced a global outage. GitHub’s failover risk existed in its maintenance planning process long enough to be missed on October 21. Neither gap was invisible. Both were unmanaged because responsibility for governing them had not been assigned.
Customers experience the system. The org chart is invisible to them.
Every service has an owner. Every project has a lead. The failure accumulates at the interfaces between teams where technical dependencies exist but accountability does not. Reliability depends on someone owning that work explicitly, with the same rigor applied to the organizational dependency graph as to the runtime one. Every service has an owner. The dependencies between them need one too.
Nabeil Sarhan, MBA, is a dynamic technology delivery manager with over 15 years of experience in tech, cybersecurity, and computing scalability. He excels in leading diverse teams and delivering enterprise-class systems across industries such as healthcare, finance, and retail. Nabeil’s passion for solution design, systems architecture, and performance optimization makes him a sought-after consultant. He holds degrees from Harvard, MIT, and Bryant University. Connect with Nabeil on LinkedIn