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 (00:00):
It sounds like you went from doing one to two releases a month to doing almost 10,000 deployments a month. Where did that whole journey start?
Boyan Dimitrov (00:08):
The challenge we had back in the day was we had a very complex monolith. We were only able to deploy it every couple of weeks. We also had a lot of silos within the organizations. The net result of that was we were just low. We wanted to ship more and we wanted to ship at the same level of quality. And we wanted to make sure that as we are going through this transition, people can focus on the business problem instead of in the end fiddling with environments, figuring out how to ship or deploy something, spending all that time to reinvent the fire in every single team.
Ganesh Datta (00:52):
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 engineering operations platform designed to help organizations continuously improve their operational maturity and reduce developer friction. 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 a thousand, this is your space to learn from people who've made the hard calls and live to talk about it. Hey, Boyan, welcome to the podcast. I'm Ganesh from the CTO and co-founder at Cortex. We're an internal developer portal, and we help organizations with their platform and reliability strategies. Today, I have on Boyan, who's a CTO at SIXT.
(01:54):
Very excited to have you on. Would love to get a quick introduction.
Boyan Dimitrov (01:57):
Hey, Ganesh. Thanks for having me on. My name is Boyan. I'm the CEO of SIXT. Yeah. Super excited to join this conversation. I've been with SIXT for about 10 years, and previous to that, I've been engineer and founder of different startups, so pretty excited of how things are shaping on today.
Ganesh Datta (02:17):
Well, excited to have you on. A little bit of context for our listeners. I had an episode a couple episodes ago with Kaspar, who's the CEO of Humanitech, and he had lots of amazing things to say about SIXT platform transformation strategy. If you want to hear about that, definitely go listen to that episode. But I'm very lucky to have you on to actually come and talk about your own platform strategy here on the podcast. One of the things that really stood out to me as I was looking up your platform transformation, correct me if I'm wrong, it sounds like you went from doing one to two releases a month to doing almost 10,000 deployments a month. Talk us through what that looked like. Where did that whole journey start?
Boyan Dimitrov (02:57):
Yeah, that takes us a while back. So about 10 years ago, roughly when I joined the company, we were having a challenge when it comes to the frequency wekinship. Here, I have to give you some context. At SIXT, we are a premability provider. We operate in over a hundred countries, and our mission is to basically develop the best experience when it comes to current or to our customers. And that's, of course, easier said than done. Serving customers in over a hundred countries comes with its challenges. People prefer to be served differently depending on where this takes place. And at the same time, we also have to oblige with a lot of local regulations, laws, et cetera. So what it means for us and what it means for tech engineering is that we have quite complex environments and quite complex software that we have to build, which really works at that level of quality and standards across all those countries.
(04:02):
And this is where declines a challenge. Very complex business environment, very complex business software that we get to build. 95%, by the way, of the software we built is built in- house. The challenge we had back in the day was we had a very complex monolith. We were only able to deploy it every couple of weeks, and often those deployments also went pretty difficultly. We also had a lot of silos within the organization, so there would be engineers who would be writing or solving a business problem. They would be handing it over to operating teams who would somehow figure out a way to deploy this. And the net result of that was we were just low to ship value to our customers. So this is the problem that we were trying to solve. And from there, our North Star was we wanted to ship more, we wanted to ship at the same level of quality.
(05:03):
And we wanted to make sure that as we are going through this transition, we keep in the end, the ownership for the whole thing where it belongs with the people who shape and create those experiences. And at the same time, we wanted to make sure that people can focus on the business problem instead of in the end fiddling with the environments, figuring out how to ship or deploy something, and spending all that time to reinvent the fire in every single team. So those were some of the problem statements that we had on the wall. And this is how our journey started. Pretty soon as we embarked on how to transition our organization, how to change how we work and how to change how we build software, we arrived at the conclusion that we have to make certain choices if we want to succeed. And one of those choices was we absolutely wanted to reduce fragmentation.
(06:11):
We absolutely wanted to reduce entropy between the different teams because as I mentioned, we wanted to put all our investment and all our effort of all the smart people that work for us in solving our customer problems versus playing with solving some basic technology problem on the way in 20 different ways. So this is in the end what I would say, looking backwards, set us on this path for extreme standardization, which resulted in our platform engineering organization, which afterwards also resulted in all the holistic platforms across web, backend data, MLOps that ended up emerging over the years, and that's how things went.
Ganesh Datta (06:56):
One of the things you mentioned as you were describing the beginning of the strategy was the desire to balance quality and velocity. And I think this has become a very hot topic today because with AI, we're writing a ton more code and we see that velocity is going up. We released a report recently with a survey on engineer leaders and pulled some of our own data across industries, and we're finding that the data shows teams are moving faster, they're shipping more, but quality's going down. It sounds like at SIXT, you guys actually saw the opposite.You're able to move way faster, but maintain or increase quality. And it sounds like the standardization and reducing fragmentation is want to enable that. How does that add up? Why did standardization and reason fragmentation lead to both an increase in speed, but also an increase in quality? Because sometimes people maybe think about those things as trade-offs, and it doesn't sound like that's the case.
Boyan Dimitrov (07:48):
Yeah, I also don't think that's the case. It's a bit trial and error when it comes to figuring out which are those components, which are those right abstractions that you want to focus on. For us, it was really about the first principles of how this experience should look like and which problems we want to be solving within our engineering teams and which problems we want to be solving essentially. So the approach we took was we knew we were going to make mistakes. It's super hard to find silver bullets in anything you do. And we tried to go for this 80% approach where we would choose a technology, could be, I don't know, anything like a build system to a, I don't know, go line authorization framework. And we would see if it really fits to the most complex problems that we have in the majority of the teams, the common denominators.
(08:44):
And if it does, we would abstract it away and we'll make it available for everybody as a service. And as we do that, we always build it modular and extendable via APIs, meaning that for the people, for 80% of the teams, they can consume this and make it part of their workflow out of the bat. It just works. And for there, 20% which might have a very specific niche problem to solve or very specific workflow, and it's not about, I want to eat a white or a chocolate ice cream, but it's more about, I have a problem and this solution is just not good enough or parts of it not good enough, then what they can do always is integrate additional functionality via APIs that stitch together, still rely on those foundational components to do the heavy lifting. So that's pretty much how we put everything together.
(09:42):
It also is what allowed us to keep modernizing and evolving it because I think a lot of people, when they embark on a journey, A, they go slow, B, they also try to, once they have made a decision, stick with it forever. Reality is, and we see it with AI as well, technology changes and it changes very fast. So lose abstractions is the way to go, at least in my opinion. And this allows you to exchange components on the fly to review this plane as it's flying and to continuously innovate also in this space to make sure that you continue to serve and address the challenges of the different engineering teams and in the end of this idea to value cycle as close to possible based on the environment you find yourself in.
Ganesh Datta (10:41):
I think it's such a great call-out. One of the failure modes that I see a lot with platforms and platform managing teams is the desire to build everything like, oh, we need to build a whole platform. And then if we build a whole thing, then people will come versus, hey, let's actually build small slices and get to the 80% mark and iterate on here quickly because we don't really know what abstractions work. And going and iterating on that, I think is such an important call out. It sounds like the idea behind improving velocity through standardization by keeping quality the same was kind of putting guardrails on things. So it's not that we're saying, oh, you can't do things or you can't break out these escape hatches, but if you're going to do things that's within these specific guardrails, these are the standard ways of doing things.
(11:23):
And that actually made it easier to operate the entire system and then gave teams more autonomy to build the stuff that really mattered on their engineering teams. Rather than continuously each team building their own plumbing, it was like the plumbing was given to them and now they focus on actual value, but then the plumbing gave them standards around reliability and quality and observability and all that kind of stuff. Is that a good way to summarize the strategy there?
Boyan Dimitrov (11:49):
Yes, a hundred percent. So it's a pool and a push topic. I think that's what makes it work. I've tried also in the past for different projects to go only with pool, you build it and they're going to come. In large organizations, that works in small teams, right? That definitely does work. But in large organizations, that's just never going to work because everybody's busy. Everybody's on a mission. There are plenty of missions, infinite amount of missions. And if you want to get something done, there must be pool and a push together. And for us, what this means is the pool is you want to build an amazing experience. For me, an amazing experience is you join a company as an engineer and from the get- go, you get a laptop and you can ship something to production at our enterprise scale at your first day, and there is nothing you can break.
(12:43):
And that means that how to figure out what projects you have access should be there, how to get started, make a diff, push it somewhere, security analytics, QA, build, whatever, all of that should be there. Whatever you ship, you should be able to ship it for small potential traffic to small test. You should be able to test it alongside the main stuff and see that it doesn't break anything. You should be able to see observability immediately, logs, traces, whatever is there. All of it should be for, you should never think about that stuff. That's for me a great experience. Or that's maybe pre-AI great experience. I might have some newer ideas there, but this is the pool and anything that you built, it should just work and which you offer for others to use. The experience we were looking for, at least at SIXT to us, and that was before even the term was coined, but everything felt serverless.
(13:37):
And I think that was the biggest pull for everybody because you don't have to maintain any infrastructure. You don't have to think about how my application scales, whatever. Even if it answers a container on some Kubernetes custom somewhere, it just works for you amazingly. We just press a button on some UI or you do chatbot, chat ops, whatever you fancy. We have different modalities for different, I guess, tastes, but all of it is centralized behind the same deployment and build systems and platforms, for example, and they will orchestrate the whole thing. And this is the pool. Pushes, as a leader at that point, it's my job to say no when everybody says, "But I would love to also have this other thing I saw on Instagram yesterday when I saw on Twitter yesterday, it looks amazing." And that's where the push comes. We go and we say no.
(14:30):
And the way it works with us is for soft problems where the obvious solution is right there and it works amazingly if you want to go and you want to ... Because in your previous company, I don't know, we are all Postgres, but for whatever reason you want to go and you want to do MySQL or MariaDB or whatever New Wave database came out yesterday for your solution, we will tell you no, unless, I don't know, you produce a three-page concise thoughtwork where you really manage to convince that the existing solutions, automations, and everything else for you that exists is just not good enough. And you absolutely cannot solve your problem. You have reached all the limits and you cannot solve your problem what's there. That's pretty much it. It sounds dramatic, but it works and it allows for whole organization at that point to move to a direction, otherwise you will never get it together.
(15:40):
And we will definitely wanted to avoid the debt by thousand cuts because that is what usually happens.
Ganesh Datta (15:49):
Yeah, I love that. I mean, it's this idea of autonomy with guardrails. You give people the autonomy to build what they think is valuable where you put guardrails around that. And actually over time, that creates momentum because then people are spending more of their time, their capacity focusing on business value producing activities rather than the plumbing and the infrastructure and doing things in four different ways across the organization that leads to thrash, which leads to quality regressions. And actually saying no may hurt a couple of times, but eventually it builds up that momentum. So I really like that and I think it's very, very important. One of the things that come to mind as you're describing this, you mentioned the next generation with AI. It sounds like all of the work you guys have done in creating consistency and standardization around the platform probably is paying dividends or will pay dividends as you think about building AI agents and bringing more of that into your platform strategy.
(16:44):
Is that true? Is that the right way to think about it?
Boyan Dimitrov (16:47):
100%. While at the same time, a lot of things are also going to change and that's also great. Where we see massive wins is because for example, we have standardized our whole internal stack when it comes to, I don't know, service to service communication at SIXT, we are a JPC shop, so everything internally, but also to many of our end clients picks JPC. It's super easy, for example, and that we've done that a couple of years ago already to just inject a layer, or not a couple of years a year ago, inject a layer and have everything MCP enabled. So all your capabilities as an organization already being able to be plugged to all the different Agentic Workload modalities that people are building, using, et cetera. Or another example, because we standardized years ago and we spent so much work on design systems for our frontends that our customers use, apps, websites, anything digital experience related, but also internally for all our internal apps, hundreds of them that our business users use, they're all built in the same way.
(18:01):
They follow our design system principles. What this allows us to do is to now start adopting heavy generation and all those webcord apps also start looking or screens all start looking the same or exactly like everything else. And while now we are speaking with you in what, January 26th, Vibe calling your landing page or using a lowable Manus kind of experience there is obviously, I guess for many standard by now, but we were able to generate full-blown enterprise screens for apps and websites in April 25, and that's because we had all those building blocks in place. And if you think about where MCP was at that time, I think you would appreciate the uplift that you get when you have a structured house, so to speak. So that those building blocks, which have been extremely helpful for us and they continue and will continue to allow us to accelerate the speed of delivery and keeping our quality up, at the same time, things also going to change.
(19:18):
Back in the day, because we really wanted to automate so much, we also had to make a lot of, I don't know, opinionated decisions when it comes to build templates and I don't know, standardizing around certain libraries and have a very rigid workforce in certain cases, just to make sure that in the end, everything that gets produced works the same way so we can automate it the same way, et cetera. Those layers, they all be gone and they're being replaced as we speak because with AI, we don't need that stuff anymore. We can very much figure out package and deploy anything. And that's amazing because it allows us to actually loosen up and have a lot more flavors in certain layers, which in the past was just difficult because somebody had to maintain NDA with them. And now with AI, that problem is solved. So that's also pretty cool.
(20:20):
I also want to mention one other thing that it's not only about ... You have to pick up your battles.
(20:29):
When you are doing or when you're operating on bleeding edge, they're already standardizing from the get- go and picking up a winner might not be the best strategy either. I have no idea what the best multi-agent orchestration experiences when it comes to me having a small army of agents, each of them coding or two, three of them working on the same code base, couple of them doing security reviews, quality reviews, integration test reviews, et cetera. I have no idea how that scales at this point of time within multiple engineers in the same team, how this whole thing is managed. And therefore, we incentify our teams to experiment with different modalities, some experiment with cloud code and do awesome stuff there and link that to our build systems at each others are doing Cursa, the visual studio code guys that are also trying to do something with Copilot and respective environments.
(21:32):
And because the whole landscape is not consolidated, it's super early to start standardizing. So we are going to let this play out, we are going to see what are really the ultimate experiences and are those really two, three, 5X experiences compared to everything else. And once that emerges, if it emerges, then will be the time for us to really be like, "Hey, let's bet on this one." Or if everything starts evening out and just makes no difference with what we use anymore, it's kind of all producing more or less the same results, then also it makes sense to pick up one and be like, "You know what? We just want to stop with all the different things that we have to support, we are going to unify ourselves now." But until then, go explore, figure it out, and then we are going to collect it once the environment is more stable.
Ganesh Datta (22:27):
Yeah. When it's early optimizing for rate of learning, and then once things are stabilized, then you kind of go and pick, and it doesn't really matter at that point. You made an interesting point that maybe is counterintuitive to me. The fact that you had spent a lot of time standardizing build templates and auth libraries and things like that. And maybe now with AI, that's not as important. My assumption would've been, maybe it is actually even more important because you can write cloud code skills and you can teach the agents, "Okay, here's our auth library and here's exactly how you can use this auth library, and here's the modalities in which it can be deployed." Or, "Here's a build template, this is the way to deploy a service, roll back a service." It's always the same. You can build agents much more easily if they have a very specific set of things that they can do and specific set of tools that they can use, it makes it easier across the board.
(23:19):
I guess how do you balance that with like, "Hey, actually agents are just good at doing all this stuff. They can just do whatever they want versus, hey, we should standardize that agents do the same thing over and over again." So yeah, would love to double click on that. I guess my assumption would've been that the standardization is actually even more important in an AI first role, but it sounds like maybe that's not the case.
Boyan Dimitrov (23:42):
There is a nuance to that. And I'll give you an example which I hopefully shows how I mean that. I think it's goat to have your, let's take the auth architecture, to have your authorization architecture standardized across the board and all your applications to go the same way and all your, I don't know, roles, permissions policies, everything to be really integrated across because that's massive simplicity and not only obviously elevates your security standards, but it makes any integration, including agents and agenda workflows that are kind of coming in now much easier to manage, much easier to integrate, much easier to secure and end. So this piece and doing that work, I think that's not only goal, that is just basically a requirement. You don't do that, you're going to have fun times with agents, that's for sure.
(24:38):
What I mean, however, when it comes to loosening up is from the other side. So in the past, because we had so many standards, for example, across ... Or let's go there, because we had a standard, how all that stuff means, how all of that works, how the security architecture is, how all those libraries are supposed to work. It also means that we had to have people that are only focused on maintaining those libraries for the different languages that we support internally. And this naturally limits heavily the amount of languages you can support because for every single language that you want to support, which is first class citizen of your platform, you would need to have bindings, you would need to have integration, somebody needs to maintain it. It's work. This is the dimension which gets simplified heavily by AI because in the end, I don't know, if I support GoLink and Java and tomorrow I want to support, I don't know, Rust, well, I go and I say, "This is the spec.
(25:48):
Those are the reference implementations go built, and I'm going to have all my REST libraries compliant, it's going to work, and it'll be much easier for a platform team to maintain that. " But back to what you said, and you're totally right here, this is because we have a standard of how this whole thing works. But my point is on the other side, this also allows you to now with AI to support a lot more modalities and a lot more variations than what, for example, traditional would be possible if you follow a more platformized approach and you need to have those golden parts and only you can have a very few of them. Now you can just have more, as far as the core pillars are there.
Ganesh Datta (26:38):
If I'm understanding right, it's still the platform team or the central team still owns like, "Hey, we are going to give you the auth libraries, but it's easier for us as a platform team to manage that because it's a spec. You want to go build something in Rust, cool. We'll spin up a Rust library for you in a couple hours and you'll have it. " So we actually are not going to limit you to using these two languages. We can support more now. But is the platform team still the maintainer of these net new libraries and the spec? Or is it that the platform team provides the spec to other teams and other teams just consume the spec itself or is that nuanced as well?
Boyan Dimitrov (27:13):
So at this point of time, the ownership has not changed, but we'll see how it goes. We have to find out this will be a evolutionary approach. It's really hard to predict, but at this point of time, they continue to own it because again, as you can imagine, when you operate at scale, there are always a lot of responsibility and accountability that comes with that stuff. And it's not one library, there are many libraries, it's all, it's observability, it's service to service, it's many, many different things. And to really create production level quality, it actually takes some more work than just right to your client. But nevertheless, with AI, for sure, they're faster to maintain that stuff and it enables them, gives them more time to support more, as I mentioned, more versions, more modalities, more things basically.
Ganesh Datta (28:08):
Yeah, that makes a lot of sense. I know we're coming up on time here. I would love to maybe zoom out a lot more into the broader topic of driving value with the platform. I think one of the failure modes that we were talking about earlier is platforms that don't really have a north star or the cool companies are building platform. We should go build one too versus, hey, we have a problem in velocity and this is exactly where we're going to solve. When you went set out on this journey and you started building out this platform, building out the platform, building out the platform engineering practice at SIXT, how did you build the case for it? What was the, "Hey, I need to set aside X percent of our engineering capacity to go and invest in this thing that we hope will pay off in these ways, but not, how did you build that case?" And then today, how do you continuously prove the value of platform?
(28:59):
Is there North Star metric you're looking at? How do you present that to the business as a, here's why we're investing in this internal platform?
Boyan Dimitrov (29:07):
Oh, I think today it's easy because again, when you see just the speed of integrations, when you just see the speed of adoption being AI, being just how quickly can we turn things around? The question is about the opposite. Are we able to scale this? Can we add more people? Can we get more projects on that level, et cetera? I think today, especially in the world of AI where you see a lot of citizen developers as well, a lot of people which have been more hardcore on the business side, but now are finally getting much closer to tech. And we also have, as I mentioned, by now citizen developers, so people who are coming from business departments, vibe coding solutions, deploying them on that platform. This is where I think you don't need to market it too much. If If you were able to do things like that.
(30:02):
Now, in the past, for us, things went differently because again, as I was saying, we didn't start with, "Hey, we've got to build a platform." It was more like we have those problems and we've got to solve those problems. So we have to solve and account for those problems. And we started really tackling it bottom up from that perspective in the sense of, "Hey, how do we mitigate this? How do we mitigate that? How do we mitigate that? " And eventually we ended up with those standards. And the rest, the way I think about it, looking backwards says my job was now I need to scale those standards. And that's what it's going to take. That's the investment that's going to take to scale those standards because we like what we are getting. The first products that we built on those standards are performing much better.
(30:54):
We can ship them much faster. The quality of those products, metrics are the same. We look at cycle time, we look at bugs per release, et cetera. Ultimately, we look at does this product that we ship on the money that we invested building it's pretty simple really. And when this match checks out, yeah, then we want to scale it. And then it's an investment case. What would the world look like if we would be able to do what we do for those couple products nine years ago, which are super small in our universe for our main business lines. And over the years, that approach is paid off many, many times because again, business is dynamic. And there is always days, months where you have to act and you have to act fast and you have to restructure how certain products work, et cetera, to react to certain, I don't know, external environmental factor, new policies being shipped, changes happening in certain country or being demanded by certain customer groups.
(32:08):
We serve a lot of businesses as well, which also basically live in the same world as we do, and they expect us to be quick. So that capability to ship those things, to integrate those experiences quicker shows up over and over and over and over again. And I think also it's in the memory of the organization, how the world used to be before. So for us, that's in the end, how things shaped up. That makes sense. I would be studying this in a brownfield in a large organization from scratch today. I would probably look at in the end, and you cannot ignore that. What is your AI adoption today? What is your strategy for tomorrow? How would that change your business, your products? And of course, your teams, what would be the impact there? How do we want to work together? And then go for the common denominators there and start from there versus how I would have started 10 years ago that for sure it's not the same.
Ganesh Datta (33:13):
Yeah. You stole my last question. I'm sure it's going to be, what advice would you give somebody who's starting from scratch? It's going to be my last question here, but I really like that. And I think to your point, it all ends with leverage. The whole point of a platform like this is to create leverage for the organization in some way, shape or form, whether it's shipping more, whether it's compliance, whether it's AI now. And when you think about that, it's like, okay, well, the thing that an organization should be focused on now is how are you adopting AI? Are you making the most of it? Are you getting the most leverage you can? And if not, what can you do to increase that leverage? And like you said, it's not about building a platform, it's about mitigating specific issues. And so if you can figure out these are the things that are holding us back from getting the most out of our AI strategy, well, there's your answer.
(33:58):
That's probably where you should start. So I think that makes a ton of sense.
Boyan Dimitrov (34:01):
Yeah. The only thing I would add is what also I believe is going to change, but that's more of a projection and not as much as knowledge I have at the moment or experience I have at the moment. But everything that we are doing with AI in the past couple of years, at least leads me to the thought that it'll be way less and more about building the foundations, really codifying them and getting this, I don't know, you're running 10 different message buses, getting the 11th in and being, this is the new golden standard. I think it's going to be way less about that. Or I don't know, the 50th build system out there is going to be about experience and standards, you being able to define that and somehow creating a shared context across your teams, organization, but also agents, how this should look like.
(34:57):
And I think even that, if you're a small team or you're going slow on this path would already help tremendously for anything that you're building today to go in a direction. And then you can see which of those common deliminators that have minimum impact, sorry, minimum effort, maximum impact, and go after them.
Ganesh Datta (35:21):
I love that. I mean, a shared definition of good and getting people aligned on what are the standards and then working from there, I think will lead to a lot of leverage. Well, Boyan, thanks so much for coming on the podcast. I think there's a lot of interesting learnings here, whether you're at the very beginning of your platform journey and thinking about how to get the most of it today, or you are at the tail end or thinking about how you want to mature your platform strategy in an AI first world. I think there was a lot that folks can take away from this episode. And so thank you so much for coming on and sharing all of your wisdom with us. It was great having you.
Boyan Dimitrov (35:52):
Ganesh has been a pleasure. Thank you.
Ganesh Datta (36:00):
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 engineering operations platforms at Cortex, reach out to us at cortex.io. Thanks for listening, and we'll catch you on the next one.