Ep. #31, Monoliths and Microservices with Rob Zuber of CircleCI

Grant Miller: All right, Rob, thank you so much for joining.

Rob Zuber: Thanks for having me. I'm excited to be here.

Grant: Cool, so let's jump right in. Tell us a bit about your background and how you got into enterprise software.

Rob: I'll give that a shot. I would say that my path to enterprise software is very nonlinear. It sort of jumps all over the place, but--

Grant: Most of us don't grow up thinking, I want to be an enterprise software executive, when I'm older.

Rob: Right, right. If we go back to the point where I wanted to be a firefighter or whatever, then I'll definitely be jumping all over the place.

So I guess I'll start a little bit with just how I got into software and then talk about how I ended up here.

But I graduated from college back at a time when it was less obvious, this industry was going to be what it is.

I studied engineering physics, did a little bit of software development in there, went to work in a production facility doing, I would say big data, bigger data that many people work with now, you know.

I was analyzing production defects and trying to optimize our factory process, stuff like that.

And became really enamored with the software part of that.

And then a couple of friends of mine started a startup back in the, this is late nineties.

And there weren't as many people to choose from, I guess, is the less generous way of saying how I ended up there, but it wasn't the industry that it is today.

And I was interested and fascinated and ended up working with some people who were really great sort of mentors and had great backgrounds in software development and learned a ton from them.

But I sort of started out doing things like running a QA team and then something we called, systems engineering, which today would probably look like SRE, those sorts of things.

In fact, one of the first things I did was write our build script.

So full, oh God, I'm totally going to say full circle because I can't stop myself.

But to be back here, you know, 20 plus years later, thinking about delivering software and the same thing I did in those early days, so.

Grant: And now you write build scripts for everybody else.

Rob: That's right. Well, I don't write their scripts for them in my current job, but uh-

Grant: You personally writing everyone's build scripts. That's how I imagine.

Rob: Yeah, exactly. Well, you know, I'm a big fan of the sort of fake it till you make it perspective.

And that feels like something you would do early in this kind of domain.

In fact, jumping ahead a bunch, in 2014 with two other folks, I worked on a small CI and CD platform built specifically for iOS.

We were called Distiller and Distiller was acquired by CircleCI. That's how I ended up at CircleCI.

And that project, the Distiller project was very much in that domain of sort of fake it till you make it.

You know, we did the smallest possible thing to get a successful iOS build and then went and found a couple people.

And we literally walked door-to-door around San Francisco, talking to people we knew in the community and saying, hey, you know, we're trying to build out this thing.

Do you want to be our customer? Do you want to try it out?

And we knew there was a pain point we were solving for pretty quickly, but then ended up realizing, soon into that project--

I think we were only maybe six months in when we were acquired by CircleCI, but we realized that iOS didn't really on its own or mobile, even everybody who was building a mobile app also had a backend system that they wanted to test and people wanted to consolidate all that onto one platform or service.

And so we took what we built, joined CircleCI and integrated those pieces to basically build out what is now the iOS offering within the CircleCI platform.

So I basically skipped over my entire career in there, but I would point out along the way that effectively I've done everything from consumer electronics to telco, mobile, consumer, web, a little bit of everything.

I really like the notion of moving into those different, I hesitate to call them disciplines, but different sort of market segments, different types of customers, because I think that getting exposed to a lot of different approaches and models like that gives you new perspectives and new ideas that you can then bring to, you referred to this as enterprise software. I think we're definitely selling into businesses.

When I hear the word enterprise, I always think, you know, very kind of large-scale, high-end, but we sell into businesses.

But we do that in what feels a bit like a consumer approach, at least for a good segment of our market, right?

So we have everything from open-source customers who aren't even paying us for their open source projects, like small open source projects to then large open source projects who do pay us or large organizations and then, small startups and we have a broad spectrum of customers.

And so the way that those customers find us, join us, work with us, can be quite different everywhere from, you know--

You could sort of sign up and put in your credit card and just start using the platform without ever talking to anyone at CircleCI and have a great experience up to us delivering it on-prim package that, you know, we help you understand how to operate, run, and you are then managing that for a very, very large organization or a large number of developers inside of your company.

So I think again, having those different disciplines or having experienced those different disciplines and approaches to the market can be really helpful in thinking about how then even to work within enterprise.

And I think, I mean, you've obviously been in this space a long time, also. We've seen a big shift in how enterprise software gets delivered.

I mean, first of all, SaaS as such a massive component of the software that enterprises are consuming, right.

And shifting away from the IT department, that's building the custom windows application for every single thing that you need to do inside your company to effectively stitching together offerings that you can get off the shelf and don't even deploy inside your own company.

So even, I probably have this in some ways, very dated version in my head of what enterprise software means.

I mean, I talked about working in a manufacturing company. I think we were 20,000 people or something like that.

And there was an entire team of people writing applications in Smalltalk on top of the IBM Unix flavor which I-

Grant: Like Power or whatever they called that thing.

Rob: I can't remember what it was, doesn't matter. In fact, a big part of the job that I did, I was running queries against the DB2 database on AS400s that were, you know, locked in someone's closet somewhere.

And so that view of the world and, you know, green screens, like dummy terminals into AS400s and stuff like such a different, different world of enterprise software from where we are now.

And so just living through that evolution has been really interesting.

I would certainly say, I remember when I first started again doing this analytics and I would write these queries against these massive datasets, you know, historical production runs and what went wrong and what went right.

And when you submitted them, so you're submitting to this, the centralized server resources, right.

And you would get back a cost. When this query runs, your business unit will be charged X number of dollars and cents basically.

Grant: So funny.

Rob: And I remember thinking at the time, how ridiculous, you know, that this notion that there's shared centralized computing and I just pay for the amount of it that I use.

And now we think that's so novel and cool.

Grant: Yeah, yeah.

Rob: And then everything shifted down to desktop applications. And then we shifted into the world of what we now call SaaS.

We called it like application service providers at the time.

And pushing everything back to centralized compute with thin clients.

And then we went to mobile and pulled everything back out onto thicker client.

Like I think we really love to go around these cycles, but at each phase, we innovate and create new capabilities and we get further ahead and getting now to this point of enterprise software, basically being streamed together, a bunch of available SaaS solutions, and then being able to go do your job.

I mean, the rate at which we can build on top of all of that, build new and novel things, is pretty cool to see.

Grant: Yeah, it's a great point. It's the idea that we can all stand on the shoulders of all these different best-in-class solutions in order to build software better and faster.

I think is actually, you know, it's quite novel of the software engineering world.

Like the idea of tool building is such a foundational part of what we do and companies like Circle, where you're building these tools that are enabling so many folks to not have to think about this as a core problem or you know, it has a multiplier effect in terms of productivity and gains, so pretty valuable from a mission standpoint.

Rob: Yeah, I love being where we are. I love, as a software engineer, sitting at this center of watching so much software engineering and product delivery happen.

It's interesting. I think by my perspective has shifted as a leader, as someone in a growing company from we're building software to we're delivering value to customers, right?

And like, how do we think about that whole perspective versus just the code that gets written, but sitting at the center of that, watching people get better and better at delivering value out to their customers is just, it's a very, very cool place to be.

I mean, honestly, just for, from the perspective of personal satisfaction and fulfillment.

As you were talking about, this notion of being able to deliver faster and faster, I was thinking it's like, kind of the second derivative.

Like it's not just the rate of change, that's exciting, but the rate of change of the rate of change, like just constant acceleration.

Grant: Sure.

Rob: Of our ability to do things and the acceleration of that acceleration, if you will, like just the rate at which we get more and more foundation on which to build the tiny, tiny amount of work that you have to do to get something of value out in front of customers to learn from it or to find out that it's not a value, but then iterate on it in a way that allows you to get to that point of value and to realize the real problem that your customers are trying to solve.

And then to be able to solve that for them is, it's in software, like, like no other industry. I mean, just the capital investment required is so low.

The barrier to entry is so low and the ability to change things.

Like as a contrast, I guess, my brother is an industrial designer and builds molds for like injection molding, like making plastic bottles and stuff like that.

And like, you kind of get one shot, you know. I mean, you can get in there with a chisel and like change the structure of the metal a little bit and like file it down or whatever, if there's a small error.

But those things are ridiculously expensive and you kind of have to get it right.

I mean, when I think about that versus, oh, there's a bug in my software, like I'm going to press the delete key and type four characters, and now it's fixed, right?

It's amazing to think about how much we can achieve and how quickly in this industry.

Grant: Yeah, no, that's a great point.

And so just real quick, kind of back to your background, you kind of mentioned all these different roles, from SRE and QA, and then obviously, you've been the CTO and co-founder.

You know, I've seen this in a handful of other founders and it's almost like you have this whole breadth of knowledge across different functional organizations.

And then, combining those together kind of gives you this like cross-functional view of problems.

Do you think that that's like been pretty foundational in your ability to scale and grow and sort of succeed as a leader and a product technologist?

Rob: I think yes, for me.

But, I'm hesitant to say, you know, that's the right path sort of thing.

I always get trapped quoting books that I've barely read, but I recently picked up a copy of Range.

I don't know if you're familiar with it, but I think the subtitle is, along the lines of how generalists succeed in a specialized world or something like that. And the first chapter or the prologue or the part that I read before I decided to buy it is a comparison between Tiger Woods and Roger Federer.

And Tiger, from age three has a golf club in his hand. And, you know, that's all he does.

It's like by eight he's, you know, going down to the golf course and playing for money.

You know, like winning against all these adults and Federer, basically will play any sport, any sport that involves a ball, sort of thing, and just credits the more generic view and the skill transfer from all of those things, with his ability to play tennis in a unique and obviously amazing way.

And one of the things I noticed about the book is that on the cover, there's a blurb or a quotation or whatever from Malcolm Gladwell who famously wrote Outliers and talked about, you know, 10,000 hours and singular focus on a specific thing.

And I think his quotation is on, along the lines of, I've never been so excited to be proven so wrong sort of thing.

And so there's clearly this almost polarizing view of whether singular focus is the most valuable thing or whether, you know, broad distribution of kind of activities and inputs and insights is what's going to get you somewhere.

So I would say for me personally, I mean, first of all, I'm obviously fascinated by the subject in general.

I am all over the place in a way that I find fulfilling. Like I love to learn new things.

You can see this everywhere in my life. Like I've been snowboarding forever.

I recently took up skiing just to try something different, right? I play the guitar, but my kids play piano.

So I started playing piano just 'cause it's like something new to learn.

And it's just the way that I'm wired in a way, is this desire to try all of these different things.

So then when I go about my job as a CTO, I think that having those different perspectives is valuable to me.

It gives me a useful set of insights, perhaps helps me to work better with other parts of the organization because I've done some product management, I've done some business development.

I mean, let's be clear, I wasn't great at any of these things, but I've done them.

And that sort of opened my eyes to what was really involved and then, how I could better enable and support those people.

But maybe I have less, you know, pure software development and technical experience than other CTOs.

So then that shapes how I think about hiring and staffing my organization, right?

I have a chief architect who has way more experience in just pure software development building systems than I do.

And so if you were a CTO who was very much that, you know, very, very technical, very much just thinking about how the software is getting built, then you would bring in other people to manage some of the other things, right.

People with maybe more of a product perspective or maybe more of a customer view.

I think for us specifically, as a company, you know, our customers are very technical.

And so being someone who, you know, has a decent and deep knowledge of tech, I don't want to understate my knowledge or experience in actual software development, you know, a good amount of experience there, but enjoys going and talking to customers and spending a lot of time kind of outwardly facing.

That's a good fit for us as a company that, you know, whose customer is very technical and where the perspective of what we're trying to help the customer do so they can understand that from me or the other way, you know, where they're running into challenges, what kinds of problems they're trying to solve.

And having that very direct kind of technical connection is a valuable thing for us.

That might not be true in say, a more consumer-facing organization.

Grant: Yeah, it's actually, it's really interesting. And I think the people you surround yourself with, and sort of how you build teams.

It's such a great insight in thinking about where you're, you know, where is your sort of negative space and who can you find to fill those spaces is a really important thing to think about hiring-

Rob: Yeah, I feel like I have just like, I love talking about books, but many years ago, I read some of the early books from what has now become the strengths finders series, or I don't really know what to call it.

And it's a big thing that they talked about, which was, you know, understanding what you're really contributing, being comfortable with that, and then building around it, right?

Like there's been much talk of the challenges of hiring in our own image.

And a lot of people look at the people they're trying to bring into their team and think the definition of success or high quality or whatever for that candidate would be the things that they value or in my case, the things that I value and the things that I value are going to be reflection of the way that I go about doing things.

And you're often in a much better place when you say, I've already got that covered, right.

Where are my blind spots or weaknesses and how can I construct a team that's going to offset those so that as a team, we're much stronger.

Grant: Yeah, there's a specific person at Replicated whose name's Austin. We worked together previously at another company.

And when I hired him, I said, his job description was to be good at all the things that Grant is bad at.

Rob: So that's a very good and simple way of thinking about it. I think that's exactly right.

Grant: Yeah and he is. And you find the same synergies with different people in different roles.

As you sort of grow, you need more people to specialize more the things that you're bad at and yeah.

And then let's kind of rewind one more time. So, it sounds like when maybe, YooHoot, was that the-

Rob: It was, yeah.

Grant: Was that a mobile company?

Rob: It was a, I mean, I could talk about it a little bit, but effectively, a consumer-facing mobile app.

Grant: Great, so you started that company in 2010, consumer-facing mobile app at a fairly popular time to start consumer-facing mobile apps.

There's a lot going on there. And ran that for a year and a half and then doing, Copious. What was that?

Rob: Yeah, so Copious was also a consumer, it was a consumer application. It was web first and we were building a marketplace.

So person-to-person marketplace, think eBay effectively and trying to imagine how to build a marketplace in a social world, right?

So this was beginning of 2011 and saying peak, Facebook, probably it's not accurate, but, you know, we were all still trying to understand what social really meant.

Facebook at the time, was still unclear about how they were going to make money.

They've obviously solved that problem since then, because now it's 2020.

And there was a huge emphasis in the Facebook world and others on platform, meaning we will be the social network upon which all social applications will exist and communicate, right?

And I think, while that was a big part of the strategy, I mean--

Grant: So probably log in with Facebook connect or whatever they called their thing.

Have an idea of who your friends are, see who, what things that those people are selling and sort of have a trusted network of like buy and sell.

Rob: Exactly, so we're trying to layer on social signal effectively as a, as a means of trust.

There was clearly, there were trust issues in other marketplaces, there's still trust issues in other marketplaces, but like any good marketplace that wasn't a problem that you could solve immediately because there's a cold start problem.

You need supply. No supply will show up without demand, right. So you have to find some way to get the flywheel moving

Grant: And how big, like give us a sense of engineering team, how big was that? And then, what kind of happened to it at the end?

Rob: Yeah, so we peaked around 25, I think as an organization, probably 10 to 15 of those were in engineering.

I'm a little fuzzy, to be honest in all the details, but something in that range, right.

It was, we raised a seed and then a series A and then effectively Facebook realized that they weren't getting anything out of this platform.

It's probably an over-simplification, but you can go back and see where this transition happened.

And they shifted all of their attention into mobile, which has worked out swimmingly for them, like kudos.

They figured out where the real opportunity was as a business, but many businesses like ours sort of disappeared overnight.

I mean, I picture a giant switch, you know, that they just turned off. That was the platform effectively.

Grant: And is this like when they were, they used to have so much third-party application information flowing into your newsfeed, that you were kind of seeing all these different apps and if you were an application, you were able to like fill that newsfeed up and get customer acquisition really inexpensively. Is that sort of--

Rob: Yeah, that's exactly right. Yeah, when someone looked at something, liked something, bought something on our platform, we shared that out with our friend group.

Grant: Right.

Rob: This is also the time that is, you know, can now infamously be referred to as Cambridge Analytica time. Like--

Grant: Yeah.

Rob: We had full access to your friend network, their friend networks.

Like it was, we all sort of looked at each other and said, is this right? Like, should we have all this information?

I mean, we didn't use it in a particularly nefarious way.

We just tried to say, hey, here's some other people that might be interested in what you're doing.

You know, would you like to share this with them?

Grant: Would you like them to watch the Apprentice and vote for Donald Trump eight years later?

Rob: Right, exactly. That was not what we were doing, let's be super clear, but yes, all of the access was there for us.

And there was, I don't know if you remember the introduction of the ticker.

Grant: Oh yes.

Rob: Where it was kind of the main feed. And then there was just so much information.

They were trying to break it up. And when I say they turned it off, they just devalued all of that, right?

So their algorithms about where stuff was going to get placed, just pushed all of our content out of anybody's main view and our mechanisms to try to grow and scale the platform sort of disappeared with it.

And so we decided to try the same business model, but move into a mobile first platform because it was now 2013, sort of mid-2013.

And mobile first was very much how people were thinking in terms of, you know, selling your used clothing and stuff like that, having access to a camera, some cool filters.

Like you can place yourself back in that time, right?

This was sort of Instagram, early Instagram. Instagram's obviously like in its own, I wouldn't say resurgence, but a new growth phase now, but that was one of the things that really made them popular, right, was the ability to have a professional looking photo, even though you had a pretty crappy camera on your phone, which is also not the case anymore.

And so helping people create simple listings, get their stuff up on, you know, that was a big part of the work, right?

It's getting a marketplace like that to function, you got to get people motivated to put the listing in the first place and then to get them to go through the pain of shipping, like those are two of the big problems you have to solve.

And so we tried to move over to a mobile platform.

As we were working on that, we were like, oh, we can build more mobile apps to just like, let's spin up a bunch of ideas and just throw them into the app store and see what sticks.

But as we were doing that, we realized how hard building mobile apps was not from a like writing the code perspective, but the kind of tooling around it.

Grant: Yeah.

Rob: The software delivery process.

Grant: People were probably like getting a rentmymac.com for a build server or something. Isn't that kind of the-

Rob: Well, the five or 10 people who actually had a build server and didn't just push their broken app into the app store? Yeah.

Grant: From their laptop? Yeah, yeah.

Rob: Right, exactly. Exactly and so there wasn't good knowledge out there about how to automate the build process.

There were no tools available, et cetera. And so we said, oh, you know, that was kind of actually that enterprise versus consumer aha moment, you know, because we were down to just a few of us working on these mobile apps.

You know, we've given some money back to investors.

It was a good time in the industry and I would say. So the folks that had worked with us had no problem just going and doing other stuff.

And we were not paying ourselves, sitting in our respective living rooms, kind of spinning out these mobile apps and trying to find something that we thought would stick.

And then we sort of had this, you know, mobile apps in the consumer space are very sort of nothing, nothing, nothing, nothing, billion users, right?

Like these overnight successes are always 10 years in the making.

Grant: Sure.

Rob: And are we going to be able to stick it out? You know, personally, or can we shift into something?

First of all, we see a problem here, which is the absence of sort of tooling and capability.

There's a lot of people moving into this space, building mobile apps.

Again, we're talking 2013, heading into 2014, and building an enterprise business, enterprise-oriented, although oriented towards very, very small enterprises can move us into much more of a unit economics kind of thing.

Like a few people will sign up and they'll start paying us.

And then we can use that money to pay for the resources that we needed, et cetera, et cetera, right.

Versus sort of holding out for that big moment where you happen to hit an unnerve and a billion people sign up and use your app, right.

Grant: So sell the picks and shovels.

Rob: Right, exactly, exactly. And so that was a shift that we made at that point.

And it was, I will say partly, hey, we should think about a different way of doing business because again, we're not paying ourselves or you know, whatever, but also this is a real problem, right?

We have stumbled upon a real problem. And it's one that we understand because we are facing it ourselves.

And if we solve that problem for ourselves, then maybe we can solve it for other people, right, which is generally a good starting point for any business.

The one thing that I think really sealed the deal that I talk about a lot is as we were trying to then build out this capability, every time I would run into an error or trying to get a build to run in a virtualized Mac environment, I would kind of Google the error code or whatever message I got, invariably land on stack overflow.

And see the question had been asked, but there were no answers. Like over and over and over again.

Like everyone is running into this problem and there were upvotes on the questions and whatever, but no one knew how to solve it.

And so I thought this is high value, right? Like there's a lot of people out there who are struggling with these issues and nobody knows how to get past them.

So if we can solve that, then we can build a business on that.

Grant: It's funny. Market research through stack overflow, unanswered questions.

Rob: Yeah, I mean, I guess it's real in a way. I don't know how you would go about doing that without the inspiration.

It was more validation than like, I don't know that you could just cruise around stack overflow, trying to figure out what problems have never been solved, but it worked out for us.

Grant: And team-wise, Copious and Distiller, you started with Jim Rose who's now the CEO at Circle.

So you two have sort of been working together throughout that time. Is that right?

Rob: Yeah, that's exactly right. So 2011, we started Copious. We had a third co-founder, a guy by the name of Jonathan Ehrlich, who is now a partner at Foundation Capital.

Grant: Oh, cool.

Rob: But Jim and I have continued to work together through that whole time.

Grant: And so how did you meet Jim just prior to that?

Rob: Through Jonathan, actually. So I struggled to not make this joke.

Jonathan is also Canadian and literally that's why we know each other.

I mean, there's a population of more than two people in Canada and somehow, but somehow, it just comes down to that.

We knew common people through, so if I go all the way back to that first startup that I worked at, where I was doing QA and sort of SRE type stuff, a bunch of the people who were at that company went somewhere else, after that company was acquired, actually many years after that company was acquired and they overlapped with Jonathan.

They introduced me to him because he was looking to start something new. He was looking to move back down to California.

I think he'd been back and forth a couple of times. He was looking to move back down to California.

And somehow in conversation, my name came up through these, you know, these common friends of mine from Toronto. So he pinged me when he was back down here.

We met up a couple of times and then he said, hey, I'm looking to start this thing with Jim.

And he and Jim had built a company back in the late nineties, independently. There's a lot of interconnection.

And so he introduced, well, he introduced me to Jim, but with the intent that the three of us maybe would work together to start this thing.

Grant: Okay, cool. And then you start Distiller after Copious, you sort of find the problem, you start Distiller, you go out into the market.

Is it just, is it the three of you or was it just you and Jim at that point at Distillery?

Rob: So it was myself and Jim and then, a guy by the name of Travis Vachon who had been one of our early engineers at Copious.

Grant: Great and so you start Distiller.

You start to go out to market, you're basically walking around San Francisco trying to get a hotel tonight or any other mobile first company to sort of get on board with your build system and like that, and that's kind of when you say, you figured out that people wanted a more holistic platform or what was the?

Rob: Yeah, I mean, we definitely started to build up a customer base.

It was slow-going because we didn't have brand recognition or, you know, whatever.

But I mean, I would go to iOS meetups and go, literally knock on doors, track people down through my network, et cetera.

So we had some early adoption, but people were constantly asking like, how are we going to integrate this with our backend build?

You know, can you do that as well, et cetera, et cetera. They were excited about what we're doing.

And I think that one of the things that excited them and then later led to realizing we shared some philosophy with CircleCI was we were trying to make it as low effort as possible for those folks to get started.

I mean, I talked about how people just didn't understand the environment.

I mean, a great example is just code signing certificates and how you manage them and how you get them into a build platform when there's a bunch of security rules around that, how that operates inside of the environment, et cetera. It's too complex to go into, but it was a really common problem that people didn't understand. And instead of saying, here's a VM, follow these instructions, we just did it for you. Like basically, if you do these two things, follow these conventions, the stuff will work, right. And so they were very excited about that, but then, less excited about having to split that away from everything else that they were doing.

And so we reflected on where are we trying to go with this?

I mean, we were just kind of kicking the tires a little bit, trying to figure out if there was something here and the idea that we would go build a complete platform, when that would put us years behind people like CircleCI or Travis CI who were probably the other big competitor at the time, just didn't seem like the right decision.

So we thought it would at least be prudent to go have some conversations.

And so we've been around long enough that we know, we know people, we know how to find people.

So we put in a call to the folks at CircleCI. Paul Biggar, who was the CEO at the time and the founder dropped in, met with him.

We actually had a lot in common technically, which was quite surprising, but also just kind of shared vision of where it was we were trying to go, shared values about how we wanted to build that.

Just a lot in common and so that seemed, and they happened to not have iOS capability in the platform at the time, the one thing that we had.

So there was just a lot of reasons for us to work together.

Grant: Hmm, interesting, okay. And so you had a fairly like seasoned team in that regard too, like three of you, but like, you know, it wasn't your first rodeo.

You knew what you were doing with companies and you probably had some venture capital relationships at that point, too.

It's interesting that you were acquired, but you became the CEO and CTO. Like how did that happen?

Rob: Yeah, it is unusual, I would say. The simplest way to describe it is ultimately, Paul knew what he wanted to do, right.

He was very excited about a product, about building stuff.

I mean, I think if I was going to use the word visionary somewhere, I'd probably use it with respect to Paul.

A really, really good understanding, saw this opportunity at the right time. So I mean, he started this company back in 2011, right.

Grant: Out of like an academic, like kind of thing, right? It was like a research project for his PhD or something.

Rob: It was post, I think his PhD was actually compiler related. So in the space that he was interested in.

Grant: Yeah.

Rob: But, you know, saw the problem, started addressing the problem, started addressing it in a way that people were sort of skeptical about, which is usually a good sign, right.

And built something that people really wanted.

But around the time that we joined, was feeling like, you know, very interested in the product and engineering perspective, less excited about taking that to the next level from a company growth perspective.

And so really said, hey, you know, now that you're here, seems like maybe you have some experience with this.

Would you like to participate in a bigger way?

And really, you know, it was kind of an evolutionary in terms of, hey, you know, from my perspective, could you try to manage the engineering team a little more and do less direct engineering?

I mean, my first three to six months, I just built the iOS capabilities into CircleCI, right.

And then asked Jim to step up and do more of the operational side from a non-engineering perspective.

I mean, there wasn't really anything outside of engineering when we joined.

So Jim started a marketing team and started to think about what it would look like to have sales, et cetera, et cetera, right.

And so we sort of ended up with the three of us operating and running the company.

And then, Paul continuing down that path of saying, you know what, this actually is not the part that I'm most excited about, would love to have you two sort of step up and take on more of it.

So it was a gradual and fairly smooth transition that was mostly initiated by Paul saying, you know, this isn't exactly what I want to do.

Like I love this company and I love what we're building, but I don't want to necessarily drive it at the helm through the next stage of growth, if that make sense.

Grant: Yeah, yeah, I mean, that's amazing amount of self-awareness, too.

Like Paul, I mean, Paul, you're right. Like visionary, understands like the future of where software's going, wrote that amazing blog post.

Like, it's the future. I mean, he's just, he's a really talented thinker and builder.

So I can imagine when looking at what he really wanted to do and just saying like, that's not that interesting to me.

Let's like, let's let these guys take this next step, that's the kind of humility and self-awareness I'd expect from him. So, that makes sense.

Rob: Yeah, and he's, I mean, he's still a member of the board, so we get to see him regularly.

He's moved on to another project and I think he's taken a lot of what he got out of this and is now doing that again in another company with a little bit more of that background and more, you know, excited and ready to take on bigger leadership.

And I think he's doing a great job over there. So, I totally agree. It's not necessarily the standard founder story.

You know, I think a lot of people want to hang on, even though like, because of some, I don't know what to call it exactly, but some, I'll just call it a social pressure, like the sense that, because I started this company, I have to be the person in this position.

And I think it takes a really sort of insightful, good self-aware perspective to say, you know what, I created this thing.

And the best thing for it is for me to do the thing that I love to do instead of trying to do the thing that like is the normal thing to do.

Or, I can't find quite the right words, but something along those lines, right.

And so, I think we're all, the company would not be here.

The insight at the time and those first few years was huge, got us to an amazing place.

And then to say, hey, this isn't what I want to do.

And I see people here who seem like they might be able to do it, it's an unusual outcome, but has worked out well.

Grant: Yeah and so, since that time, you mentioned that you have two sort of go to market angles.

One, people just sign up and pay, but you've also really, I mean, you've become quite utilized within the enterprise, right.

And so, I'm guessing that that was a bit of a transition from bottom up, right.

And sort of added at more enterprisey features in along the way or what is that transition look like?

Rob: Yeah so, I think that's right. The thing that we're seeing and have seen over the course of that time with respect to enterprise features, there's a couple things.

So first, we started out very focused on the individual developer and scaling that to things that help across projects, across teams, right, which gives you some leverage or added value to the customer at higher levels or higher scales of customer, right?

When you're thinking and single teams or single developers, you build features in a certain way, and then there's different capabilities as you get to multiple teams.

And I think that's actually reflective of an insight that that I continue to have about how the company started like, we solved the very specific problem, but that was the problem of companies that looked like CircleCI, right.

A small Rails-monolith building start-up, and one team, maybe more than one team, but probably working on the same code base.

Like, basically magic for those folks.

Like, you click a button and now you have a functioning build and you can just get back to work.

And I think there was also a sort of market timing thing in there where 2011 is the year of Rails monoliths right. And the product was built really well for that customer.

And that customer was the customer driving or the team, like that profile, those were the folks driving TDD, driving automated testing, CI, like really drove the adoption of these practices.

One thing that I noticed, actually, when we built Distiller in 2014, is that all of the automated testing tools in the iOS world in 2014 were written in Ruby.

And the reason I believe they were written in Ruby is in 2014, all those people from 2011 who had been building Rails monoliths, realized that the world was shifting to mobile apps, went to work on mobile apps.

And they were like, what are you people doing?

Where are the automated testing frameworks, right.

Like, how do I build automated tests for my, and it just didn't exist.

Grant: Yeah.

Rob: And so, dependency management was written in Ruby, automated testing was written in Ruby, coverage tools were written in Ruby.

Like everything, because it was those and they were like, well, we could write in objective C, I guess, but that's going to take us five times as long.

They all have experienced in Ruby. And they just brought that perspective over to the iOS world, right.

So go back to 2011, you've got these monoliths building, small teams.

And so the product was built for them, which was amazing, but also a little bit to a fault, right.

And with a, I guess, calling it a fault would be wrong. We'll call it the "crossing the chasm"framework, right?

Like pick one specific market, dominate that market and then figure out how to expand from there, is the more generous way of thinking about it, I guess.

And so then as we've expanded and as our customer base has expanded, we've ended up in larger organizations needing to share tooling across teams, polyglot environments, you know, languages and frameworks that we weren't necessarily familiar with.

One thing we've noticed or that we experienced and therefore solve for was we used to do everything for every framework that we supported, right.

So if a new language came out or a new set of tooling came out, then we would build into our product direct support for that. And think about that as a product extension. But if you look at how, I mean, we talked about the acceleration of the acceleration in terms of how software changes, right? And so over that time, it just became impossible for us to keep up. And so, we had to shift from thinking about what our offerings so much as a product, meaning everything is baked in and start shifting towards a platform.

So an example of that being this orbs capability that we have, which is like shared extensions to the CircleCI platform.

And the reason for doing that is, I mean, we have software developers as customers, right?

So they can surely, if we give them the extension capability, they can build for it.

So now when someone comes out with a new framework, they can say, oh, here's the extension to make this work really seamlessly with your configuration.

So now you can use our framework or language or whatever, which is something that, in software development, we love to generate although not very, very regularly.

And that has allowed us to expand into sort of more environments, bigger environments.

So that's a big piece of the puzzle is really just being able to adapt to many, many different types of software development in organizations that are sort of small and just starting and are using what we consider to be best practices today.

Versus organizations that are going through massive agile or digital transformations that have been around for hundreds of years, in some cases, right?

And so being able to be more adaptable in that way, and then, to bring it around to Replicated, we have an on-prem offering that we started out purely SaaS, but we have some specific customers, especially as you get up into larger enterprises who have needs that are better suited to, you know, to operating the platform themselves.

So shifting into a world where we have that as an offering has been very much driven by moving up into those larger enterprises.

Grant: Yeah and I mean, Circle was a very early Replicated customer.

I think we met Paul at like a DockerCon and we were like just sitting in the hack room, not going to any of the talks and just like sitting next to each other.

And then we ended up like, what do you do? What do you do?

And then we started talking and we're like, we could use that.

It was like the most, perfectly nerdy and awkward initial sales conversation anyone's ever had.

Rob: Yeah, that sounds, I mean, it sounds about right for this space, I think that.

I mean, I don't know all of your customers, obviously, but there are probably others like that where it started out as SaaS.

People just sign up and pay monthly with their credit card sort of thing.

And it's easy, but you get to this point in your growth where addressing a certain class of customer is not possible.

I mean, first it's just the credit card, right? Like these small companies where every developer just has the company credit card and just signs up for services, like they exist.

I can tell you, but that's not everybody, right?

At GE, not every engineer can just take the like company credit card and start signing up for services, I'm sure.

So, you know, you just get into a different sales motion, a different type of support that's expected.

That's actually been a big thing to diverge out of my core for a bit in terms of the product itself. How we offer support, right?

Building out a support team, adding customer success and customer success engineering on that.

So having a dedicated group of engineers who actually, you know, spend time with our customers, either getting them set up, supporting them along the way, helping them optimize their process, helping them be better at delivering software with our product.

All of those things become much more important as the customer you're targeting scales.

I mean, we're not shifting entirely up, but we're expanding the types of customers that we address.

And so many things change along the way that are not just the type of product you offer and the features you have, but how you support it, how you interact with those customers.

I mean, when you get out of, again, clicking on the terms of service button, and putting in your credit card and into negotiating contracts and, you know, annual payments, like just stuff that's very, let's call it run-of-the-mill or table stakes in an enterprise world, but is a big shift from where you start, when you've got this SaaS service with teams of five people signing up.

Grant: Yeah, I mean, I think, you know, being able to stretch and do the whole spectrum is I think is becoming more and more important for software companies because ultimately, I'm guessing that a lot of your customers come from, they used CircleCI somewhere else.

And then eventually, you know, they bring it into the next organization they're at, and that might be a larger org so they need enterprise or they use Circle for an open source thing or they used Circle somewhere else, right?

And so you sort of have this funnel, that's constantly feeding your enterprise sales and enterprise sales, not just on prem, but like even just large organizations that probably have massive contracts with you. You know, those are, you're kind of constantly feeding that funnel with the broader adoption.

Rob: Yeah, that's exactly right. So we do have large customers on our SaaS or cloud offering, for sure.

And the entry points to the funnel are varied, absolutely.

The engineer that worked with us previously or used our product for some side projects or open sores and then goes into a new organization and says, "Hey, I think we'd all be a little bit better off if we use more modern tooling,"whatever--

And then can champion that cause, maybe get it into their team, you know, depends on the organization, obviously, what kind of flexibility people have.

But can try things out or maybe builds up a demo and gets some buy in and then sort of builds that out.

But then the transition can be slow, right? It's a team and then a couple teams.

And then we reached this tipping point where maybe we're having a conversation higher up in the organization about the value.

And then being able to support that in the right way is a big part, I think of that enterprise interaction, which is, you know--

Just because one developer is sort of kicking the tires doesn't mean we, you know, we get a meeting with the CIO or the CTO or whoever owns things.

Maybe there's a different point in there, but having, you know, a great support channel so that that person can make sure they have a, you know, so they have a good experience and then, moving up into customer success because they're starting to use the product a bit more.

And then maybe they want some help to get things rolled out and we can support that through our account execs or whatever.

I mean, there's just, as a company selling into those organizations, having all of those different levels of interaction and support for our customers and for the people that are advocating for our tools inside those organizations is a big part of being able to make that transition successfully.

So, there's that, the customer who comes in from somewhere else where they had used it.

There's the small company that, you know, starts out and then they are successful and they grow.

And so they continue to use our product, but they have growing demand for it.

And then there's the kind of at a higher level, you know, people just looking to make a change, right, which is more of your, feels a bit more like your classic enterprise motion of we're stopping and reassessing what we're doing.

And now, we're out looking and those folks come to us and we have a conversation and a kind of more standard sales cycle from that perspective where there's a higher level buyer.

Grant: And within that sort of like higher, you know, high level buyer like, how do you talk about Circle and just CI, in general, as like a strategic part of what they're doing?

And how do you talk about organizational change? Like how do you really, how do you describe the value? Like, what do you say?

Rob: Yeah, I love that you call that organizational change in there because one of the things that I end up talking about a lot is that, you know, tools don't change your culture, right?

Like I think if you take that example of a team that's sitting down and really trying to reevaluate what they're doing, there's an opening, right?

They're looking to get perspectives on what's going to work for them, what kind of approaches they should take.

And we talk a lot about what it is you're trying to achieve and then how we can support you in that, as opposed to this notion that, I think would be incorrect, that if you buy our tool, it's magically going to fix, you know, how your software development works.

So, how do we talk about it? I would say, you know, starting from there, right?

This is a model of what we think you're trying to achieve, right. Reduced time in delivery. And that's like, it's a very big bucket, but starting with, taking your idea and getting it, getting that value delivered to customers, right. And that, you can go all the way back to, it depends on the organization where they're at in this life cycle, but all the way back to agile practices around development, and then more iterative testing, the actual continuous integration. I mean, all of this is about reducing the barrier to get from, you know, an idea to the value of that idea actually being delivered to customers, right.

So I guess at a higher level, one thing that I always lean on is that we live in a world where we are differentiating competitively on software, right.

I mean, banks are a great example for me, where, for the most part, the offerings are pretty similar, right?

I mean, between regulation and sort of just maturity of that industry, 90% anyway, of what I can get from a bank is the same.

And so what do I care about? I care about the experience that I have with the bank, right? Like how easy can you make it for me to do what I need to do?

And that happens through software, right, through the interface that I have with the bank, which in 2020 is almost entirely digital, right?

My online experience, the app that I use, I mean, I won't name the bank that I use, but I think the app that I have is currently non-functional, right?

It's like in a loop where it won't actually log in anymore. And that's really challenging.

I mean, I have checks that I can't cash. I have to drive to a bank now to put my checks in an ATM because the app is not working properly, right.

And so, that is motivation for me when everything else feels like a commodity to just go to another bank.

Like literally just take my deposits and put them somewhere else.

And so recognizing that, that's the thing that you're differentiating on and that we are all innovating at a much faster pace and therefore, speed is what wins in the market means that in order to win, you need to be able to deliver value to your customers faster than your competitors. Right?

And to do that at low cost.

But we've also realized because I've been through all these cycles that low cost doesn't mean find the cheapest possible engineer. It means get great engineers and make it as frictionless as possible for them to deliver value to your customers because that's how you're going to win, right?

They're the ones that are going to have great insights into the direct needs of the customers, obviously, in conjunction with the product team, whatever else.

And in order to support them in that, you want to have frictionless tools that just get out of the way and allow them to do this stuff really effectively.

And so then when we think about how we build our product and when we talk about what we care most about, it is that, right, like how do we give you the confidence that you need to ship effectively, but do it in a way that minimizes the time invested from your engineering team?

And the things that matter there are the ability to get up and going, right?

The ability to put the management of that into the hands of the engineers.

Like there are many, if you actually get into our specific space, many times you end up in a scenario where you have to go talk to the IT department to get them to change some configuration, because you're trying to deploy a new thing.

Like, remove all those bottlenecks and then things like pure performance, right.

And ability to not just on a single run, but like distributing your workload in a very easy fashion.

So low effort to get a, just a high throughput of builds so that you can get that confidence quickly so that you can ship stuff out to your customers and deliver that value.

Again, when you're talking about organizations that are coming to us, they know a lot of that.

We work with them on kind of filling in anything they may not have seen for themselves that they start on this process.

And then, when it comes to people who aren't seeing that, or aren't thinking about things in that way, they're earlier in the buyer journey, right?

And so we write content and we give them information that will help them start to see, hey, this is how I can shift my organization.

And now that I'm thinking about that, here's an organization that clearly does this well.

That's a place I should be looking for the actual tools to support it.

Grant: Interesting and you know, is it a pretty good mix of folks that are like, kind of coming to you directly, looking for change and folks that are just like scaling up and you know, sort of started with, you know, a credit card and keep using more and more? It is like--

Rob: Yeah, I would say it's a blend of all of those. I don't know that I could give you useful percentages or anything like that, but we definitely span that, that whole spectrum.

Grant: Sure.

Rob: And obviously, those where we sort of introduced the concept, but that's pretty, pretty rare.

I would say like, demand is probably the wrong word, but we'll just call it that, the demand in the market.

We get a lot of our conversations started through people who are actively looking, right?

And so whether they are those small companies who, I mean, if you were to start a company today, I'm guessing, I don't want to speak on your behalf, but you know, the first thing you would do would not be well let's hire someone to run the build server.

Grant: Right.

Rob: Just be like, okay, well, this is a problem that's solved, but there's still intent because you have a new project and you need a solution for that project.

So you're going to say, okay, what's the best thing that I can get now to solve this problem for me.

And then, at large organizations where it's more of a change, there's still intent, right?

Like this is an active initiative because we're trying to change the way we manage source control.

We're trying to change the way we do projects. Maybe we're shifting from a monolith to microservices.

Like there's lots of triggering events that lead people into reevaluating their tooling, or maybe, I mean, we just raised a bunch of money.

And now we actually have time and people to like, look at you know, what tools we're using and kind of reevaluate them.

I mean, there's just so many different events that trigger the conversation.

And I would say on the flip side, for us, that trigger or moment of intent is really important.

I think it's important for everybody.

But if a team, right, that would be a potential customer, feels like they have a kind of useful working build platform and they have a different primary problem, right, another thing that's causing them a great amount of heartache, then convincing them that they should stop focusing on that and turn their attention to replacing their build system is going to be an uphill battle.

And so really being good at capturing those moments of intent is really valuable for us.

Again, I'm pretty sure that applies to everyone, but it is one of those things that when it's working well enough, you're kind of less likely to get excited about going and making a change.

You know what I mean? And so really understanding what are those triggering moments and being there to capture that conversation is a big part of how we think about making sure that we continue to grow.

Grant: Yeah and I mean, I think ultimately, you know, your high level point, like every company has to go through what's broadly said, digital transformation, but like, I just think about it as every one, you know. Everything becomes a software company.

We have to differentiate their software, the tooling you use to do that is super important and helps you move faster.

And so using best in class tools help you get there faster, right?

Rob: Yeah and again, ultimately, that's where it ends up.

I just think that we've realized, and I, this is partly me speaking as someone selling CI and CD and software delivery tools, but also as an engineering leader, like whatever problem I look at inside of my organization, I try to stop the tool conversation and replace it with the, what is the problem?

Like, where's the cultural challenge? What is it about our way of working that's creating this problem?

How can we address that and then, okay, cool. Now let's talk about what the right tool is to support that.

Because I think when you lead with tools in that conversation, okay, you just kind of have a new tool with the same problems, right.

And hopefully, it's clear that I'm not suggesting that-

Grant: Tools don't solve everything, it's organization, it's organizational change, yeah, that's a great point.

Rob: Right, right. I mean, better tools is better, but lead with the organizational change and then support it with a great tool and understand the organizational change you're trying to drive rather than just hoping.

Like, if everyone else is using this tool and therefore, I adopt the tool, but I don't change my organization or how I think, like I'm not going to get a lot of benefit out of that.

Grant: Yeah and shifting notes a bit, Circle as a company, you've kind of been on this really interesting trajectory where you kind of continue to grow.

You've raised a hundred something million dollars.

As a CTO, how has your role evolved throughout that, right?

And I think you mentioned when you first started, you wrote all the mobile code and now you're managing teams of managers. So, talk about that evolution.

Rob: Yeah, I would say messily is a key word in terms of evolution.

So it's evolved in a, I don't want to say unpredictable, but it is. It's hard to know week-to-week or month-to-month, what the next stage of evolution is going to be.

I think when I look back, one of the things that I would maybe do differently or advise people to do differently is, I generally was moving to the next stage of evolution too late. Right?

And of course, it's hard to say that you would do it differently.

And I think that people who go through high growth multiple times end up on the flip side of that, right.

Like let me build out this team of really senior executives, even though I don't have any of the people that they would manage.

Like, it's a challenge on both sides, right. And so, it's a little bit of just hanging on for the ride, but, you know, in terms of phases, yeah.

I went from writing code to managing directly the team of engineers.

And then so I personally, eventually, I was VP of engineering and then hired a VP of engineering and took the CTO title to split apart sort of operational management from technical direction, right.

And my technical direction at that point was still pretty, shorter time horizon and mostly internally focused.

And then, now I have two VPs, senior engineering managers under those VPs, engineering managers under the senior engineering managers, and then separately, a chief architect, who I mentioned a while back and then some, so we have like a technical track and a management track.

So we have some more senior ICs who think about bigger picture things like the structure is very, very different now.

And I would say at each of those phases, knowing or understanding how to lead has been a constant evolution for me.

And part of that is moving from, you know, from managing to leading, meaning like talking to individuals about their personal thing that they're doing.

And sort of being able to understand the whole picture through that, to setting a high level of guidance and context and direction and giving room for people to take that and do the right thing with it.

I heard this great expression a few years back and I can't attribute it, I wouldn't be able to, but it stuck with me, which was effectively, when I find myself, this is someone else saying this.

But when they found themselves stepping into a situation because they were needed, the question they always asked immediately was, what have I done to create an organization where that intervention was necessary, which is effectively like, how do I change the structure or the knowledge, or what do I do differently such that my intervention is no longer needed in this scenario? Which I think is a really interesting kind of way to think about that evolution.

I mean, it's always going to be a little bit messy when you grow at the rate that we're growing, but that's a real challenge to think about.

And then, what that now does for me.

So at this particular stage of our growth, and I would answer this question differently six months ago, and probably six months in the future, is allows me then to be looking at a longer time horizon because I've enabled the operation of my organization in a way that I can step out of that and be thinking about, you know, where do we need to be in a year, in two years?

What are the major shifts in the market that we want to be thinking about?

You know, that probably fits pretty well into this kind of classic CTO job description, but at smaller scale and at rapid change in scale, you can get pulled into the day-to-day and into the challenges so easily that carving out the time to think about that longer term gets hard and everyone suffers.

And I think that's the other big change for me, personally, is having been a small startup person for so long, having started out sort of doing operational things, all that, like, I have been very reactionary in a way, right?

Like a big part of my career was reactionary because things were so unknown in the moment and making that shift and, you know, building out an organization that's capable of handling those things again, to think longer term and think more strategically is probably the biggest, the biggest shift and the one that is hardest to achieve for most people.

And I think there's, you know, we talked earlier about transitioning from Paul as a founder to myself and Jim growing the organization.

Like people have strengths at different phases of organizations, as well.

And so, riding through all of that has been, it's required a lot of modesty, I would say, and self-reflection and being willing to say, okay, this is the thing I'm not good at.

And I'm going to try to learn something about it really quickly because it has, you know, my role has changed so much.

Grant: Yeah and so what has sort of enabled you to make that transition from individual contributor to manager, to, you know, true leader in sort of like thinking about the future, because you know, there's a handful different options, right?

You could be naturally amazing and talented or you could do total trial and error, right?

And just screw it up a bunch of times along the way, or, you know, I'm guessing based on how you're talking about sort of these books and things you're reading, you're finding outside sources and you're maybe, is it literature?

Is it mentors? Like what's been your path to smooth out that transition?

Rob: Yeah, that's a great question. It's definitely not option number one.

Like, I've never done it, but I obviously just knew what to do, inherently.

Yeah, it's the ladder of your lists like, outside influence in many different ways.

So I'm fortunate enough to live in the Bay area.

And so, the access to other people, either going through the same experiences or having been through them, it's pretty easy to find folks.

And I happen to have a decent network at this point of people in similar situations.

I've joked about this before, but the CTO role is not like there's no, there's no peer in your organization, right?

Like when you, this is true of all executives. If you are the top level owner of a function in your organization, you don't really have peers.

I mean, you have the rest of your executive team who are all responsible for their own thing.

And obviously, that cross communication and all those things are valuable, but there's not, like I can't bounce ideas off of another CTO in the org, right?

If you're a kind of mid-level IC engineer, there's a bunch of people around you that you can just talk to you and say, hey, I'm thinking about doing this thing. I'm thinking about doing this thing, right?

And so the depth of knowledge and context of whatever, like it's a good portion of that doesn't exist inside your organization. So building that network outside, really big part.

Grant: And has that network been formal or is that a fairly informal network of yours?

Rob: Both, so I belong to at least one group, maybe a couple here in the Bay area that's comprised mostly of people in similar jobs, but I also go to things like, there's a series of conferences called the CTO Summit, and it's not just CTOs, but sort of senior engineering leaders and have met people at those that I stay in touch with.

Grant: Who also happen to sort of be your customers in some regard too, right, so?

Rob: Yeah, exactly. I mean, there's additional value to me, but what I end up, like, I've spoken at a few of those and I always end up talking about just my experiences as a leader and the things that I've struggled through or whatever.

Because I think that that kind of content is really valuable for people and that's what other people speak about.

But then, it's one of those that happens to be the kind of conference that's mostly hallway track.

There's a lot of great talks, but everyone, you know, it's like 100 to 150 people. You get to know half the room while you're there sort of thing.

And so building those relationships has been really valuable.

Grant: I always kind of say for, as a CEO, there's just so many mentors and folks that I feel like I have access to.

And most of our investors, you know, have like built and run companies and CEOs are fairly like engaging and out the world.

But CTOs, I think it's a little bit harder because you know, you're a little more focused on internal and technical operations and you're not on every call with different people and you're not--

Like networking is not necessarily a huge part of your job so I've always found it.

We've had to very much be intentional about finding networks and mentors for our CTO, Mark, but it sounds like you've done this pretty intentionally, as well.

Rob: Yeah, well, it's an intentional accident.

I just fell into groups of other people who were struggling with the same thing. And so, and have just been really fortunate that way.

The thing that I think is interesting though, about what you just said is like most people who end up in this role, I'm speaking on behalf of all CTOs in the planet without knowing most of them.

Grant: That's totally fair.

Rob: Are coming from, yeah well. I do many things like that every day, so it'll be fine.

Grant: Yeah.

Rob: But they're going to be coming from a technical background, right?

Like, you grow up to the next level based on the skill that you have at the previous level.

And so, I'm generally not worried about the technical skills or the specific technical challenges.

The things that are challenging for me and I think probably other CTOs at our size of organization and above, and even getting to here, are really more generic leadership and management challenges, right.

Again, how to convey context and intent and direction in a way that's going to land with your whole team.

And I would say like, we've been laughing about my book reading, but you know, I've stopped reading for the most part, O'Reilly books.

Now I love O'Reiley books, but like O'Reiley is like the pinnacle of like tech books to me, right.

And when I do read books that happen to be published by O'Reilly, they're about product management, for example, like ancillary functions that I need to understand better in order to be able to lead effectively.

And then the other books I'm reading are about change management and leading at a higher level and understanding like clearly helping articulate the purpose of your organization versus just the specific details of what you're trying to build right now.

And so, I think it's actually moving, although still in the CTO role, I think that I'm guessing again, I'll be more generous.

I'm guessing on behalf of others, that a lot of the transition is from being an expert in your domain of knowledge, right, which is the technical side into the more generic challenges of leadership.

And the good news is, you can get inspiration from a lot of different places.

I actually, I haven't figured out how to execute on this, but I've been talking a lot lately about trying to find a mentor or coach who comes from like a like a sports background.

You know what I mean?

Like somebody who, at the end of the day, knows how to inspire a team through some really challenging times and some really amazing times, right.

And can communicate sort of really high-level goals in a way that that will rally folks around it.

Because I feel like I've got the technical stuff as much as I'm ever going to need it, pretty much sorted out, you know.

And of course, so now I'm reaching back to my like multidisciplinary, cross-cutting perspective kind of view of the world, which works for me.

And so bringing in some outside ideas, as opposed to just thinking about the technical challenges, I think is kind of a next phase of growth as a leader.

Grant: Yeah, it's a very tough transition, that whole, all the way through.

And so I think the idea of like, "hey, part of the way I make that is I also understand how the other organizations function" is probably a really important part.

Because a lot of what you're doing at the highest level, you know, beyond sort of vision of where the product goes is interacting between the other organizations.

And you're sort of the conduit through which, you know, a lot of the collaboration and sort of how do you mesh different strategies and different internal worlds, right.

I always like to, I talk about, you know, in the security world, like if you read the playbook, if you read, you know, the ISO 27000, you understand how every security professional is going to evaluate your product in your organization.

And so, you know, read the O'Reilly book on product management to understand, you know, how your product lead is thinking about things and the decision, the sort of criteria they're using and the frameworks that they have in mind that you can better collaborate and better communicate.

Rob: Yeah, I think Will Larson, right, wrote an "Elegant Puzzle", which is actually a book very much on engineering management.

And one of the things that he talks about in that is your first team, right?

And as you become a manager, your team is your peers, right? Not the people that you're managing.

And understanding their domain and the things that they think about and how they think about them, is really critical to helping you be an effective member of that team and then, you know, effective at your job.

But I think that that's been a big realization for me, right?

Is that, yes, I am responsible for engineering, but the way that I'm going to be effective at that is to understand how that interacts with the rest of the organization.

And to understand that from the perspective of the rest of the organization.

Like what is important to them? What is it they're trying to achieve?

And then that gives me better context and the ability to share that context with my team.

So they're not looking at list of features, but rather, looking at in the same way that we treat our external customers, the problem they're trying to solve and then can be creative about how to solve that problem.

Grant: Yeah, that's really important.

I mean, if you were making that transition, you know, I think that perspective is really useful and I think it's a hard jump to make.

I think you've done it really well. So in kind of last part here, you know, I mentioned that we know Paul, Paul Biggar, you know, it's the future blog post that is on the CircleCI blog, that I think, you know, has kind of helped create that sort of meme for us.

And you know, but you are thinking about the future and you are thinking about a lot of where software development and this is going.

Do you have any sort of thoughts around where we're headed? What the next few years look like in terms of software, how much more automated does it get? What else do we focus on? What's exciting you?

Rob: So the thing that's probably most on my mind at the moment, especially in our space, is kind of the transition in how we build software and then how that's reflected in how we validate software.

So trying to think up a level, we provide CI and CD tools, right, or a tool for CI and CD.

But when we think about what we're really delivering, and we talked about this a little bit earlier.

We're thinking about building confidence through the validation of your changes, right? So you're making changes because that's how you deliver value out to your customers.

And you want to make sure that they are functioning the way that you wanted, right?

And as we've all shifted and I'm encompassing probably more than, more than necessary in that.

There's been a general shift in the market away from monoliths and towards microservices, we use more third-party libraries and external dependencies.

We integrate all these other SaaS platforms that we've been talking about into our platforms.

The way that we deliver software is getting more and more complicated to a point where certain types of a validation are extremely expensive in a pre-production environment, right?

Meaning the process that I go through in terms of unit testing, functional testing, integration testing, whatever I'm doing in my, ideally in my continuous integration flow gets capped, right?

I mean, there are organizations with thousands of services and the idea that I'm going to spin up thousands of services in a test environment, CircleCI or otherwise, in order to make sure that all of the interactions continue to function, just becomes impossible.

And so there's a point at which, it's actually cheaper for me, lower impact, to test those things in production or to validate them in a production environment, right.

And that is funny in some ways, because the notion of testing in production has been a bit of a meme for years, right?

Like I didn't bother testing it. I'm just going to let my customers figure it out. But we're now making investments in how to do that effectively, right?

By limiting the scope of impact in terms of really good observability on what's happening.

Things like, canaries or you know, gated features, like those sorts of things that allow us to scope and manage and therefore, identify if there's something we didn't really expect that's occurred, right.

And we've been doing this for a long time with things like exception handling, you know, Rollbar, Airbrake, those sorts of tools, Sentry.

I'm trying to be nonpartisan.

We have some experience, but have done it in kind of this ad-hoc manner.

And now we're extending how we do that, but it's a little bit loose, let's say, meaning I have a bunch of tools and I can string them together if I want to.

And they are all tied to the current state of my production environment.

But I think what's exciting for us about that is it brings us back to like, why are we doing this?

Is we have the opportunity to thread that through for you and help you see, oh, this change that you created has flowed through, yes, it got through its unit test and functional tests and integration, whatever.

But now it's out in this small canary in production, and we're seeing this behavior and give you the capability to manage that and tie it back to the source in a way that I think is really helpful.

And I think gets people to a better place, ultimately, in terms of their ability to deliver in these new complex environments and have that confidence.

And so I think that, because of the picture of how we deliver software is changing, understanding what it is that we deliver to our customers and how we can deliver that to them in this evolving world and I think we're on the very, very front end of that, just to be clear.

Like this is very early adopter stuff, but that there's a really cool opportunity for us to you continue to add value through that shift in a way that I'm honestly just excited about building and working on and us delivering software in that way.

I think that one of the things that underlies thinking about that, that's cool from when we talked at the beginning about coming through school and my own training, as in engineering and like--

When you build stuff from an engineering perspective, in classical engineering disciplines, everything is a cost risk trade off, right.

You spend a lot of time and there's like giant tables of materials.

I happen to do some specialty and material science, right?

It's like, this one costs this much and it has this strength.

This one costs this much, and it has this strength, which one do I choose to build my bridge or my airplane or my lawnmower, right.

And so, that kind of discipline and thinking, being applied to software development, I think is really cool.

I don't think we're great at it. I think we have a lot of room to grow, but then using that to make decisions about how to manage the software delivery pipeline, I think is where we're headed.

And I think I'm excited about it from a CircleCI perspective and I'm also just excited about it as a software engineer.

Grant: It's cool. I like that future, as well.

Rob: I think we're headed there so, you can enjoy it with me.

Grant: Yeah, Rob, thank you so much for your time today.

Really interesting for, you know, for sharing so much of what you've learned and you know, throughout your career and in the last, you know, five, six years at CircleCI.

So thank you very much.

Rob: Yeah, thanks for having me. It's been great chatting.