Subscribe
Share
Share
Embed
Candid conversations with the builders shaping the future of engineering.
Braintrust dives into the operational realities of running high-performing engineering organizations, from production readiness and migrations to AI adoption and operational excellence.
Hosted by Ganesh Datta, CTO & Co-founder of Cortex
Ganesh Datta:
You're listening to Braintrust by Cortex, where we explore how engineering leaders blend AI, platforms and culture to build high-performing software teams. I'm your host, Ganesh Datta, CTO and co-founder of Cortex, an internal developer portal designed to help engineering teams ship reliable software faster with AI. In each episode we go deep with CTOs, VPs of engineering, and technical leaders who've been in the trenches, navigating the tension between speed and quality, building reliability at scale, and figuring out how to lead through major platform shifts. Whether you're running a team of 10 or 1,000, this is your space to learn from people who've made the hard calls and live to talk about it. Anish, thanks for being on the podcast.
Anish Dhar:
Thank you for having me.
Ganesh Datta:
I will do intros anyway, but I'm Ganesh, one of the co-founder at Cortex, and you are my other co-founder.
Anish Dhar:
That is true, yes. We've been working together now for what, seven years?
Ganesh Datta:
Six years on Cortex and more years beyond that. This one's going to be an interesting one, a lot of our listeners are engineering leaders, VPs of engineering, CTOs, staff engineers who want to understand how to run engineering organizations. I thought what might be interesting today was just talking about our journey as founders. We started with absolutely nothing, building a product from scratch, and we've delivered this product now to over 100 customers of different shapes, sizes, and industries, and the way we think about the product that we ship has changed. And I think it might be interesting to just walk through that journey and talk about how our own mindset as founders have changed to give our listeners an idea of where they might be in this journey and how they should be thinking about their own responsibilities and engineering leaders, and go from there. What do you think about that?
Anish Dhar:
I think that's a great plan.
Ganesh Datta:
So, let's go back all the way to day one where we decided we wanted to build this thing called a service catalog that didn't exist yet. I remember me and Nikhil, our other co-founder, started working on the backend and we were just hacking features together. We're like, "How is this going to work? We got to build a service catalog." We decided, "Oh, we're going to use these YAML files," and that's going to be the core of everything as we started building around this, and you started working on the frontend. You want to tell us a little bit about how the front end came together? What was the first UI? How did we build it? You were our front end engineer for six months.
Anish Dhar:
I was our front end engineer, yeah.
Ganesh Datta:
Yeah, you want to tell us how that went?
Anish Dhar:
Yeah. I mean, thankfully I was an engineer for a little bit, so I knew how to code. And I wish vibe coding was a thing back then, because it wasn't. I think we would've actually moved infinitely faster if that was a thing. But yeah, I mean, it was a simple React-based app, and honestly we were trying to find product market fit. And so, I don't think we were even thinking about, I mean, I certainly wasn't thinking about how does this scale or what does the architecture look like? It was just how do we get something quick to test in the hands of potential customers? And in the early days, we didn't have anything that any enterprise customer would want. And it's ironic because the problems that Cortex solves are fundamentally much more prevalent in larger enterprises. And obviously larger enterprises have way more core requirements on what they expect from the products that they deliver, but we didn't have any of that. I mean, we didn't have on-prem, we didn't have RBAC, I mean, we couldn't handle any scale.
Ganesh Datta:
I remember the first front end was like we downloaded some React template from some website, and it came with some design components and stuff that we just hacked together. And obviously we've come a far, far away from that, but I think it's just a good reminder of we just had to figure out do people even care about this problem?
Anish Dhar:
Yeah. I mean, we were building something that just literally did not exist in the world. We had no one to even look to it as an example. And these concepts that I think now are table stakes for every engineering leader, the idea that you need some sort of system of record, I think back then people would ask us, "What are you actually building with a service catalog?" They confuse it for all sorts of other applications. And I think it was probably good that we didn't over-engineer it honestly in the beginning, because so many things did change. But what was interesting is the architecture decisions that you and Nikhil made early on ended up being very competitive in a great way for us. And I think it's helped.
The YAML files are still the way people think about their services and import data, but we've just added a ton more automation on so you don't have to maintain it. But back then, yeah, I remember even having swagger as the specification for these YAML files. It just made it so much easier, I think even when we were building for scale later in the year.
Ganesh Datta:
Yeah, let's talk about why speed was so important for us. I mean, we used to be in competitive deals and we would ship features literally overnight, and we wouldn't think about the architecture, we wouldn't think about the scalability of it, but we were moving fast. We would ship things literally within 24 hours, big features that ended up becoming really, really important. But why was speed so important? Why were we optimizing for speed over anything else? Because obviously we've had to go back and rebuild a lot of those things now, because those things crashed and they didn't scale, but people cared about those features. But why was that the case back then, why was speed so important?
Anish Dhar:
Well, I think speed is the only thing you have when you're a startup. When you have nothing to your name and you're just trying to figure out what customers want and you're trying to win deals, I think speed is what gets you loyalty from customers, it just drives urgency. And I think that's always been the cultural ethos of the company, especially on the engineering team. Now, I will say that it's hurt us a little bit in times too. Certainly there was a period of seven or eight months, I think last year where a lot of the things that we shipped super, super quickly, yeah, they didn't scale. We had a few customers where they imported millions of entities and we had never handled that kind of scale before, and we honestly weren't ready for it. But back then, I mean speed was, a lot of our early customers recognized that. And when we would hear something on a call and then the next day just ship it, and I think people appreciate that.
Ganesh Datta:
Yeah. I mean, I think we had customers from back then that are still customers today, literally just because we were so responsive, and like you said, they would ask for something and we would ship it. And I think it was so important because like you said, nothing like Cortex existed in the market, and so we were literally just trying things. We didn't know what an IDP was, we didn't know what a service catalog was supposed to do, and that's the gift and the curse of being the first mover. I mean, we've seen over the years how many of our competitors have copied all the things we built, but for us it was really about trying things, and just shipping things and seeing what stuck and what didn't stick and I think that's why it was so important.
Because a lot of it, when you think about it from a go-to-market perspective, and I think that's what some engineering teams struggle with today is there is a go-to-market component of it as well. It's how do you take something to market and see how people react to it? Do they understand what it's supposed to do? Do they understand the message? And the easiest way to get that information is to ship the thing and get it in people's hands, and see how people react and see how people use it. And so, I think that's why that speed was so important, and you have an opportunity to come back and fix those things further down the road.
Anish Dhar:
And people don't realize we were a platform from day one. We had to be. When Backstage came out and helped define the concept of internal developer portal-
Ganesh Datta:
A year and a half into our journey. We had already launched almost two years before that.
Anish Dhar:
And it quickly changed the perception of what an IDP should be from just a service catalog to there was self-service and plugins, and obviously I think we also introduced scorecards to the world and that's now become table stakes for any IDP. But maintaining a platform from day one is crazy. I mean, most products just have a single use case and a single buyer, and you really just focus and you're able to build. That focus helps you, I think. For us, we were spread thin for a long time. We would have customers who would have radically different use cases. Early on some people, workflows was like the number one thing that they needed to do. Some had scorecards, some were just focused on the catalog. And I think it's stabilized now as people have adopted IDPs, but back then I think one of the unfortunate parts of that is we would have engineers just siloed working on very specific projects because we just had to get things out.
Ganesh Datta:
Yeah. And I think it's interesting, speed is even more important in some ways if you're attacking an industry that already exists, because you might be facing incumbents with deep pockets that are well-capitalized who can throw money at the problem. And so as a startup, the only thing that you have is your ability to out execute and innovate. And I think we have definitely taken that to our advantage. I think being in a new market, you have the advantage of being the first mover because you're building things that people didn't even know they wanted. And so, you have that time advantage because you're ahead of the pack, but if you can do that and be quick, then you're doubling down on that mode. You're moving, you're shipping new things that people don't even realize they need or your other your competitors don't even realize they should be building, but by the time they realize they should be you've already gone four capabilities ahead.
And so, I think it's been really important for us, even to this day, finding that balance between speed and quality. But on that note, let's talk about when that mindset shifted. Obviously we care way more now about quality, and scale and reliability than we ever did before. When, as founders, would you say our mindset shifted and why?
Anish Dhar:
Cortex quickly changed from a platform that when we first started the company, like we talked about, we didn't know what the use cases would really develop, and there was so much exploration. And what I think shifted for us, I mean, I remember when we signed our first million dollar customer, it was I think three years ago, and they put Cortex in the same category that they put Jira in terms of stability. And it was like we need another contract. And the reason is it became mission-critical, and we're now in the literal path for certain customers even though if Cortex is down you won't be able to deploy your service. And so, I think that meant very, very quickly the internal culture had to change as well to match the seriousness that customers put into the product. Especially when you're talking about helping with incident management, or anything that 1% extra downtime for these customers is millions of dollars. And so, you have to start taking it seriously then.
But I think the interesting thing is changing culture can be hard too. The company, we've always prided ourselves moving as quickly as possible, and especially for the go-to-market team, it can feel like a little bit of a shift like, "Hey, things felt like they were coming out every single week. What's going on?" We're taking a little bit longer, but the end result is the quality has gone way, way up too. It's interesting because I do wish we had started a little bit earlier, but I think it was a customer demand that just forced it.
Ganesh Datta:
The other thing I think about is market proof. Once you have proof of the market that hey, this is a thing that matters, that we care about, maybe you're still iterating on what variation of the product and capabilities are the ones that's going to stick, but you found evidence that generally the thing you're building is valuable. At that point you can say, "Okay, well we should invest in the foundations that maybe we may build new features on top of that," but the core foundations are the same. I think that's been an interesting journey as well, knowing now that IDPs are so central to so many organizations, going from what is a service catalog and why do I need one, to we cannot deploy without the service catalog and the information in it I think is proof that, okay, well the service catalog probably should be rock solid, and you should invest in those foundations and whatnot.
So I think there's, as founders, it's having visibility into the market dynamics and how that's shifting as well. I think that's been a really, really interesting part of it. And I think the other thing, your point about go-to-market I think is really interesting because you're not just changing the perception from outside the company, we're changing the perception from inside the company as well. And so, how do you tell a story internally that quality and reliability really matter? And I think it's about showing them why it matters to customers, and then eventually I think it can be a competitive differentiator. We see today none of our competition can handle the kind of scale that we can. We've been through that pain and we've invested in our platform foundations, and now I think Cortex is the only IDP that can handle millions and millions of entities, and scorecard millions of entities, and ingest all this data from different integrations.
And I think eventually that quality and reliability becomes a note. Because if you're trying out the product, and one product works and the other product crashes, which one are you going to choose? And I think that's an interesting transition that's happened in our market is our ability to be consistent or reliable is one of the reasons people choose Cortex.
Anish Dhar:
Yeah, I completely agree. And fun fact, you and Nikhil wrote tests even when it was just the three of us. So, I think we've always tried to adhere to quality, but yeah, I completely agree with you. I mean, the scale that we can handle now, it gives us confidence to support any type of customer. And I think also we have to give a lot of credit to the customers that did have that pain for a little bit. It definitely was a little bit tricky to navigate-
Ganesh Datta:
We wouldn't be here without them, for sure.
Anish Dhar:
Exactly, yeah. But yeah, I think those moments, I think it really defined the engineering culture in a very positive way. I think everyone on the engineering team can probably vividly remember those few months where we were just constantly barraged with scale that we'd never seen before. And it's like champagne problems in some sense, because it's like, okay, that means people are taking your product more seriously. But yeah, it was just a good reminder that it can quickly erode trust too if you don't show customers that you're actually actively working on these things.
Ganesh Datta:
No, absolutely. I want to talk about that testing thing really quickly, because I bet people are wondering why on earth when we had zero customers and we were just building the product that me and Nikhil write tests, and it was basically a way for us to get leverage because we knew that if we ship something, how do we make sure that whatever we had shipped was not going to break? And so, by having tests it meant we could focus on the next thing, and the next thing, and the next thing without going back to think about the old stuff. It sounds obvious that it's the whole point of testing, but even as a startup, even as a three person team, it was so useful for us because we were able to say, "I don't even have to think about that stuff that we wrote six months ago. There's good tests, we'll figure out that later. We're going to focus on the next feature that we need to go and push to market."
So, it actually ended up being really high leverage for us over the years. So, if anyone's listening and wondering, "Should I be writing tests as a startup?" Especially now with AI, I mean, you really have no excuse to not be writing tests. It's so much easier.
Anish Dhar:
It's true. And it's interesting, writing the tests is one example of something I don't think a lot of startups would've done that. Another really interesting thing that I don't think a lot of people also know is we supported on-prem very early. I mean, our first customer was an on-prem customer.
Ganesh Datta:
It's true.
Anish Dhar:
And that just added an insane layer of complexity, and obviously it's very hard to support on-prem deployments, and I think thankfully most of our customers are cloud today. But what would you say to someone who's thinking about supporting an on-prem product, especially as a startup?
Ganesh Datta:
That's a great question. I think going back to a earlier point, it's about proving out the market. And I think for IDPs, if I had to do it all over again I would've made the same decision in our market, because the interesting thing about what we're doing is IDPs are all about data. It's all about the information, it's about the context. And I think Cortex connects to so many different things and pulls in so much rich information about your engineering organization that it was very difficult back in the day to convince customers that they should do that. They had never done this before. I mean, think about it, what other platform gets access to HR data, and security data, and observability data, and on-call data? We were probably the first tool in most of our customers' toolkit that had connections to all these things. And so, going back in that day and trying to convince people like, "Oh, you should give us access to 15 different tools," was probably a very difficult, uphill battle.
So, I think I would do it all over again if I had to, but I think it depends on the industry. If you are building a better version of something that already exists, probably shouldn't fight that fight, especially in an AI first world it's probably easier to build capabilities in the cloud first. I think it depends, though there are some businesses where being supporting on-prem is a competitive differentiator. But yeah, I think it really just depends on the customer. But talking about AI and going back to the idea of speed, I think a lot of organizations are starting to internalize that speed is suddenly becoming a critical thing, not just for startups or even for big companies, because if you can ship more, you can ship more features than with AI, then everyone needs to be shipping more.
So, it's not just for startups anymore, it's for bigger companies. And so, how do we think about balancing now, or how should engineer organizations think about balancing speed and shipping fast with AI no matter the size with the things that we're thinking about now around reliability and quality? How do those things align? Because it's not just for startups anymore, it's for everyone.
Anish Dhar:
I completely agree with you. We get the privilege of working with a lot of ... Every single one of our customers has introduced probably a coding assistant at this point. And I mean, the reality of it honestly is I think the introduction of these systems has 100% increased speed, and you can see it in these large ... I mean, look at the earnings call of Meta and Google, and I mean, all of these companies are seeing now massive revenue. Even ServiceNow, massive revenue jump because of investments in AI and their own AI products, and you're seeing enterprises move quickly and it totally changed their entire strategy around AI. And it is speed, but I also think that there's huge ramifications for this. This code, no one has context on it. You have entire parts of a code base that are just written using a coding system. And yes, it's faster, but I think a lot of organizations probably aren't doing the second level analysis of, "What happens to my MTTR?" Or, "How does my reliability security posture change?"
Every SRE platform team, this is probably the biggest thing they're stressed about right now is how do I ... Sure, my engineering productivity metrics are going up, but what's the full story?
Ganesh Datta:
Yeah, I mean, I think the things that we just talked about, things like reliability, uptime, the ability to service the customer become more and more important with an AI first world. You can't have your LLMs dropping secrets into your code and they don't even realize it. So, are you scanning for secrets? Are you fixing vulnerabilities that maybe your coding assistant has introduced that you didn't even realize? All those things are becoming ever more so important, except I think the difference now is that there's an expectation that you do all that and you're moving fast. I think that's the interesting shift in the landscape that we're seeing today.
Anish Dhar:
Yeah, absolutely. It's going to reach a tipping point. I mean, you're already starting to see it. I forgot which company I saw, someone prompt injected their AI customer support chat agent. And there's no doubt though that this is the next technological wave and it's an unbelievable amount of innovation. But there's always, I think with any new wave, whether it was mobile and cloud, or now AI, it introduces just immense amounts of risk as people quickly adopt these things without really fully understanding the end-to-end lifecycle for them. I'll tell you one thing that drives me mad though is when I see companies saying they're replacing engineers with AI, which just total BS.
Ganesh Datta:
It doesn't make any sense. I mean, the reality is that LLMs are just not there yet. But at the same time, this has been true for how many technologies in the past? We would be sticking our heads in the sand to say that AI's is not removing the need for as many people in certain roles. I think that's the truth, it's creating more efficiency in certain areas, but it creates more demand in other areas. And I think that's where every technological wave has created some sort of shift in other places. You think about the migration of cloud, you needed fewer people who understood data centers, and how many companies were building their own data centers. But the flip side is all of a sudden you needed a lot more people who understood infrastructure, and networking, and cloud things, and scaling, and distributed systems because now more companies could build distributed systems. It was cheaper to do that.
A startup could spin up microservices and ship that on a 10 node Kubernetes cluster where you in the past were probably running a PHP application on a single server rack sitting in a room somewhere. And so, it was just the shift from one type of work to another type of work, and I think that's what's going to happen in engineering as well. It's going to be a shift from one type of work to another. You may need less investment in certain areas, more investment in other areas, what are LLMs going to bring up? Maybe you will have to invest more in reliability and security, and that's becomes so much more important. Or maybe you're going to have to invest in people who are experts in observability when it comes to LLM eval. So I don't know, it's going to be a different transition. I don't think we know the answer yet, but saying that it's going to just remove the need for engineers, moving to the cloud made companies more efficient. It didn't replace the need for engineers.
If anything, it increased the demand for engineers. More companies could be founded, more companies could take an idea and go and push it to the cloud, and it was so much easier to get started, and all of a sudden the demand for engineers went up. And so, I think we're going to see the exact same thing happen with AI now.
Anish Dhar:
100%. And I think the interesting thing that we're even seeing with our own customers is that non-technical people for the first time are able to build technical products. And I mean, you're seeing the success of organizations like Replit, and Lovable, and vibe coding I think has actually impacted non-technical people in the most positive way. They can build internal tools, and systems, and just spin up things that are going to help them with their day-to-day work. And even for our MCP server we just launched, I mean, I was surprised to see the reception from the non-technical people just embrace it completely, because now for the first time they can just ask questions and interact with the product without needing to log in or understand any technical concepts, and I think that's just a net win for everyone.
Ganesh Datta:
Yeah, absolutely. I think it makes it easier for more people to ship things, enables more people to prototype, more people to self-serve things. On the flip side, I think it changes the expectation as well, because if you say, "Hey, non-technical people can build things on their own," the quality expectations for those things is probably lower, but the quality expectations for things that your engineer organization shipping is going to go higher and higher because now people can do more, they can ship more. And as a result, the expectations of the quality of those things I think is also going to go up, so I think that's going to be an interesting transition as well.
Anish Dhar:
The Coinbase CEO, he recently did an interview where he said he interviewed every engineer on the team, and if they said they didn't use AI he fired them. I mean, what's your perspective? If you're an engineering leader who your team existed before AI, all this became a really thing, how should you think about it? Was that too extreme of him?
Ganesh Datta:
I go back and forth on this a lot, I think there's probably some element of an industry aspect to this. If you are a highly regulated industry, like you're dealing with health tech or financial services, probably be a bit more careful or make sure you have the right guardrails in place. You probably should be using scorecards, for example. Do you know how many repositories have secret scanning enabled? Are you looking at how many vulnerabilities there are? Do they all have SLOs? That kind of thing. Having that visibility first is probably really important. You don't want to just let people loose and be like, "Yeah, just merge PRs. You have no idea what they do." But at the same time, if you are an early stage startup or you don't have those same kind of requirements, yeah, you probably should be pushing people to, we were talking about speed, that's a way to increase speed. And so, I think it really depends on the industry, but for the most part people should probably be adopting it. And I think what's important is it's not just for engineering teams, I think it's for everyone.
Anish Dhar:
That's right.
Ganesh Datta:
People should be thinking about AI as a brainstorming partner, as a way to sanity check thing, as a proofreader. I will say, I hate reading AI slop. So, if you are a non-technical person who's using AI, please use it as a way to help you shape your thinking and maybe write things. I do think writing is a way of communicating and it forces clarity of thought. And so, offloading all that to an LM is silly, but you should use that to help shape what you're writing and then go write a thing. But you should be doing that. You should be saying like, "Hey, I've written this document. What am I not thinking about? What perspective should I include? I'm trying to close a deal. How should I think?" There's so many things you should be doing. So, I do think everybody should be adopting AI in those ways. We're coming up on time here, maybe a question from our perspective as founders. What advice do you have for engineering leaders who report to founders at maybe the stage of company that we are, or even an earlier stage startup?
Anish Dhar:
Engineering leaders, especially at our size of a company, it's a difficult role to be in, especially when you have founders who are trying to drive urgency and speed. I joke about quality is super important, but I will push super hard on an engineering team to try to deliver as quickly as we can. And I think that's what makes our working relationship so great is that we have a really good balance of I'll ask for the world and you'll help me realize what we can actually deliver. But I think a great engineering leader does the same thing. They're able to understand the ambition and the goals of the organization, but set the tone on quality and what great execution should look like. I think great engineering leaders are very technical, and can understand and help with system design. And at the end of the day, I think especially as a team of 30, 40 engineers, you'll have a few staff level engineers as well who are spread across the team.
And I think great engineering leaders earn their trust and are respected by your most senior member of the engineering team. And I think that means you have to be pretty technical, because otherwise I don't think people will take you very seriously. I think the best engineering leaders I've ever worked with are also extremely product focused. When I was working at Uber, some of the best engineering leaders I know, they could have been a VP of product if they wanted to. And I think that is a superpower. It's being able to obviously understand how to architect great systems, but know what to build for customers and be able to speak to them. Customers like talking to the VP of engineering, and I think that's a great skill to have. So I would say, yeah, being very product focused is very critical.
Ganesh Datta:
I totally agree. I think if I had to give two pieces of advice, one would be finding out how to maintain that speed. Though we said speed is the most important thing, and as the founders, that's how we made a name for ourselves. We wouldn't be in a position where we could hire VP of engineering if we weren't fast and shipping quickly. And so, how do you surface risk? How do you surface when things are not quick and helping us understand why things are not quick? I think that's one really important thing. And I think the second important thing is helping us see around corners. Like we're always going to push for speed, but as an engineering leader can you tell me what is the next thing that's going to break? That strikes a good balance because you can say, "Sure, I can figure out how we're going to ship this thing really fast," but I need you to give me room to fix this other thing because that's going to break next.
And if you don't want our team to be bogged down by the next thing, then we should go and make sure we're fixing that as well. So, I think being that person who can help us see around corners, I think also comes with understanding the product and being very product minded, being technical, understanding the limitations of our architecture, building the trust of your engineering team. But I think that's another piece of feedback that I would share. Well, I know we're at time. Thanks so much for having us [inaudible 00:28:07]. For the listeners, they don't know that this is literally how we spend our time every afternoon. We just sit for hours and talk about the journey, the market, where it's going, how we want to ship, the features we want to build. And so, it was really cool to be able to do this on a podcast so people could get a little sneak preview of how the magic-
Anish Dhar:
That's right, that's right.
Ganesh Datta:
The secret sauce.
Anish Dhar:
Thank you. Yeah, this is super fun. We'll definitely do it again. Thank you.
Ganesh Datta:
Thanks so much for listening to this episode of Braintrust. If this resonated with you, do me a favor. Share it with another engineering leader who's wrestling with these same challenges. And if you want to continue the conversation or learn more about how we're thinking about internal developer portals at Cortex, reach out to us at Cortex.io. Thanks for listening, and we'll catch you on the next one.