Harness CEO Jyoti Bansal: The enterprise needs guardrails to ship code quickly

Jyoti Bansal has no time for golf.

The serial enterprise tech startup founder knows he works more hours than the average Silicon Valley executive, which is already a pretty high bar to clear. But that's the price you pay for running four companies simultaneously: a startup incubator (BIG Labs), a seed venture fund (Unusual Ventures), a $450 million cybersecurity company (Traceable), and Harness, which has raised $425 million in funds and was last valued at $3.7 billion.

Harness is focused on arguably the most important part of the software development process: delivery. The company sells a continuous delivery platform that also incorporates some other vital steps in the development chain, such as integration, security, and cost management.

While releasing smaller pieces of software more-or-less continuously has become the norm inside the tech industry, enterprise companies in other sectors of the economy are still trying to figure out how to move faster without breaking anything. In a recent interview, Bansal argued that those companies will only buy into the need for speed if they can be assured that they can still ship safely and cost effectively.

Over the course of that interview, he discussed the Biden administration's push for software bill of materials requirements, supply-chain security worries, and the calendar-juggling feats needed to run four companies.

This interview has been edited and condensed for clarity.

Runtime: Over the last decade or so, it seems to have become very obvious to mainstream enterprises and businesses in general that releasing software faster has huge benefits. I'm wondering, now that that knowledge is spread more widely, if you're seeing examples of folks who are maybe taking a more of a thoughtful approach to how they release software.

Jyoti Bansal: Most people have wanted the speed of shipping things quickly, but most of the larger enterprises haven't fully gotten there.

The thing that was always important for them is like, it's not just the speed. Facebook had this tagline "move fast and break things" and if you go and take it to a large bank, and say "move fast and break things is how we move fast," it just doesn't work there, right?

If you look back at the history of CI/CD, it started with CI (continuous integration). Jenkins was invented and people started doing CI right; integrating your code change into some repo and running the tests and making sure the code is shippable. But shipping the code — the CD part of it — was always the biggest problem.

And the first thing that we did (at Harness) is (realize) you need to break CI and CD. People almost use CI/CD as one word; it's really two different words and two different practices. In CI, the personas that need to be involved are different; it's mostly developers and QA. When you start getting into CD, you have everyone from security, governance, compliance, infrastructure management, cost management, and then SREs; everyone has to be involved in the production deployment process.

When we launched Harness — this was like in 2018 — the only way you could do CD was either home grow your script completely on Jenkins, or you tried to make Spinnaker work. From my perspective that was like, "no, this thing is completely broken and no one is happy." Let's go and solve the CD problem by building a proper platform for CD that simplifies the deployment, but the core of it was "move fast and not break things."

Velocity is only one part. You have to bring (security, cost management, compliance), and that's the only way to ship to production every day.

What do you think about the push for a software bill of materials, and how those kinds of requirements play into this kind of product?

I think it's a must-have idea. Almost every piece of software that someone is shipping is composed of so many things now. It's similar to when you buy a car, and the car is composed of so many pieces that someone assembled together; like, you don't build a car, you assemble a car, really. That's how it is in software.

You ship software as a container, and the container has so many third-party libraries, API calls to other things. Not having a bill of materials of what your software is composed of, it does create a major security challenge when a new vulnerability comes out.

Everyone got a shock when the Log4J vulnerability came out. Log4J is everywhere, and people still can't easily figure out the answer, like, "tell me all the pieces of software that are deployed where I'm vulnerable to this thing." And figuring it out was months upon months of work for many people.

I think it makes a lot of sense. It doesn't make sense to not understand what is deployed, where (it's running), and what it is composed of. We think it should be very deeply integrated in the CI/CD pipelines. And we are launching many more capabilities on that front — management around tracking it, integrating that into the CI/CD pipelines — all of that work we are doing.

Is that something you currently offer? Or is that something you're working on?

We are launching later this year.

On the same token, the whole notion of a CI/CD pipeline itself seems like it's a pretty rich target area for a software supply chain attack. How have you thought about that over the last couple of years, as this has become more top of mind?

We very, very strongly believe in security as a first-class component into the CI/CD pipeline, and we designed with that in mind from day one. We are the only CI/CD pipeline that very strongly incorporates OPA, or the open policy agent, as a governance framework around everything that you will do in the pipeline.

So you can define OPA policies on who can make a code change of a certain type and what would be the criteria around when would we deploy it in production systems, what tests need to be run … all of those will be governed through very well-defined OPA policies. So the SolarWinds thing, for example, if an OPA policy around who can do what was clearly defined, it would be a bit hard for a hacker to come in and do what they did to SolarWinds.

Platform trends come and go, between companies that want to be one-stop shops for software development to others that want to focus on a given area, like CI/CD, and do it really well. How do you see Harness evolving?

We want to become the one-stop shop. And we are systematically growing; we started with CD and CI, feature flags, cloud cost management, SLO (service-level objective) management, chaos engineering, (and) insights in your software engineering processes. We take a modular approach: we have eight modules in our platform, but we are building many more modules.

But the approach that we take is that we don't force our customers or users to use all of it. We believe in a very open ecosystem, and the ability to work easily with others. People can use our entire platform, or they can choose three of ours, and two others. What it also does is it makes sure that we are building best-in-class on each of these. If you don't think ours is best-in-class on something, don't use ours. Use something else.

Are you running four companies right now? How do you do that? How do you manage your time around that?

There's a few factors to it. Number one is the people. If you have the right people that you can trust, that you can work with in a way that makes it easier to manage time, then you can focus on the things that matter the most.

The second part of the answer is … I really think in terms of not time management, I think in terms of impact management; where can I make the most impact, where I can move the needle significantly. Most of the time, I'm a product guy, so it's about innovation and setting the right product goals, but many times, it could be raising capital or hiring the right people or some kind of go-to-market strategy, pricing strategy … whatever it is. Where I can make the most impact is (where) I like to spend time.

So instead of saying, I spent 30% time here, 40% I'm here this much, it's really focused on making an impact and having the right people around to do that. That said, I do work longer hours than most people, but it's my choice. It's not like anyone asked me to, because that's what I like to do; I don't have interest in playing golf for six hours, you know. This is my passion. So that makes it a bit easier.