How to Build a Technical Strategy That Solves Business Problems | CircleCI CTO, Rob Zuber

**Rob Zuber** (0:00)
And the first time I did Continuous Deployment, which was like 2011, I was terrified. Deployment used to be seven gallons of coffee and four all-nighters in a row to try to get the thing to work.

**Conor Bronsdon** (0:11)
And I was like, we're gonna do that every day.

**Rob Zuber** (0:12)
That sounds awful, right? But then we tried it, and I was like, this is amazing. I will never not do this, right? I will never stop delivering value to customers as quickly as I think about it. Here's my idea. Now it's in the hands of customers, like there's a little typing involved, but that's going away apparently.

**Conor Bronsdon** (0:28)
Is your engineering team focused on efficiency, but struggling with inaccessible or costly Dora metrics? Insights into the health of your engineering team don't have to be complicated or expensive.
That's why Linear B is introducing free Dora metrics for all of you. Say goodbye to spreadsheets and manual tracking or paying for your Dora metrics.
Linear B is giving away a free comprehensive Dora dashboard packed with essential insights, including all four key Dora metrics tailored to your team's data, industry standard benchmarks for gauging performance and setting data-driven goals, plus additional leading metrics, including merge frequency and lower request size. Empower your team with the metrics they deserve. Sign up for your free Dora dashboard today at linearb.io/dora, or follow the link in the show notes.
Hey everyone, welcome back to Dev Interrupted. I'm your host, Conor Bronsdon. And today I'm joined by the CTO of CircleCI, Rob Zuber. Rob, welcome to the podcast.

**Rob Zuber** (1:21)
Glad to be here. Thanks for having me.

**Conor Bronsdon** (1:23)
My pleasure.
It's really great to have a technical leader like yourself here. You've been a two-time founder, obviously doing massive work at CircleCI. And it's given you this in-depth perspective on when efficiency is paramount in technical expertise, how businesses grapple with aligning technical direction to business goals, and avoiding wasted time and resources and missed opportunities when you're leading. And as an expert in crafting technical strategy, I know you're giving a talk today around how to do so effectively. But I'd love to understand the risks of failing to do so, because I know so many companies struggle with this.

**Rob Zuber** (2:02)
I think it's a great thing to think about it, and to be super clear, I would not call myself an expert.

**Conor Bronsdon** (2:07)
I'll do it for you, don't worry.

**Rob Zuber** (2:08)
Well, I mean, all of that comes from trying many, many different things and learning and trying, and maybe we'll call it failing, having a hypothesis, seeing what works, what doesn't. All that stems from exactly what you're asking about, which is that the risks of being misaligned, the cost, the overhead of maybe building things in a disparate direction. So I would say a couple key things in there. One, aligning folks across an organization so that you get more leverage out of the work that you do.
Often the same problems are being solved in pockets around organizations.
And you don't necessarily want everyone waiting for one person to solve that problem, but as a leader, you often have visibility that individuals or maybe teams don't have where others are facing similar challenges.
And so helping lift those up, surface them, identify, hey, these folks have a really great solution. Maybe you can learn from them, take from them. Maybe we can build something that others can use, et cetera. That duplication is a trade-off, right? There's sort of individual velocity or throughput, right? But over time, that tends to build up as sort of debt across your organization where you're paying for the maintenance of many different implementations, let's say, of a solution to a similar problem. I think engineering leaders as a whole, once you get to, let's call it a director level, which is sort of the audience here, are really not just engineering leaders, right? They're business leaders. Their responsibility is to use technology to drive the goals and the outcomes of the business.
And so one of the challenges that we face as engineering leaders is the investment time horizons for technical strategy tend to be longer than the time horizons that we have clarity about the business, right? I mean, particularly look at the last few years, so many things have changed so quickly. Feels like chat GPT and like generative AI showed up overnight, right? I mean, it was like 60 years in the making, but it still feels like November 30th, 2022 was like the day sort of thing. And so being in a position to adapt is a big part of what you should be investing in technically. And I think people tend to get focused engineering leaders. And again, I'm speaking for my own mistakes, too focused on sort of a precise view of where the business is going and what you're trying to achieve versus what I now refer to as the sort of set of most likely outcomes, right? Like the span of those possible futures, if you will, and putting yourself in a good position to adapt. I mean, from a software delivery perspective, we've spent the last 20, 25 years moving from waterfall to agile and then CI and CD and progressive delivery. All of these tools are designed around the assumption that we are wrong, that we won't know what to build, that that MRD, PRD, whatever was not right.