This post was originally published on Startupon on March 30th, 2023, my newsletter Q&A series that features some of the most influential builders in the game. It’s no secret that taking the leap to found a company and figuring out how to scale a startup in the early-days is hard, but this part of the journey is relatively unspoken about. I’m aiming to demystify the founding journey by interviewing founders, operators, and executives about their experiences scaling their companies. Subscribe here and never miss an issue!
Chronosphere is a cloud-native observability platform designed for devops teams operating in a cloud native world. The company’s tools help to eliminate the cognitive load of monitoring infrastructure by summarizing the health of infrastructure, applications, and the business in a single control plane. It solves complex issues by following them through the different layers of the stack, enabling businesses to operate reliably at scale and make precise, data-driven decisions. Their customers include companies like DoorDash, Snap, and Zillow, who have used Chronosphere to reign in costs, improve developer productivity, increase customer satisfaction, and gain a competitive advantage.
Uber was early in adopting cloud-native architecture in 2014/2015, long before the rest of the industry. Upon its implementation, we quickly realized there weren’t any tools on the market to help us monitor this fundamentally different type of infrastructure, which captures a ton more data, shifts throughout the entire tech stack, and therefore requires an end-user interface that captures these varying data requirements. Given legacy tools building Application Performance Monitoring and IT Monitoring weren’t a good fit for this type of technology, we created our own tool internally.
Soon, the next wave of companies adopting cloud-native had the same dilemma – spin up a huge team to build this themselves, or find an imperfect pre-built solution. So we open sourced what we built at Uber, which allowed us to help the early-generation of cloud-native adopters solve their observability problem and gain early traction. Then, three major cloud providers adopted kubernetes and it was off to the races.
“We already solved the problem years before the rest of the world even knew they had a problem.”
A lot of large companies produce cool tech in house and open source it for the benefit of the world. During our time at Uber, we never thought about building our company. We just wanted to build a great open source project that was useful to the community.
My advice would be not to over think it and don’t over commercialize it. First, start with how you can provide value to the community. There’s opportunity down the line to commercialize, but first start with building something useful. If it gains traction, that’s your signal that the market needs something like this. The biggest mistake someone could do is overthink how to commercialize open source too early.
Our “aha moment” was realizing the underlying tech we were building at Uber solved real pains with scalability, cost efficiency, and reliability.
“However, this wasn’t luck. We built the product based on working and listening to customer pain points.”
As our Head of Product says, our real value was “being fair” – showing the customer how we can align the value of the data to the cost they’re paying. We showed customers that you might not need all this data, but that we would figure out which data is valuable, and in what form. Giving our end user a guarantee that the data they’re using is valuable was a far better value-proposition than giving them a cheaper product.
Our biggest tailwind was that the world shifted to cloud native. By 2027, 90% of enterprise-apps will be cloud native. The whole industry is moving in this direction, and when you move in this direction observability is key. We were speaking with a customer recently, and he mentioned that he’s gone through cloud native migration 2-3 times over his career and unfortunately it isn’t common knowledge, but without observability you can’t do this migration at all. It’s almost a requirement for companies to migrate, and for us it’s a huge benefit because 1) it’s a huge market opportunity to help the industry get there, but 2) without us it will be a huge blocker to helping them achieve their migrations.
Incumbents try to be the best at everything, which is impossible. From a strategy perspective, we’re crystal clear on what type of use cases and pain points we’re trying to solve for – cloud-native use cases and workloads.
Additionally, we were specific on how to go-to-market and the segments we go-to-market for. For us, we were born by solving this problem at Uber, making our system one of the largest in the world and allowing visibility into the business (tracking drivers) in real-time. So we determined we would primarily serve and optimize our strategies around the top end of the market because the foundations of our product’s scale, reliability and cost efficiency resonated the most there. We’re tailored to the largest tech-forward digitally-native customers in the world like Doordash, Robinhood, Snapchat and others. Ie. We optimize systems with 100,000 dashboards, which changes the way you organize and discover data vs. with a handful of dashboards.
As founders leading sales, it was always clear during customer conversations that we were the technical experts who understood the technical problems and technical solutions at hand.
However, founder-led sales doesn’t scale at all. But it is important early-on. Once you get some traction, it’s time to build up the machine in the proper way. For us, it was hard to employ a top down enterprise sales motion without structure, so initially we left a lot of deals left to chance.
“We slowly learned that there’s a science to sales, just as there’s a science to engineering. There’s a process - tried and tested ways - to build a scalable go-to-market engine. That was when we decided to hire a sales and marketing team to help.”
Our first sales hire didn’t have an observability background. My co-founder and I had the domain experience and needed someone who could sell. So, we looked for candidates who had been a first sales hire before and could thrive in a gritty environment. At this point, we did everything in Google Sheets (not Salesforce) and needed someone who was okay with a lack of systems and processes.
My role has changed a ton. The way I look at my role as CEO, is that if we don’t have a department, I go do that job first. Not that I’m going to be best at it, but it gives me an understanding of what to hire for i.e., if you’ve never tried to market or sell your own software, how are you going to effectively hire someone else to do it? Luckily, we now have great people in their roles and I can focus on other areas.
In terms of growing the team, we aim to hire people who can get the job done. That's the baseline for any of our hires and any level. Early on in scaling a startup, what’s important early is screening if candidates will be a cultural add to a company. When I look at the majority of candidates we reject, it’s not a skills gap, but it’s because we don’t think they’ll be a cultural add to the company.
Our product. If you’re selling up against a competitor, your product needs to be orders of magnitude better, not just a little better, than theirs. If you’re playing in a crowded market and your product isn’t differentiated, it’s going to be tough. As an incumbent that’s okay, but if you’re a challenger that will be very difficult.
The other thing we do really well is Customer Success. We put a lot of focus on treating customers like partners. Almost all of our customers call our customer success process a differentiator for both signing and retaining customers.
Open source is core to our technology, and we continue to promote that the only way users can interface with Chronosphere is through open source standards. This is better for the industry as you don’t want to be locked into vendors. We want to push and iterate on these standards. Especially in observability, open source is important for data production and consumption.
Every day. I think it’s normal for everyone to feel a little imposter syndrome. I just try to get through my days by thinking about what I need to get done. There are definitely some seasoned execs out there but I think everyone deals with it a little. I try not to think about it though. I try to get through my days and weeks by thinking about what I need to get done. I don’t get caught up in vanity metrics.
“Everyone starts from somewhere. We were engineers before this. We never thought we’d be running a big company. But here we are.”
I admire Dave McJannet, CEO of HashiCorp a ton. He’s doing a great job at HashiCorp, but he’s also one person that’s always been on the other side of the phone to answer questions or dish out advice. Even as a public company CEO who is super busy, he still makes the time. I like how he operates. There’s no bravado to him. He’s always heads down and executes. I’ve never heard him brag and that’s something I respect a lot.
If you’re an early-stage founder building in this space, I’d love to hear from you! Email me here.
