Tag: failure rate

  • Why You Should Embrace Incidents and Ditch MTTR

    Why You Should Embrace Incidents and Ditch MTTR

    The cliché is that everyone in IT hates incidents, and the natural reaction when assembling incident response metrics is to look for numbers that you can lower over time. Fewer incidents and shorter incident response times must be better, we think. You might already be familiar with the common metrics associated with these goals, including mean time-to-resolution (MTTR) and total incident count.

    As it turns out, however, these metrics actually work against your company’s resilience goals. To understand why, let’s look at the industry that birthed most of our modern incident management practices and has learned the most about how to properly apply them: the airline industry.

    What the Airlines Can Teach Us

    From the 1950s to the 1990s, the airline industry built and refined best practices for incident management that we have since simplified and that have been widely adopted across the tech industry. What’s often termed “modern incident management” simply means the predictable and repeatable approach to handling unexpected disasters and the learnings-driven remediation steps that are prized when building a DevOps or SRE practice.

    One of the most important findings to come out of this research is the somewhat surprising fact that incidents weren’t being declared often enough. Instead, incident reports were created and the carefully assembled response and cataloging process was only followed after catastrophic events, which meant earlier opportunities to catch the underlying problem during a less severe incident were being missed.

    So why did an industry with such incredibly high stakes take so long to realize that more incidents were actually a good thing? You guessed it: a misguided desire to decrease the incident count. In chasing this goal of “lowering the number,” pilots and mechanics were often reluctant to file incident reports for anything less than the most critical situations, which meant the powerful, learnings-focused response and remediation process was only triggered in response to relatively rare and critical situations.

    This is a textbook example of Goodhart’s Law in action. To paraphrase, Charles Goodhart posited that any metric created will ultimately become the goal. In other words, if the incentives are aligned to reduce incidents, no matter how good your response and learning process is, it will only be executed in the most dire and unavoidable circumstances. After discovering this, the industry rapidly moved their focus towards expanding the use of the incident process by working to expand the spectrum of situations that could be classified as incidents with the goal of triggering the formal incident response process more often, distributing learnings for more incidents of lower relative severity and, yes, ultimately resetting the goal to increase the number of incidents.

    This approach effectively turned Goodhart’s Law to the airlines’ advantage—any effort to game the metric(s) meant more learning, not less. Filing incidents became directly and heavily incentivized and these metrics were never used as a justification for punitive action. This resulted in the safest decade of commercial aviation on record, with over 12 billion passengers traveling and no fatal accidents.

    What IT Can Learn About Successful Incident Response

    As technology companies, there is much for us to learn from this exercise in achieving resilience versus chasing “lower numbers.” The primary learning is this: increasing your incident count by incentivizing the use of your incident management process for more non-critical incidents—likely your SEV2s and below—and focusing your metrics and incentives on that goal, is likely the best way to reduce your overall count of catastrophic failures.

    For most companies, this means putting MTTR on the back burner and instead focusing on making the incident process itself more accessible throughout your company and across your organizations. It means leaders should talk about impactful and recent postmortems publicly and that postmortem distribution should be a priority; it should also be something that’s measured. Most importantly, it means opening up the incident management process more widely. Ideally, everyone at your company should have access to systems that allow them to file incidents, read incidents in progress and review postmortems from previous incidents.

    I like to reference the “big red button” philosophy of factory floors, where the decision-making power to declare an incident is in the hands of every employee. An unsafe situation shouldn’t be up for discussion, debate or approval before being acted on, even if the situation is later determined to be less severe than originally thought. The context of why that incident was filed—why that big red button was pressed—may prevent larger, more catastrophic failures in the future.

    So if you’re just getting started building out an incident management practice at your company, or you’ve been chasing MTTR metrics and focusing on pushing your incident count down as a primary goal, consider taking these learnings to heart and creating a positive incident culture with positive metrics meant to encourage and reward incident responders and reporters. Your company’s future depends on it.

  • The Persistence of Enterprise Tech Failure Rates

    The Persistence of Enterprise Tech Failure Rates

    During a recent dinner conversion with a CIO friend, I was surprised to learn that his organization was having challenges delivering the applications and IT services on a timely enough manner that the business needs. The business is taking too long to approve the budget for major tech projects to start, then develop and deploy, and the CIO expressed frustration how it is always behind the demand curve and following where it should likely be in the market. His level of frustration as he described the situation was painted all over his brow.

    Hearing this was surprising to me; after all, we’ve been writing about how such problems delivering with speed and agility are challenges that are designed to be solved by DevOps, agile development methods, microservices and all of the things we focus on here at devopsy.kinsta.cloud and Container Journal.

    The discussion we had got me wondering how common this situation remains. How many companies are still struggling with their ability to retool themselves into more agile developers? In the late ’90s it was common for tech projects to fail. I recall surveys I reported on that found 60 percent, or higher, failure rates of large projects. But back then software rollouts were truly big bangs. There were years of development time and hundreds of physical servers and thousands of endpoints that had to all be managed. There existed layers and layers of committees and bureaucracies between the developers, IT admins and business leadership. IT is supposed to have moved beyond all of that.

    Unfortunately, however, if recent surveys are any indication, it still seems very common.

    A survey conducted last year by portfolio management provider Innotas found that more than half of tech projects are not well aligned with the goals of the business. The survey, the annual “Project and Portfolio Management Landscape survey,” also found that more than 61 percent of IT professionals questioned did not think that they have adequate resources to manage demand for tech projects in their organization.

    Part of the challenge may be that there’s inadequate project management in place at many organizations. The survey found that 38.7 percent of respondents didn’t have a project management office at their organization; however, 16 percent are building such offices. Additionally, 25 percent of those surveyed said they don’t have a formal methodology to prioritize projects.

    Other areas of concern ranged from project prioritization (26 percent) and alignment (13.8 percent). Attaining benefits and finding the appropriate budget were also challenges at 12 percent or fewer of organizations surveyed.

    This is concerning, as more enterprises are doing everything they can to move more swiftly (or, at least say that they are). As we covered in “Digital Transformation Strains Traditional IT,” according to a recent report published by Salesforce’s “2016 State of IT,” IT leaders are focusing on mobile apps, migration to the cloud, building adequate cybersecurity/incident response, customer-facing digital apps and productivity apps.

    The Salesforce report found that 68 percent of respondents are increasing their tech budgets on mobile apps, cloud and security. The majority (63 percent) of respondents also said they plan to increase their budgets allocated to cybersecurity, while 62 percent will spend more on employee productivity apps.

    Some of the things that has come up, repeatedly, in my conversations with other CIOs is that those companies that are struggling have poor business-to-IT relationships and ongoing feedback. This creates a lot of distrust and poorly aligned priorities.

    We covered a lot of this earlier in a number of posts, which are available here:

    Five often expressed obstacles to enterprise IT innovation

    Enterprises still struggle to leverage IT as a tool to innovate

    The IT mandate: Be a catalyst of business innovation

    Driving Innovation with DevOps