John Egan - CEO & Co-Founder at Kintaba

(Joel Beasley at 00:00:00) Hello, my friends. Today we are talking to John, the CEO and co-founder at Kintaba, and we discuss the innovation they are bringing to modern incident response management, the history of incident response going all the way back to the airline industry, and the most effective thing you can do when things start going sideways. All of this right here, right now on the Modern CTO Podcast. Here we go. This is the Modern CTO Podcast.

(Joel Beasley at 00:00:39) Hey, John.

(John at 00:00:41) Hey, Joel. What's going on?

(Joel Beasley at 00:00:42) Dude, living the good life. How are you?

(John at 00:00:45) Doing all right. Yeah, same deal.

(Joel Beasley at 00:00:48) Where are you calling in from?

(John at 00:00:50) I'm out here in New York. We've got an office. It's actually right across the river here in Long Island City, but I live over in Manhattan.

(Joel Beasley at 00:00:57) Is it back to being a little busier, or is it still like zombie town out there?

(John at 00:01:02) No, it's been better for a while now. I think the city was hit so hard at the beginning of all of this that I feel like everyone just has been taking more and more precautions and spending time outside and almost getting used to it from a new normal standpoint. And then the vaccine rollout is in overdrive. So we just opened up to 30-plus yesterday, and I actually just got mine yesterday.

(John at 00:01:28) So fingers crossed I don't have any side effects during this interview. But yeah, I think we're up to 80% of the city vaccinated or something at this point. So it's pretty exciting.

(Joel Beasley at 00:01:39) If we did have side effects during this interview, that would make it go so viral. It would be fantastic. So feel free to have a seizure. I'm just kidding.

(John at 00:01:47) Might be great for you. Doesn't sound so good for me.

(Joel Beasley at 00:01:52) For us, we're going to help get the word out about Kintaba. Am I saying that right, by the way?

(John at 00:01:58) That's right. Yep. Kintaba.

(Joel Beasley at 00:01:59) All right. So I'm saying Kintaba right? What does that, like, what's the name mean?

(John at 00:02:05) So Kintaba's name is sort of born from a Japanese art form called Kintsugi, which I'm not sure if you're familiar with, but it's the art of taking broken pottery and reassembling it using golden inlay. And the outcome of that is that your repaired version of the artwork is actually more valuable than the original. I think it's just this fantastic metaphor towards the efforts that are going on in the resiliency space, which is how do we look at companies and ourselves as stronger for our scars as opposed to how do we hide them and try to make them invisible? I just think it maps really nicely. So Kintaba really comes from the continuous effort, right, of practicing on yourself as an organization and as a team.

(Joel Beasley at 00:02:53) I love it. And it has to do, like, it's perfectly tied because you do incident management, incident response. Explain what that is.

(John at 00:03:00) Yeah. So we're an incident management platform, which entails incident response, right? And there's been a really fascinating progression in the tech industry over the last maybe 10 years, where we've started to move from what was historically just alert management in terms of how do we respond to server 105 going down and paging Phil who's asleep, who wakes up and turns it off and moves on, to how are we managing major black swan events that are beyond the predictable within our organization. And so this is captured in a bunch of different terms, right?

(John at 00:03:36) Modern incident management is one of the ones, but incident management platforms as we've built it inside of Kintaba is really based around how do you go and implement those best practices and processes inside of your company of any size that historically have been really effectively practiced by Facebook and Google and Netflix, and are only now starting to really kind of propagate out of those organizations and be formalized practices in other companies.

(Joel Beasley at 00:03:59) Have you come across the book Principles, Ray Dalio? So he talks about believability, right? Like people being believed. Why are you believable on this topic?

(John at 00:04:09) So we've got a lot of history in this space. I've been a startup founder operating under the fire since 2011. I had another company back then doing high-speed data transport that Facebook acquired back in 2012. That's how we ended up there. Spent 2012 to 2017 at Facebook building tools as that company scaled, really went through hyper-growth internally as well as externally. I think we were 4,000 people when Zach and I joined, and then by the time I was gone, I think we were well over 20,000.

(John at 00:04:41) So constant fires, and we built all of the tools inside of that company, everything from recruiting to some of the task management updates that happened to knowledge management, to communication, and ultimately even Workplace, which was Facebook's enterprise offering, was something that I ultimately owned. So I've lived my whole life, my professional life at least, under these fires of rapidly growing organizations, at small engineering teams that are managing unusually large user bases. So I've got a lot of experience there. Zach does as well, primarily from the security standpoint. So he worked really deeply in the security team at Facebook and then ultimately managed mobile application security at Uber.

(John at 00:05:17) So another sort of hyperscale world of everything on fire as you're growing really quickly. Then Cole as well also did a lot of internal tooling work at that company and then within different teams that were just dealing with these outages and fires. I think these are the companies that were really at the forefront at the time, like 2011, 2012. It was really Facebook, Google, Netflix practicing these types of blameless modern incident management that has really taken the rest of the industry a little bit more by storm over the last few years. So we've just got a lot of history. I think it's a short history in the tech world for major modern incident management, despite the fact that it's got about an 80-year history outside of tech.

(Joel Beasley at 00:06:02) What company was acquired by Facebook? What was that about?

(John at 00:06:05) So it's a company you've probably never heard of. Its formal name was Caffeinated Mind. Originally, we were doing what I call kind of AirDrop before AirDrop. So we were doing peer-to-peer transfer in the browser before that was a common thing. We were actually using Adobe technology, RTMFP technology, and we were at the time moving over towards enterprise high-speed transport, mostly for the media industry.

(John at 00:06:28) That company lasted 18 months before the acquisition. So very rapid arc through Y Combinator and bootstrapped and shoestring budgets, all of a sudden being pulled into what I'd call a much larger rocket ship.

(Joel Beasley at 00:06:41) Did they buy you for the tech solving the specific problem they had, or did they just like the people? Why did they buy you?

(John at 00:06:47) So they mostly bought us for the people. Facebook was really building all of its own tooling out and was trying to think more about how can it build product-oriented tooling internally. So it had an existing team inside, I think it was called XTools at the time, and it was transitioning from that into a newer name, kind of Information Tools. And within that team, our goal was really, can we build organizations out of our tools? So we would build a recruiting tool and build then a people tools organization inside of that. We'd build a chat and collaboration tool and then build the Workplace team inside of that.

(John at 00:07:15) So it was a really unique approach to building tools within the organization where we really got to maintain that feeling of being founders throughout our time there. It didn't feel like being sucked into another team. It felt like just being given a much larger budget to execute tools. I think we had a unique perspective just from building enterprise tools at a time when they weren't particularly sexy and just having a lot of passion for that space.

(Joel Beasley at 00:07:41) Workplace. Everybody knows Workplace now. Facebook really pushed that hard and you got to be responsible for that?

(John at 00:07:49) Yeah. So that was originally a two-person project based out in Menlo Park. And it was originally really deep inside of the Facebook product. It was part of the Groups product originally. Then we spun it out and started a team out in London that we grew really quickly.

(John at 00:08:06) Lars Rasmussen, the creator of Google Maps, was actually the engineering lead on that project in the early days. And yeah, it was just sort of a fascinating founder-like stab into the enterprise space for a traditionally consumer company. It's now quite large. I don't know the numbers at this point, but by the time I left and came back to the US from London, it was growing pretty profitably.

(Joel Beasley at 00:08:29) And so at what point were you thinking, I need to go start Kintaba?

(John at 00:08:36) We really always felt like founders at Facebook, I think I said before, and I don't think we ever really dropped that feeling. And so once I kind of finished getting Workplace up and off the ground and had returned to the US, I was living in New York and working on a new team out here, and I just felt right. I was talking to Zach, I remember, one night on Messenger and just saying, I think maybe it's time. Maybe it's time to go and do something new. We met Cole over this period who's the third co-founder in Kintaba, and he was also itching for something new to do.

(John at 00:09:10) It just felt like the right timing. It felt like a good time to go and build tools again, and it felt like a good time to go and attack a new user base outside of the Facebook family that we've gotten to know really well.

(Joel Beasley at 00:09:21) And so how did you do your research for exactly what product you would build, where your market is? How did you do the market validation, market pressure test?

(John at 00:09:30) So we're pretty practical people. We went out and just hung out with all of our friends who had left Facebook and gone to other major value organizations like Stripe and Pinterest and Very Good Security, et cetera, and just walked tools with them really that they were familiar with from their time working at major tech companies like the Facebooks and Googles of the world. And so what do you miss? What can't you get off the shelf anymore? And the tool that kept coming up was a tool inside of Facebook that was called Sev Manager, which was responsible separately from the alert management system for dealing with these major black swan events, right?

(John at 00:10:06) The site is down. Things are going horribly wrong. Things are falling over. Domino effect. We've got a sandstorm that just took out an entire data center.

(John at 00:10:15) It turned out that companies really at any scale, we talked to friends who were starting their own companies and were at eight or nine people, everyone is dealing with these fires day to day, these unexpected black swan major outages that require people to respond to them. You need a tool at that point and you need a process for how are you going to deal with the unexpected. It just kept coming up over and over and over again until the point where we said, well, we should just build this. We should really go and build this tool, because our expectation coming into it was that certainly there's already something off the shelf that does this, right? Surely, people are solving this problem with PagerDuty or they're solving this problem with an Atlassian project or product.

(John at 00:10:57) That just didn't turn out to be true. We weren't finding that the way that those tools were presented was approaching the incident really from that first-class citizen standpoint, where you're really looking at an incident down and you're looking at it from symptom and amorphous initial report and sort of distilling downwards into solution and then reflection for knowledge gathering inside the organization. So there just didn't seem to be a tool out there for it that we could find. Whenever that's the case as a tools builder, that's kind of the best moment to go and say, okay, great. Let's go build this for ourselves.

(Joel Beasley at 00:11:33) And then you put it in the hands of your friends and let them try it out and give you feedback or?

(John at 00:11:38) Yeah. Yeah. So we had a lot of early beta testers in the product. We're very iterative builders. So we started with something that was as simple as a dashboard, right?

(John at 00:11:47) What does it mean to have a different dashboard inside of your company that makes public all of these major outages, which is a big difference between most internal IT and SRE tooling where these dashboards are available to the IT SRE and maybe some of the engineering team. In major incident management, you need those dashboards available to everyone in the company because the definition of these things are that they're affecting everyone. They're company-critical. So we really started there. We started just with the idea of how do you get this dashboard up.

(John at 00:12:14) And then we propagated forward from that to, great. So now where do you collaborate to solve these problems? Is that happening in Slack? Is that happening inside of Kintaba? What does that incident command center look like where your primary job is organizing the people who are responding to this major incident more than it is kicking off scripts or otherwise? You're really working with humans and managing context and what do they know and how are we progressing and are we getting closer and closer to closure?

(John at 00:12:34) And then finally, it ended up being the postmortem piece, which is how do you go and record the knowledge from this major incident and what really happened? How do you take the responders and give them a platform on top of which to propagate out information about how do we make sure this never happens again and how do we spread that throughout the company? So it's really those three things that we kind of grew during the initial beta testing phase. And then we launched it back in February of last year. So it's been just about a year that it's been live.

(Joel Beasley at 00:13:09) And you're growing. You've got customers. How's that going?

(John at 00:13:13) Yeah. It's going really well. Our initial approach to this was supposed to be go find one or two companies that were willing to work with us once we were live and sort of maybe give them the product for free, give them huge discounts, iterate quietly for a couple of years and then watch it again. Instead, what happened is we had this flood of inbound companies wanting to try and use the product straight out of the gate. They were companies of pretty varied type, right?

(John at 00:13:43) We have small 30-, 40-person companies like Vercel, which was called Zeit at the time, which are very developer-driven organizations. And then we had much later-stage unicorn organizations like Gusto, right, which is like 1,300-plus people.

(Joel Beasley at 00:13:56) I love Gusto. I use Gusto. I got to talk to their founder. I love them. Great company.

(John at 00:14:03) They're fantastic. Best thing about them is when you go visit, if it's not the pandemic, you get free socks because they're a shoe-free office. So it's one of the best pieces of swag I think you can get when visiting an office.

(Joel Beasley at 00:14:14) I'm sending an email after this podcast. I want some Gusto socks. I love socks. Yeah. Sorry.

(Joel Beasley at 00:14:19) We're off topic. Kintaba is way cooler. I keep forgetting the word. What is it? What's the Japanese word?

(Joel Beasley at 00:14:27) Oh, Kintsugi. Kintsugi. But I've heard that story, right? It's a great leadership one I hear a lot.

(Joel Beasley at 00:14:33) The other day, I was camping and I happened to hit an electrical box and damage my fender. And I tried to think to myself, maybe I just, like, fix it with some gold and, like, have a good story. And then I was like, no. I got to get it replaced because it just looks bad.

(John at 00:14:49) I think, I mean, there's this

(John at 00:14:51) Really interesting cultural change that's happening here, right? Which is there's a desire, even from customers I think, but really just the community of technical workers, to have more visibility into the outages and failures of other companies. I think we can see it on places like Hacker News. When there's an outage now with Cloudflare, the first thing people talk about is wanting to read the postmortem. They want to see what really happened.

(John at 00:15:16) They want to know why it went down because we're all sharing infrastructure these days. If Cloudflare went down, it could be something on AWS that I'm using as a founder, as a developer or otherwise. And so I immediately want to know, what happened? How did it happen? How did it affect me?

(John at 00:15:32) In a lot of ways, it sometimes eclipses the outage itself. Sometimes the reasoning behind the outage is more interesting. I think that's a really exciting change that's happening in the industry, right? From, "Oh, this company is terrible because they went down," to, "We generally think there's probably good people working there. It'd be great to understand why they went down so it doesn't happen for us." I think that's one of the core tenets of modern incident management that we have to embrace, and that is just starting to be embraced.

(John at 00:16:02) I think it's one of the reasons that products like Kintaba are becoming more popular.

(Joel Beasley at 00:16:06) Are people sharing? Your customers—this is an internal incident management tool typically. Are people sharing these things publicly, like on a status page?

(John at 00:16:14) Yeah, so we're working towards that. I mean, if you think about where this goes, you sort of have an order of operations. The first one is get companies to adopt healthy incident management practices, and then the natural follow-on to that becomes help them be more public about their incidents. We sort of had a run of startups like statuspage.io that helped us at least expose the basic incident itself, but I still think we're in the early stages of the piece after that, which is not just that the incident is happening—it's pretty hard to hide that—but the actual inner workings of why did it happen and how did it happen. What is the technology equivalent of the NTSB report for an airplane crash? I think one of the things we do really well in tech is we take these things that in the rest of industry look like huge binders, right, and really complex processes, and we boil them down and distill them into their atomic parts. I think that's really what modern incident management, what Kintaba is trying to do. It's trying to take what outside of tech is a pretty complex process of incident response management reflection and turn it into something that anyone can do, that you or I or a five-person team doesn't feel like is strange to go and do, which is write a postmortem.

(John at 00:17:27) Even if you're a six-person team, go write a postmortem. Even if it's two sentences, you're going to get value out of it internally. I think that progression is pretty exciting.

(Joel Beasley at 00:17:35) You mentioned earlier that it goes way back, like 80 years. Do you know the history of—do you know about all of that? Are you an expert in the incident response history?

(John at 00:17:45) I don't know if I'm a perfect expert, but I've certainly read the experts. There's folks out there like Sidney Dekker who write a lot about, especially in the airline industry, the progression from the old world, which was we just blame people. Every time something goes wrong, we say, "Well, Ed's an idiot. Fire him. That'll fix the problem." We progressed forward from that. The airline industry really led this because they were able to focus on an outcome that was worth spending a lot of time on, which is how do you keep people alive because you want to avoid these plane crashes. They made a couple of really important learnings early on, and it kind of breaks down into three, right? One is no matter what you do, you're going to have major incidents, so you need to have some sort of process in place for it.

(John at 00:18:33) You can't just go and say, "That was a mistake from person number one or person number two." We have to be prepared for it. We're not going to hire perfection, and we're not going to have perfect systems. Number two is that the people who are involved in these major black swan events are victims of the context and systems inside of which they're operating more than they are the cause of the situation itself. And then the third is that those people are also the most important account holders of context to help everyone else avoid that situation ever happening again.

(John at 00:19:08) These are sort of hard-fought learnings, right? It's actually against human nature. The very natural thing for us to do when things go wrong, because as outsiders, we have 20/20 visibility back into them, is to say, "Well, you should have known X and you didn't know X, and so you're fired and the next person will know X." The reality is X happened because the system we put in place as business owners put the person in the situation for that problem to occur. So airlines had to capture this, right, in terms of how do we capture more often and earlier the smaller incidents such that we avoid the big ones?

(John at 00:19:43) And so you actually want—it leads you to a realization that you actually want more incidents as an organization to avoid the big ones, right? When you have SEV levels, you have a SEV 1, which is major catastrophic outage, right? You have SEV 2, which is not quite catastrophic, but major outage, and you have SEV 3, which is we caught this early enough and people probably didn't notice. It turns out what you really want within an organization is to maximize your SEV 2s and SEV 3s such that your SEV 1s decrease. And if you put that in the context of an airline industry, it makes a lot of sense, right?

(John at 00:20:13) You want to maximize your reports of problems on my dashboard, problems with my stick, problems during the flight, to avoid airplane went into the ground. I think that's kind of the learning that was able to come out of that industry out of necessity, and it really propagated from there outwards and sort of worked its way through additional kind of human factors knowledge until we got to this point today, which is we have to absorb that into every company, not just life-critical organizations. I think the story is Google got most of its incident response processes from the Mountain View Fire Department, where they actually absorbed that, and they got that probably from FEMA-style training, and they got that from the DOD, and the DOD learned a lot of that from the NTSB. And it's really fascinating when you take this stuff backwards academically because we're the recipients of all that learning much more than we are the inventors.

(Joel Beasley at 00:21:01) Dude, that's a lot to think about.

(John at 00:21:04) Yeah, it's a really cool history. And I think companies like Stripe—I think their internal tool for this is called the Big Red Button. And they call it that because it's based off of the factory floor, right? Which is the idea that if something's going wrong, anyone can hit that big red button.

(John at 00:21:21) And one of the big tenets of modern incident management and of Kintaba is this idea that anyone within the organization should be able to go and declare an incident because we trust our people to be able to go do that. It's not a higher-up decision. It's not something that you go and clear. It's a big red button sitting on the factory floor that if you feel like needs to be pushed, you should go and push that button.

(Joel Beasley at 00:21:44) Push the button. For sure. That should—you can do a marketing campaign around that. That's basically you're just saying use the product.

(John at 00:21:53) Yeah. I think we really get this benefit now of looking back and it seems almost obvious when you talk about it this way. It's like, of course, anyone should be able to file an incident. But we talk to a lot of companies that are just getting into this space, and I think culturally, they're working towards that. But you're really starting with a world where this lives inside of one part of the organization.

(John at 00:22:14) Maybe you have an SRE team and they're responsible for filing incidents. Really, the practice you want is you want anyone in the product organization, anyone in the eng organization. Really, you probably want folks in your sales organization and otherwise to be able to file these incidents. What's important is that your management system does a good job of helping you categorize and control who gets impacted, contacted, and brought in as your response team. That's what a tool starts to do, right?

(John at 00:22:41) So when you think about where does Kintaba fall in this massive learnings from the last 80 years, it's really just about putting into practice all of these learnings. How do we make that dashboard accessible to everyone? How do we do a good job of finding the right people who need to respond? How do we bucket these things effectively? How do we propagate the information out to the rest of the company as the incident's progressing?

(John at 00:23:05) All of those are sort of the practical implications of what should a tool do to give your company the benefit of this, you know, almost century of learning.

(Joel Beasley at 00:23:14) And so how are you going to market? Are you doing, like, can—are you letting people try it free? Are you doing B2B sales teams?

(John at 00:23:23) So we're one of the only products out there right now in this space, especially in the startup space, that is fully self-service accessible. Any company of any size can come in, sign up on the site. You don't have to talk to our sales guys. If you want to, you can, but you don't have to. You can click a button and we're even free if you're small.

(John at 00:23:39) So if you're a five-person team, the product doesn't cost anything. So if you're really small and you're just getting into incident response and management, there's no cost associated with it. And we'll continue to do that forever. I mean, that's a requirement, I think, for getting a product like this off the ground—is understand how to help accessibility into it to all organizations. Because if you look at other competitors in the space, whose names I won't list here, you'll always be faced with the "contact our sales team" button, and you'll go through a multi-month effort of conversations and talking and then eventually being sold this impossibly expensive product that you would only adopt if you were an organization with over a million ARR.

(John at 00:24:19) And that's just silly.

(Joel Beasley at 00:24:21) Yeah. Especially because it's something that's that widely applicable. Everybody that has a product running in production has to deal with incident response.

(John at 00:24:30) That's right. That's right. It's every single company. I mean, every company is on fire. And you don't even have to be a technology company.

(John at 00:24:37) Right? Like, every sales team is on fire. Every customer success support team is on fire. Right? Incidents, as long as they're categorized down to the organization inside of them, your response practices aren't actually that different between your engineering team and a non-engineering team.

(John at 00:24:54) You can have a PR incident and your process is still the same. It's declaration. It's bringing that team together. It's tracking the progress. And then it's writing up your reflection in your postmortem and distributing it to the relevant people.

(John at 00:25:05) Like, that's the same thing if you're a PR team as it is if you're an engineering team.

(Joel Beasley at 00:25:10) Yeah. I would say that the engineering teams are more used to this, though.

(John at 00:25:16) Yeah. I mean, if you look at our customers, certainly. If you look at where does this land easiest, you know, like, who's the part of technology organizations that are adopting modern incident management? Yeah.

(John at 00:25:28) A hundred percent. It's the engineering organizations. And that's really thanks to the propagation of it out of the bigger companies. Right? People are leaving companies like Facebook and Google, and they're joining other startups, and they're joining smaller companies, and they're expecting these tools to be there when they show up.

(Joel Beasley at 00:25:44) That's true. That's true. Now I'm curious to know. So you have this idea. You do the beta.

(Joel Beasley at 00:25:49) You put it out there. You get some people. You're in a really unique position because your users are—how do I say this? They're at the highest stress point possible. So typically, you know, you build a leadership software.

(Joel Beasley at 00:26:01) People aren't extremely stressed out when using the product. Right? So you've got a situation here where people are—their emotions are riding high, things aren't good, money's being lost, and they're having to use your software. What is something that you learned that was maybe, like, counterintuitive about that experience?

(John at 00:26:26) So I think when we first started building Kintaba out, we had a very sort of responsive tools mindset to the product, which was, this is really all about getting out of your way as much as possible. Right? And we still do actually advertise a lot towards that. Right? Like, take over the management side of incident management.

(John at 00:26:47) But that was really the core focus of the user experience was how does the product back off and let you interact with the command center, interact with Slack, et cetera. Some of the unexpected feedback we got back from early customers was that they actually wanted the product to be a little bit more human when they were interacting with it because they were under this higher level of stress. You know, we got some feedback from one customer that whenever they were interacting with the Kintaba bot inside of Slack, they were actually talking to it. They were actually responding, you know, and adding the bot and putting emojis on the bot because that was the non-human in the room that they could direct, right, their emotions to during these high-stress moments. And so the learning for us there really was that Kintaba has to not only be the tool—your incident response process can't just be the tool, it also has to be a bit of a participant in the response process from an almost emotional leadership standpoint.

(John at 00:27:44) The attitude that your tool takes on is the attitude that the response team will start to absorb. So when it's high-stress, like you described, when you're dealing with losing money, when you're dealing with servers being down, you've got to walk that line just perfectly in terms of how the tool speaks whenever it comes in and makes a comment. You can't be flippant, but you have to be positive. That's a tough line to walk. And so I think the learning there for us has really been, you know, you're creating—when you create an incident response tool, you're actually creating one of the responders. And you get an opportunity there to shape, you know, how everyone else acts because they're expecting the tool to be the best practice.

(John at 00:28:22) And so you need to be—at the end of the day, you're almost the incident response leader when you're the tool, just like you would be if you had, you know, an incident commander inside of the company that was trying to propagate this culture. And I thought that was pretty cool. I think a lot of the time when I think about tooling in the past, we really try to think about that tooling as invisible. And I think in this case, because it's so human, because it's so emotionally charged, there's much more opportunity for the product to help impact culture from an emotional and sort of voice standpoint, as well as there is from a core functionality standpoint.

(Joel Beasley at 00:28:57) Do you know that there are consultants that go run these mock explosions essentially? Like, they'll get everybody into a conference room and say, "Okay, our server went down." They'll run an incident response exercise. This is happening a lot. Do you know about this?

(John at 00:29:12) Yeah. I think a lot of that's built out of kind of the older world almost of disaster recovery, right, where you would run these types of drills. Not to say that it's an outdated process, but, yeah, I think that is something that's happening. I think the challenge with a lot of that is when you're building out those processes and pulling a lot of people into a room and saying, "Okay, we're going to do it now and here," you sometimes end up localizing that information to the group who's able to attend. And what you really want to do is propagate out those practices in a tool.

(John at 00:29:45) So there's sort of a saying, right, which is if you want to implement a process, you should implement a tool. And I think that's kind of the evolution of that action is really the tool. It needs to be able to both teach you live what you should be doing from a process step-by-step standpoint, as well as it does need to be able to permit you to prepare.

(Joel Beasley at 00:30:02) Yeah, but I'm saying you should talk to these companies that are doing this across the United States and have them do it with your tool, because they're not selling tools though. They just sell the consulting of that day exercise. So if you can connect with them, this is their entire business model and they're doing this every single day with companies all across the United States, at least. Then they could be using your tool, especially since you've got a free version, and then you can get a bunch of customers and you've got people teaching on your tool.

(John at 00:30:33) I'm writing this down as you say. No, definitely. I think it makes a lot of sense. And I think there's probably more opportunity for collaboration inside of this space across all of the, what you might call the practitioners and the tools builders, than has really historically been done. You end up with a lot of silos of practice, which is, okay, we're going to do this with your consultant from mega corporate, ServiceNow, or otherwise that's going to explain how to do it. But then, like you said, I think there's a very large number of independent consultancies and organizations out there practicing these things. And they're basically doing pen and paper incident response and teaching that way. So yeah, 100%.

(Joel Beasley at 00:31:17) Yeah, because people will use what they have until something better comes along. And I know a couple of them too. I can connect you. I'm gonna ask around. We have this group called Elevate Role. It's tech leaders come together. There's about like 220 of us, but we split into small groups of like four and five people, and we have a guest speaker every week. And so I've gotten to know the different members of the group, and I know a couple people who have smaller consultancies, maybe like 10, 20 people. But this incident response stuff is exercises that they run with the executive teams of companies. And so, you know, they're teaching them how to do it with their tool, like their New Relic alerts go off or whatever. Okay, this is happening and this is how we respond. But if you could just handle this tool or just be like, hey, do you guys know Kintaba exists? And then, how are you teaching people? Do you have resources on the website? Is it strictly embedded in the flow? Like, if I want—let's put some context here. Let's say there's 20 people in my engineering department, right? And I'm like, this sounds like what we need. And so I go on there, I sign up, and then I need to learn how to actually manage the incident. How does that happen? How do I learn that?

(John at 00:32:40) So we work pretty hard not to make you go through a learning experience. You know, we don't send you over to a set of docs that you have to go read and kind of become culturally aligned to. As it's built, the product is meant to feel like a series of steps that you go through naturally. So you'll sign up, you'll immediately get a couple of integrations you ought to do to go make it work best for your business naturally. You'd plug it into things like Slack if that's what you're using for communication. But really, what we're trying to push you towards is get that first incident filed. And as soon as you start there, as soon as you click that incident button, everything else can be done live while the incident is happening. So the fields you need to fill out are predefined. We don't make you go through and pre-configure every single field that needs to be done. We know the best practice. We know how much of a description needs to be put in. We know how much of a title. We know that you should just be able to go and create tags and get these things categorized quickly. And then once it's created, everything inside of the command center is designed to let you real-time go and start to build, even if you didn't understand or even if you didn't pre-configure the product. So you can start to define who your responders are, get them pulled in. We'll send emails out, we'll link them back. We broadcast incident announcements into Slack so people discover it. Your process as you move forward can be driven both by you as a responder as well as by—we have an automation system that can go and do things like comment into the incident response channel to help people know what to do next. But really, we're only trying at the top level as a new user to get you to go through the flow at least once so you can feel that value. And that flow is really just declare the incident at all, which is a pretty big barrier for a lot of organizations. Just define it, make sure people know it exists, record and log the responders who are supposed to come in, get them involved, let them know what's happening and record that collaboration so it's not lost six months later by the Slack channel that you delete. And then once complete, stay on the original responders from a comm standpoint through email and otherwise to make sure that they actually go and write that postmortem and then auto-distribute it. So we're really putting you through an obvious-feeling flow, but then taking on roles as a product to make sure that after you have one incident, two incidents, three incidents, your process gets better and better over time. And the people who are aware of the tool and operating inside of it use it. I hate to use the word viral, but the goal of the product is to be naturally viral. You shouldn't have to internally go and advocate other people to adopt it. Incidents are sort of like train crashes. Everyone wants to look at them. So you naturally get this attraction into the product of people inside the organization who care. And so you sort of naturally start to build up this group of individuals using the product, and it spreads really nicely.

(Joel Beasley at 00:35:25) So how do you teach your people what an incident is? Like, if you open this—I get it, if you have the engineering team and maybe there's a common vernacular, you all understand what you classify on a scale of severity or however you're scaling it. But like, let's say you're opening this up to the entire company now and you've got, you know, Jill in support. How do you train them on the big red button?

(John at 00:35:55) So we default to a lot of simplicity when it comes to the parameters that you might put into an incident, which helps a lot here. We really start with three sub-levels. And when you're creating an incident, we're descriptive of what those are, you know, what degree of impact defines each one. We're also—none of this information is permanent. So the whole idea behind an incident, right, is that it changes over time. So you can be wrong. You can actually create your incident, you can misfile it, you can put the wrong tag on it or otherwise. But the critical thing that we do is we always bring in an incident—we call it an IMOC, an Incident Manager On Call. And generally, initially, it's the person who first signed up for Kintaba, but it's defined as a rotation. This person is brought into every incident within the organization. They're there to sort of be the context holders and the orchestrator for how is this supposed to work. So if the random person from marketing comes in and joins the product six months in and files their first incident, you're going to have an IMOC involved in that incident as well who can help do things like recategorize, redefine, and move it forward. But these things are different per organization. We don't really intend to come in and say, here's exactly what a SEV 1, 2, 3 is in your company. You'll figure that out as you continue to file and as you continue to create these things. There's not even a really strong, perfect best practice of what is the line. We have huge companies that file three to four incidents a week, and we have tiny companies that file 10 to 20. Depending on how you're operating, that's okay, as long as your team is responding effectively and going through the flow. Thousands of internal factors affect whether or not you have more or fewer incidents. But we'll generally push you towards lower barrier. We'll generally say the more incidents you file, the better, because the process should be lightweight enough that it's not a disruptive process.

(Joel Beasley at 00:37:43) How do you get them to file their first incident when they're signing up? They usually aren't having an emergency.

(John at 00:37:48) Yep. So this is the million-dollar question, right, into how do you get adoption of these kinds of SaaS tools. Our goal initially is to integrate with the other tools you're already familiar with, right? Get into Slack. We connect into Jira, et cetera, in ways that you will think of us next time there's a major incident. We also put you through a sort of new user experience the first time you come in where you get to practice creating an incident alone so you can be a little bit more comfortable with what the tool is going to do for you as you move forward. But it's really, you know, at that point inside of a company, it's really a sort of trust question after you've adopted the product. Will I remember it? Will I trust it to be better than just going and firing off a Slack channel on my own? And that's really just an effort around tool crafting. That's about keeping the product feeling safe, easy to use, accessible in such a way that you feel comfortable going in there and filing, and then deleting if it's the wrong—if you were just trying something out, you can go mark those incidents invalid and get rid of them. You're not trapped in sort of a permanent world of your test incidents.

(Joel Beasley at 00:38:52) How do you get feedback from the customers? Are you just on calls with them all the time? Is there a feedback system?

(John at 00:38:58) We've got a lot of Slack channels with a lot of our customers. You know, we're pretty early stage. We still rely on a lot of manual outreach, discussion. We are certainly analytics-driven in terms of what people are using inside of the product, for what's working well. But being such a kind of cultural change for organizations to adopt, it's a lot of just direct conversations about where are you finding a lot of value here versus where is it getting in your way? This is sort of the primary thing we care about. Where does it feel like it's making your business better every day versus where do you feel like it's just kind of an annoying additional tool that you've got to go reach out to? I think in this era we're in of a new SaaS product every week, you have that risk of just being another thing that you've got to go and open up and interact with. So we get a lot of our information from direct human contact, a lot of outreach, a lot of phone calls, a lot of Slack conversations. We try to turn around feature requests faster than anyone else. And in doing that, we tend to get a lot of kind of immediate feedback on why are you doing this? Why would you want to change that? What is this giving to you that it might give to someone else? And so, yeah. So I believe pretty strongly in just kind of continually talking to users. I think that's sort of the standard here, you know, versus just looking at globs of data and saying, well, we need to go and virally pull more people into screen. Why? I think that's not really our job. Right? Our job is to get out of your way. So we almost, in a lot of ways, want to see lower time spent, but higher sentiment.

(Joel Beasley at 00:40:31) How do you, as a leader of this thing, how do you structure the time that you're going to spend with your customers? This is just—I'm personally curious. Do you put blocks on, like, Tuesday and Thursday for three hours and say, okay, in these time blocks, I'm just gonna be going around, exploring, talking to customers, engaging with them? Or do you set a certain number of meetings a week? How do you guarantee in your schedule that you're spending time with customers?

(John at 00:40:59) So a lot of it is inbound interrupt-driven and just sort of being accepting of that. You know, you have to be willing to take feedback at the moments that it comes in. You can't often schedule it, especially if you're keeping open lines of communication with your customers. So that's probably 80% of it, honestly, is inbound feedback that we're rapidly responsive to so that we can better understand the kind of high-level problem. That's less about blocking time and more being accepting of the fact that you're going to be interrupted and it's a valuable use of your time. In terms of blocked time, that's more where we try to schedule kind of deep conversations with customers. And we don't do those as often, right? Those happen every month or two in terms of like, let's get on a call with the leaders inside of the organization, the torch holders who are really pushing incident response, and understand where the things we're doing are working and where they need to see more to be able to get the value out of the product. So it's a combination. But honestly, I think the interrupt-driven side of it is more important. I think being available at the moment of feedback is something that a lot of, especially startups, really struggle with because you're doing so many things. The natural thing to do is kind of to push it back and say, okay, we'll respond to these things later on. But if you kind of accept that priority as being one of the most important pieces of information you can gather, then it makes more sense to actually be willing to kind of close out as a leader the deep work that you're trying to engage with and context switch over into the opportunistic feedback. And I think Slack has sort of forced this on all of us, right? It's become the new notification that pops up where there's an expectation of rapid response. But I actually think that that's really healthy, right? That lets us iterate a lot faster. If you rewind the clock 10 years, SaaS businesses really struggled to get consistent feedback from their user bases. They had to go and schedule these time blocks and they had to convince you to get on a phone call, right? Or they had to get you into these big long email chains with bullet point, bullet point, bullet point, or fill out this form or fill out the survey. And I think we've progressed really nicely beyond that. I think the—you know, maybe it's the evolution of customer success, right—is customer success isn't really about being an email address anymore. It's about being everywhere and being able to kind of accept that inbound information wherever it happens.

(Joel Beasley at 00:43:14) No, I like that. And I haven't even gotten to explore Slack's new tools yet, but I saw an email a couple weeks ago that I can now message other people that are outside of the organization. Have you played around with this at all yet?

(John at 00:43:27) Yeah, we use that really heavily. That keeps us connected, you know, especially to sort of the early torch holders inside of these companies. The people who—you put your neck on the line, especially in a larger company when you bring in a startup SaaS. You're saying this is going to be better than maybe our established relationships. And so those types of relationships we keep open very closely, personal one-to-one. And we do use actually that Slack feature pretty heavily for it.

(Joel Beasley at 00:43:55) Tell me how it works. So I've never used it. I just saw the email about it. I have Slack, you have Slack. Let's say I want to talk to you. How does that—how do I do it? How does it express itself? Can me and you be in a channel together in my Slack? Like, how does this work?

(John at 00:44:10) Yeah, it's pretty similar to like shared channels if you use those, where there's sort of an outreach that goes out. And I think in most cases I've seen, it's been through email. There might be other channels you can use to do it.

(John at 00:44:21) And once that outreach is accepted, you basically get into a direct message experience where the company name is shown. I think because we tend to be working with people inside the engineering and IT organizations, there might be an approval step there that they're also following through on that I don't see. With shared channels, I know you have to go through an approval step from whoever the Slack administrator is. But for the direct messaging side of it, I'm not sure if that's as present or if it's a different setting. It hasn't proven to be a huge barrier.

(John at 00:44:50) Most of these actually elevate for us out of existing shared channels. So we'll tend to have a many-to-many relationship that then kind of escalates or propagates out into one-to-one conversations.

(Joel Beasley at 00:45:01) So tell me about your co-founders. Did you meet them all while working at Facebook? What's your relationship like with them?

(John at 00:45:08) Yeah. So Zach and I have actually known each other since high school back in Chapel Hill. We went to school together and were just hackers in the early days. We did all of the fun stuff that you do back in the early 2000s, even late '90s, when you could still do things like red boxes and play with pay phones and kind of early-stage hardware hacking. And he went off and went out to California, moved about halfway through high school, and went to school out there.

(John at 00:45:34) We really didn't reconnect for five or six years. I think he was working at Apple and I was working at Harvard at the time. And I'd reached out and said, "Look, I think we ought to go do a company together. I think we ought to start a company." And I flew out there and slept on his couch for a little while, and we did our interviews with Y Combinator.

(John at 00:45:53) And Zach, just being the guy he is, just quit his job at Apple one day into being accepted there. This was back when it was much harder from a monetary standpoint to get a startup off the ground. Y Combinator gave you $17,000, I think, at the time and told you good luck. And with that money, you went and rented an apartment in Mountain View. And you slept and ate and lived in that apartment and worked in that apartment and did everything you could to get up off of the ground.

(John at 00:46:18) So it was a big thing for him to leave an organization like Apple back then. And he's just always had the same sort of fire that I have in terms of let's just build things that people love and let's put things out there and let's iterate aggressively and let's do that on our own and take those risks. Cole, we met later. We met Cole at Facebook. Cole was sort of more of an up-and-coming, just really effective, diligent, thoughtful architect when it came to tooling from a standpoint of how do we build these things the right way in a world of sort of throw things against the wall and hope for the best.

(John at 00:46:51) I really appreciated that. It had a pretty profound impact on the tools that he touched there. He was actually a big part of the early building of Workplace as well. He built some of the early underpinnings and technical architecture there. And so everyone just worked really well together.

(John at 00:47:05) We're all friends. We hang out, pre-pandemic at least, in person and now digitally. I think that's important. I think in the early days—they probably still espouse this, right—but in Y Combinator, one of the biggest things they look for in founding teams is, you know, are you friends?

(John at 00:47:20) Because it turns out that's really what keeps founders together more than anything else, right? Like, product ideas change, efforts change, things work, things don't work. And it's really founders kind of falling out from each other that break companies the most often. And so it's really important to me to work with people who are my friends and people who I get along with day to day, not just people who I think are going to technically execute most effectively.

(John at 00:47:43) Despite the fact that I have Zach and Cole do, I think that where I put on the hierarchy of needs, I think I put friendship and capability there above everything else.

(Joel Beasley at 00:47:54) So what else do you do in your personal life other than build this empire?

(John at 00:47:58) I mean, pre-pandemic, in the good old days, a lot of outdoor cycling. I lived out here in New York and quickly learned the routes up and out of the city. There's really some beautiful cycling you can do out here up along the Hudson River, all the way up north to Garrison and Cold Spring. It's just incredible. Actually biking to and from work when it's not too cold here as well, over and across the Queensboro Bridge.

(John at 00:48:20) So I get to be a commuting warrior as well out there. But that's a good way to kind of just get things out. That's sort of my big one. Otherwise, I spend a lot of time as much as I can with my family. I've got a three-year-old, actually, who was born one month after we started this corporate entity that eventually became Kintaba.

(John at 00:48:41) So I felt like they've grown up next to each other. The company has grown up next to my son, which has been pretty fascinating. I always had the theory: if you're going to be a founder and you're going to have a kid, you need to figure it out from day one, or else you're never going to be able to go and switch into it. So that's really it.

(John at 00:48:55) It's the company. It's some physical stuff when I can get it in. But, you know, luckily with working with your friends, you get a lot of that social value from day-to-day work that you'd otherwise kind of have to go, you know, out to bars or otherwise to go and satisfy.

(Joel Beasley at 00:49:11) My daughter is almost four, and I started this whole journey a month after she was born. So she was born in September. I started it like at the end of October. And I was looking at my life and I was just like, here we go. I mean, all this big change is happening.

(Joel Beasley at 00:49:29) It's about as scary as it could possibly get. And I'm okay with that. And if you're not, you probably shouldn't be founding a company.

(John at 00:49:37) I had this theory that there's the maximum amount of stress and pain that any individual can feel. And if you're going to max it out anyway with a child, you might as well max it out with the startup as well. Turns out I was completely wrong about where that threshold is. I thought it was back here. It turns out it's a lot higher up.

(John at 00:49:55) But yeah, I think there's a lot of us out there. There's a lot of founders who are also parents who are learning how to do both, how to raise companies and raise children. I think we rely on our partners a lot for that, as well as we just rely on learning from each other. Actually, I would prefer if there were more social groups for parents who are founders to go and kind of share strategies, because I think that's a lot of emerging knowledge: what do you do when you have a three-year-old?

(Joel Beasley at 00:50:27) Yeah. Like, you can go to the group, but you can bring someone there to, like, do like how church would be where you can drop the kids off and then go in. You know?

(John at 00:50:34) That's right. Yeah. Like, who, where, where do we spend time these days? Like, especially digitally, where do we spend time? I think, you know, it's more and more it's on Zoom, and it's more and more in Slack channels, and it's maybe in games.

(John at 00:50:46) I think more and more often, like, we do a game day once a week inside of the company. That's really helpful just from a social standpoint where we play video games and connect on Zoom. And it's a really effective way to just talk about things that aren't the company. And we have a couple of other parents in the company as well. So it's helpful for me, I think, from a sort of life management standpoint.

(Joel Beasley at 00:51:05) I like your concept of max pain because I use that phrase, max pain. People ask me how difficult things are, and I was like, alright. So you're going to have max pain duration. It's like, you're going to scale up to max pain, and then you're going to be there for this amount of time, and then you're going to come back, you're going to recharge, and then you're going to go right back there. And Elon Musk says, staring into the abyss and eating glass. I think that's a fantastic—it sets the expectation. And then when you actually do it, it just means something on a whole other level. You're like, oh, wow.

(John at 00:51:38) I think it also helps us empathize with our companies, right? The companies that we're working with, we're in the incident response business. We're in the world of people going through pain. And I think one of the most effective things you can have when you're dealing with a major incident is to have someone else in the room who's gone through a lot of pain.

(John at 00:51:54) We've talked a lot about the pandemic as it relates to major incidents. And the one thing that it's done for us is now we've all gone through a major incident together. All of humanity has gone through a major incident. And it has this positive effect on the outside, right, beyond once you're past it, which is now we all have this shared experience and we all have something that we can empathize with each other over. And the next time something goes badly, whether it's within a smaller group or on the same scale, I think we can all approach it a little bit with less emotion and more compassion for each other.

(John at 00:52:30) And I think that's one of the things that incident management really tries to push, right? It's this idea that incidents aren't strange. It's not unusual. We're going to go through these as a company, and they're going to happen all the time. And we learn as we file more of these things, as we have more of these things, how to approach them from a standpoint that isn't aggressive and mean-hearted.

(John at 00:52:50) How do we approach these things kindly? And I think that that's really the advantage of practicing it. And I think, you know, it's the one maybe silver lining to what's happening with the pandemic is we're all hopefully gathering a little bit more compassion for each other and understanding how hard things can be when things go really wrong. And I think that there's a nice translation there culturally into incident response for companies as there has been for this pandemic.

(Joel Beasley at 00:53:22) So alright. Call to action. People want to try Kintaba. They want to experience it for themselves. How do they do that?

(John at 00:53:29) Yeah. So the product is free to sign up. Easy to sign up. It takes a few minutes. It's kintaba.com, kintaba.com. There's a link right there to sign up.

(John at 00:53:39) If you want a deeper dive into it, there's another link there for a demo where we'll hop on the call with you and get super deep into how it might integrate more directly with your specific stack and your team. But yeah, the idea there is it's minutes to get up and running and you should be able to file an incident within five.

(Joel Beasley at 00:53:57) Thank you so much for listening. And if you found this episode useful, please share it with a friend or a colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email: [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.