Rob Zuber

I'm the CTO of CircleCI.

What is it like to be the CTO of CircleCI?

Well, I've been the CTO for 11 and a half years, so it's been a lot of different ways, I'd say over that time.

When I first started here, we were 14 people,

and now we're a lot more than that. So at the moment, being a CTO in a developer tools company is pretty exciting. The SDLC software delivery lifecycle is changing significantly, almost on a daily basis.

What we do in our mission, what we're trying to solve for people, delivering great software doesn't change that much. But as a CTO of a developer tools company, meaning I am an engineer, building tools for engineers, it's something I've always been really excited and passionate about, and because there's so much changing right now, it's just a very exciting time to be thinking about the problem of software delivery.

And so I would say it's very hands-on at the moment, not like I'm building the product, right? I have a lot of people that build product, but if I'm not in the mix and thinking about how things are changing, I don't have a lot of value to add. So it's an exciting time to be doing that job.

I am not, but I am building things on a regular basis because it gives me a feel for what's possible and what kinds of problems we can solve for our customers.

Yeah, so yes and no.

The no being,

we're not capable of changing that quickly, right? So you have to look at across a spectrum. That's one thing we have to understand as a provider of these tools. We have customers across a huge spectrum in terms of where people add in their adoption, what they understand, where they're trying to be, right? And so we have to solve the problems of the people who are at the laggard end of the scale and the people who are way out on the front end.

And then our engineers trying to be productive every day. Like they don't want to change their tooling every day. They do want to adopt new things, but they also have work to get done. So it's finding that right balance. But absolutely, between reading news, kicking the tires on things, I've been around a long time in engineering, so I have a lot to lean on, but I have to figure out how do I apply that in the context of this new tool, this new capability, et cetera. So I lean on all of the knowledge that I have, and then I absolutely, I spin things up, I try things not because I have a deadline or a goal that I'm trying to, I need to build this thing, but if I don't do some building, then I become very disconnected very quickly.

Whoo!

I don't know if there's one particular thing. I think,

I am, I'll say this, I don't have a computer science background. I studied engineering, engineering physics.

I went and worked in a factory, and then I ended up sort of transitioning into software because of things that I learned there, but I think there's so much change in how we're thinking about software engineering that it's moving away from being just a computer science problem, and so the reason I highlight those other details in my background is it's a broader engineering problem, like it's a very multidisciplinary engineering problem, and bringing ideas, bringing approaches from other disciplines allows you to come up with creative new ways to approach things that are maybe not in the domain of software anymore,

and so I like that. That's just, I am a,

since I was a little kid, I just like taking things apart and building things and understanding how they worked and figuring out what was possible, and I think our domain has grown really quickly because what we're trying to achieve is different from just sitting down and writing algorithms the way we've, I mean, we haven't always just been writing algorithms, but the whole model has shifted enough that this multidisciplinary, fresh ideas, that just is interesting and compelling to me.

Yeah,

I think you need the disciplined understanding of software. I think that we can achieve sort of significant leaps in what we're doing by bringing ideas from other places, right? And so I, again, I just really enjoy bringing all these different perspectives together and looking for novel solutions to interesting problems. I mean, we're here at this event talking to a bunch of people about how they're building, and I've learned tons of things in the last hour, just about very, very different perspectives because everyone's trying different angles.

And so we're shifting a little bit from, you know, tried and true patterns to a little bit more open space, and that's just exciting. I mean, as an entrepreneur, as an engineer, those are exciting opportunities for me.

Yeah, I'll go with yes and no on changing hiring. Absolutely, the things that we test with, right? How we think about executing a technical test or something like that has shifted, obviously, because the tools people are using are changing. But we have always been a product-forward engineering company. Like, we're engineers building tools for engineers, right? And so on the one hand, you could say, well, everyone understands the problem because they are engineers, but we really want, in order to get that understanding from our engineers of what our customers might be grappling with, we need people who think about the product. Not just I'm going to implement a thing, I wanna know what the solution is that I'm creating for the customer, what problem I'm solving for them, and be able to drive towards that, regardless of how we implement it. And I think that's becoming maybe more prevalent. Like, a lot of people are talking about making a shift to more product-oriented engineers. That's something that's been consistent with us.

But I think that is more forward in the interview process, maybe. Like, that's the thing we're leading with, as opposed to just can you code. Because how you code and whether you can, it's changing so quickly. What we really care about, and what we really focus on is that, do you understand the problem of the customer? And as we've been discussing that problem, the shape of the problem is changing quickly. Ultimately, we care about teams delivering great software to their customers quickly, but how we get them there and what tools they're using changes how we think about that. So we need people who are super curious, wanna be relevant in the market, like understand what's happening and changing, and are very product-forward. That's mostly always been true, but more than ever, I guess I would say.

Yeah, absolutely, absolutely. I think, and particularly as things change really quickly, the way that we think about executing, about planning, about how we test an experiment, all of that is shifting.

Because the time horizons just shift in terms of how you construct and how much the market changes while you're constructing.

That's something that we're also very focused on, is that again, the curiosity drives the willingness to change and say, "Oh, well, this situation has changed. "Let's go pursue this other problem."

We can't get set in our ways because the change is just too quick.

Yeah.

Yeah.

Yeah, it's a change.

Right, right, yeah. The first early adopters. Yeah, that was about 2011, yeah. Yeah, I mean, it would have been late, late 2011. I think the product actually launched early 2012. I joined mid or early 2014.

And obviously, a lot has changed in that time. And we're talking about change now. But we've been through containerization.

Well, probably first, Web first went to mobile first, and then it was containerization and Docker and orchestration and microservices.

Somewhere in there. I mean, just getting people to go from, "Okay, we're doing continuous integration to continuous delivery and continuous deployment." Like, it's just been a constant world of change. And now we're on a new, just the trajectory of change, or the rate of change right now is bananas.

Yeah, it's a great question. I mean, I always have to remind myself of the bubble that we live in. Like I am the CTO of a developer tools company in the Bay Area selling developer tools to shops that want to be great, right? And will invest. I don't spend a lot of time with people who are like, "CI is for the birds, it's a passing fancy." Like no one actually needs that.

So I probably, my view is skewed. But we're seeing it in the data. Like certainly even within our own data. Like I think if you look at Dora metrics or something, you know, we talk about the different quadrants or quartiles.

Our customers are probably all in the elite quartile, right? But there's a lot of stratification within the elite quartile. Like I want to take that and break it apart.

And if you, DX has done a great job of publishing numbers showing, yeah, on average, we're not seeing a lot of shift. But if you break apart that average and you look at the distribution, you've got people that are getting worse and people that are getting better. And the ones that are getting worse, right? The challenge is we don't have or they don't have the infrastructure in place. And I'll call it infrastructure like CI CD is real.

Observability, like all the tools to help you manage that, right? And you're gonna be cautious about what you've built because you don't have the trust to put something that you build out in production. But there's a lot more to moving quickly than, I care a lot about CI CD, but like, are we good at defining what it is that we want? Do we have, like, do people have clarity of what our goal is as a company? Like start at the very beginning and in so many places, like AI will not fix your problems. Right? If you're good, AI can make you great, right? Like if you have all the tools and if you can be really confident in what you're delivering and you can, and you have well structured architecture, right? Well written code with arguably with documentation and code documents itself to an LLM, right? But if you have all that in place, then you can see a big uplift. And then, you know, you have cultural aspects. You have so many different factors that come into play. But if you're missing anything critical in that whole flow, you know, you're just driving a Ferrari into a ditch kind of thing, right?

Yeah.

Yeah, I think we've seen that already, right? Pre AI, I mean, the evolution or formation of platform teams and that whole structure, right? Like is an acknowledgement that a portion of our time and energy should go into the tooling that allows us to deliver, right? I might be buying all that stuff off the shelf and gluing it together, but still somebody needs to manage and own that, right? And I think, in some organizations,

people just carve out the time, but forming a team and giving it a name and giving it ownership and a goal or a charter or whatever, is really operational management in the sense of like, we are protecting the time of this percentage, right? It was like everyone, when you have some spare time, work on platform things,

then you're up against the deadline, right? And it's like, well, now we're under crunch time. So the platform things go, we stop testing, we stop whatever it is, and we're gonna get this thing out. Although testing usually makes you faster. Just like, I'll plug that in, right? So carving out capacity and saying these people, these humans, their day, every day is spent making us better because that returns is something we saw happen before AI. But if you made those investments and you got here, now you're like,

thank whoever did that, right? Because now we're ready to accelerate even more. We have, you know, robust testing, we have fast pipelines, we have confidence in our observability once we put something in production. All of those things give us the freedom to take advantage of the acceleration. If everything else is slow and clunky, now we're just like, again, it's like a little bee in your bonnet or whatever, racing around, trying to get stuff done quickly, and just, you know, making it worse.