The Debrief by incident.io

In this episode, hosts Norberto and Lawrence discuss the recent CrowdStrike incident that began on July 19th.

You won't find any backseat commentary on the technical specifics, but instead a deep dive into the things we care about incident.io, like communication, their over response and proactive problem-solving during crises.

This week, we're talking to Sabin Roman, engineering manager at Linear, to talk about processes that sit behind building their product.

We cover how they build teams around planned work, how their "goalie" role works to protect teams from unplanned work, the zero bugs policy they've introduced and how they ensure everyone at Linear sweats the details on their product.

This week we sit down with Hank Jacobs, Staff Site Reliability Engineer at Netflix to discuss their deployment of incident.io across their organization.

Among other things, we discuss how great UX has allowed them to roll out to hundreds of teams in months, how they have more entries in their Catalog than any other incident.io customer, and how their partnership with incident.io has been an overall game changer.

During a recent episode of The Debrief, we spoke with Jeff Forde, Architect on the Platform Engineering team at Collectors, about building an incident management program at various stages of growth. 

In that episode, we called it growth from zero to one, one to two, and two to three. 

But what happens once you’ve scaled beyond three and answers to question you may have become that much harder to find. 

To get to the bottom of this, we chatted with Oliver Tappin, Director of SRE at Eagle Eye, about what to do once your company has reached a point where there’s no precedent or roadmap, and you can’t necessarily look to others for answers. 

This week, we have a really fun conversation lined up.

For this episode, we chatted with Toby Jackson, Global SRE Team Lead at Future, about why it’s a bad idea to take a cookie-cutter approach to incident management or, put another way, why it’s not a good idea to treat all incidents alike.

In our conversation, we discuss what’s wrong with this approach, some situations where this might actually make sense, how psychological safety factors into this conversation, and a whole lot more. 

This week, we're sharing an extra special episode.

It's no secret that the decision to buy or build isn't exactly a straightforward one. And the decision you make can be influenced by a ton of factors.

But the fact is that in some instances, buying can make more sense than building, and in others, building can make more sense than buying.

In this episode, you'll hear from John Paris, Principal Engineer at Skyscanner, to get the story behind their build versus buy journey.

Joining him as the host for this episode is none other than the CPO of incident.io, Chris Evans.

In their conversation, Chris and John discuss Skyscanner's setup before adopting incident.io, what life has been like after adopting the platform, and a whole lot more.

It’s fair to say that AI is here to stay. 

So, as companies grapple with this reality, they’re putting their best foot forward to build AI features that really make a difference for their customers.

But should you be building these features if there’s no obvious fit in your product? And even if there is, are you making sure to stay true to your product principles? 

The reality is that deciding to build AI into your product isn’t a decision you make on a whim.

There are tons of considerations around how to do it right—many of which we wrestled with ourselves when we were building our AI features just a few months ago. 

So, in this episode of The Debrief, we sat down with our CTO, Pete Hamilton, and Product Manager, Ed Dean, to get some perspective on how we weighed the decision to build with AI and how we thought about principles along the way.

It’s no secret that teamwork is one of those things that, when done right, can make a world of a difference. 

So sometimes, when responding to a particularly complicated incident, it can be best to bring a team together to figure out what’s going on and work towards a fix. 

But it’s not enough to just jam a bunch of folks into a room and hope for the best. You need a framework in place to ensure that everyone stays focused, diagnoses the issue and resolves it as quickly as possible. 

And for SRE, Dan Slimmon, clinical troubleshooting is just the framework to help with this. 

In this episode, we chat with Dan about this approach to collaboration and why, he thinks, it can help teams resolve issues much faster. 

In our conversation we discuss what the benefits of clinical troubleshooting are, why teams get tripped up on collaboration in the first place, what firefighting and incident response have in common and a lot more. 

Whether you’re a seasoned vet when it comes to incident response, or just getting started out, it can be easy to fall into the trap of doing too much all at once.

And it just makes sense.

Incident response is one of those things that doesn’t have a single, perfect formula, so teams can be left doing a little bit of everything in an effort to get it right. 

That said there are some fundamentals that, regardless of how mature your organization is, can be a great launching off point to better incident response.

And that’s exactly what we’ll be talking about in today’s episode of the Debrief. 

This time around, we’re joined by Viktor Stanchev of Anchorage Digital, to chat about actionable advice for responding to incidents—from declaration to post-mortem. We cover what having a good incident response even means, why it’s important to declare incidents early, how to better communicate during incidents and a whole lot more. 

If you’ve been looking for practical advice for running incidents from a veteran in the space, you’re in the right place. 

In last week’s episode of The Debrief, we had on Colette Alexander, Director of Engineering at HashiCorp, to discuss some of the myths around incident response.

In that conversation, one of the myths we spoke about was the idea that asking “why” is better than asking “how.” And how, in reality, asking "how" allows you to focus more on the contributing factors that led to an incident happening, whereas “why” tends to single out a person, which can lead to a lot of blame. 

For this episode, we’re diving a bit deeper into the reasons “how” is not only better for learning, it’s also better for the psychological safety of your team. 

This time around, we’re joined by Dennis Henry who currently works on the Architecture team at Okta. Dennis is a big believer in psychological safety and learning from incidents, so he’s just the person to shed light on this fascinating topic.