Please welcome Steve Newman, the man who created Google Docs, and the current founder of Scalyr.
Davis Baer: What’s your background, and what are you working on?
Steve Newman: I’m an engineer and, I guess I’m supposed to say “serial entrepreneur” but I’m more comfortable with “startup guy.” I’ve co-founded six startups, including Writely, “The Web Word Processor.” We were acquired by Google in 2006 and relaunched as Google Docs. The original motivation for Writely was to help people collaborate to create a document — or as we thought about it, “solving the problem of having to email Word files back and forth.” And of course people do use Google Docs to collaborate, but a lot of the value turned out to be in having access from anywhere.
Currently I’m CEO of Scalyr, where we’re attacking the problem of operational visibility: giving engineers on the front lines of software development the ability to understand how their applications, services, containers, etc. are behaving. Traditionally, everyone treats this as a search problem and throws their logs into a keyword index, which doesn’t work very well. We’ve come up with a radically different approach that is both crazy fast and much easier to use.
A screenshot of Writely, which was acquired by Google and became Google Docs
What motivated you to get started with Scalyr?
It stems directly from my experience at Google, scaling out Google Docs and then an infrastructure layer that sat underneath Docs and some related apps (Sheets, Drive, etc.). It was your now-classic chaotic cloud environment, with lots of moving parts. As an engineering team, we were spending a huge fraction of our time just investigating the issues that would constantly arise. These are complex systems, generating a flood of logs and other telemetry data, and the tools we had to analyze that data were simply not up to the task — too slow, too complicated, and too limited.
Scalyr gives us what we needed (but didn’t have): the ability to dive into the morass of logs, explore, pivot, and drill down, and quickly come up with an answer to why a system is misbehaving.
What went into building the initial product?
We had a pretty clear idea from the outset of what we wanted to build. The challenge was technical: how to give sub-second answers to questions that can draw on terabytes of log data, and do it scalably and at a reasonable cost. My co-founder, Steven Czerwinski, and I spent three years basically in my garage — the attic above the garage — building a new data management architecture from scratch. We had to rethink about the problem in terms of the ways that engineering teams work with operational data, instead of trying to play off of existing keyword indexing designs that are optimized for retrieval of natural-language documents.
Somewhere along the way, we brought in Claudia Carpenter, another Writely founder. Claudia is amazing at UX, and she’s designed an interface that allows engineers to take advantage of our engine without having to learn a complex query language. I like to say that we’re all about minimizing the time from a question in an engineer’s head to an answer on their screen. The fastest engine in the world won’t succeed at that if no one understands how to use it.
What’s your business model, and how have you grown your revenue?
The business model is straightforward — we charge based on log volume. We keep it simple, with no extra charges based on number of users, servers, alerting rules or things like that. Our customers are engineers, and they appreciate a straightforward approach, which also makes things easier for us.
The nice thing about this approach is that the more useful people find our solution, the more data they send us, and the more revenue we get. Often we’ll start out supporting a single team or service, and then spread throughout an organization. In this way we’ve been able to build revenue rapidly without having to go through a heavy enterprise sales process.
How did you get your first 10 users?
Partly network and word of mouth, partly blogging about the product and the technology underneath it. One of the nice things about building a tool for engineers is that they’re interested in the technology. We got a lot of attention by talking about the unique approach we came up with for managing operational data.
What are the biggest challenges you’ve faced and obstacles you’ve overcome?
The biggest challenge was the core technical problem of processing these massive data sets in real time. We liked that because it played to our strengths as an engineering team. If there’s one thing you learn at Google, it’s how to not be afraid of scale.
Early on, another challenge was getting companies to trust us as their solution for a mission-critical task. We’re past that now, but when you’re new on the scene it’s always a challenge to build that trust. We got past it by being very open about what we were doing, how we were doing it, and why we were confident that approach would work. I think it helped that we were an experienced team, have already made all the usual mistakes, and learned from them. People can pick up on that.
If you weren’t building Scalyr, what would you be doing?
Probably building something like Scalyr. :) I gravitate toward engineering challenges, especially performance and scalability challenges. I also gravitate toward broken situations, where everyone is unhappy with the solutions available for a particular problem. I once saw Jeff Bezos give a talk where he said something like: “Entrepreneurs are people who are never satisfied. They’re in the shower and they say ‘this shower is terrible!’ It takes forever to warm up, and the nozzle is in the wrong place!’ And then they start thinking about ways to fix it.” That’s not an exact quote, but it was the general idea. I like Scalyr because it scratches both itches — a product category everyone is dissatisfied with, where the solution involves an engineering challenge. Writely was the same thing, though the specific engineering challenge was very different. So I’d be looking for something like that.