01 — The headline
Storm operations moved from narrative to structured state
The core change was replacing ambiguous radio handoffs with constrained outage state updates that OMS/ADMS and customer channels could trust under pressure.
02 — Situation
Legacy coordination could not keep pace with events
Dispatch, control rooms, and crews were interpreting different versions of the same outage. During major events, that gap translated directly into rework and unreliable ETAs and ETRs.
03 — Constraints
Field and control-center constraints
The platform needed to perform in bad-weather reality, not ideal-office connectivity assumptions—and under a critical-infrastructure availability bar.
Critical-infrastructure availability barMOD held a critical-infrastructure application label: 99.95% reliability—about four hours of downtime per year, with no single maintenance or failure window longer than thirty minutes.
Integration windows and riskOMS/ADMS change windows constrained release timing; ADMS sync could not depend on middleware that might fail under storm load.
Harsh field UX conditionsInterfaces had to support gloves, glare, and intermittent service without losing workflow integrity.
Customer-facing ETA dependencyAny outage-state error propagated to external channels, raising trust and communications risk.
04 — Key decisions
Platform-defining calls
We made fewer, stronger decisions early so operational behavior stayed coherent during storms.
Prioritize structured workflow over map polish
The callLocked outage-state contracts first, then optimized interaction design around them.
The tradeoffDelayed some visual refinements to avoid unstable downstream operations data.
Ship resilient list/card/map parity
The callKept one shared job object across all views to remove interpretation drift.
The tradeoffHigher data-model rigor and validation complexity across UI surfaces.
Integrate SMS deep-link acknowledgment
The callAdded assignment messaging paths that open directly into MOD work objects.
The tradeoffExtra integration and monitoring overhead to preserve reliability under event load.
Remove MuleSoft; own the ADMS path
The callReplaced middleware with direct ADMS integration and a resilient VM cutover pipeline for failure recovery.
The tradeoffMore internal ownership of integration ops, monitoring, and rehearsed cutover playbooks.
05 — What shipped
MOD field experience with two-way systems sync
MOD shipped as a PWA plus native shell pattern with structured state modals, supervisor review, and bi-directional outage synchronization back to core utility systems. The team removed MuleSoft from the ADMS path and built direct integration with a VM cutover pipeline so backend failure could be isolated without extended field outage.
Callout: this was intentionally built as an operating system for storms, not just a field app refresh.
06 — Results
What moved
The immediate result was better outage-state coherence; over time that translates into faster restoration cycles and cleaner customer ETA communication.
07 — For the next PM
Operating lessons
In mission-critical response software, reliability decisions are product decisions and must be visible at the roadmap level.
Model state before screensWithout a disciplined state model, UX polish amplifies confusion instead of reducing it.
Rehearse with real event pressureStorm drills expose failure modes that normal QA never reaches.
Close the external truth loopIf customer ETA channels do not inherit the same clock, trust decays quickly during outages.
List & map
Same assignments as sortable queue vs regional map—density vs geography.
Field Outage Management (MOD): assignments through closeout
MOD: queue and map views, structured status and verification, restoration wired to ADMS/OMS. PWA + Capacitor for crew devices.
Screenshot 1 of 12