Incident Command

Post-incident reviews consistently show the same pattern: the technical problem gets solved faster than expected, but the incident takes twice as long to resolve because of coordination overhead, unclear ownership, duplicated work, stale status information, and decisions that aren't logged anywhere. Incident Command is a centralised management interface built from real post-mortem findings, not from adapting a generic project management tool to an emergency context.

1. 1.
   Centralised Command View: Build a single-screen interface that gives the incident commander real-time visibility into who owns what, what's been tried, and what the current status is, without requiring team members to update a separate system.
2. 2.
   Decision Logging: Capture every key decision with a timestamp and owner, so the post-incident review has a complete record of what was decided, when, and by whom.
3. 3.
   Action Ownership: Make action ownership explicit and visible, eliminating the 'I thought you were handling that' coordination failure mode.
4. 4.
   Low Friction Under Pressure: Design every interaction for a stressed engineer under time pressure, no menus, no navigation, no configuration. The interface should be immediately operational.

• ◆
  Post-Mortem Analysis: Reviewed 14 incident post-mortems to identify the most common coordination failure modes, ranking them by frequency and time impact.
• ◆
  Opinionated UX Design: Made deliberate design choices that reduce optionality under pressure, fixed screen layout, no customisation, forced fields for owner and timestamp on every decision.
• ◆
  Rapid Prototyping: Built in vanilla HTML/JS to minimise load time and dependency overhead, incident tooling that requires a build step is incident tooling that isn't ready when you need it.
• ◆
  Validation: Ran tabletop incident simulations with the engineering team to validate that the interface reduced coordination overhead under realistic pressure conditions.

Generic project management tools fail during incidents because they offer too much optionality. You can organise by sprint, by assignee, by priority, by label, which means you spend time deciding how to organise instead of responding. Incident Command has one view, one way to log a decision, one way to assign an action. That rigidity is the feature. Under pressure, constraints are faster than choices.

Built from real incident post-mortems. The UX decisions came from watching how coordination actually breaks down under pressure, not from copying a project management template. The interface is opinionated because incidents don't benefit from optionality.

Faster mean-time-to-resolution by cutting the coordination overhead that compounds every incident.