Stephen Whitworth and Chris Evans, incident.io | KubeCon + CloudNativeCon Europe 2023

This is texturing TV. Hey everyone, we're back. We're back here in kubecon Amsterdam day three final day of our coverage here in Amsterdam.

It's been an amazing three days. We've spoken as so we probably have done 50 or 60 interviews spoken to a lot of people and we're really really happy to have our next two guest here. io.

They're the two co-founders. Let me introduce you here to my to my far right? We'll start with Chris Evans.

Who's the CPO Chief product officer. io. I think we got it right guys.

Welcome to Tech strong TV. How are you? Yeah doing well doing well today and slightly tired.

But yeah, I keep it going today. We are it ends earlier today. We got power through this.

So look, I got both of you on here. I love I'm fascinated by Founders stories, right? I founded for five companies myself over the years.

io? So yeah, I mean like the three of us said you three of us who co-founded this. Okay Pete's not here at the moment.

But all of us like long long sort of I say long reasonably long careers in engineering all those sort of individual contributors originally myself personally, like went on to then lead sort of platform engineering teams that kind of thing and those teams like very sort of clear lines into things like on cool and dealing with incidents. They're usually the folks on the front line there and so immediately before starting this company. I was working.

In fact, all three of us are working. I can be called monzo in the UK, which is a sort of a tech scale up bank and part of my responsibility. There was looking after Encore and Incident Management and an incident there were just incredibly complicated things.

So they were not like engineering typically things where you just fixed and issue. They were things that bled out into regulatory concerns and things where the CEO would need to brief the press and all of those things. So ended up writing some software there myself.

They ended up being used across the bank and then that snowballed in a fantastic way there and eventually it was used by everyone in the bank, like customer support people were declaring incidents Engineers were operations people were and that was sort of the spark for starting this company here Excellent Man. Steven you want to add to that or that's pretty sums it up? No, I think it's a I think it's quite similar for me.

So I was you know product and Engineering before this and I started a company before joining monzo where you know, I was getting paged and woken up to deal with issues, but to didn't really have any software to help me then went to monzo saw what Chris and the team had built and it was like immediate kind of ah, okay, like out of love this all the company. I've worked out same with Pete as well. So it's yeah, it's very much a story of like building software to solve our own problems and then trying to kind of take that to the world.

Yeah. It's a common theme in in Tech startups, right? So so at what point did you say?

Okay. What we built here Armando is great, but let's go take this. On the road, right?

Let's go build the company around it. Yeah, so that was about two years ago at this point. So essentially yeah, we kind of ended up ended up building from scratch really.

com slash monzo slash response, but it was really like the feeling of you know, there's so much more that could be here, you know, there's for example like Status pages on call like there's so many things around around the product and yeah, it really going to the point that like this doesn't exist in the world. You know, we're going to go create it and like we we felt like we were the team to do it as well. So, let me let me dive.

Little weed bag diving here. So look in in the world of devops. com almost 10 years ago now in the world of devops, we've had some incident response right Patriot Duty.

Public company incident response friend of mine Todd Vernon started company called Victor Ops, which I think Splunk. Yeah Splunk on call now. Yeah required another incident response.

There was another one with the word pager in it, and I'd be darned if I remember what it is, but they were right here, too. What makes incident I/O different I think yeah, I think if you look at where products have been sort of like catering for these kind of Engineers devops folks as well. They they're very well catered For when it comes to observability.

So understanding when systems go wrong the tools you mentioned there Fantastic Tools for managing things like Encore rotations, making sure people are available around the clock to support these tools, but where they kind of fall short is what happens after you've been paged. So imagine it's 2AM and you know, my page has gone off and something's broken. I don't really go to page of Duty to to go and navigate that I'm typically jumping into whatever tool it is.

I'm using to communicate with the rest of the people at my company and for for many folks that slack while the folks that's Microsoft teams some people jump on zoom. And so that's really where the product that we've built sort of fits in really nicely. Is that for the response part of Incident Management?

We will sit right where you are communicating which means everyone has, you know, all of these various different tools that they're already using at their fingertips. So we integrate with page Duty really nicely and so you can automatically kick Incident when your pager goes off, but we can also then use incident I/O to escalate to other people. So imagine I'm you know, a short, you know Short Straw and I need to like dial him Steven.

I can just grab him straight from within slack without leaving that channel and the kind of reason that's important is every time you sort of leave the channel the place where you're communicating is an opportunity to lose content and what's happening and no one wants to do that in these super high pressure situations. And then we have you know, it's like kind of putting out the fire side of the world. So that would be response.

But then there's also a huge amount of value that is left in you know, doing debriefs and post-mortems about the incident so our product because you've used us to respond when something goes wrong. We kind of know everything that happens. We know what actions were communicated who was spending time who is fixing things so we can kind of export all of that to a debrief to save you time and then we have this like final, you know final bit of the puzzle which is usually in a debrief or a post-mortem people aggressively agree that like, we definitely have to refactor this bit of code or we need to scale up this part the system people then you know, Go about their merry way put this thing in jira and like basically never gets done issue just happens again.

And again, like we try and you know, we close off that Loop for you. So you can just like make sure that thing went wrong kind of talked about it and you got the work done and then that's like the one incident View and then we have many so analytics workloads, you know, it's even getting woken up 15 times in a month. Like this is all stuff that we can just kind of give you for free out the box.

So yeah, so there's a there's a whole dashboard then Right, so it doesn't just exist in a slack or a team's no, they're right. Yeah, it's just a nice integration because if you're already using that to communicate fine, stay where you Communicate absolutely, but if you don't have slack, oh, you don't have teams or you don't want to use that you could just use the incident interface itself, right? Yeah, so that the perfect use case would be like, let's say I run the customer support team at you know at a bank and I care about incidents because I have tens of thousands of people that are like in my queue and I need to deal with it, but I don't really want to be in the like technical discussions of how things are being solved.

You can just log on to our web product and just see that the updates being streamed. So you're being kept in the loop. It's like high, you know High signal low noise.

But if you want to hear yourself down into the down into that in the detail, you're going to slack and yeah, we sort of think of it as like a different way of Building Products. So a lot of companies have thought about you know, their web product is the Hub and slack as maybe like a spoke of these things. We sort of thing a bit more like a funnel which is most people will first interact with us through slack, but we try and convince them that our web product is so good and bad for the final exactly exactly.

Right? Yeah. So is the product or if it is a sass kind of more freeing or is it?

From the installing your own no, it's a hundred percent sass so it's right, you know, click it into existence sign up really pretty quickly and then we will sit as I said on top of slack plug-in to all the other SAS products you're using so, you know Confluence Google Docs Google meet Zone ton of other Integrations, essentially. So I'll go here is to plug in all of these tools that are already in existence when people are navigating incidents, but they're all like in different logins that you've got to go and manage and you know the world where you can just integrate with us. It's a lot simpler.

So I love that. All right. Hey, let's turn to cubecon.

You guys announced the new product here this week. We did. Yeah, we announced the launch of our status page product.

So this is if you look at pretty much any company, they will have a status dot whatever that domain is calm and that is a place that customers can go to see when you know, when they're service that they're using. Well, they go to the website that they want to go and buy whatever it is isn't working. They will go to the status page and be like well what's going on here?

And so we've launched this product it's deeply integrated into Our response products so, you know public Communications aren't and afterthought or something off to the side that another team manages we can be plugged right into how folks are responding to incidents which means you know for companies that means like building building trust with customers because they are fast to update things and folks then are you know, more trusting of the companies that they're dealing with things. So yeah really excited to launch. It had a great uptick already and people signing up for it.

So, yeah really delighted. I love it and and the products in GA available right now for people are using yeah good to go. Great, you know, one of the trends I'm seeing it this year's show.

It's a much less of a developer-centric mindset. Hmm, right? It's actually an opt-centric mindset that we're seeing here.

Whether it's platform Engineers or sres. Response kind of teams not to disk the developers. I think what's happening is sort of a new pattern where for so many years we talked about shift left.

Putting more on the developers plate, right? Hey in addition to writing the code we want you to do testing want you to be mindful of security. We want you to understand about cicd and to deploy sometimes the developers are deploying and When stuff hits the fan and that beeper goes off.

I need you on my incident response team. We're going right to level two and three. We're not laying it.

You know just one level one response. Now what we're seeing a little bit of a push the other way. Mmm, right where hey these people here that you know traditional Ops sort of rolls.

There's a lot of cloud native stuff for them. Like an incident IO frankly, right? We're gonna pull the developers in but instead of Shifting left.

We're almost pulling developers, right? Mmm, right it's that's my look my opinion my observation. Wondering what you guys think about.

You know, from what you've seen here. Yeah. I think I totally agree with the shifting left thing.

I've seen that I've seen a lot of a lot of emphasis on like things that Engineers need to consider now and I think that is led to like a huge amount of like cognitive overhead on what is a job of trying to deliver value to to customers by writing code. Essentially. Yeah.

I still think it's a good thing shift left principle and I think putting more responsibility and having people more thoughtful about operating their software. It's still really important, but I think that's like honestly we're Solutions like incident are like just like objectively helpful in the like we built this because like running incidents was something that we wanted all of our Engineers to do at the company. We're at previously, but it was just an absolute.

Burden and the cognitive overhead of trying to think about public customer comms and looping in the CEO and pulling together other parts of the company where you're also in the depths of kubernetes trying to fix a a node that's wedged and you've got, you know a problem there. It's just too much and I think this is where like we're very congressant. And so part of our product is literally, you know, automating some of those workflows that you know, you would otherwise be that mental tax and you start to put that in the mix and it becomes a much more reasonable ass to ask folks to be considerate of those kind of like service considerations and thinking more about the customer at the end of The Journey there.

Excellent Matt great guys. We're almost at a time. I I'd like one of you to look into that camera and for people who want to find out more about incident IO and they want to you know, get on the on-ramp.

Give them your best advice to how to engage with you guys. That's okay. io Handley.

It's the name of the company as well as the domain we offer two week free trials, and we would be absolutely delighted to to run a demo and figure out whether we're a good fit for folks. Fantastic Hey Stephen pleasure Chris a pleasure to have you on here. Good luck with incident.

IO keep us posted on this good luck with the new products and hey, we're getting ready for kubecon in Chicago already and it'll be that six months. We'll see you there. But maybe we can see you before our Tech strong team.

Absolutely. We're gonna take a break. We've got lots of guests ready to go right now here.

We'll be back in a minute live from Amsterdam kubecon.