Welcome Dave Rosenthal

A few months back I was talking with a leadership candidate and they said something that stuck with me. We were chatting about the challenges of scaling organizations and projects, and how one of the problems that often arises is reliability. One way they had tackled this at an early stage project was to keep a whiteboard full of every current bug. If it was full, you’d have to fix something since there was no room to allocate another task. More interesting in the conversation was how they thought about the definition of the bug:

A bug is anything where the system performs in a way not intended by its current implementation.

That conversation has stuck with me for months and I began to reference it regularly. It brings a simple clarity to software design, but also many other problems. It’s the kind of clarity I’m always looking for as a leader in a company, the kind I want to be able to deliver to a team, and a way that pattern matches well with how I think about problems. Suffice to say, I’m thrilled that the person I had the conversation with, Dave Rosenthal, is joining Sentry as our Chief Technology Officer, and I’m transitioning to Chief Product Officer

Sharing this news today feels a little different, as last weekend was the 16th anniversary of Sentry’s first commit. It’s rare that us startup-folks have the opportunity to spend so much of their career building something they’re proud of. It’s also a great time to reflect on what we’ve accomplished as a product and company, as well as the challenges yet to come.

If you’ve followed Sentry, you might remember when I decided to step down as CEO, and Milin joined the team. Today’s news is a little different but has a lot in common, and it stems from a key fact we recently shared: a lot of customers - more than 100,000 - rely on our cloud service. It’s a poorly kept secret that our ambition is to bring Sentry’s technology to every developer in the world and to do that requires taking a different approach to many problems. That means we’re always looking for opportunities to tackle ever-increasing challenges of scale, and in this case to expand the overall capacity and scope at which Sentry executes.

Dave brings incredible experience to the team, with an irrational attraction to hard problems. If you aren’t familiar with Dave’s background, a big highlight for me is his work on FoundationDB, which I think we can agree fits in the category of very hard problems. Dave’s background in building foundational technology (pun intended) at enormous scales brings a valuable, but familiar perspective to the existing leadership team. It’s exactly the kind of thing we admire at Sentry and the kind of person I want to work with.

As Dave will be taking on the CTO role, I’ll be assuming the duties of Chief Product Officer. You’ll still find me lurking in just about any conversation related to Sentry, but I’ll be biasing my time on our product strategy and some far-edge R&D experiments like Spotlight. Mostly though, I’ll be spending a lot more time with our community and customers. This aligns well with something I want to talk about today; an area I’ve been focused on recently has been the re-alignment of our product, particularly around the growing complexity of Sentry’s surface area and why some of it exists. That led us to an internal conversation around what problems we’re trying to solve for developers, and revisiting some past decisions.

We spent the better part of Sentry’s history focused on making it easier to debug production errors. That journey will never be complete as we continue to see technology shifts, meaning our product has to adapt. In recent history however, that problem has become increasingly complex, and what is particularly interesting is how we’ve seen our journey come full circle. You see, when Armin joined Sentry, we sat it in a little cabin in the Austrian mountains, brainstorming where we wanted to take Sentry. That led us to draw up our original spec for distributed tracing. Why’s that relevant to error monitoring you might ask? Because tracing is just a means to enable debuggability.

You’re going to hear that word a lot. Debuggability. It doesn’t need explaining, and it’s what we’re rallying our investments around. It’s the thing that made Sentry’s error monitoring great, and it’s what we need to continue to deliver, but it also requires change. We’ve been focused on taking a different approach to observability tooling these last few years; our goal was to apply our opinionated patterns beyond errors, primarily within the performance monitoring space. Though the feeling today is that we may have fallen into the timeless trap of building new products while assuming our existing investments were still the best they could be.

If you’ve dealt with some of these modern runtimes, particularly something like TypeScript, you’ll find a lot of the context we’re able to capture is far more fuzzy, and less actionable, than say an error from the Python runtime might be. Looking back we’ve recognized that we were so wrapped up in one narrative, that we glossed over the fact that the system is no longer performing the way we intended. It was no longer efficient to debug every error, particularly because of the missing context in these runtimes. We’re going to fix that. Soon you’ll see us connect the tracing technology that we developed for performance monitoring, improving debuggability across any kind of application issue, including everyone’s favorite TypeScript stacktraces.

I’m not going to go deep on this today, but if you find yourself nodding along, if Sentry’s made you frustrated, or you feel like we’re missing the mark, please let us know. We’re at just about every tech conference in existence, all over GitHub, Twitter, and Discord, and you’ll certainly find all of our contact addresses in just about any sales tool under the sun. I - and everyone else on the team - would love to hear from you.

If you want to come help us solve these problems, particularly if you enjoy very hard problems and love to prove someone wrong when they say something is too difficult, consider sending us your CV. We’ve got a lot of bugs on our whiteboard and they’re not going to erase themselves..