 I want to page when automation fails or I want to page with context the beauty of something like Transposit is, not only are we going to page you, which is the bare minimum of all paging services to contact you, we're going to give you context. So when you're coming into that incident or to that alert, if you've written a script or a workflow that says go check something, pull this Grafana dashboard, pull this DataDog dashboard, you're going to come into that with that information right in front of you. Such an opportunity to not start from zero. This is your host, Sapil Bhartiya, and welcome to another episode of our Let's Talk. And today we have with us Brian Taylor, VP of Customer Success and Solutions Engineering at Transposit. Ryan, it's great to have you on the show. Thank you, Swa. Appreciate it. Very nice to meet you as well. It's my pleasure to host you today. Primarily, we were going to talk about you folks made an announcement this week on call capabilities. But before we go specifically into that announcement, since this is the first time you and I are talking on camera, I would love to know a bit about the company, what you folks do. I do know that you folks, you know, work in the incident management, but that's a broad space you've do leverage a lot of AI and automation. So let's talk about Transposit. We are an incident management platform, but primarily focused on the automation of getting started. And I'll say this, I mean, that the differentiator for something like Transposit is we don't just handle the getting started piece, which I think you see a lot in the industry, you know, starting a Slack channel or creating a Jira ticket. I think what we really want to do is we want to take you from that signal, being the alert to resolution and ultimately with hundreds of integrations, that's possible. Perfect. Thank you. Now, let's also talk a bit about incident management. If you look at the overall kind of health of a system or state of the system, or when something goes wrong, we can talk about all the way in early days about monitoring, log tracing. And now we talk about observability, but talk a bit about where does incident management fit there. And also, as you also talked about ticket, you know, of course, there is a lot of fatigue over no false flags and people keep getting notifications and alerts. A lot of time goes wasted in that. So I want to first of all talk about incident management, and then how transport makes it easier for, you know, of course, DevOps teams to kind of not get overwhelmed with all the alerts and notifications. I love this question. The one thing I'll say about me is pretty passionate about certain parts of this. So great question, and I appreciate you asking it. But one of the things that I really love is the concept of automation in a way that prevents that fatigue. A, if I take the first step to get contextual information and potentially take a resolution step before I get started with something, I don't need to be paged. It's the beauty of that system. I can imagine a world where X goes wrong and Y is the first step that any on-call engineer is ever going to take and step Y could be done by anybody in the company with an automation platform that handles that authentication. That on-call presence is only required when that fails. And I really like the idea of that. You know, in my life, in my previous life, it's what I strived for. It's like, how many times do I page someone just for them to be able to do something that I could have done automatically or with automation? And so I like the idea of thinking alert, signal, service. What is the outcome of that? Or what is the thing that I can impact before I'm required to join that ongoing incident or that alert resolution? So it's technically why we're bringing on-call into our solution. If you are, we want to page you when automation fails, right? And if it's not automation failing, it's bringing that context, bring context to the thing I'm being paged for. If I'm going to do steps one through five, do step one through five for me. So I like that. Talk about the evolution that you have seen of incident management where you do know before the whole DevOps, DevSecOps, SREs that from these movements happened, these were the problem areas either for a specific team. But now do you see the incident management in more of a cultural thing where it's part of the kind of whole team where you look at not it, where you don't look at it as a tool, as a kind of solution, but also a culture shift also where the whole teams look at something is going wrong or something might go wrong. How do we respond to that? And also it's not just about what went wrong, what lessons we can learn, but that's where tool comes to help them. But this is a culture movement as well. That's what I want to talk to you. We've moved from that observant report type of mechanism where you had a dedicated team that was watching something turned from green to red. And they were either taking action on that or they were expected to understand hundreds of tools or services. And I don't think it's not a stretch to say that that wasn't complicated in the first place. There's no one in a business that knows more about a service that's being operated than the people building that service. So it only made sense to move the problem closer to the people that could impact the resolution. And I think we've seen that as part of DevOps. And I personally believe that that is... I'm not a huge fan of the saying make the engineers or the developers feel the pain. I feel like I am advocating on behalf of the customer to say the customer shouldn't feel the pain. I do believe that there is a deeper ownership for the engineering team as it relates to the services that they provide, both to internal customers and external customers. And I think that's been the primary shift is time equals money and customers pay for downtime. Our customers pay for uptime and companies pay for downtime. And so downtime is preferable to be minimized. Right. No, very well said. And sometimes we do tend to forget that no matter what we do, we are serving the customers. And the interesting thing is that customer, they are on their own journey as things are changing transform. We have to be on the same journey. We also continue to evolve with them. And as before, like off camera talking about the company itself, the way it started with a different focus. And then it also evolved over time. That's what we are all doing. Which brings me to the next question, which is about your latest announcement, this which also kind of shows the evolution of the company itself. So talk about what you folks announced this week and what problem does that solve? We've announced transposite on call. And the primary reason we're bringing this into the platform is we are an alert management or event management platform. So we allow some some basic alert management. But those alerts can lead to incidents. And if you're going to create an incident workflow that starts with something and ends with something else, there's probably a piece of that workflow that says escalate to an additional resource, whether that's a person or a team or a service owner, we want you to be able to include those in your workflows. We want you to be able to think about that ahead of time and say when X happens, page Y, we really want to tie those things together. So and again, going back to what you know, you and I have talked about previously, I want to page when automation fails, or I want to page with context, the beauty of something like transposite is not only are we going to page you, which is the bare minimum of all paging services to contact you, we're going to give you context. So when you're coming into that incident or to that alert, if you've written a script or a workflow that says go check something, pull this Grafana dashboard, pull this data dashboard, you're going to come into that with that information right in front of you. Such an opportunity to not start from zero. It is starting at resolution or at least resolution discovery. And to me, that's a game changer. I've been on call for 20 years. I've never had that luxury. As we're talking about this kind of crowded space, talking a bit about what, of course, you did touch upon some key point, but I would like to go up with specifically when it comes to the incident management lifecycle, the whole when we look at the solutions, integration, evolution. How do you set yourself apart from others? What edge you have over some of your competitors? And I would love if you can name some competitors as well. Ultimately, I think the differentiator for us, again, look at the incident landscape, look at something like incident.io or brutally. Those tools are fantastic at getting started. They are great at that. Getting started is the minimal requirement for excellent incident response. That is my take on that. I want to empower our users specifically to be able to declare an incident, investigate an incident, escalate an incident, communicate throughout an incident. And here's the goal of running an incident response process, remediate or mitigate that incident. You want to get to a point where the pain is not felt by your customer. And again, I want to be clear on who the customer is here. There are internal customers and there are external customers. There are plenty of services running in a microservice architecture that are meant to serve other services that have external customers. So it's all connected and we really want to get you from not just starting that incident, but taking those steps in between that can get you to clear understanding of the problem and next steps to take and eventually remediation or mitigation. And I think that's what separates us, right? When we launch, and again, we even look at integrations differently. We have hundreds of integrations, but in the event that you want access to a tool, as long as it is an API that has some off, we can build that for you. And I think that's a differentiator for us, because if you were to launch transpositing your organization today, you have access to 100 different integrations and not all of them are ticketing or on call management. Those are going to be AWS name the game out of their entire service catalog. That's going to be GCP their entire service catalog. So it's, you know, pretty in depth in what we can do to fill the gap between starting and finishing. Now, let's talk about AI. When we look at AI, you folks have been leveraging AI for a long time. But now we have started talking about generative AI, Gen AI, chat GPT is a big buzzword these days. Talk a bit about how do you folks leverage AI and not just, you know, the, it's funny to use the word legacy or traditional AI, but also, you know, a generative as well. I really do appreciate the fact that when I got the transpose that we had an AI strategy already. And so what I like is that when others were announcing, I know we have AI capability, we already had it. And so we've, we've done a couple of things. Throughout the incident process, if you are running an incident in transposite, you know, we're friendly with Slack, we're friendly with transposite UI. So it doesn't matter where the communication is taking place. One of the things I truly appreciate about, appreciate about transposite is as you're going through that incident, as you're having those conversations, you're not having to dictate to a scribe or take time from the resolution process to scribe. We actually have an AI teammate that is listening, watching that conversation and providing that context. We even prompt for you say, man, look, this appears to be an update to this incident. Something has changed. Would you like to change that? We provide that functionality out of the box. And then at the end of the incident, what we hear is a lot of people like to run a post mortem. You'll never hear me say post mortem. That's what our customers say. I call it a post incident review. I do that because there's a lot of learnings to be had there. I cannot tell you the number of times I've seen someone go through that timeline and pull the important pieces out. It's error prone. It's can easily misunderstood as to what action was taken by who back at what time. And so I think the benefit of our AI is that summarization includes key events that took place during that incident. This person did this. This person mentioned this. This decision was made by the group. And we're doing that throughout the entire incident life cycle. And so by the time you finish your incident, we're going to give you a pretty good head start on your post incident review. I think that's a big one. But we're not going to stop there. Now that it's out there and now that we see a lot of this, ideally, what good is 100 integrations if I cannot suggest that you use one? If you're taking this action every time you have an incident, we want to enable you to say, do you want to do this from now on? Do you want to make this part of your incident response process? So getting away not just from the summarization aspect, we want to be a suggestion recommendation engine. And that is huge. Like being a recommendation engine or a suggestion engine based on someone's ongoing conversation and the tools that they're already using is a superpower and one that we're uniquely designed to solve for. Ryan, thank you so much for taking time out today and not only give us kind of a very good summary overview of what you folks do, but also on call the future that you have added and how you make it easier for teams to deal with incident management. Thanks for all those insights. And I would love to chat with you folks again. Thank you. Well, fantastic. I really appreciate the opportunity and I've watched your show. You're doing a great job. I really appreciate it.