“What’s your pricing power?”: An Interview with CircleCI CEO Jim Rose

Starting your own business and maintaining momentum is incredibly difficult but in the online space its exceptionally hard to make an impact and keep any type of business running on the ground.

So we spoke to CircleCI’s CEO Jim Rose, who has been setting up businesses for over ten years and worked as a CEO  for half of that time to learn about his career, how he developed his business, his key advice for future entrepreneurs and much more.

What’s your background?

I’m originally from Wisconsin and went to Duke for undergrad. After I graduated, I spent some time in China as an analyst working on the copy machine supply chain. There are lots of stories there, but we’ll save those for another time.

After awhile I came back to the States and spent some time working in Seattle, and then for WPP. It was the just at the start of first tech boom, and I started a company called MobShop.

We wanted to give consumers the ability to get discounts when they bought goods at volume –this was way before Groupon, who had a similar idea and ended up buying one of our patents.

That was my first startup, and I haven’t looked back since.

What do you do now?

Today I’m the CEO of CircleCI. CircleCI has been around since 2011, and I’ve been the CEO since 2015.

Our mission is to shorten the distance between idea and delivery. We want engineering teams to be able to go from code to production as quickly and efficiently as possible. Continuous integration and continuous delivery (CI/CD) are two practices that CircleCI enables.

The whole idea is that you are taking small changes and merging them into a master build frequently, so that you can find and detect issues while they are still easy to fix. CI/CD is often synonymous or foundational with DevOps on engineering teams.

How do you think of making those changes?

Our customers are asking the same fundamental questions: How can we deliver more value, more quickly?

How can we reduce our downtime and our risk?

How can we compete in an environment where everything is speeding up?

And so teams are looking for ways to empower their engineers to move quickly, while also making sure they have the guardrails in place to deliver a high-quality, secure product. Cloud-native companies often naturally work this way — you might think of them as being DevOps-native as well.

Who are your clients?

While our early customer base was mostly made up of small startups like us, today we’re seeing big Global 500 companies from all sectors: financial institutions, government agencies, automakers, major retailers, and so on.

Every company is now a software company, and every engineering team is looking for ways to deliver value, faster.

What motivated you to get started with your company?

I came to CircleCI in 2014 via the acquisition of a company I founded called Distiller. There’s a bit of a winding backstory with Distiller and how I get to CircleCI, so let me set the scene.

I mentioned that I’ve made a career out of being an entrepreneur. In 2010, I co-founded a company called Copious with Rob Zuber (CircleCI’s CTO) and Jonathan Ehrlich. The idea behind Copious was that you could use Facebook and Twitter data to deliver a more social and personalised shopping experience.

You can think of it as eBay or Etsy where the recommended products were based on recommendations from your social graph.

We ingested your Twitter + Facebook data to show you items and sellers you might like. We built a pretty thriving marketplace — and then one day in 2013 Facebook basically shut down access to the news feed for companies like ours (and Zynga, most famously), and our growth engine was kaput.

First we ported Copious to mobile. Then, as we had time between releases, we spent some time trying to decide what we might build next. We were experimenting with a few different mobile app ideas.

As we were building prototypes, we kept hitting the same pain point: it was really, really difficult to do testing well for iOS. The cost of a single error was really expensive. You would send an app to Apple for review, wait 4-10 days for it to come back, and they would reject it if they found a single bug.

You had to make sure the app you sent was going to get through, so quality mattered a lot. Shipping any changes in mobile was really hard and cumbersome.

So we invested in building tooling to solve this problem, and then realised that what we had built, which eventually became Distiller, was the thing with the most value.

How did you figure that out?

We were ramping up to a decent customer list and usage, and we started to hear more and more from users that they wanted an integrated toolchain for CI, to be able to build projects for macOS, Android, Linux all in the same system. We had just happened to build Distiller in Clojure, which CircleCI is also written in. We were also just a few blocks away from each other in San Francisco. It made a ton of sense to join forces since the feature set was so complementary.

What was the key takeaway for you?

I think the key takeaway here is that the thing you think you’re going to build when you start is never the thing you end up with. This was startup number 5 for me, and I’ve definitely learned that lesson over time.

Building something as an entrepreneur is all about staying alive until you find “the thing.” Before you have product-market fit, all you’re trying to do is find the flicker that you have a business before you run out of money. If you find the flicker before you run out of money, you can get more money. If not, you shut it down.

You see this all the time out in the market. If you think about the origins of Slack, that was their internal chat tool that they used while they were trying to build an immersive video game.

Shopify started as an online store for snowboarding gear. Twitter was a podcast subscription service.

How have you attracted users and grown CircleCI?

Developers take pride in their tools, and we do our best to be a company that people are proud to be associated with. We share a lot of our thinking and internal work on leading and growing engineering teams, and talk about how we make technical decisions, like our design of the first package manager for CI. It’s hard to track how content directly drives to user growth, but certainly page views and discussion in the wider engineering community is great awareness for us.

Moving down the funnel to acquisition, we have a land-and-expand model. We want to make it possible for everyone touching code to be able to try CircleCI and use our service for their projects. We offer a free tier for both public and private projects, and we also provide a lot of resources to big open source projects.

Why do you think open source is important?

We want people to have an opportunity to play around, kick the tires of our system, and find the value in what we provide. There’s no way we could have grown as quickly as we have if we required a credit card up front.

The core of our product is about helping engineering teams become more productive: faster, safer, and happier. A lot of teams suffer under legacy systems or tooling and may not realise the amount of pain they are putting up with.

When your build takes 30 minutes, or an hour, what does that do to your productivity?

What does it do to your willingness to experiment, or ship something small?

Ultimately, smart teams know that time they spend doing things not related to their unique value are not good uses of their time. Unless your business is building and maintaining CI/CD systems, there’s no scenario, or a very limited number of scenarios, in which it makes sense for your engineers to spend time doing this. The people cost in terms of dollars and hours is just too high as compared to the compute cost you would spend.

What are your goals for the future?

When every company is a technology company, the opportunity to help teams modernise their software delivery process is very substantial.

What are the key aspects of the devops ecosystem right now do you think?

I see three pillars of the developer ecosystem: runtime (AWS, Google Cloud, Asure, etc.), code and collaboration (GitHub, Bitbucket), and build/test/release (CircleCI). If you think about the journey of a big enterprise organisation, they will usually start by moving out of the data center and into the cloud. Then they think about standardising their version control system on GitHub or Bitbucket.

Once those two pieces are in place, teams will start to look at inefficiencies in their process. Are they still deploying quarterly, or dealing with monster merge issues?

Are developers filing tickets to folks in other buildings who need to update a language version in order for them to get a small change out?

Being able to move quickly and focus your team on what matters is a huge competitive advantage, and we don’t see investment in tools that help your team be more productive slowing down.

How does CircleCI Improve that experience?

More code is tested and deployed with CircleCI every day than on any other system on the planet, which means we see more real-time information as to the current state of the developer ecosystem — what’s happening in both code and production — than anyone else.

We don’t just want to build the best tool or pipeline for code to go from one system to another. We plan to intelligently harness that data to create proactive alerting, and help the entire system become more resilient and more reliable.

You can think of the analogy like going from a paper map (legacy software development tools) to Google Maps with real-time traffic information. If a big open-source library that your codebase relies on ships an update and your system goes down, CircleCI is likely aware of that as soon as it happens.

How do you aim to help developers?

We want to help reroute developers around those issues and provide more insight and awareness about their dependencies and what’s happening in their code base. And for open source creators, we want them to also have information about how changes in their projects are impacting their downstream users, via alerting and other health metrics that we think we can provide in a way no one else can.

It’s an ambitious goal, but we believe we can grow to the size and scale of GitHub and the big cloud computing players like AWS.

What are the biggest challenges you’ve faced and obstacles you’ve overcome?

Before finding product-market fit, optimise for speed, not elegance. Pick a toolset and a process that helps you move as fast as possible, with the assumption that at some point you will have to rewrite everything. Don’t waste time scaling before you need to.

There’s a golden moment after the product-market fit and before “we’ve overloaded the system and everything melts down.” This is a crucial time to layer in process and scalability at a reasonable cadence and rate. When you miss that, things start to get really hard.

If you had to start over, what would you do differently?

Everyone focuses on the wrong things before you find product-market fit, and then they focus on the wrong ones after product-market fit.

Pre product-market fit people waste time talking about the company they want to build. Instead, you need to focus all of your energy on building the product that will support the company that you want to scale in the future.

Once you have that, you can figure out how to build a sustainable path around that. Over and over again I see folks who have a death spiral because they haven’t figured out their product. You have to be 100% focused on fit in the beginning, through whatever means necessary.

People also get too precious about what they are trying to build. They hold on to their ideas too tightly, when the main question you should be asking is, “Can you build the one thing customers actually want?”

Once you’ve done that, you can start to think through things like your technology stack, organisational structure, and whether you have the right people in the right roles.

The first time you start a company you will do everything wrong. People get better at this over time, but you’re still completely at the whims of the market. It doesn’t matter how good the team is, or how cool the product is, or how elegant your technology is. If customers don’t want it, and the market rejects it, it doesn’t matter.

Andy Rachleff has a famous quote that talks about this: “When a great team meets a lousy market, market wins. When a lousy team meets a great market, market wins. When a great team meets a great market, something special happens.”

How do you know when you have product-market fit?

It’s really important to be able to assess this, and there are some things you should look for.

Does the market pull as opposed to you having to push?

For example, are you trying to keep up with demand coming in from customers irrespective of your efforts to push into the channel?

How much pricing power do you have?

Pricing power and your ability to raise price is a clear indicator. Most companies charge too little.

Can you increase your price without backlash?

If so, you’ve added real value. Most people post-product market fit try to reduce price and end up in a spiral to zero.

Have you found anything particularly helpful or advantageous?

Some people say you should read and listen to everything about your industry in your spare time. I would recommend the opposite. You should listen to any podcasts that have nothing to do with startups. Your entire life will be consumed by what you do from a company perspective. It’s really important to find an escape from that to stay fresh and sharp so you can focus on making the business work. If you go too far down the rabbit hole you lose perspective.

What’s your advice for entrepreneurs who are just starting out?

When you are in pure startup stage, in the very early days, the only thing you should do is focus on the customer. Lock in. You need to understand whether you are doing something customers actually want and that the market will accept, and have blindness to everything else.

Once you find product-market fit, you can start worrying about the other pieces. Before product-market fit, thinking too much about things like organisational structure or honing your systems are just not good uses of your time.

I’ve been through the startup process a few times now, and another thing I strongly recommend to everyone is to do everything related to the incorporation and funding of your company as by the book as possible. While there is no one standard, you don’t want to spend time on things that don’t matter before you know you have a product.

Your corporate documents and structure should be vanilla standard. Relationships between the founders should be vanilla standard. You want things to be as clear and easy as possible so that you never have to go back and renegotiate. Every time you try to do something custom or fancy, you’re just finding more opportunities to pay your lawyers.

To be fair, these are hard conversations to have, and so often founders will ignore them, or try to do something absurdly custom. And ultimately, it’s expensive, time-consuming, and very unlikely to matter.

On the venture front, you need to have a very real conversation with your co-founders about what you all want in terms of outcome, and figure out a plan to get there to support that.

Most people who take venture money the first time don’t understand fully what they are getting into, and then 12-18 months down the line with the investors they realise they’ve gotten themselves into something they didn’t fully understand.

Before you take venture capital for the first time, sit down with someone who has done it before and get them to explain what taking money entails and whether you really want to do it. You are signing up for big growth goals. Josh Kopelman at First Round Capital was quoted on this in the New York Times.

He said, “Big problems have occurred when you have founders who have unwillingly or unknowingly signed on for an outcome they didn’t know they were signing on for…I sell jet fuel, and some people don’t want to build a jet.”

Most problems in the venture world come from misplaced expectations, and first-time entrepreneurs don’t always understand that going in.

Related Posts