Founder and entrepreneur Jyoti Bansal tells Ben, Cassidy, and Eira about the developer challenges he aims to solve with his new venture, Harness, an AI-driven software development platform meant to take the pain out of DevOps. Jyoti shares his journey as a founder, his perspective on the venture capital landscape, and his reasons behind his decision to raise debt capital for Harness.
Jyoti is a cofounder and CEO of Harness, a software delivery platform meant to modernize your DevOps tooling and take the friction out of CI/CD.
Devs can get started with the developer portal.
In addition to Harness, Jyoti is a cofounder and entrepreneur partner at Unusual Ventures, which specializes in working with early-stage startups (pre-seed to Series A).
Connect with Jyoti on LinkedIn.
Shoutout to Stack Overflow user kukuh, who won a Lifeboat badge for dishing out some wisdom on Android productFlavors in gradle-kotlin-dsl.
[intro music plays]
Ryan Donovan Monday Dev helps R&D teams manage every aspect of their software development life cycle on a single platform. Sprints, bugs, product roadmaps, you name it. It integrates with Jira, GitHub, GitLab, and Slack. Speed up your product delivery today, see it for yourself at monday.com/stackoverflow.
Ben Popper Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. I am your host, Ben Popper, Director of Content here at Stack Overflow, joined as I often am by some wonderful co-hosts, Eira May and Cassidy Williams. How are you doing y'all?
Cassidy Williams Hello! I'm excited to be here.
Eira May Happy to be podcasting with y'all.
BP So today we're going to be chatting with Jyoti Bansal. He is the CEO of Harness and a multi-time entrepreneur with a couple of exits. We're going to be chatting about a few things. One, we had a podcast recently that was pretty successful chatting about a book a professor had written on venture capital and what are some of the alternatives. So for this recent company, Jyoti has raised debt capital, passing on VC even though he has known VCs in the past and worked with them, so I want to understand why he did that and what the landscape looks like for software developers and entrepreneurs out there right now. And then Harness is meant to be a DevOps experience platform. Obviously developer experience and DevOps is something we love to talk about on the podcast, so we'll get there too. So without further ado, Jyoti, welcome to the Stack Overflow Podcast.
Jyoti Bansal Thank you. Great to be here.
BP So why don't you tell folks really quickly how you got into the world of software and technology and what led you to becoming a creator of companies.
JB I grew up in India in sort of a small town in India. And in India when you grow up there, all your parents want you to be either a doctor or engineer or software engineer. And I said, “Okay, software engineer sounds a little bit better. I can’t deal with being a doctor.” So I went to one of the technical schools in India, Indian Institutes of Technology, and after I graduated from there I was like, “Let's try to go to Silicon Valley. That's where all the fun stuff in software is happening,” and I came to Silicon Valley. And when you come to Silicon Valley, you start seeing almost all the innovation and so much activity happens in the startup land and the startup world. When someone has an idea and you can go and create products and solutions to try to bring that idea to the market, there is venture capital, there is access to talent, all kinds of things that we have these advantages in Silicon Valley and I got very fascinated by that. And so working as a software engineer in the Valley, I started seeing problems that developers face. Again, one of the biggest problems that I faced at that time was that we can’t troubleshoot when things go wrong. When things go wrong, it's just hard to figure out. And we are building more and more complex software systems and some things go wrong in software all the time, some bugs, some slowdown, something happens, and troubleshooting is so hard. So that's what my first company was about. I was like, “Let's build out a next generation troubleshooting monitoring platform where we can trace everything that's happening in your software and do that low overhead and try to fix it.” So that was my first company. It was called AppDynamics. I started that in 2008. It was my first foray into entrepreneurship. I was a software engineer becoming a first-time entrepreneur there. But really for me, it’s the passion for solving the problem for developers, which I faced myself first-hand as a developer. And AppDynamics became a very successful company. We have thousands of customers. In 2017, we were about to IPO, and just a few days before our IPO at that time, Cisco came in and made an acquisition offer to us, which after a few rounds of negotiations, famously at that time, we decided to sell the company instead of going IPO. And it was a great outcome for the company. We were sold for $3.7 billion, big successful exit for all the shareholders, all the employees, et cetera. After that, for me personally, I said, “Okay, let me try to retire and not do anything,” but I realized it's not my thing. I like to build tools for developers and actually improve developer productivity. I always look at it from the lens of that we have 30 million software developers in the world, roughly, and the cost of a software developer, if you average over US, Europe, India, China, all of it, is at least 100,000 US dollars. So we have $3 trillion of our economy that we are spending on software engineering and doing software development, and about 30-40% of it is waste. It just could be optimized and there's so much toil and waste in how developers do their job. And so that's why I got back into starting my second company, Harness, which is around how we build a platform for optimizing developer experience and take the toil away from everything that developers have to do from builds and deployments and security, governance, compliance, FinOps. All the stuff that happens after you write your code can be optimized and build a platform from the ground up to take care of all the DevOps, DevSecOps, and all those kinds of things. So that's my journey to starting my second company, Harness. A few years later, I also got excited by another problem, which is securing all the code. One of the problems that we face as developers is that it is hard to secure the code and hard to secure all the APIs that connect all the code. And so I started another company called Traceable, which is in the API security and next generation app security, code security space, so a smaller startup then Harness at this stage. And then finally, at some point I also got fascinated by how we do venture capital. So we talk about raising capital at Harness, but I also got interested in, as founders start their companies, how VCs engage with them and how VCs can help them. It's a little bit broken, so I co-founded a venture capital fund called Unusual Ventures where we focus on very early stage investing and helping with startups and founders and early stage company building. So I would say that's the summary of my journey on being a founder.
CW That's so awesome.
BP Usually when I have a problem with something, I complain about it and then I leave it alone, or maybe I write a blog. You start a new thing, whether a company or venture. You're like, “This is a problem. We're starting a new company. We're dealing with this.” What are some of the things you think are broken about venture capital? Why did you go with debt capital? And what are some of the ways you might advise entrepreneurs to fix that, or some of the ways you're trying to fix that at your fund, Unusual Ventures?
JB That's a great question. I would say venture capital is great for the economy. I'm a part-time venture capitalist as well, so if I didn't believe venture capital was great, I would not be doing that. So I do think entrepreneurs should look for venture capital if they need to grow their businesses. It's high risk for any investor to put money in your company. You're selling equity, investors are taking risk. In venture capital, understand that it's a risky business. The startups are a risky business, many of the startups they invest in won't succeed. And they're fine with it, that's how the business model works, which is great for the innovation economy that you can take a chance and build some things which may or may not work. So I'm a strong believer in the venture capital ecosystem. Why I started Unusual Ventures was the belief that how VCs work with the early stage founders– very, very early stage when you have an idea, I call it the zero to one stage– is not ideal. It needs improvement. Investors have to come and help the companies a bit more and the founders a bit more. What happens in most cases is that where the investors want to help is when a company already has traction. And my point of view is that when the founders need the most help is before they have any traction because most of the times founders are, especially in these kinds of technical products, they are engineers, they have no idea how to run a business, how to do sales, how to do marketing, how to do all kinds of business aspects. So that's where the VCs can help more, and that's why we started Unusual Ventures with that concept. Can we create a platform where very deeply we become part of your extended team to help you in that zero to one stage, and let you take care of the technical elements and we can help you with all the business parts from whether it's sales, marketing, and kind of teach you through that part so you can get from idea to the first million dollars of revenue more. And after the first million dollars of revenue, as a founder, you should have figured out some of those business elements of things and you run with it. So that's why I started Unusual Ventures. The second part of your question is, when we raised capital at Harness, why did we do the debt financing and not a venture capital financing? I would completely separate the two things. It's not that I have anything against venture capital. Harness is a much larger company. We are not an early stage startup. We are $150 million+ of ARR. In the past, at that size you can go IPO as a new company just a few years ago. So we are a very late stage company growing very well. There is still the risk in a startup, but we are not as high risk. So we have options of more different kinds of financing options. When you're an early stage company, selling your equity is the primary option, and that is the right option. Most founders should see that no one else will give you money and take the risk. You have to sell the equity in the company. But when you become more of a later stage company like Harness, you have more options that are available. If your business is doing very well, the business is low risk, the business is at a high degree of maturity, which we are at Harness, we are fortunate that we are so we could attract other options of financing. The primary one is a lower cost debt financing. And so we looked at, if you sell equity in the company to finance the company, or we take a lower cost debt financing, or we do a hybrid of the two, which are also available options, what is the right cost of capital for us? And it was pretty clear doing all the math that the right cost of capital in the interest market at the lowest cost of capital is actually a lower cost debt on that option, and that's why we did $150 million dollars of debt financing in the business, which is the least dilutive for everyone in the company, low cost for us in terms of cost of capital annualized that we have to do, and it's really that. So I don't have a ‘venture capital is good’ or ‘venture capital is bad.’ As a business, really the purpose of the business is to not raise money. The purpose of the business is to build products and drive revenue and deliver value to your customers and drive profits. That's the purpose of the business. Raising capital is just a means to that end. So whatever is the best way to raise capital towards that end is what you do. If you're earlier stage, venture capital is the right thing. And when you get later stages, you have other options and you pick what the right option for you is.
CW You lightly touched on this with just how hard it is to be a founder, especially when the market is a little bit hectic and stuff, and you've been a founder multiple times. Have you taken breaks? Is this something where you've kind of burnt out from being a founder or in general, or have you tried something non-tech and come back? How have you dealt with that personally?
JB That's a great question. I was burnt out after my first company, AppDynamics. When I sold the company, I wanted to take a break, and I did really. My first instinct was, “I can't do this. This was too intense.” It took nine years starting the company to by the time we were going IPO and we sold the company, and it was an intense nine years. I did want to take a break. And I took a break and I was doing a lot of travel and doing something else, all kinds of things like that. But what I also realized is, after about eight months I was really bored with the break, that I do need to go back into what I enjoy, so that's what I did. So I do this because I enjoy building products and building startups and solving some of these problems. And it is intense, so you have to kind of keep taking small breaks in between. You don't need to wait nine years to take a long break, you have to keep taking breaks. But at the same time, you also have to do things that are outside of tech. I have my passion in a few other things like restaurants and making wine. That's kind of my break from tech. If I want to take a break, I invest in some restaurants, I make some wine, and that's my non-tech, I don't want to deal with tech at all.
EM You can sort of context switch into another arena and can give your brain a bit of a break and then prevent pressure to the kind of problems that you're used to working on with these early stage companies. It seems like a really great strategy to take a break by working in another area where you find intellectual fulfillment or something that's totally different like winemaking.
JB Definitely. You also need to maybe use different parts of your brain or different parts of what will challenge you or excite you or be interesting.
CW Sometimes a break still challenges you but just in a different way so you can feel something else.
BP So now might be a good time to segue over. We chatted a little bit about venture and your preference for debt, why it works in this occasion. You mentioned, AppDynamics was created based on issues you had as an independent contributor or working at other companies, so what are the things that Harness tries to do for the DevOps experience? And specifically, it sounds like it's not DevOps in the sense of how to work faster or get to a finished product, but how to avoid burnout and support mental health, which is something we've seen quite a bit in our surveys and research– that developers enjoy their jobs and can feel fulfilled by the work they do, but often struggle with work/life balance and burnout. So what's the idea here?
JB I think that what you see in your surveys is what we see as well, and that's really what was the trigger for me to start Harness. Developers are wasting a lot of time in unnecessary things that could be automated with the right tool chain, with the right set of processes, and it's creating a lot of burnout for developers that aren't doing it. We did a survey around this recently as well, and the findings are very, very similar. The amount of burnout that you're seeing in developers is pretty high. Ours is called the State of Developer Experience, where we talked to 500 engineering leaders and practitioners. We found that about 52% of developers attribute burnout as a primary reason for why they are leaving the jobs. And you have 23% of developers in the survey that we found that they are working overtime for at least 10 days a month. About 62% of developers experience scope creep, expanding requirements, they're taking on more and more things, and just to get going is hard also. We found that 70% of the people in our survey said that it takes at least two months for a developer to on-board and get going with even in the first few code changes and code commits that they're doing. So a lot of inefficiencies in there, but the part that we really see is just the toil. Developers enjoy the creative part of what they do. If you look at the developer job, there is the creative part of the job, which is problem solving. You are given some problem, you want to solve it, designing the right solution, writing code to do it, et cetera. But there is also a lot of the non-creative kind of manual repetitive tasks which take about half the time, and that's what creates much more of the developer dissatisfaction, because they don't really want to do it. They don't enjoy it. No one does, and you're doing the same thing again and again. But those things are important– that the quality is right, the security is right, you have right checks and balances. But a lot of those could become automated and could become streamlined and remove a lot of the toil away, and that's where we focus on at Harness. The origin of Harness when I started the company in 2017 was along those lines. I was seeing the problem myself with a lot of AppDynamics customers at the time. Almost every AppDynamics customer that is solving problems on observability, they'll all complain about the problems around DevOps, how much toil is in DevOps, how hard it is. And we will see at Harness itself. We were about 500 engineers at that time when we sold the company to Cisco, and we will see with 500 developers in the company, we are always struggling with DevOps and the toil that comes with it. We couldn't ship code fast enough. We had so many people doing manual scripting, manual DevOps kind of things. And it was costing us a lot, but still we were not getting the right developer satisfaction, the right velocity, the right quality, and the stress that comes from the developers was high. And that's what it was for me. You joked about how I see a problem, I want to solve it, and I was like, “Someone needs to solve this. Why is everyone building homegrown DevOps things?” Pretty much every company I talk to, they're building a homegrown DevOps tool chain. I was like, “Does it make sense that every business in the world is creating a homegrown DevOps tool chain?” You go to these DevOps conferences and people will very proudly present how they build their homegrown DevOps toolchain. And yes, it's a good thing that you were to build it, but should you really? If you are a travel company, you are a bank, you’re a insurance company, you are an airline, should you be spending your time and energy in homegrown DevOps toolchains? Would they be good enough? It's so ironic that developers have the worst tools out of most of the jobs. The strange reason is because they can do their own stuff. Salespeople, for example, can't build their own tools because they're not programmers. They can't build their own tools, so they have to buy professional commercial tools. Same with HR people. They normally can't build their own tools because they're not programmers so they have to buy professional tools. The problem is that, because developers can build their own things, they feel that they should build their own things, and they have their full-time job as well, which is to build innovation for their business. So the tools become a side thing and they are very suboptimal tools as a result. So of almost all professions, you see developers have the suboptimal tools because they try to build on their own instead of having professional commercial tools to help them with their job. And that's really what I wanted to solve at hand– just bring world-class commercial professional tools to developers and we reduce all this toil and all of this productivity loss that's happening which is costing everyone a lot. It's 40% waste. There are 30 million developers in the world, hundred thousand dollar cost. $3 trillion is spent on software engineering. You're wasting a trillion dollars out of three trillion dollars. So a trillion dollars of waste in the world that could be solved with building the right tools, and that's what we've been building at Harness. We started with building tools for CI/CD. I would call it the next generation of CI/CD platform. Most people use things like Jenkins in larger enterprises. We're kind of changing that out to a completely next-generation tool chain that can remove almost all the toil that comes with CI/CD. Feature experimentation, feature management, FinOps, security testing, developer portals, every aspect of the DevOps tool chain we have been systematically building out in our platform to reduce the toil from them.
CW That's awesome. It's It's kind of like a lot of developers would prefer, “I'm going to build this Lego set from scratch instead of just buying something that already works.”
JB Which is great, but the problem is that now someone has to maintain it. Someone has to keep up with it, and have your real job, to build the products that your company wants you to build. So the side thing that you build now becomes this very suboptimal tool to do your job and now you're inefficient. A year later, two years later, that tool is used by 50 other developers in your team and they're all running inefficiently because of that. I do think as an industry as developers, we need to go and change that.
CW I think that's a big problem for startups in general too, because a lot of companies are just like, “Oh, build or buy,” and then developers always lean towards build and they should probably just buy and move on, so that way they have these efficiencies that are built by people who are experts in this kind of efficiency.
BP Jyoti, I'm not trying to pick on you here and make fun of you, but I think there is this funny mentality among developers where you're like, “Why do developers have the worst tools? It sucks. We’ve got to build something new.” And then you're like, “But developers shouldn't build something new. They needed to use something off-the-shelf.” And it's like, “Wait a minute.” There's always the mentality of, “I want to fix it. I want to make it better. I want to optimize it. I could build it.” and then, like you said, there's, “But wait, pump the brakes. Maybe we've got a solution for you and you can focus just on this piece over here.”
JB It's a good question of where is that balance. I would encourage developers, if you think to do some part of your job, the good tools are not there, instead of you trying to build it part time in your existing job as one hour a week because you have to do your full time job and build some tool to do that, maybe start a company to build the tool. Get funding, hire 10-15 engineers and build a great tool to do that so you can support it and do it, which is hard to do, but I would say that's what I would encourage. I would actually try to encourage through my venture firm as well. That's what we should be doing. So there is good investment in these tools because it's not like the developer cannot build a tool. The problem is how would they do it as their part time job with one or two people doing it and the company doesn't really want to invest too much into it. And then you do end up with these suboptimal tools. Most of the homegrown tool chains are not very good. Unless you are a very, very large company that can afford to put dozens and dozens of engineers on those, most companies cannot.
BP Cassidy, I think you've told me about this, but there is that outlier where people say, “Oh man. Once you get inside Facebook, or once you get inside Meta and you've been working there and they built everything and they've always focused on developer experience, and it's just so fun once you're in there.” But of course, for most people, it's not going to work. It's because they've been scaling and building in that direction and had the resources to do it.
CW Right. And it's a double-edged sword or whatever too, because sometimes the big companies have such custom solutions that you're just like, “Well, I'm used to this very specific thing. Now when I go to this other company that's not as big, you're like, ‘Oh, well I guess I have to build this from scratch or buy a tool?’”
JB I think that's exactly the debate. The tools that the Metas and Googles and Amazons have built over a long, long time, they're very custom built. They cannot be really used by others outside of those companies that easily. Why shouldn't everyone else in the industry have the same caliber of toolchain? And that's really what our thesis is. Let's bring the same caliber of toolchain, but more generalized, that's not as customized, but that can be used by everyone and bring the same kind of experience.
BP Or there's another solution which a couple of startups we've talked with are using. If you're building something really great– one was even inside of Spotify, I think. They're a fairly large company with a long history. If you're building something really great internally and you notice when you take it out to conferences that other developers love it, what you should do is open source it. Now everybody's going to work on it. Now it's not just your developers, but everybody who's maintaining it and contributing to it, so you have both the internal and the external benefit.
JB Yeah, definitely. And that's great. Anytime a good project like Spotify Backstage comes out, that's great for the community. Everyone can work on it, and I strongly believe those are always great. There are opportunities for everyone in the community to engage in it. Harness is a big part of that project that Spotify made open source and we are helping the community, we are contributing there, but we also provide a kind of a more managed professional offering around it. Because when it's open source, the engineers at Spotify know how to operate it well, but if you go to many other organizations, you're a large bank and you want to try to figure out, “Okay, how do I use the same project? How much effort do you have to put in,” they need some help. Then there's an opportunity for professional vendors like us to help provide that help, and there's opportunity for the community to use those projects and contribute to those projects. So it's always great when things like these happen. Kubernetes is a great example if you think about it. That's one project that came out of Google and what they built internally and definitely helped the entire industry.
BP Yeah, Kubernetes is a great example.
[music plays]
BP All right, everybody. It is that time of the show. We want to shout out some folks who came on Stack Overflow and contributed some of their knowledge or their curiosity. We have a Lifeboat Badge awarded to Kukuh, trying to figure out how to add some Kotlin in their Android project. They're stuck on product flavors. We've got a great answer in here. It's been viewed 8,000 times as part of our Mobile Development Collective. So if you're interested in mobile development and you've had a question in this area, there is an answer for you. As always, I am Ben Popper. I'm the Director of Content here at Stack Overflow. You can find me on X @BenPopper. Email us with questions or suggestions, podcast@stackoverflow.com. We love having listeners on to be guests or just chat about some topics you suggest. And if you like today's show, leave us a rating and review. It really helps.
EM I'm Eira May. I'm also on the Editorial Team with Ben at Stack Overflow. You can find me online @EiraMaybe.
CW I've been Cassidy Williams. I'm Senior Director of Dev Advocacy at GitHub. You can find me @Cassidoo on most things or at Cassidoo.co.
JB I'm Jyoti Bansal. I'm CEO and founder at Harness. Harness is a next generation software delivery platform, helping you with all modern DevOps, CI/CD, feature experimentation, FinOps, security testing, everything you need to reduce developer toil. You can check us out at Harness.io. You can check me out on LinkedIn, on Twitter. Social is @JyotiBansalSF. And I look forward to hearing from you.
BP Great. All right, everybody. We'll put those links in the show notes. Thanks for listening, and we will talk to you soon.
[outro music plays]