CEO Speaks with Tariq Shaukat of Sonar

It's great to be here, Ben. Thank you for the invitation. Looking forward to it.

Good point. I have a long and winding road of a career. I sort of say it's a bit of a random walk, but I'm very fortunate that it ended up in a place I'm very happy with. I'm an engineer by training — mechanical engineering. I'm in software now but started off in mechanical engineering. My first couple of jobs out of school were in the tech world, pretty entry-level roles, a little bit of consulting, a little bit of enterprise software. I then spent a bunch of time in both the consulting and the consumer world. I was at McKinsey for a long time, and then I was the chief commercial officer at Caesars, which was really my first big organization that I was fortunate enough to lead. I went from there to Google to help get the cloud business off the ground. If you had said at the beginning of my career when I was in mechanical engineering would I end up in the software world, I probably would have said no. The transition from engineer to business leader was not that hard a leap because of what I enjoy doing — I really enjoy talking about the vision, setting up operating cadences. If you apply engineering to how do you get the business results you want, that's what I think of as my management style. I was fortunate enough to have mentors who helped me get into those positions.

It's a great question. This is one of the things a lot of people miss who come from a traditional business background. It's not that you have to understand exactly how Kubernetes works or how a server functions. It's obviously helpful to immerse yourself in the product. If you're going to be a business leader in the technology world, you need to know your product inside out. But leaving that aside, there is a way of thinking about problems — I often talk about first principles thinking and systems thinking. Systems thinking and the system dynamics of an organization, of a product, of an ecosystem — it's an engineering-centric approach to improving business performance. To give a real example: when I got to Bumble, it's a dating app, tens of millions of people using it. But fundamentally, if you strip it all away, it's a two-sided marketplace. You have to find people who want to meet very specific other people, and it has to be mutual. Not different than Uber — you have drivers and riders — except in Bumble, the driver has a lot of perspective on what rider they want and vice versa. One of the things we did very early on was literally lay out how are people successful on Bumble, really thinking about it as a system flow — step one, step two, it's a positive reinforcement loop. I'm giving this as an example because it's an engineering mindset approach to business. When you explain it to the engineering team, they get it. All of a sudden you can connect the dots between what you're trying to build in sales and why that financial metric is important, because you're showing how it all fits together and creates these virtuous cycles.

For sure. If you ask what the connective tissue is between all the different things I've done, they're all tech-enabled businesses. Marc Andreessen said it over a decade ago — software is eating the world. Almost every business is a tech business in some way. The distinction between tech companies and non-tech companies is increasingly blurring. Is Tesla a car company or a technology company? It's a technology company that happens to build cars. The through-lines for me are data and analytics — Caesars runs on data and analytics, and we applied it in a best-in-class way to marketing, customer segmentation, and customer experience to improve profitability. And the willingness to raise your ambition and to experiment — that's a big distinction. I had a customer in my Google Cloud days in the oil and energy business. He eventually said, we spent five years thinking about the hole we're going to dig, we're going to put two billion dollars into digging that hole, and then we finally say go ahead, but we can't make a mistake because we spent two billion dollars. Whereas in cloud, yes you can make mistakes, but software is much easier to experiment with, much easier to be iterative. There is a mindset difference. The mindset is how do we make sure the data is available to everybody, how do we really capture and use data, and how do we have a mindset that says should we be doing this differently. That's the Google legendary 10x thinking that Larry and Sergey insisted on. That mindset you find in startups, inside Google, and I think it's sometimes the biggest thing missing in companies trying to digitally transform — they almost try and transform the processes as they are, as opposed to saying how would you reimagine this if we could start from scratch, recognizing there's real constraints.

Let me introduce Sonar. We are the world leader in code quality assessments and code security. If you're a developer writing code, we've got seven million developers around the world who use our tools to check that the code is of high quality — maintainable, reliable, readable, generally high quality code — and an increasing number of people are looking at whether the code is secure. We do this in a way that is very developer-friendly. We started as an open-source developer tool. In the industry there's a lot of talk about shifting left — we talk about starting left. How do you just start in the IDE as you're writing the code with quality that ensures your code base gets healthier over time? We've got almost 30,000 customers around the world, 400,000 organizations use us because of the open-source footprint. What attracted me is really what I was talking about earlier — software has eaten the world, every company is a software company. There's this expression that AI is not going to take people's jobs, it's the people who use AI are going to take the jobs of people who don't. Something very similar exists in the software world — companies that get better at software are going to outperform companies that don't. What excited me about Sonar is that code is the building block of software, and the quality, efficiency, and security of that code can play an unbelievably important role in improving overall corporate performance. I like to do big things that are going to have an impact. This was a growth-stage company — 600 people, a couple hundred million of revenue — so it's a scale player but not Microsoft or Google, which I've done. You could really have an impact and drive the direction of the business in an area that will continue to grow, particularly with AI now transforming software development. We have a right to be one of the authors of what happens in the future of the software development world. That really excites me — similar to why I joined cloud in 2016, which was pretty early days. You could shape the industry, shape the evolution, and I find that really personally motivating.

You have to build it secure. This is the big thing people are realizing. It's one thing to put up a big wall around your castle, but if your castle is going to fall down the second somebody throws an arrow at it — I'm stretching my metaphor — but if you build it right, if you build it secure, if you build it reliable, there are studies that show it's like one-tenth the cost compared to fixing issues later. If you've got a rotten foundation in your house, you maybe have to tear it down or do real structural rework, versus taking that extra step to make sure the foundation is strong. That's what we really believe — by starting correctly, by empowering developers to do this right as they're getting started, by giving them the tools and data and information, we can help companies save tons of time, energy, resources, and improve customer satisfaction. You don't want your application to glitch out when you're on the treadmill or driving your car.

There's a lot in that question. It fundamentally gets back to the point that somebody has to design how this codebase is supposed to work. In many companies, particularly ones that have been around a long time, there's not been one author — the codebase evolves. To your biology background, it's been an evolutionary process on most large code bases. Even at Bumble, when I got there it was about a 10-year-old company, and there was all sorts of evolutionary baggage — some of it is tech debt, some of it is just complexity, or we built it in a monolithic way when it should have been modular. There's a dependency that nobody remembers why it exists, but now it exists. In my geekier moments, I talk about the entropy of a codebase — the natural state of any large organization managing a large codebase left unchecked is that you'll have more and more chaos and disorder. Think about a large bank with 20,000 developers all working on this codebase — how do you make sure they're actually building towards the architecture? If you come back to what Sonar does, our core strength is we know as well as anybody how to analyze code. We can analyze the structure of your entire codebase — dependencies, how it's structured — and we can do it analytically. It exists as data in a structured way. So we can get your architecture and then put rules in place that become guardrails for your development team. Our hope is it helps control this entropy, this emerging disorder. What really excites us is not just the traditional need but the huge need in an AI-enabled, AI-assisted way. We acquired a company called AutoCode Rover that builds one of the leading AI software repair agents. When you think about an agent working on five lines of code, that's relatively easy — now multiply that by a large bank with two billion lines of code. What is the north star for the AI to start understanding the codebase so it's not adding complexity and disorder? We think this becomes almost an imperative in this rapidly evolving AI-driven world — you can't really live without that architectural understanding.

I would love to naively say this is just a tech thing, but there's always a people component and a process component. You've got architects in most companies — maybe not as many as before, maybe they're not as empowered as they should be. What we're trying to do is give them the megaphone, the tools to have the designs and strategy they put in place be embedded in rules in the development process so developers at least have awareness of when they're reinforcing the architecture or not. We very much believe every company should decide what's right to enforce. Our tools enable you as a company to do this the way you want. Having the information will empower the developer and the architect to make decisions in a very explicit way. When I was at Bumble, our architecture was captured in a big Lucidchart — lots of boxes and lots of spaghetti connecting the boxes. We took it seriously but that was how it was managed. What we're trying to do is bring structure and rigor and pull the developers into the conversation, as opposed to this just being yet another thing imposed on development teams.

We're really proud, and I can't take any credit for this. The origin of the company and its footprint is really a testament to the early teams and the founders. I joined a year and a half ago as co-CEO with our founder. He stepped down to what he very much with relief in his voice calls just the founder role now. This was a company started because they as developers felt a real need — they were frustrated managing development teams and didn't have a good way of controlling the quality of the code. It started off 15, 16 years ago now as an open-source project in Geneva — not Silicon Valley, one of the more unlikely places. It has grown as a Geneva-based company for 15 years, largely bootstrapped the entire time. We've got a very deliberate way of working that's core to our DNA. We've been cash-positive from day one, we're very cash-positive now, and growing. It's a rare company these days that didn't do growth at all cost. The reason this has all worked so well is because they focused on the developers — how do we give developers insights and tools they want to use. One of the things we're proudest about is the level of open-source and developer-led adoption. One of our seven priorities for the company is be indispensable to developers — it's our north star. It drives real product decisions and real go-to-market decisions. We focus obsessively on minimizing false positives. Any code scanning tool will make some mistakes — if you do it eight times out of ten, developers will tune you out. Part of being a developer tool is making sure you're not disrupting their workflow, giving them high signal and relatively low noise. Our north star is what will get a developer to actually use this. The founder Olivier is almost the guardian of the developers inside Sonar — as we try to do more for other personas, he's always there asking, does this work for a developer, is it adding value?

We have a business with seven-plus million developers who use the platform. We're very proud of it. Yes, we built the reports that a chief compliance officer can give to regulators — it's not that we're indifferent to enterprise needs, but there is no business, there is no product if the developers don't use it. The notion of train and pray — I'm going to train my developers on this tool and pray they use it — too many enterprise software companies in the developer space try that and find they're spending a lot of time and energy on stuff developers are just not excited about. Do we get it right all the time? We don't. We were just in a product review this morning talking about our false positive rate, which we think is best in the industry, but it's still too high because it's not zero. We're not resting on our laurels, but the purity of what we're here to do — it's got to be easy to use, compelling, high signal, low noise. These things can't interrupt the way developers do things. You get into a flow, you don't want to get out of it — how do we attach ourselves to that and help?

We at Sonar happen to be very lucky — there's that curse, may you live in interesting times. One of the areas being disrupted the fastest is software development. It's not that software development won't exist — it is fundamentally changing. Cursor, Codium, Copilot — these are absolutely changing the way software developers work. A lot of the press has got it wrong. There will be a lot more people able to write software from scratch because of these tools — the barrier to entry is super low and getting lower. But if you're working inside a large car company, you still have to make sure it's not going to crash and nobody can hijack it. In our mind, the nearest impact is reducing a lot of the toil work, the repetitive work. Stripe put out a study saying half a developer's time is spent on stuff that is not creating value — documentation, debugging, remediating tech debt. AI is going to play a massive role, but it will be very different depending on what slice of the world you look at. What we're seeing is an explosion of code — more code is being written because you can write it faster. That code has hallucinations, errors, and there are malicious attacks being put into the LLMs themselves. It's creating a whole new level of uncertainty. One customer recently said they're experiencing an outage a week because they're using AI code generators and their code review practices aren't up to standard. The problems AI creates are subtle and hard to find — it makes up a library name because it seemed logical that it should exist. Platform engineering is now a real thing — you need to standardize your development toolchain because all these changes make rigor, discipline, and structure that much more important. We're riding sidecar to these AI code generators because you generate the code and then need to check it for quality and security. Lastly, the expectations have changed — four years ago the answer was educate the developer, now it's take all the context about what created the issue, feed it into an LLM, and see if it can come up with a fix. I caution my team constantly: don't believe the headlines. The headlines are almost always sensationalist, and it's going to have a bigger impact in some parts of the market than we expect, and a very different impact in other parts.

That's what I would say. If you go back to cloud, the traditional companies that have done best are the ones that were ready to change the way they do things and become more adaptive. The AI world is very similar. It really gets down to: the companies that do AI better are going to outperform the ones that don't. However, I'm not sure democratizing is exactly the right word — the waterline has risen. Satya Nadella said recently that a lot of enterprise software right now is basically a CRUD database with a nice user interface on top of it. You have your data, and as a company you couldn't make good use of cloud if you didn't have your data in good shape. In an AI world it's ten times more important. If you do have your data in good shape, you can start building your own applications much more easily than five years ago. I do think it's raising what's possible and everyone has access to it, so from that standpoint it is democratizing the capability. But now it gets down to people, process, and mindset.

I was just on a call with our chief growth officer, and we're using some functionality from Stripe which is great. He was marveling at the fact that he no longer needs to relearn SQL because the chat interface to get business insights out of the database is just so intuitive and easy and effective. It really is changing the user interface — it's making a lot more of a company's information and data accessible to other people, which is great. Then you're as smart as the question you ask. Understanding what questions to ask will become a huge value. I have kids who are about to go to college and you keep wondering what should they be studying. Maybe it's philosophy or something like that in the future, because knowing what questions to ask and knowing how to critically think will be even more important because of AI and LLMs.

Well, and how to critically think about the results that you're getting back — that's the other critical part. An LLM will tell you something, you've got to figure out is it making it up, is it actually smart, and what do you do with it. That becomes the competitive advantage now, not who can write the fanciest SQL query.

All right, good to see you and looking forward to our next one. Bye bye.