Before Adding A Delivery System, Map the Topology
Every engineering organization already has an operating model. The first TPM inherits that model before they understand it. It is the aggregate of how work enters, how decisions get made, how dependencies get resolved, how capacity gets consumed, and how production feedback changes priorities.
The model may be informal, partially documented, or inconsistently applied. Dependencies surface in standup, ahead of structured planning. Decisions stall in Slack threads. Priority changes arrive as verbal directives with no written trace. Ownership dissolves at team boundaries. These are observable characteristics of the system and clues to its failure modes.
The first ninety days are an exercise in delivery-system discovery, instrumentation, and tuning. A new TPM should first understand how engineering work moves through the organization, identify the conditions that repeatedly disrupt delivery, and introduce the minimum coordination mechanisms required to address them. By day ninety, the organization should have a lightweight engineering operating system that can be inspected, measured, and tuned. Governance that precedes that diagnosis rarely fits the system it is supposed to serve.
DAYS 1–30: MAP THE TOPOLOGY
Every engineering organization is a sociotechnical system with structure that predates the TPM’s arrival. Engineering, Product, Architecture, Infrastructure, Security, QA, Operations, Design, vendors, and executives operate as interconnected components joined through organizational interfaces. Program risk concentrates at those interfaces because ownership, information, and commitments cross organizational boundaries there: where Product hands scope to Engineering, where application teams depend on platform capabilities, where architecture decisions wait on a leader managing seven competing priorities, where engineering hands off to operations without shared readiness criteria.
The TPM’s first job is to map enough of that topology to intervene intelligently. The delivery system can be mapped across four dimensions that together answer: What enters the system? How does it move? What does it depend on? What must be decided for it to continue moving?
Demand topology: How does candidate work enter, compete for capacity, and become committed? Which channels can create engineering commitments? How much demand arrives reactively, through incidents, escalations, or urgent remediation? An organization that appears capacity-constrained may actually have weak demand admission, with too many channels converting requests into commitments without reconciling aggregate demand against finite engineering capacity.
Work topology: How does accepted work move through the system? How are handoffs managed between teams, functions, and phases? Where does work queue, and which queues exist outside the work-management system? Those wait intervals often dominate elapsed delivery time. Jira captures what is logged; much of the delivery system stays hidden in the wait states between tickets.
Dependency topology: Which dependencies cross team boundaries, company boundaries, or architectural seams? Which carry external dates? Which depend on a single specialist or platform team? Dependency risk increases when dependencies are numerous, tightly coupled, externally owned, or attached to hard dates with little schedule slack. Team-level planning rarely exposes the full execution graph. The consequential question is where dependency failure can propagate through that graph.
Decision topology: What decisions recur across programs? Who holds decision rights? Which decisions regularly escalate, and what is the elapsed time from identification to resolution? Decision latency, the elapsed time between a decision becoming necessary and reaching an actionable resolution, should be measurable. The TPM can then decompose three failure modes: discovery latency (the organization lacked awareness that a decision was needed), decision latency (the organization knew and stalled), and execution latency (the decision was made but not acted on). Each requires a different intervention.
Production feedback sits across all four dimensions: incidents, defects, customer behavior, reliability signals, and security findings can create new demand, alter priorities, expose dependencies, and force new decisions.
The output of this phase is a Program Topology Map covering work entry points, decision authorities, dependency edges, integration boundaries, capacity pools, external constraints, wait states, escalation paths, release gates, and operational feedback loops. For each recurring ceremony, five questions apply: What recurring failure does this mechanism address? What information does it produce? What decision does it enable? What dependency or ambiguity does it resolve? What would happen if it disappeared? Ceremonies without clear answers become candidates for redesign, consolidation, or removal.
Mapping requires deliberate observation and active intervention. The TPM should resolve obvious coordination failures as they surface while distinguishing local symptoms from recurring system behavior. Unblocking a six-week-stalled decision creates immediate value; understanding why decisions repeatedly stall creates durable value.
Phase one output: Program Topology Map and Baseline Failure Modes.
DAYS 31–60: INSTRUMENT THE SYSTEM
The topology map becomes useful when it changes what the organization can observe and act on. The second month converts mapped failure modes into observable conditions.
Reporting communicates known state. Observability helps the organization detect conditions that conventional status reporting leaves invisible. A weekly status deck may report that a program is on plan. A dependency-maturity trend showing that four critical integrations remain unaccepted can reveal schedule risk before milestone variance appears. The goal is delivery-system observability: detecting degrading conditions before they become delivery failures.
Program governance should scale to delivery risk, dependency complexity, and rate of change. At a Fortune 10 health enterprise running more than ten concurrent programs across more than a hundred backend dependencies, the dependency topology was dense enough that team-level planning exposed only a fraction of the execution graph. A single program could carry fifteen integration points across separate engineering domains, each with its own planning cadence and release governance. Integrated planning, a structured process for surfacing cross-program dependencies before they became blockers, was proportional to that genuine complexity. Headcount is a weak proxy for coordination complexity. Interface complexity is more informative. The relevant variable is how many consequential dependencies, systems, partners, and decision boundaries must converge for delivery to succeed. A twenty-person organization coordinating payments, identity, regulated data, external APIs, and third-party fulfillment may carry interface complexity that demands comparable discipline.
At a core banking technology provider serving more than 160 regulated financial institutions, production work repeatedly consumed planned capacity and planning assumptions became stale well before the next annual cycle. Two mechanisms addressed this: category-level capacity visibility separating operational from development work, and a shorter replanning cadence to revisit assumptions before they became expensive commitments. Launch governance was treated separately, tied to readiness criteria calibrated to the regulatory and customer obligations specific to each release.
The underlying skill is mechanism extraction: identify the coordination problem a framework was designed to solve, isolate the useful mechanism, and calibrate it to the local topology. Scrum, Kanban, SAFe, SRE, and Lean each contain mechanisms that solve specific problems. A dependency-discovery problem may justify integrated planning. Rapidly expiring assumptions may justify shorter replanning cycles. Decision bottlenecks may justify explicit decision rights and escalation thresholds. Integration failures appearing late may justify readiness criteria and earlier checkpoints.
Dependency tracking deserves more structure than a binary model. A useful maturity progression: Identified, Owned, Committed, Scheduled, Ready, Integrated, Validated. The important principle is that dependency existence and dependency readiness are different conditions. Time in state reveals dependencies that have stopped progressing. A dependency remaining Identified for forty-five days signals different risk than one identified yesterday. The useful program-health question becomes: What percentage of critical dependencies have reached the maturity state required for the current delivery phase?
A useful planning identity:
Effective planned capacity = Nominal engineering capacity − recurring operational load − interrupt load − mandatory remediation − coordination overhead
The discipline is accounting for recurring capacity consumption before committing feature work. Necessary coordination still consumes capacity. A nominal twenty-engineer team can behave like a materially smaller feature-delivery team when incidents, escalations, remediation, and vendor troubleshooting consume sustained capacity.
Every mechanism introduced should have a trigger, a purpose, an owner, an expected signal, an operating cost, a review date, and an exit condition. Without explicit ownership and review dates, mechanisms persist through inertia. A daily dependency call during a critical migration may be appropriate for six weeks; kept indefinitely, it becomes structural overhead. A temporary architecture review may be warranted while teams converge on a new platform interface; once that contract stabilizes, the additional review layer should be reconsidered. Mature TPMs distinguish permanent operating mechanisms from temporary stabilization mechanisms.
Phase two output: Minimum Viable Instrumentation and Initial Operating Mechanisms.
DAYS 61–90: TUNE THE SYSTEM
Phase three closes the feedback loop by testing whether the signals and mechanisms introduced are changing delivery behavior.
Leading signals deserve particular attention. Dependency maturity, decision aging, blocked-work aging, and readiness evidence change before a milestone slips. Milestone variance and missed launches arrive after the underlying condition has already consumed schedule. Every mechanism introduced in the second month should generate a measurable leading target. If dependency maturity tracking was introduced, the signal may be fewer critical dependencies first discovered after implementation begins. If decision logging was introduced, the target may be lower median decision latency or fewer reopened decisions.
A local metric can improve while the delivery system degrades. Shorter decision latency achieved by pushing decisions upward may increase executive bottlenecks elsewhere. Local optimization can simply move the queue. Tuning requires tracking second-order effects alongside the primary signal.
Ceremonies that consistently produce decisions or resolve dependencies should remain. Ceremonies whose purpose can be satisfied through durable written communication should migrate in that direction. Synchronous coordination consumes capacity from every participant simultaneously. It earns that cost when interaction itself produces the result: negotiation, design decisions, conflict resolution, or tradeoff choices. Status, metrics, and routine updates belong in asynchronous form.
Failure consequence should also determine governance depth. At a federally administered health-benefits exchange, enrollment windows created immovable dates and little tolerance for discovering integration problems during launch week. The governance depth there matched the consequence of discovering readiness failures after the window opened.
Production is where planning assumptions encounter reality. Incidents, defects, reliability signals, and operational toil should become inputs to subsequent capacity and priority decisions. A mature engineering operating system is a closed loop: demand, prioritization, capacity allocation, planning, execution, integration, release, operations, production evidence, and reprioritization. Each transition is an interface where information, ownership, or time can be lost. Many organizations perform parts of this loop while leaving production evidence weakly connected to portfolio decisions.
Phase three output: Measured Operating Model and Governance Adjustments.
THE MINIMUM VIABLE PROGRAM OPERATING SYSTEM
By day ninety, the operating system should answer nine questions reliably. These questions define the minimum shared state required to coordinate delivery.
Priority: What matters now, and how are competing outcomes prioritized?
Ownership: Who owns each consequential outcome or decision, and what happens when that is contested?
Capacity: Where is engineering capacity actually going, across development, operations, technical debt, compliance, and interrupt load?
Dependencies: What must happen elsewhere for this work to succeed? What is the maturity state of each critical dependency?
Decisions: Which unresolved decisions are constraining execution, how long have they been open, and what is blocking resolution?
Risk: Which conditions could materially change delivery scope, schedule, quality, cost, security, reliability, or customer impact?
Integration: Are independently progressing components converging into a functioning system on a timeline that supports launch?
Readiness: What observable evidence establishes that something can launch safely, including external partner readiness?
Health: What conditions indicate whether delivery is improving or degrading, and which thresholds trigger intervention?
The mechanisms established to answer these questions should be as lightweight as the delivery environment permits and as rigorous as consequence of failure requires. Interface complexity should drive governance depth. Its components include the number of boundaries a program must cross, their coupling strength, ownership distance, volatility, externality, and failure consequence. A thirty-engineer consumer technology company may carry a payment system, a mobile client, a third-party identity provider, cloud infrastructure, a machine learning recommendation service, regulated data, and an analytics pipeline. Coordination design should reflect that interface complexity.
Coordination debt is future delivery cost accumulated when recurring coordination problems are repeatedly absorbed through human effort without improving the underlying mechanism. The interest appears as recurring meetings, repeated escalations, rediscovered dependencies, duplicated analysis, and reopened decisions. The minimum viable program operating system addresses coordination debt explicitly, resolving it before the interest accumulates.
INFLUENCE WITHOUT AUTHORITY
The first TPM typically owns very little through organizational hierarchy. The TPM arrives with responsibility for program health and limited formal authority to enforce it.
TPM influence is often decision leverage: improving when a decision happens, who owns it, what evidence informs it, and which consequences are visible. Making dependencies visible before they become blockers gives decision-makers actionable options earlier. Quantifying tradeoffs between scope, schedule, and technical risk replaces directional opinions with structured choices. Documenting decisions and their rationale reduces the cost of revisiting them. Connecting technical conditions to business outcomes gives senior leaders a clearer basis for tradeoff decisions.
Influence becomes durable when accountability no longer depends on persuasion in each individual interaction. Visible commitments, explicit decision rights, and observable consequences create that durability. The TPM creates the conditions under which accountability can function.
Dependency observability matters most when it preserves optionality. During a large-scale commerce-platform transformation, a critical technology supplier encountered severe delivery delays threatening a dependent migration. Because the program had established explicit dependency tracking, integration-readiness criteria, and documented fallback options, the deterioration became actionable while recovery options remained. The program recovered without downtime or data loss. The delivery system had been instrumented well enough that the failure surfaced while alternatives were still viable.
COMMON FIRST-90-DAY MISCALIBRATIONS
Several miscalibrations appear frequently enough to name directly.
Ceremonies imported from a prior employer arrive calibrated to that organization’s dependency structure, planning cadence, and scale. Applying them before mapping the local topology often imposes coordination overhead the new environment never needed while leaving the actual coordination problems unaddressed.
Creating dashboards before understanding which decisions require information produces reporting attached to nothing. A dashboard earns its maintenance cost when it changes a decision, triggers an intervention, or improves shared understanding of program state.
Treating Jira configuration as program management confuses the tool with the system. Work-tracking configuration provides incomplete visibility into how dependencies resolve, decisions happen, and capacity shifts.
Scheduling recurring meetings for every coordination problem imposes synchronous costs on problems with asynchronous solutions.
Standardization earns its value where teams share recurring coordination problems. Uniformity becomes costly when materially different delivery conditions require different controls. A team managing a regulated data pipeline and a team building a consumer-facing mobile feature carry different integration requirements, risk profiles, and planning horizons.
Becoming the human integration layer for processes that should become durable organizational mechanisms creates a coordination bottleneck with a single point of failure. There is a useful TPM bus-factor test: if the TPM disappears for two weeks, does the program retain its priorities, dependency state, open decisions, readiness criteria, and escalation paths? If those disappear with the person, the organization has encoded coordination in memory, not in the operating system.
CONCLUSION
By day ninety, the organization should know what matters, where capacity is going, which dependencies threaten delivery, which decisions are aging, what evidence establishes readiness, and what conditions require intervention.
The first month maps the topology. The second instruments the failure modes. The third tests and tunes the mechanisms.
The final measure is durability. If shared program state disappears when the TPM leaves the room, coordination still lives in the person. When priorities, dependencies, decisions, readiness, and escalation remain visible without continuous intervention, the organization has an operating system.
The first ninety days begin with learning the terrain. The lasting value comes from making that terrain navigable for everyone who follows.
The TPM succeeds when coordination becomes a property of the system.
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