Going from Developer to CEO: Chronosphere
👋 Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover topics related to Big Tech and startups through the lens of engineering managers and senior engineers. In this article, we cover three out of eight topics from today’s deepdive into tech scaleup Chronosphere. To get full issues twice a week, subscribe here.
We don’t frequently have CEOs on The Pragmatic Engineer: in fact, today is the first issue when we’re talking with a CEO – partially – about their CEO job. I’ve always wondered what it would be like to go from a developer, to eventually become the CEO of a large and growing company.
Martin Mao travelled this path: starting his first developer job at a local startup in Australia, then making the move to the US – first being at Microsoft in Seattle, then at Amazon, and then at Uber, in Silicon Valley. He’s solved interesting engineering challenges along the way, too – like building observability for Amazon’s EC2 offering, and being one of the first engineers on Uber’s observability platform. We covered more on this topic in the article How Uber built its observability platform.
However, Martin had not written a line of production code for the last four years, as he’s taken on the role of CEO, and heads up observability scaleup Chronosphere – at more than 250 people and growing. The company supports billions of active time series across its customer fleet. Chronosphere was actually founded by two former software engineers: Rob Skillington – the CTO of the company – and Martin, acting as CEO. It’s not common to have only engineering founders at a company: my gut feel is that at infrastructure startups, such a setup can make a lot more sense.
Today, we cover:
- From learning to code in Australia, to working in Silicon Valley
- Launching a startup
- Going from developer to CEO
With this, it’s over to Martin, who tells his story and applicable learnings.
1. From learning to code in Australia, to working in Silicon Valley
How did I learn to code? In high school, in Australia, Prashant Varanasi was one of my good friends. He was learning to code, and needed help in a programming competition, because he needed a team of three. He asked for help, and taught me the basics of Visual Basic, so we could enter the competition. And we ended up doing well in it, too! Afterwards, we both won scholarships to college to study computer science. Prashant would later work as a senior software engineer at Google, and a distinguished engineer at Uber, but, of course, back then, I didn’t know this.
In college, I tried my hand at a couple of startups. I founded a text messaging startup at first. Then, I joined a startup that tried to beat Facebook, and become the #1 social media company in Australia, around 2007. At this social media startup, we put a lot of work into importing your contacts from Microsoft Messenger. But when Facebook entered Australia, they pretty much crushed us.
After graduating, I began looking for a more serious job. In 2009, the tech scene in Australia was not as vibrant as it is today: Atlassian was still small and Canva didn’t exist. Google was already on the scene, and I interned at the Google office, working on Google Docs. However, Google paid a fraction of what they did in the US, so I set my eyes on the United States.
Microsoft
In 2009, not many US tech companies were hiring, as the sector was still recovering from the 2008 crash. Microsoft, however, was, and I got an internship to work there. They accepted five interns from Australia, and I was lucky enough to be one of those five.
When I went to intern there, I thought I would spend three cool months in Seattle, and that would be it. I had no idea you could get offered a full-time job at the end of an internship, until the internship ended and Microsoft came to me, saying, “Oh, hey, here’s your job offer.” It was an offer to stay in Seattle. On top of the option to continue working at Microsoft, it was also the best monetary opportunity as well, so I took it without a second thought.
I worked on Office 365, as it was born. I joined the Microsoft Office team but was tasked to work on a new product. My team was taking the Office product distributed on CD ROMs and making it into a SaaS solution. They called it Office 365, and in 2010, this was a really exciting project to work on. We then shipped the first version, and then I felt that it was time to move on.
See, I was working at Steve Ballmer-era Microsoft. We had a target to hit a two-year release cycle. They let me code full-on for eight weeks, and then told me to stop. I asked what I should be doing next. They said, “It’s now QA time!”
I tried to push bug fixes, but was told that it was too risky. I was, however, told that I could get those fixes ready for the next release. But the next release was not for another two years’ time!
After a few years, I thought to myself:
“What am I doing here? I’m not productive at all. I should do something else with my life.”
Amazon
I attribute a lot of things to luck, and how I ended up at Amazon was one of these. My mentor at Microsoft was a senior engineer who had moved over to Amazon and ended up running a part of the EC2 team. This was around 2013, and EC2 was one of the hottest services at Amazon.
For some reason, Amazon didn’t have any senior engineers on the part of the EC2 team that was responsible for the EC2 instance management, and for the Windows business. The Windows business was itself a billion-dollar business at the time! So my former mentor reached out and asked, “Hey, do you want to be a tech lead on EC2?” I thought about it for a while, and then decided I couldn’t turn down an opportunity like that.
And it was really interesting to work on EC2. I wrote code for drivers on Windows, and started to put a basic observability system in place. EC2 had no observability system back then: people would spin up EC2 instances but have no idea whether or not they worked. So we took on the challenge of fixing this.
With my team, we built the basics of what is now called AWS Systems Manager. This was a remote management tool, to do things like:
- SSH remotely into machines, via a browser interface
- Roll out patch updates
- Manage rolling updates for several machines
We built it, shipped it, and presented it at re:Invent – Amazon’s annual flagship event. It was a lot of fun!
After a couple of years, it felt to me the mood changed to most teams just wanting to ship new services. The focus seemed to shift to: invent something new → build a service for it → ship it. Once you do this a couple of times – building and shipping a new service – it starts to become easy enough. The discussion I had with people went along the lines of, “Oh, I know what service you want to ship. I know how to do it. It’s not that hard to do, anymore.”
It was around this time that Rob Skillington – now my cofounder at Chronosphere – called me up and convinced me to join this startup called Uber, and said it would be a crazy ride!
Uber
The pitch to join Uber wasn’t just the business vision, but also the engineering one. The engineering pitch went something like, “Hey, here’s your chance to come in and work on a system where we don’t use the public cloud; we own our own datacenters, and we get to build infrastructure services that could one day become the size of Google’s infrastructure.” It was a pitch that was hard to say no to!
I joined in 2015, when there were a couple hundred engineers at Uber, and the infra team was made up of about 50 people.
Rob was right that Uber would be crazy. It was at Uber where we ended up building M3: Uber’s open source, large-scale metrics platform. We previously covered the building of M3 in the article How Uber Built its Observability Platform.
2. Launching a startup
At Uber, I felt like we had completed the core mission of M3. We spun up a reliable observability platform, and rolled it out. Virtually every engineer was using the platform. The roadmap, frankly, was not that exciting, compared to the challenges we had to overcome in the past.
I decided to look around. I looked at both internal and external opportunities. And of course, I also considered building something from scratch.
In 2019, Uber didn’t have a ton of opportunities, internally. The speed of execution felt slower than it had been in earlier years, and truly hard problems were hard to come by.
On the other hand, I found the idea of building a company very compelling. We originally built M3 to support Uber’s scale on a microservices/container (cloud native) architecture. It was that very architecture that created the scale, reliability, performance and cost-efficiency challenges. When we built M3, we thought only Uber and a handful of companies in the world would need something like this: such as Google, Facebook and Netflix.
Kubernetes changed the observability needs of so many companies. As Kubernetes really picked up in popularity, it was clear the majority of the world’s architecture would look like Uber’s architecture did, and that M3 would be a solution to observability needs. We just so happened to have M3 open sourced – ready to be used in the open, as well.
We then looked at the competition. No one was in a position to solve this problem! None of the existing vendors had built and optimized for a cloud-native architecture. At scale, pricing was out of hand with all solutions.
The cloud-native observability market seemed one that would be ripe for disruption. And we just so happened to have the perfect solution, already built and tested at scale. I remember thinking that if we ever wanted to start a company, there would never be a better opportunity from a timing perspective.
Finding a cofounder
My cofounder is Rob Skillington. We are both Australian, have known each other for over a decade, and worked together closely for four years at Uber on M3. In fact, he even officiated at my wedding!
My personal and biased belief is that starting a company with someone you know and trust really helps. Building a company is hard. There are a lot of tough moments, which might prove to be even tougher with someone you don’t know as well.
Find someone who’s interested in a different part of the business from you, and someone who brings different skill sets. It’s common to have two engineering technical cofounders, but generally one has to focus more on the business side. In our case, Rob remained technical and I focused on the business.
Finding one cofounder who is technical and one who’s interested in the business is not as easy as you might think, either, because both founders need to want to enjoy their area. I see so many technical folks that just don't want to move over to the business side. This is fine, but then you need to go and find a CEO so you can focus on what you love to do!
Fundraising
Fundraising turned out to be pretty straightforward. Firms like Sequoia and Greylock were reaching out to us, when they heard we were planning to start a company. These VC firms have these scout networks of folks who work in Big Tech whose job it is to look out for interesting tech to invest in: and this was how they found us.
We put together an 80-page business plan. This business plan was not really for the investors, but rather, to help us think about the business. In this document, we covered:
- The product
- The market
- The go-to-market (GTM) plan
- Our competitors
- … and many other things!
We worked on a few iterations of this plan, and once it was solidified, this gave us the conviction that we were onto something. With the plan in place, we sent this document – rather than the usual pitch deck – over to the VCs.
Our approach was unorthodox, but worked! The document answered all the questions they had, and we still did a pitch, of course, with a deck. We ended up pitching to a firm and partner we liked, early on: Jerry Chen at Greylock. Jerry gave us a term sheet on the spot, and we took it.
Launching the company was easier than I imagine many founders have it. After all, we already had open source technology to use – M3 – and we also had a clear path on what we wanted to build, similar to the roadmap the observability team at Uber used to have.
When we started out building the company, it felt a little like a continuation of our path from Uber. We were heads down building the product we wished we could have bought.
Here's the timeline of our fundraising story since the launch of the company:
- May 2019: founding the company
- Nov 2019: the first round of funding led by Greylock: Series A ($11M)
- Jan 2021: Series B ($43M)
- Oct 2021: Series C ($200M)
- Jan 2022: Series C-1 ($115M)
An interesting bit of history is how the first funding round at most startups is called either a pre-seed, or a seed round. But we didn’t have one of these! We knew what we wanted to build, and knew there was a demand for it, and we had validation from the M3 open source community on the demand. We had the technology ready in the form of the M3 project, which was a massive achievement by itself.
We needed $11M to get started. When we told Greylock that we were raising $11M, they said that that figure was too large to be called a seed round. Still, we didn’t get hung up on the name. We just called it a Series A.
3. Going from developer to CEO
With my cofounder, Rob, we quickly established that he would remain technical, and I would be on the business side.
By the end of my time at Uber, I didn’t feel that I had to prove myself in engineering any more. I was there from the beginning when we built M3. I could still get joy out of technical stuff, but I've proven that I'm a solid engineer, and that I'm an okay engineering leader. I didn’t feel like I needed to go and prove anything more in those areas.
Still: I had this hunger to learn about how the rest of the business worked. At Uber, I wasn’t that close to the business and had no idea about the details. Being the CEO, I got to learn so much of this!
My day-to-day life now, as CEO, is very different to when I was an engineer or even an engineering manager. Right at the start, I still had GitHub access and did some reviews. But I was definitely the first and only member of the early team to become “non-technical.” I had to take care of everything else that wasn’t technical at the company.
Now my days involve not just back-to-back meetings, but also tons of context switching! It’s like, "Oh, I have to switch context to a marketing meeting where we're talking about a demand generation strategy to one about customer success to one about how to sell to customers."
Over time, I built up a support network. Below are a few things I did to find people who could help me navigate the new problems I faced:
- Leaning on VCs. VCs don’t have as much domain knowledge, but they have a vast network. I would ping my VCs, telling them: "Hey, I'm trying to solve this marketing problem. Can you put me in touch with 3-4 people in your network that could help me walk through it externally?"
- Leaning on advisors. For people who have been helpful, I tend to keep in mind as an advisor. For example, I have a sales advisor, a marketing advisor, and people who can advise in a few other areas.
- Seeking out other founders and CEOs. I never realized how most founders and CEOs give a lot more time than you would expect. For example, one CEO in particular, from a publicly traded infrastructure company, has helped me out no end. If I text this CEO about something, he’ll make time to help and offer support, even though I know how busy he is. I notice that most such CEOs are really protective of their time, yet they’re still willing to carve out time for other founders. This makes me want to pay it forward as well, and help earlier-stage founders too.
This was three one out of the eight topics covered in this week’s The Pulse. The full edition additionally covers:
- The early days of Chronosphere
- The need to introduce a career ladder
- The impact of Uber and future plans
- Advice for software engineers
- Appendix: Chronosphere’s 80-page(!) business plan
Subscribe to my weekly newsletter to get articles like this in your inbox. It's a pretty good read - and the #1 tech newsletter on Substack.