The FireHydrant team often describes Jon Lehr as the “best hype man we could've ever asked for” – between persuading CEO and Co-Founder Robert Ross to quit his job at Namely to build FireHydrant full time, to giving them the opportunity to publicly launch at a packed NY Enterprise Tech Meetup full of prospects in 2019, to speaking annually at company all hands.
Given just an hour of downtime can cost an organization over $100,000 and as major companies like Amazon, Meta, Bank of America, GitHub, Slack face significant revenue losses due to software outages impacting millions of users and businesses, our conviction in the need for better incident response tools in the enterprise has never been stronger.
To capture some of this excitement, we chatted with Robert on how his background uniquely positions the company to win, his leadership style throughout the growth phases of the startup, and what’s next. Check it out below:
FireHydrant is an incident response tool. We make it easy for teams to assemble, triage, resolve, and then learn to prevent future incidents with retrospectives. We are the tool that responders use after they have been alerted of an incident to run the entire incident response process collaboratively.
A big part of what we’re changing is the idea that incident response has to be manual, painful, and reliant on years-old knowledge or processes at a company. We teleport responders to the point where they can start mitigating an incident as fast as possible, and get rid of the swivel chair you have to sit in to find and work the problem. If we can move all of the incident response into one Chrome tab or Slack channel, we’ve done our job.
This year marks two decades since I started writing code. For much of that time, I was an on-call engineer. Even when I wasn’t technically on-call, I often inserted myself into incidents because I liked the challenge and problem solving involved. What I didn’t like was the ad-hoc freakout that took place whenever we needed to start solving the problem – the inconsistency of getting set up, finding the right people and information, digging through code and systems you didn’t write or build was disorganized and distracting from the problem. As I learned more about each business I worked at, I started to understand how much that dysfunction impacts not just the engineers day-to-day, but the customer experience and ultimately the bottom line. I wanted to find a way to put responders in the position of focusing on solving the problem vs. everything else. And that’s what we’re doing with FireHydrant.
"I’ve been part of developer communities much longer than I’ve been trying to build or scale one. And as a developer, I know that authenticity is key. I don’t want to be sold to — I want to build relationships, hear other peoples’ stories, and figure out new ways of approaching the problems I have. To build a great community and generate trust, you have to give to it."
We take that approach seriously with our blog and our Better Incidents community. The moment developers don’t trust you, good luck getting them back. So, we make a point to keep FireHydrant out of the spotlight unless we’re relating through solving similar problems, like running more low severity incidents or using our data to help people benchmark incident metrics. Our focus is on giving more than receiving because we genuinely believe it’ll come back to us if we’re leading with useful advice, stories and connections.
I think the #1 hurdle, especially right now, is tight customer budgets. Responders know they need to buy this tool, but we have a lot of integration overlap and compete for the same budgets as similar tools that touch FireHydrant. So, it's critical our team become consultants and be able to explain the unique differentiators FireHydrant provides. This is easy for me given I’ve been fixing incidents for so many years.
"Scaling this incident response expertise across every one of our teams requires standardized language for a new category and being able to articulate the pain and solution in a trustworthy way - because, remember, developers can smell bullshit!"
Our long term vision is to build a world where all software is reliable. In order to get there, we’ve got to break it down and make sure we can meet customers where they are today. For most teams, that’s just trying to make incidents less painful. So we are attacking it from two angles. First, we are focusing on making incident response drop dead simple for any responder. And second, and what I am really excited about, is the release of Signals, a modern alternative to legacy alerting providers like PagerDuty. While we have historically relied on integrations with alerting providers, it became clear to us that most of them were overpriced smoke alarms that have failed to adapt to the way teams build software. With the release of Signals this Winter, FireHydrant will be the first to market with best-in-class Incident Response and modern Alerting, in one tool.
From there, we can expand our focus to help people get more value out of their incidents to actually start improving their software — even helping them predict how to avoid incidents in the first place.
Work-Bench had a well-defined thesis around the problems of site reliability and software reliability even before meeting me.
"Jon and the Work-Bench team have made many customer introductions as well as investor introductions for our sequential funding rounds."
Not to mention our relationship just feels fundamentally different – Jon and I nerd out over music and go to karaoke. The fact that there’s trust and friendship there means that we can openly have tough conversations when necessary.
Don’t stop being who you are. You’re going to get tons of advice and you’ll be encouraged to read lots of books and case studies on what others have done. But don’t ignore your own instinct and what drove you to build your company in the first place. You’re going to have to stretch and grow into new roles, especially if you’re a founder/CEO with a technical background (like so many of us out there). But growing doesn’t mean abandoning what made you good at this – what attracted customers and investors to you and your company in the first place. If you love to write code, but some book tells you that a CEO doesn’t do that, you’re going to lose sight of your product and your customer pretty quickly.
"Your job is to find new ways to stay close to the product, team, and customers without compromising scale while also staying true to who you are and the ideas that come from being you."
Don’t forget to pause and look back on how far you’ve come. When things start flying, it’ll feel like weeks and even years pass in the blink of an eye. It can be easy to get lost in what’s not going well or where you need to improve, but you need to balance that with perspective on how much you’ve accomplished and how you did it. Five years ago I just wanted to make incident response easier for people. Now teams of hundreds of engineers, at companies like Spotify, 1Password, and Snyk use our platform. You’re going to have days where you get punched in the face in the morning and historic wins in the afternoon. It helps to have the historic context so you can ride the waves.
