Hyperfocus

Context

The company’s 50+ product teams could explain product features with business cases and metrics, but reliability work was invisible. Product leaders lacked a way to show impact, so incidents recurred and board questions grew about whether the organisation had maturity to manage stability. The whole org needed a consistent pattern for when reliability must take priority.

Approach

JP reframed the narrative around incidents and repair items. Instead of abstract “tech debt,” the framework tied them back to the teams at their root — and to the customer impact they created. When metrics crossed set thresholds, a team moved into Focus (50% recovery). If issues persisted, they entered Hyperfocus (100% recovery). Teams now had predictable shifts, triggered by their own data and grounded in customer experience rather than debate.

To make it stick, JP tested early drafts with leaders and senior ICs. Rough versions encouraged feedback and co-ownership. Language was tuned until it worked in both boardrooms and engineering forums. By rollout, leaders saw clarity, engineers saw credibility, and the framework was ready to scale.

Delivery

Rolling it out to ~1,800 people meant more than publishing rules. JP co-presented with leaders at all-hands for top-down legitimacy, while speaking with IC credibility to resonate with engineers. Hyperfocus was framed as breathing space to fix issues, paired with the accountability of asking, “did you need this to happen to see it coming?” The framework was embedded into weekly reviews and all-hands, making transitions visible and reinforcing success when teams exited Hyperfocus.

Outcome

- Reliability gained parity with features - same weight, same language.

- Shared triggers cut debate; incidents fell and triage sharpened.

- Investment landed where it mattered most: the services at risk.

- Teams began using Hyperfocus themselves, not just when pushed from above.

- The framework scaled, but its anchor never shifted: stability first.