Engineers build systems that account for failure. They ask where the single points of failure are, which dependencies sit on the critical path, how far a failure can propagate, and what the recovery path looks like before anyone needs it. Then they build accordingly.
I came to program management through engineering, and that sequence matters. The mental model transferred remarkably well.
A complex program behaves much like a distributed system. Engineering, product, security, operations, external vendors, regulatory reviewers, and executive decision-makers are interconnected components. Each introduces dependencies and potential failure modes. The TPM’s job is to understand how those components interact and design the delivery accordingly.
The programs I have run that landed cleanly were the ones where we identified credible failures early enough to build the recovery path before we needed it.
Programs Have Failure Modes. Plan for Them.
When I start a program, I run through a set of questions borrowed directly from systems thinking. I group them into four categories that become the program’s resilience spine.
Dependency. Where are the single points of failure? Which dependencies sit on the critical path with no backup path? Which external partners hold delivery commitments our launch depends on?
Detection. What signals indicate something is degrading before it fully breaks? How early does that signal arrive? Who sees it first?
Containment. How far can a failure propagate before it touches the customer? Which components can operate independently if a neighbor fails?
Recovery. Who has authority to activate a contingency? How quickly can the program recover? What is the actual alternate path, and has anyone proven it works?
These are engineering questions. Applying them at kickoff changes the architecture of the program before execution begins. What follows are four programs where that architecture changed the outcome.
Example One: When Your Vendor Goes Bankrupt Mid-Program
Engineering principle: Redundancy and failover
Several years ago, I led an e-commerce platform conversion for a global consumer goods company. The deployment window was fixed: a narrow period between major retail holidays where a cutover had to happen cleanly or not at all. Engineering, business operations, and the external platform provider all had tightly coupled dependencies on one another.
Before the conversion began, I examined the dependency map. A single external vendor held a disproportionate share of the program’s critical path, with no redundant operating path behind it. That structural fact, on its own, justified a contingency. I made the deliberate decision to keep the incumbent platform operational in the background throughout the transition. Not as a permanent fallback. As a live, ready option that required no setup time to activate. I had effectively treated the vendor the way engineers treat an external service dependency: assume availability can disappear and preserve a viable operating path before it does. The specific failure mode was unforeseeable. The need for a fallback was not.
Mid-implementation, the vendor went bankrupt.
Because we had maintained the incumbent as a viable operating path, the reversion was immediate. No scramble, no data exposure, no customer impact. After the vendor’s software assets became available under new ownership, I led the subsequent conversion under controlled conditions and on a timeline we could manage.
Outcome: zero downtime, zero data loss, no customer impact across two platform transitions.
The lesson: a fallback requiring setup time during a crisis has already failed its purpose. Redundancy must be ready before the failure arrives. A vendor’s financial and operational health belongs on the program risk map alongside its technical capabilities.
Example Two: When the Data Itself Is the Security Risk
Engineering principle: Secure by design
Earlier in my career, I worked on a healthcare technology engagement where production-derived patient data was being supplied to lower development and test environments after nominal de-identification. The transformation was presented as sufficient protection.
I examined it. The masking was a simple, predictable cipher. Without any software or decryption tooling, I could visually reconstruct the underlying patient information. The data was readily re-identifiable. The ease of re-identification raised an immediate question about whether the data satisfied HIPAA’s de-identification requirements under 45 CFR §164.514. The program had a live privacy and compliance exposure that had never been formally assessed.
I escalated and stopped the practice.
That decision immediately created a different problem: engineering now had no usable test data. The complete solution required both controls: eliminate the unsafe data path and provide engineering with a synthetic-data path that preserved delivery. So I built one. I developed automated generators capable of producing thousands of realistic but entirely fictitious member records at a time, including the demographic attributes, account flags, family structures, and identifiers required for meaningful functional and performance testing.
The principle I carried forward: a smaller synthetic dataset you can fully trust is more valuable than a larger masked dataset whose masking effectiveness remains unverified. When a control’s effectiveness is uncertain, you build around it.
I subsequently carried the same principle into healthcare and regulated financial-services programs, making safe test data and telemetry controls explicit design dependencies during planning. Security built in early is simultaneously a security practice and a program-resilience practice. It gives the team time to solve the underlying engineering problem before the control becomes a launch blocker.
Example Three: Instrument the Program, Not Just the System
Engineering principle: Observability
Engineers instrument systems because waiting for complete failure provides information too late. A well-instrumented system surfaces degradation while there is still time to intervene. Programs need equivalent telemetry.
Conventional program status reporting tells leadership someone’s assessment of how things are going. A green, yellow, or red indicator captures one person’s judgment at one moment in time. Telemetry does something different. It shows why the assessment is justified, where the leading indicators are moving, and what thresholds will trigger an escalation.
During an observability program at a core banking SaaS provider, I built program-level instrumentation alongside the technical observability function: dependency readiness tracking, aging unresolved decisions, partner delivery variance, environment readiness, integration test completion rates, and release readiness indicators that aggregated across teams. The program status at any point was derived from real signals.
Detection earns its value only when paired with a predetermined response. A partner milestone slipping beyond an agreed threshold triggers escalation to a named owner. An architecture decision aging past its resolution window gets elevated to the designated decision-maker. Integration-readiness deterioration triggers scope or sequencing review. The objective is to connect every consequential signal to an owner and an action while recovery options remain available.
The engineering parallels are direct. Metrics measure conditions associated with successful delivery. Alerts establish thresholds requiring intervention. Tracing follows dependencies across organizational and vendor boundaries. SLOs define measurable service expectations; programs need equally explicit thresholds for acceptable delivery performance. Each has a corresponding response procedure. The program equivalent works the same way: a signal without a predetermined owner and action is noise.
Example Four: When the Deadline Has No Flexibility
Engineering principle: Capacity, failure isolation, and recovery
The hardest programs to run are the ones where the deadline carries regulatory or contractual force. Missing it means operational failure with consequences that extend well beyond the program team.
I ran the performance engineering program for a government-administered health benefits exchange during two consecutive open enrollment cycles. The enrollment windows were federally governed and operationally immovable for the program team. Once enrollment opened, the system had to hold.
The program planning approach started from that constraint and worked backward. I mapped the failure domains: which component failures could affect enrollment. I established capacity assumptions and defined what the program would do when demand exceeded forecasts. I built recovery ownership into the plan explicitly, naming who would act when specific thresholds were breached and under what conditions escalation would trigger. I coordinated operational and engineering readiness simultaneously. Passing expected-load tests was insufficient. Launch readiness required evidence that the platform could withstand adverse load and that teams could recover quickly when thresholds were breached.
The platform completed both enrollment cycles with zero downtime and full SLA compliance.
The practitioner lesson: launch readiness means establishing confidence that the organization can operate through adverse conditions. Resilience gets built in the months before the launch date. The week before is too late.
The Resilience Patterns Translate
Every engineering pattern that governs resilient system design has a direct program management equivalent.
Redundancy becomes an alternate delivery path. Failover becomes a predefined contingency with named activation conditions. A circuit breaker becomes a predefined condition that pauses or isolates a failing workstream before it propagates risk downstream. Observability becomes program telemetry. Fault isolation becomes dependency decoupling. Graceful degradation becomes a predefined minimum viable operating state: the product retains core functionality while a degraded or unavailable integration recovers in the background. A health check becomes a readiness criterion. An SLO becomes a measurable delivery expectation. Incident response becomes a program recovery procedure.
Every one of these is a design decision made before the failure occurs.
Resilience Has a Cost
Engineers make economic decisions about how much redundancy each component warrants. The same calculus applies to program investments in contingency. The evaluation runs across five dimensions: likelihood, blast radius, detectability, recovery time, and recovery cost. The more severe those dimensions become in combination, the stronger the case for investing in an alternate path before launch. A dependency that can fail with little advance warning can justify more contingency on its own, because the program may discover the failure too late to recover cleanly.
A low-impact dependency may need only documented ownership. A critical external API may warrant monitoring and a tested retry path. A business-critical platform migration may justify maintaining the incumbent until the new environment proves stable under real conditions. A sensitive-data dependency may justify building an entirely different technical solution. The amount of resilience you engineer should match the potential blast radius of the failure you are designing against.
Why This Matters for Health Technology Programs
Programs that touch personal health data, external lab and pharmacy integrations, wearable devices, and regulated telehealth workflows carry above-average blast radii at almost every dependency point.
A lab, pharmacy, wearable provider, or payment processor also introduces an organizational failure domain. Their engineering capacity, release schedules, security reviews, test environments, and incident response procedures sit outside the program’s authority while remaining inside the customer’s experience. The integrated program plan therefore has to treat external-partner readiness as seriously as internal engineering readiness.
A TPM running these programs needs several answers early. What sensitive data enters the system, and where does it travel? Which external organizations receive it, and under what contractual terms? How do lower environments obtain test data while protecting real individuals from exposure? Which integrations expand the attack surface, and which reviews carry lead times long enough to affect the schedule? Which security or compliance findings can block a launch, and what is the contingency when approval arrives late?
These are program architecture questions with direct compliance consequences. The answers belong in the dependency map, the milestone structure, and the risk register from day one.
Before the Kickoff Ends, Build the Failure Plan
The four examples above had different failure modes: vendor insolvency, a data protection exposure embedded in existing practice, a regulated deadline with no extension mechanism, and delivery risk distributed across a complex multi-team platform. What they shared was that the contingency was a first-class design input, not a slide added to the risk register after the kickoff deck was already finalized.
For every critical dependency in a program, I document six things before execution begins.
Failure mode. What credible event could make this dependency unavailable, unsafe, late, or unusable?
Blast radius. Which milestones, systems, teams, customers, or regulatory commitments would that failure affect?
Detection. What measurable signal will indicate that the dependency is deteriorating, and how early does that signal arrive relative to when action is still available?
Containment. What can be isolated, paused, decoupled, or allowed to operate independently so the failure stops propagating before it reaches adjacent systems or teams?
Trigger and owner. What threshold activates intervention? Who owns the decision? Who has authority to escalate?
Recovery path. What can the program actually do if the failure occurs? Define the alternate vendor, rollback procedure, reduced operating state, sequencing change, synthetic-data path, or additional capacity before it is required.
I run the same review whenever a new critical dependency enters the program or an existing dependency materially changes. I test the highest-impact contingencies before launch. A recovery path that exists only in a document remains an assumption until the team proves it can execute.
Engineering taught me that resilient systems are the product of deliberate architecture. I apply the same discipline to programs.
I plan programs the way I learned to engineer systems: understand the dependencies, instrument what matters, constrain the blast radius, and build the recovery path before anyone needs it.
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