From Open Source to Continue: My Journey to CEO

From Open Source to Continue: My Journey to CEO
Photo by Lachlan Donald / Unsplash

I'm excited to announce that I'm joining Continue as CEO! After months of increasingly deep involvement with the team, first as a user, then as an advisor, it just started to make sense. And honestly, it feels like the perfect next chapter in my journey.

How It Started

I met the Continue team at an Ollama meetup back in August 2023. Their tagline in the demo was "Task, not Tab Complete" and it stuck with me. In a landscape full of flashy AI demos competing for attention, they were doing something different: actually solving real problems developers face, not just adding incremental features.

After the meetup, I started helping out however I could. I connected them with folks at Heavybit who I thought might invest. Then I began advising on pricing, strategy, and partnerships. What started as occasional advice gradually turned into working half time, and then one day I caught myself naturally saying "we" when talking about Continue. When Ty and Nate approached me about stepping into the CEO role, I was honored by their trust. It was a significant change for the team and a big decision for everyone involved, but also one that felt right given how our working relationship had evolved.

My Winding Path to Software

Here's something you might not know about me: in college, I was actually studying molecular biology, with plans to become an immunologist. Had I continued on that path, I likely would have found myself in the middle of COVID research. I'd been on that track since high school, doing wet lab research, the whole nine yards.

Then one day, I decided that wasn't what I wanted anymore. I wasn't sure what I was going to do next when a friend introduced me to his boss, Keith, who took a chance on me as a junior software engineer. That job changed everything, for one thing, I could pay my bills!

That same boss helped convince the company to pay for me to get a master's degree, which led me to work on TinyOS, an open source operating system for wireless sensor networks. I was nerd sniped by the cross compiling tool chain, working to make fast to get started and easier to use. Back when Linux live CDs were popular, I took Xubuntu and customized it with everything you needed to develop on TinyOS, my first real developer tools project. It helped other folks get started with what was otherwise a complex toolchain.

A small embedded hardware device with a USB plug. Roughly the size of 2 AA batteries. The tmote sky was an early research and development platform for wireless sensor networks. What would now probably be called IOT.
10k RAM, 48k Flash, and a 250kbps low power radio what more do you need?

Eventually I left the company and decided to move to California without a job. Because of my TinyOS connections, I started hanging out at David Culler's lab at Berkeley. The students somehow got me a badge and an email address, and one day David Culler invited me to lunch and talked to me about three options: join his lab as a PhD student, become a staff researcher, or join his startup, Archrock.

I went with the startup, and that launched my career in Silicon Valley. From there, I can draw a straight line through every role I've had. At Archrock, I met Wei Hong, who knew Mike Olson from their grad school Postgres days, which is how I ended up at Cloudera.

Kitchen Team and Developer Experience

At Cloudera, I led what we called the Kitchen team, kind of a mix of what today might be called platform engineering and developer experience. We were responsible for the infrastructure that made development and deployment possible. The name came from an interview with Google's Hal Varian where he attributed Google's success to the "kitchen" in which their products are developed:

"I also think we have a better kitchen. We've put a lot of effort into building a really powerful infrastructure at Google, the development environment at Google is very good."

A view of a commercial kitchen with 4 massive stock pots in the foreground and chefs knives on a magnetic rack on the wall in the background.
The original picture from the Kitchen blog post. Taken at Kitchen on Fire in Berkeley where I worked for a while teaching home cooks before starting at Arch Rock.

It was clear to me then that the development environment was critical to high performing companies. This insight probably explains why I later took a tour through many of the developer environment startups during my consulting journey.

After Cloudera and a short but amazing stint at WibiData, I felt a bit burnt out on infrastructure and reached out to friends at Puppet. They suggested I try sales engineering, which I thought would be temporary but ended up loving. 

When I started at Puppet I had never actually been a sales engineer. I'd been on sales calls with reps before, but this was my first time in the role. My rep and I went to a company for an onsite call. They brought one of their sysadmins to the meeting, and he wasn't thrilled to be there. He felt they had better things to do than waste time on a meeting for a product they weren't going to be successful using. His team did more or less everything manually.

I remember thinking I'd been there before and how I felt. So I asked him what I would have wanted to be asked: "What sucks the worst for you?" 

Time suspended for a moment, my wide-eyed rep shocked that I'd ask it that way. The guy was surprised too. But he answered. Managing SSH and SSH keys. He had to manually put all the right things in the right places every time a new developer showed up or changed their keys.

I asked him if he'd like to automate that right now with Puppet. He didn't think it could be done. We sat together and did most of the work in about 15 minutes. That changed his life, literally the thing he hated most about his job was done. We also got the sale.

That's when I realized I enjoyed talking to people about how tools could make their lives better. It wasn't about the technology itself but about solving real human problems.

Docker and Democratizing Development

Then came Docker. One day I found myself typing docker run redis and thought, "ok, that's pretty cool." Just a simple command, and suddenly I had a database running, no reading the docs, no configuration headaches, no dependency nightmares. I joined Docker's sales team early on, then later ran part of strategy after the company split, building relationships with Amazon, Microsoft, GitHub, and Google.

My favorite moment at Docker, and maybe in my entire career, happened in a tiny beach town in the northern Dominican Republic. It was around the time that the narrative in Silicon Valley was that "Docker is dead." We went to visit family and recharge the batteries. I was wearing a Docker t-shirt at a small beach bar at the hotel, and the bartender asked if I knew Docker. When I told him I worked there, he lit up. He told me he was taking night classes to become a developer so he wouldn't have to be a bartender forever, and Docker was making that possible for him.

That moment hit me hard. It felt like I was paying back Keith, David, Wei, Mike, Scott, and all the people who gave me a break. And I was now, through my work, helping others get their break too. Every time somebody gets a job because of things I've helped build, it feels like I'm paying that initial opportunity forward. That's what drives me.

Another highlight from my Docker days was when I got to play Minecraft with Scott Hanselman. Not something I ever expected to have as part of my job. It was part of a demo showcasing Docker Compose with Microsoft Azure ACI. We built it as a way to show how containers could make deploying complex applications simple, even something like a Minecraft server. A fun reminder of how developer tools can bring both utility and joy when done right.

Continuing the Journey

After Docker, I took some time off during the pandemic and started advising startups, mostly open source dev tools companies. I worked with several dev environment companies like Gitpod and Daytona because I believe in democratizing development. I think it's too hard to get started as a developer today, we ask people to know 19,000 things before they can even begin.

I've always gravitated toward tools that make it easier to get started. Docker did that, docker run redis was revolutionary in its simplicity. The dev environment companies I advised were trying to do the same thing, click a button and get what you need to start writing code without worrying about all the complexity underneath.

Continue feels like the perfect next step in that journey. I believe in open source, I believe in making development more accessible, and I believe in building tools that amplify what developers can do rather than trying to replace them.

I'm excited to be joining Ty and Nate in this new role. There's much more to share about our vision and approach, but I'll save that for another post. Now you know more about me.

Let's continue this journey together. And I mean that literally, I'd love to hear your thoughts and ideas as we build this next chapter.