{"id":10301,"date":"2022-08-30T10:00:19","date_gmt":"2022-08-30T09:00:19","guid":{"rendered":"https:\/\/ee.yelkdev.site\/?p=10301"},"modified":"2024-04-16T10:43:13","modified_gmt":"2024-04-16T09:43:13","slug":"why-product-teams-still-need-major-incident-management","status":"publish","type":"post","link":"https:\/\/www.equalexperts.com\/blog\/our-thinking\/why-product-teams-still-need-major-incident-management\/","title":{"rendered":"Why product teams still need major incident management"},"content":{"rendered":"

You\u2019ve probably heard of <\/span>You Build It You Run It<\/b><\/a> before. It\u2019s an operating model that empowers product teams to own every aspect of digital service management. When done well, it accelerates your time to market, increases your service reliability, and grows a learning culture. <\/span><\/p>\n

There are also some pitfalls, which can drain the confidence of your senior leadership, and ultimately put the success of You Build It You Run It at risk.<\/span><\/p>\n

In our <\/span>You Build It You Run It playbook<\/b><\/span><\/a>, my co-author Bethan Timmins and I look at a common incident management pitfall, and the risk of major incidents lacking an effective response. The good news is that you can guard against this pitfall; and if you find yourself already stuck in it, don\u2019t panic – there <\/span>is <\/span><\/i>a way out!<\/span><\/p>\n

What is incident management anyway?<\/h2>\n

If you work in a large IT department with separate Build and Run functions, you\u2019ll have one or more operations teams managing your SaaS, COTS, and custom back office applications. In our playbook, we call this <\/span>Ops Run It<\/b><\/a> for your foundational systems.<\/span><\/p>\n\"\"\n

You\u2019ll probably have an L1 ops bridge team, an L2 application support team, and an incident management team. If there\u2019s a<\/span> RACI model<\/span><\/a> to show who\u2019s responsible, accountable, consulted, and informed on incident response, it\u2019ll look like this:<\/span><\/p>\n\"\"\n

Incident commander and incident manager are different roles. An incident commander is a leader of an incident response team. An incident manager is a facilitator for all incident response teams.\u00a0<\/span><\/p>\n

During an incident, the incident manager captures incident details in your system of record (such as ServiceNow), coordinates software incident response across multiple teams when necessary, and periodically updates senior leadership and users of impact and resolution progress. They usually nominate the application support team manager as the incident commander.<\/span><\/p>\n

It\u2019s important to have a repeatable, reliable incident management process that\u2019s easily followed. If you\u2019re thinking about implementing You Build It You Run It for your digital services, it\u2019s essential that you don\u2019t lose sight of that repeatable, reliable process.<\/span><\/p>\n

The no major incident management pitfall<\/h2>\n

With <\/span>You Build It You Run It<\/b><\/a>, your on-call product teams are accountable for incident response for their own digital services. If no effort is made to align them with your major incident management process, they can easily miss out on incident management altogether. It can be expressed as this RACI:<\/span><\/p>\n\"\"\n

Symptoms of ad hoc incident response include:<\/span><\/p>\n