Demystifying Software Development: A Conversation with Engineer-turned-CEO

Ori Keren, Cofounder and CEO at LinearB, began his career as a software engineer and team leader for Interwise and CloudLock. Along the way, he noticed major flaws in the software development process and the black box it can be. Today, his company is focused on streamlining the software development process and demystifying the work of software engineers.

I sat down with Ori to discuss the major milestones on the path to building a successful company, his efforts to secure a seat at the table for software engineers, and the potentially radical impact of generative AI on the future of software development.

I think this conversation will be extremely helpful for founders working on businesses that build for and sell to software engineers. Can you tell us about yourself and your journey with LinearB?

In the early days, when I was 13, I built my first program in BASIC. I mention this in every interview I do because this thing was like magic to me—like a small piece of art. With this device, you could play games, input code, and build things. So naturally, I started my career as a developer. I was really passionate about building things and understanding what a product should do. I was promoted and eventually became a team leader and the director of engineering, for two startups that grew very quickly. The first was a company offering a product similar to Zoom, before Zoom was a thing, that was acquired by AT&T in 2007. Later, I worked in a cybersecurity company called CloudLock as VP of R&D. We were acquired by Cisco at the end of 2016. Those roles prepared me for what I’m doing now.

Every entrepreneur or founder has their own journey. My journey involved growing through all the pains of life inside R&D. Once the Cisco acquisition happened, their corporate development folks invited me to start looking at and evaluating other companies. This built my appetite to do something of my own. I did it twice. The second time, I was very involved in all of the details of the acquisition. I said, “Okay, I’m ready to see the full picture.” So that was my process. I had to go through all these early stages, through a natural and very organic process, to start LinearB.

What we do at LinearB is collect data and use that to optimize the day-to-day R&D systems and align R&D investments to business goals. I missed those features so much when I was in my lead engineering role because I would be heading into meetings with my CEO, and time after time, failing to communicate, “Here’s the state of our organization. We’re trending up here or we have a problem here.” There were no standard key performance indicators. But the CEO knew all about the sales processes in a very intimate way. I wanted the same relationship and that’s why I started LinearB.

LinearB’s platform is here to help engineering leaders deploy a metrics program that shows how to do things correctly, and then provides ML-powered automation to fuel that improvement. On one side, you’re making sure that the things you’re measuring are aligned with your business goals and helping your CEO to understand their situation. On the other, you’re maintaining operational efficiency, building programmable workflows, and finding and fixing problems in your development pipeline. Not all of the changes that run through this pipeline are the same, so we’re helping to solve the problem of classifying them. This enables teams to implement the right policies.

That’s LinearB in a nutshell: creating a better workflow empowered by data.

I’d love to understand the work you did with design and development partners in the early days of LinearB. How did you structure those partnerships and transition them into paid customers?

We have two founders, myself and Dan Lines, also a former VP of Engineering. From day one, we decided to build a go-to-market function, without an actual product yet, and build that product side by side. Not many companies do that. Before we started the company, we built a very simple proof of concept. Then in 2019, we started developing the product. We started looking for design partners with a simple proposition. We’re not going to charge you money. Give us access to your system. We’ll report on your development process and help your team measure itself.

Immediately, there was a lot of interest. We were very quick to find these customers early on and provide them with something that could elicit feedback. That thinking has always been in our DNA. Eventually, we reached a significant value point. We had two or three design partners ready to take the next step. They bought the product for a year and that’s when we realized we had something here. That was the foundation of the LinearB platform.

In software, sometimes people ask for too much when they need initial integration in order to begin demonstrating any value. They introduce something a bit too architected or robust, which makes customers hesitant to allow access to their system. You had a very lightweight, simple value proposition to offer in exchange for access to your customer’s information. How do you manage that?

You’re touching on a very interesting point. In order to show value, integration is key. You have to reduce the friction and ensure people aren’t forced to connect with systems they aren’t comfortable with. When we onboard customers, they’re sometimes connected to six or seven different platforms. We decided that we would focus on one integration that would require the minimum amount of access possible. It helped that I spent time working at a security company. We had to prepare our security practices and demonstrate how we work and secure our customer’s systems.

Now, we’re ready to come to a conversation, ask for access, present, and prove that we value a customer’s trust. It’s important for us to show the measures we’re taking to protect our customers. We also pride ourselves on how easy it is to onboard to the LinearB platform - it’s one of our differentiators.

What’s it like for you being a CEO, after having spent your career as an engineering leader?

Every day is so unique and different. Through my time as a developer and team leader, I have come to know this space very well. It’s interesting to see things from both sides, sitting at the CEO's chair while coordinating with my VP of engineering and understanding that it’s time for engineering leaders to get a seat at the table. It’s time to be accountable, measure the things that are important to them, and move away from the conception held in many organizations of engineering as a black box. These are really exciting times.

On a personal level, I really enjoy it. Every day is so unique and different. I recently read this amazing blog post about a CEO writing his job description every year to see if he’s still the right person for the job. I totally identify with that. Every year, I ask, “Okay, what do I need to do as a CEO to grow to the next level?” These things change so rapidly. That’s what I like. We’re a product-centric company, which is my strength. You really have to understand your business data: your pipeline. We have hundreds of customers and we know the status of every one of them. You have to work with the numbers to understand what’s happening in every aspect of your business and still know when to listen to qualitative stories and I love that part. I’m passionate about the problems. I enjoy talking to people in the company in order to solve them. So I’m enjoying my role every day.

Take me to the mountaintop of LinearB’s success. Where do you want to take this business in the next several years?

The problem we’re trying to solve is really big. I think that five to eight years from now, you’re seeing an entirely different landscape of how software is being developed. Today, the development process doesn’t flow. Somebody thinks about a problem, they implement a solution, somebody needs to review and approve it, and then you run tests. The entire process depends on disparate systems. You have one extreme, where companies work through trunk-based development. You write the code, it immediately goes to production, and you trust your developers to implement enough tests. On the other hand, companies use an extremely regulated process, with many guardrails and complex development processes.

Somebody needs to find the middle ground. We’re trying to solve that problem. I think we can make a true dent in how software is being built. We want to be the platform that orchestrates this process. There’s so much toil and inefficiency in the processes used today and we’re in a great position to show that, from the highest level of the business to the lowest, there’s a solution for that.

It seems like you're interested in transitioning from analytics, insights, and recommendations to focusing on workflows and the practical implementation of software. How do you consider the competition within that space?

We have a component, called gitStream, that lets you orchestrate and automate how your code is moving through the development pipeline. People love it. When they buy LinearB today, they’re buying our analytics, as well as gitStream. So we can be the one that helps you orchestrate your processes end to end. Of course, there’s going to be competition. There are many big players in the software space; our big advantage is that we’re objective. Some competition exists today and some of it will arise in the future. Being the ones that provide all of the context and language in which people program their pipeline is an amazing direction for LinearB.

How are you thinking about generative AI as it pertains to engineering workflows? Are you seeing an impact on the workflow of your engineers?

First of all, LinearB is what we call customer-zero. Our engineering organization is always using our product. So I’ll answer this from the perspective of our engineers and also our customers. Generative AI definitely feels like a major shift. Every company in the world needs to ask themselves, “How can I use this? What is my strategy?” Otherwise, you’ll be left behind. We’re spending a lot of time refining our position and our approach to AI. At LinearB, our business isn’t telling customers how to write code. We step in when the code has been written and figure out how to streamline the process of getting that code through the pipeline and out the door efficiently. We’re in a great position because, with all of the machine-assisted coding happening today, there is a real need for a platform to facilitate the development process.

I do think there will be compliance and security issues stemming from this wave of generative AI. Malicious people are going to exploit any security flaws in these language models. So there is a need for gates to an extent, to ensure that machine-assisted code can run smoothly. We understand how we can contribute to solving this challenge and empower customers to make these decisions consciously. Our role will be to enable this revolution.

Today we are already leveraging AI/ML in our platform to suggest best practices and automate tasks in the code journey like estimating the amount of time the approval would take, suggesting the best reviewer, or suggesting the shortest CI path, to help make the day-to-day of devs easier, and to improve operational efficiency for engineering leaders

You started with the design process in a top-down direction. It sounds like you introduced a product-led growth (PLG) motion second, which is what many consider to be the way to build a business today. What were the benefits of taking the route you did?

In the beginning, we had to address the possibility that people would log in to use the product, view the dashboard every week or two, and log out. Obviously, this isn’t sustainable. Retention wouldn’t be where we needed it to be. So we had to address two main things. One was making sure that the product wouldn’t just be some kind of static metrics program. The second was building a layer of R&D metadata to improve workflows. We knew that we had to provide value to practitioners and developers. That’s when we developed a PLG package.

We stood at an interesting crossroads after COVID hit. Our PLG motion had been very successful. People started raising their hands to buy the product for their companies. So we saw two motions happening. On one hand, people who are coming to our website and are ready to buy after a short trial and on the other a pure PLG motion that takes more time but is more viable in the long term. We thought we had to choose one motion. But with all of the global instability because of COVID, we realized we had to pursue both motions. And it’s proved itself 100% because we successfully grew the business by emphasizing the the-top down motion. In terms of customer acquisition, it’s a 60-40 split, with 60% coming top-down and 40% from PLG. I think it was a very good decision because it enabled us to grow and provided us with time to inject PLG strategically.

Especially in today’s economy, you must find people with the patience to work with you on the PLG motion. Investors lose patience. Again, nobody gives you the right answer but for us, it was the right decision to do both, which we continue to do. It enables us to scale up the business, build confidence, find investors, and optimize how we utilize PLG. It can do amazing things to your product.