#225 - Driving Engineering Excellence with Platform Engineering and IDP - Ganesh Datta

I imagine if a sales leader said like I don't need Salesforce, I don't need CRM, we're just going to sell and hope for the best. Like you would fire that sales leader tomorrow. So why is it that injuring leaders are not treated the same way? Every single other function has a system of record, right? Like sales teams have CRM, finance has ERP, but what does injuring have?

It's like the wild, Wild West. Today I have with me Ganesh Dutta. He's the Co founder and CTO of Cortex dot IO. Reliability practices, security practices, efficiency practices, and velocity practices. Those four are the kind of like pillars of injuring excellence to us. Injuring excellence basically means like the alignment of injuring practices with business outcomes. Think about those business outcomes that injuring excellence ties into. It tends to buck into these three things.

It's time to value, time to market, and innovation. It's not just about the metric. What you need is like an end to end platform that helps you understand like your software ecosystems. At what point in engineering stage do you think everyone should try thinking seriously about having this platform engineering and internal developer platform? You need to start with data. Do you have a system where you can track your software assets,

infrastructure assets? A single place where you can determine accountability and ownership. What do you see some this misconception people have when they think they want to adopt A platform? One of the biggest misconceptions with portals in particular is do I have to get all my data in order first before I put it into the portal? The second misconception is. Hey guys, welcome back to another new episode of the

Technical Journal podcast. Today I have with me Ganesh Dutta. He's the Co founder and CTO of Cortex dot IO. So today we'll be talking a lot about how to build a great engineering team best in class. So welcome to the show Ganesh. Thanks. For having me. Right Ganesh, I always love to

start by maybe having my guests explaining about themselves. Maybe. Any current turning points that you think we all can learn from you? So my name is Ganesh, I'm one of the Co founders and CTO Cortex. Like you mentioned, I was a software engineer before starting Cortex. I was at a fintech startup and I got to see the mullet to micro service journey while I was there. And it was a very interesting opportunity because there are quite a few turning points.

And I'll kind of give you the story of the journey that I went through and some of those turning points. So when I started at this company, I was working on a team and there was an initiative to break the first microservice out of the monolith. I eventually got added to that team and it was interesting because at the time that particular project was successful, but kind of struggling. And so like, it was a first

microservice. There's a lot of learning, a lot of things we had to do. And it was an interesting time because at face value was like, OK, a lot of things are broken, like lots of bugs, like a lot of bug fixing. And it was, especially as an early career engineer, it felt like, Oh my God, I'm just like fixing bugs all day long. Like, what's the point here? But I would say it was actually a turning point in my career because it allowed me.

And this is where I think my manager coaching helped a lot was, hey, like, don't look at these as just bugs, right? Like if you want to become a, you know, very senior engineer one day, the whole point is to be able to look at these things and say, what are the patterns we're seeing here, right? And so like, I think that framing really, really helped. I was like, OK, well, I started thinking about them as bugs and let me start thinking about them as patterns of issues in this

particular micro service. And so eventually I, you know, saw a ton of patterns and I got the opportunity to propose like a new architecture for the way we were computing, like account management data for credit cards and loans and things like that. And so we got by in to work on this big project. And it was great because having had that personal pain of going through all these different bugs, I knew exactly the impact it would have to do this RE architecture.

And like I know every engineer wants to do a RE architecture, but I think the the point was I was able to articulate a very clear business value and like the types of bugs we were running into and the customer impact and whatnot. And so I've got to take on that project and there was a ton of learnings around that, you know, the way you communicate it, the way you set timeline. So that I would say like that was a really pivotal project for me.

Another thing that, you know, I got to do while I was there was a lot of performance based things. It was like these small issues that kept popping up. And it was an opportunity for me to be much more proactive. Like, without anybody saying, like, you just go in and dig through Datadog and say, like, where are we seeing like our highest P90 fives and, you know, P90 requests and what are the patterns, What are the bottlenecks we're seeing? And can we start attacking those more aggressively?

And so in my spare time, I would go and try to fix these issues and eventually it was a really fun thing we would do at every endpoint that we fixed our P 90s and P90 fives, we would print out a chart of like the latency graph and I would stick it up on the wall next to me. So eventually I had like a trophy case of these like latency charts. It's like, look at all the things that we fixed, you know, over the over the last year or so.

And it was just a way to show like, hey, I'm, it's a way for you to represent the kind of like sloping work that you have to do to keep services and systems up and running. So I would say that's another turning point. And the last one I'll say was really investing time and energy into how can I take all the things that we learned and share

them across the organization. And it was another thing that was just like it came from personal pain, which is I as an engineer that was on call for service, I would get paid for something. I'd go to another service and I try to like figure out what's going on. It was it was like a downstream or upstream service on an issue. And like the logs look totally different. The metrics are named completely different. Like, why is my service doing one thing and your service is

doing another thing? Like it sucks to manage these services. I took it upon myself to say, OK, we're going to standardize this thing. And it was more out of frustration than anything else. I was like, we just got to do things the same way. Otherwise I'm going to like, I'm going to lose it. And so put together this like what I eventually realized was a production readiness checklist, but it was just like list of best practices and standards and like login formats.

And I was like, OK, nobody's following these practices. So I'm going to make it really easy to do these things. I built like standard libraries that like would pre configure your request tracing and your logging. And then we built like cookie cutter templates to spin up these services and without realizing it was like I was kind of doing these like grunt work, dev experience type things. And now obviously like teams have come up around that, but

the time was not really a thing. And it was an example of like, hey, if you can make your peers lives better, you will get that. You will earn that respect. You will earn the right to kind of take on bigger and bigger projects. And like, don't wait for permission for a lot of these things. Like you can make things better. And so that was another turning point for me. And like, the reason I tell these stories is also it helped me in my own personal career and growth as a software engineer.

But those were the things that led me to Cortex as well. So like the idea of like, hey, how do we help bigger and bigger organizations do like production readiness and ownership and standardizing the way you you operate And like Dr. Excellence and standards like that became a bigger and bigger, bigger question for me until it was like, I got to do this a better way. And that's going to have Cortex started. So it was a kind of a series of, you know, turning points for me and my career.

And then eventually the biggest turning point was like I quit and started Cortex. So like, yeah, those those are kind of the things that I found really impactful as part of my journey. Thank you for sharing such a good story, right? So I feel there are many things that we can learn just from your sharing, right? The first is about like looking for patterns, right? Maybe it could be bugs, could be issues, incidents, whatever that

is, right? Because sometimes when we are tested in those moments, right, we feel frustrated or why is this happening to me? But actually, if you want to level up and step up, right, So you can probably solve the root cause instead of just the bugs, the symptoms of the issues, right? And I think learning, learning and sharing, I think that's really a good thing as well for any engineers, right? It could be internal, it could be also publicly, maybe through blog post or whatever that is,

right? So maybe I would like to pick a

little bit about finding the patterns, right? Because I'm sure in most engineering teams, they will always have these issues, incidents that they have to face, especially when things are in production, right? So for engineers that want to, I don't know, improve their skills in finding the root cause and fixing it, what will be your advice to, you know, look for patterns instead of just fixing the issues? Is there any practices or things

that you do normally? Yeah, I think it's, it's important to be very systematic about it. If we're a marketing team and we're trying to find like which cold emails work best, we're not just going to like look at our emails and pray like, OK, well, let's hope we get the best e-mail. It's like, OK, we're going to send out three different types of emails from look at the response rates. And like you're very systematic about it. Like, why not do the exact same

thing for engineering practices? And so if you were like a very junior engineer and you're feeling frustrated by incidents, let's take an example. One of the things that you can do is think about, OK, am I frustrated at the fact that I'm being alerted? Am I frustrated at like constant interruptions? Am I being frustrated? Am I frustrated about the lack of of information when something goes wrong? Like something is it something is going wrong and I don't know what to do about it.

Something is going wrong and it's the same thing has happened multiple times. Nothing is going wrong and I'm being alerted about it. Nothing is going wrong or it looks like nothing is going wrong, but something is going wrong. When you realize like there's kind of these buckets you can bucket it into. And so I was like, OK, I'll start there, but how would I like, assess my own view of the world in some sort of like

meaningful way? And it doesn't have to be perfect because if you start with some simple like categorization of these things, like as you go through, you will naturally realize, hey, there's actually another class of things that I didn't think about. Let me go back and like it right on my pattern, the patterns I want to match against and so on. And so like starting with like even something rudimentary is

really important. The thing that, you know, I started with as a very junior engineer was like alert categorization. It was like this bucketing of alerts. And I was like, OK, like I don't even know what the patterns are, but I know that there's like general things that like I'm getting alerted for that I

shouldn't be or what not. As I went through and I got a list of like all the alerts in the last three months and I literally just went through and marked them like, there shouldn't be alert, there should be alert, there shouldn't be alert, here's a run book, blah, blah. And then share it with a team. I was like, I don't even know if I'm doing this right. Let's get the team's feedback.

And it was like, hey, actually this alert is really important because of X or this alert doesn't make sense. We can like quiet it or, you know, it's kind of like that, that conversation of why are we even doing these things? And then you go back and you kind of iterate and it's like, OK, well, if this alert's important, then why is it frustrating? Is it because I don't know what to do about it? Then you go back with the proposal and like, I think that iteration loop is really

important. I think the other thing to do is like, honestly, I mean, now with LLMS, you can even like take a list of your JIRA tickets and put it into an LLM and say like, hey, like, tell me what you, what do you see here? All right, like it's much easier now than I think it was like 10 years ago. But the ability to kind of go through and say, if you're on a product team, can you categorize the types of things you're working on into the highest

level abstraction? It's it's like basic software engine practice. You're like, what is the highest level abstraction possible? Before you go really low, Like, OK, these tickets that I'm working on, these bugs I'm working on are on this part of the product and this part of the product. OK, let me go into that part of the product. Now make it a little bit more granular, a little more granular.

It's like, OK, well now I'm not able to break it down into any patterns, but you naturally found patterns that way by like starting at the biggest abstraction layer and whittling it down more and more granular. Then you can work your way up and see how things relate. And so I think going through the like that systematic exercise is really important.

Yeah, so many great tips for those of you engineers who want to kind of like improve your skills in terms of maybe we call IT system thinking also sometimes, right, how to actually identify this kind of root cause patterns. And I like the tips where you mentioned using LLM, right. So maybe try give it a try. You know, LLM is sometimes very good at summarizing things and seeing things that we don't see normally. So I think that's a good tips as

well. So the next today we plan to talk about building a best in class engineering team or building engineering excellence within that team, right? So maybe could you start a little bit by defining first what is engineering excellence to you now that you are ACTO at a company and a previous job as well you have seen like big engineering teams operate. How do you define engineering excellence? It's a great question.

The one thing I'll add is like, I feel like I have a unique perspective here because you have been a sophomore engineering being ACTO now, but then also the kind of goal of cortexes of companies to help our customers with their injuring excellence initiatives. I've seen like how the world's best like e-commerce companies and financial services companies, healthech companies have tried to do this as well.

Until like as I, you know, answer your questions, I'm going to try and weave in like the things that I've learned from our own customers and are like the other CTOS that we work with. I think to us injuring excellence basically means like the alignment of injuring practices with business outcomes, right? So like of course, every engine organization needs to build features and products and all that stuff.

Like that's table stakes, but it's the practices that we adopt as an engine organization that lead to the outcomes that we care about. And so again, kind of going back to the, the sales and marketing analogy, like sales excellence is like given an account, given an opportunity, how likely am I to close it at what dollar amount, right? Like that's like the, the obvious business outcome. There's practices I can do to do that, right? It's like, am I asking the right questions?

Am I talking to the right personas? Am I, you know, using the right decks? Am I, you know, helping them see the value of the product properly, like all the right practices. It makes it more likely for a customer to see value and buy the product, right? And like sales organizations have been doing this for like, you know, a century, at least at this point of like, you know, it's a very well studied thing like bookkeeping and like tracking your like CRMS.

The idea of CRMS existed way before Salesforce, right? Like this idea of like, if we can build a high functioning machine and we like really operationalize the way we do sales, we're going to drive more revenue. Engineering is like slowly coming to that same realization of like, hey, if we build the right systems and the right processes and the way we do engineering, we will get those

business outcomes we care about. And so when I think about this business outcomes that engineering excellence ties into, it tends to buck into these three things. And this is what we think about as well. It's time to time to market and innovation. So are we, are you innovating as much as you can? Are you getting your product into the market as quickly as possible? The second one is around cost efficiency. So like are you managing your cost and you're being as efficient as you can?

Like are you doing more with less? And the third one is around product quality and customer reliability. So like are we delivering a world class product is reliable, you know, is the customer happy with it? I use these three examples because depending on where you are in your company journey, what type of company you are, the outcome you care about might be totally different, right? Like as a start up at the very beginning of the cortex journey, all we care about was time to

market. Like it was like, we don't care if there's quality, like it's going to break, but we want to see what works and we want to see what people care about. So like, let's move really quickly. And then from there it became like, OK, well now we have a ton of customers. They really care about reliability. We want to build a great customer experience. Time to market is still really important and we don't want to lose that.

But it's an ebb to flow. Like OK, these next couple months we're going to really focus on reliability. That's the thing that really matters. But you talk like a larger organization, maybe they care about cost efficiency. Like, hey, we hired 1000 engineers in the last like 3 years and like, you know, there's a lot of pressure from investors and blah, blah, blah. And we got to like, you know, focus on cost. We're going to really double down on that.

You know, maybe a company's trying to go IPO and they need to get their cost in order. There's some outcome that your processes can relate to. And so injuring excellence is like the connection of injuring process to those outcomes. We bucket those. In my head, I think about injuring excellence. I break into kind of these 4 buckets underneath that. So it's like it's reliability practices, security practices, efficiency practices and

velocity practices. And so those four are the kind of like pillars of injury excellence, if you will. And so it's like it spans the entire SDLC, right? When you think about like developer experience, for example, it's like it's about the tools for a developer in their like day-to-day work, right? It's like very localized interior excellence is more broad. It's like architecture review process to incident management to security. Like all those things are like the excellence of your

engineering organization, right? And like developer experience is part of it. It's like, hey, are we giving our developers tools and making it easy to be excellent? But it's like not the entire thing. And I think that's where I really focus on injuring excellence because in some, in some cases, like maybe the developer experience sucks, but like right now it's a trade off I'm willing to make because we need to improve our security or

something like that. So thinking about like the business outcome first, the part of the injuring process that I want to change to drive that outcome and then thinking about how I'm going to do it. Like that's to me what injuring excellence is. It's like our practices in service of business outcomes. Well, thanks for outlining such a great, you know, the way you pitch it like from outcomes to pillars. So I think at the end of the day, it's all about business outcomes, right?

Engineering is just one organization within the company. Obviously, engineering needs to also drive business outcomes, right? So in many various companies, I believe there are many challenges. I think what you mentioned, right, time to market, right, innovation, right, bringing some new features, maybe even new things into your system as fast as you can. And then the second one is about reliability and quality, right? Bugs, incidents and maybe security issues and things like

that. And so the third thing is about cost efficiency, which I think in many companies these days, they're kind of like looking back at the cost, how much they spend and try to, you know, optimize a little bit. So I think every company might go through this journey differently as well. Like what you mentioned, maybe startups prioritize something different than their big organizations. So maybe if we can dive slightly

deeper into all this, right? So obviously, there are many dimensions to all of this, right? One of the most important thing in any engineering excellence is about leadership. Maybe I'll start from there, because most likely you can't do anything if the leadership doesn't support all these things, right? So how important the role of the leaders? Do you think an organization such that the injuring team can

achieve this excellence? I think it is extremely, extremely important and especially because if every team that is working on injuring excellence initiatives does not know how their work ties to a business outcome, it doesn't go anywhere. But I'll give you a concrete example of this. A lot of organizations in the last two years have spent a lot of time investing in platform engineering. And platform engineering should in theory enable quite a few outcomes, right?

It should help you go to market faster. Like if you build up the right platform, your developers are more autonomous, but they're also following your best practices. Your platform is secure, it's modernized. So you're, you're being efficient, you're using your resources effectively. So a face value platform engineering should be a great way to drive injuring excellence.

But platform engineering, especially large organizations sometimes can become like this kind of corner of the organization where it's not really tied to leadership or the leadership is not able to articulate to that team like how their work ties into the broader business outcome. And I think it's really important for an injury leader to say, hey, this quarter or this year or this half or whatever, the thing that we really care about is business

outcome. Actually we want to move to market faster or we want to improve security or whatever that is. And interrogating kind of each set of initiatives as to like how exactly does this initiative tie back to that? And can I then tell that story to the rest of the organization? So like, hey, our platform engineering team is going to be headed down for three months.

You're not going to see anything, but it's because we are building out a, you know, the very first slice of our organization, very first slice of that product that is going to improve security of the way we provision infrastructure. OK, I understand how it connects back to that. As an engineering leader also challenge your teams to steal

thread. So rather than saying we're gonna build a whole platform or we're gonna deal with this whole thing and then like solve the business outcome, it's like, no, there's like choose a business outcome. What is the number one thing blocking that today? And what is the bare minimum slice across the entire stack that I can deliver to move that needle just a little bit for

right. And so it's like when I think about reliability, if, you know, MTTR is top of mind and see, my CEO is saying like, hey, we have too many incidents. Like we're paying too much in SLA fees. We need to improve our incident costs, OK? We're, I'm not gonna like go and rebuild all of our services and like, you know, fix all of our tech that all at once. It's like, you know, what is the number one thing that's stopping us? OK, it's you know, we're spending too much time fighting fires.

OK, why are we spending too much time finding fires? Well, there's like 10 reasons. Like the number one reason is like. We don't know which teams are in the critical path for these key outages. And so we spend 30 minutes per incident getting the right people in the room. After that, there's still a lot of other problems, but like we spend 30 minutes there. OK, like let's take that one level firmly. What is the next thing we can do to standardize that and so on.

And so it's like now up and down the entire stack, you have a single thread. And so as an engineering leader, it's really important to maintain that focus and like challenge the teams. It's like, do we have to do all this? Like what is the bare minimum thing? Like if a product leader is doing that for the product, engineering excellence is like the engineering teams pruned in some sense.

It's like the thing, the practices and the tools and the stuff we're building for those engineering and business outcomes. And so like we should have that same product management mindset of like, what is the minimum viable or minimum lovable, like process or, you know, tool that we can build for this particular issue.

And so I think being able to carve out small slices of value that drive to business outcomes by telling that story more broadly across our organization, making sure everyone's bought into the business outcome and holding teams accountable to not building, not just doing science experiments all the time, but like driving towards something very clear means that the next time you want to do one of those things your CE OS bought into,

it's like, hey, this investment in like this random engineering process resulted in us moving the business outcome. So the next time as an engineering organization, we want to go and say, hey, we need to fix this tech debt. You've earned those stripes. You've said, hey, the last time we made this argument, we moved the business needle. We're not lying to you. Like we have another thing we want to do. Like you've bought that, you

created the feedback loop. And so as an engineering leader, it's your duty to like bring those business outcomes from the business to engineering and then use the same business outcome to tell the story back to the business of like, hey, here's how our investments impacted the business. And so as an engineering leader, you're gonna be thinking about both sides of that equation. Well, I think that's a really great tips, right. Again, it all comes back to the

business outcomes. First try to tie to maybe like one single business outcome and identify the initiative that you want to do. And I think I like that you mentioned create a slice, right? You know, maybe people call it thin slice in product management, right? So the same thing you can do in your technology stack. And platform engineering is also like the most common examples I think these days for engineering team to try to improve things.

But obviously introducing technology itself might not be sufficient, right? Because I think many people try to use technology as the solution for improving their engineering excellence and cannot convey that to the stakeholders. I think this is one of the challenges simply because maybe there are gaps in technical understanding versus the business stakeholders who are non-technical. And the other thing is about building the story around what kind of outcomes that you want

to build, right? So for people who probably still

rely on kind of like implementing tools, be it, I don't know like cloud, AI, platform engineering, whatever that is, right? Maybe also sometimes re architecturing certain things to improve the engineering excellence. What will be your advice for those kind of people right before they approach these kind of thing with such new technologies and new architecture? Is there anything that they can do before they embark on that journey? Yeah. I think it's understanding what

the North Star is like. We should understand either what metric we're trying to move within our organization and which business metric we're trying to move, or even if it's not an immediately move, a metric like the hypothesis as to like the series of things that will eventually move some specific needle. And it doesn't have to be a

business outcome necessarily. Like if you are are on kind of a hands on team, you know, insecurity or something like that, buying a new tool, you can still tie it back to one of those pillars, right? It's like, you know, hey, I'm improving our security, improving our reliability, I'm doing these things. And like your agent leader should then be able to tell that story to the business, but like, as long as you can tie it back to one of these pillars.

And so the way I think about it, for example, is going back to the platform engineering example, let's say you're a platform engineer and you want to spend two months building out a self starter kit for new services. On it's face, it's not a particularly interesting project

to the business, right? It's like, hey, I'm trying to invest in Terraform. I'm investing in, you know, like I am policy tools and like I'm doing, I'm buying a bunch of stuff and like setting all these things and I'm spending all this time and energy, but why does it matter? It's like, OK, well actually the reason all that stuff matters is this. And this is where like the measuring the current state of the world is really important.

Today, it takes us 1 1/2 weeks to spin up a new service and go through all the approvals. It takes us four days for security review. Once it's ready to go to production, it takes us four days for SRU review, and then finally it goes to production. So on like either sides of the equation, we're spending, you know, minimum of two weeks outside of like the actual writing of code. And so therefore, if I can reduce those two weeks down to days or hours, then like the ROI is there.

So by investing in a self starter kit, you know, through the platform measuring team and buying all the right tools for it over the 50 services that we create per quarter, you know, across the organization times a reduction of two weeks, we've saved X dollars of money and we've improved our security posture because now every team is by default registered with our vulnerability management tool, the moment to create a new

service. And so the likelihood of a breach is much lower by, you know, some amount. So like, now I've made a case for these tools from a efficiency perspective and a security perspective. And so it's not just like, oh, I'm like creating a cool, like experience for my developers. It's like, does the CEO really care about that? Like, maybe, you know, it's like, yeah, I want my developers to be happy and like, and there's a retention aspect and all those things about like

sentiment. But like, fundamentally, if you tell me like, hey, not only are my developers going to be happy, I'm saving us X weeks per service. I'm increasing our security posture and like our incident rates should go down. That's a much easier way to make that case. And the other thing like you mentioned, like coding assistance is the same thing. It's like, OK, well, can we measure the impact of that?

That's an interesting one. Actually, though, coding assistance, just kind of a side tangent here is like I had a customer recently tell me it's like, hey, why are you making such a big fuss about, you know, measuring the impact of 50 bucks a month or whatever? You wouldn't ask like, does my developer really need like 16 gigs of RAM, like versus 8? Or like do they really need Intellij? Like can't they just use them? It's obvious that it's one of the tools in their tool kit, right?

It's like you wouldn't question a developer who's like trying to get an Intellij or something like that. So why are we making a big fuss about spending 50 bucks for a tool? And it's just part of your general tool kit. It's like laptop IDE, terminal coding assistant, like it's part of our general tool kit, right? So it's like, it's an interesting idea. So the same thing should hold true for your injuring

excellence platform. That's another topic as well as like, you know, why are more engineering leaders not thinking about injuring excellence? But yeah, I kind of a side tangent there, but hope I answered the question.

Yeah. I think that's a great example that you outlined just now, right? So I think one thing that I picked from your explanations also in your career journey, right? So engineering also needs to be able to measure things, right? Be it in the maybe software telemetry or even like their, I don't know, velocity metrics that you mentioned or those kind of measurements that I think must be in place, right, for us

to build engineering excellence. How important for leaders to actually build an initiative to actually gather these kind of measurements? Because sometimes, sometimes it's easy to you can come out from a systems, right? But sometimes, especially when you touch multiple running elements, right? So it's very hard to actually

quantify the metrics. So how important do you think for engineering organization to actually put an effort, invest time and actually come up with metrics and maybe do like a good cadence around, you know, looking back at the metrics, how to improve them and things like that? So maybe any tips on this? Yeah. Yeah, absolutely. That's a very, very important question. So I think it is a must and I'll

explain why. Going back to the sales analogy again, like imagine if a sales leader said like I don't need Salesforce, I don't need a CRM, we're just gonna sell and hope for the best. Like you would fire that sales leader tomorrow. Like any sales leader that doesn't have a CRM that's not using that data to make judgments about the organization and where to invest is going to be laughed out of the room, right? Any data leader that doesn't have data tooling is going to be

laughed out of the room. So why is it that engineering leaders are not treated the same way? Like why is engineering leaders do we not say, of course I need a system of record like every single other function has a system of record, right? Like sales teams of CRMS, marketing teams are marketing automation, finance has ERPIT has CMDBS like ITSM tools at service. Now every single function has a system of record, But what does engineering have? We're just like caution to the

wind, like do whatever you want. Like every team just out there like it's like the wild, Wild West and it's really insane if you think about it like, you know, like every other function is treated so differently and engineering is the most expensive organization. We should be much more systematic and data-driven and methodical about the way we build our engine organizations. And what I would challenge though, is like, it's not just about the metrics.

Like imagine if all Salesforce said was like fancy reports, right? Like just like a funnel dashboard or something like you wouldn't need that either. What you need is like an end to end platform that helps you understand like your software ecosystem. So it's like accountability and given a service, which team is accountable for it? Where's it deployed? Where's it running? You know, how many vulnerabilities does it have? What is the code coverage? Like what is the on call rotation?

Like where can I collect this data? How do I use that data to drive best practices? So like in, for example, in Salesforce, again, I can use the CRM to drive practices in sales. It's like, hey, before you start Apoc with a customer, you need to fill out all these fields. You need to make sure you understand if they have budget, you need to make sure they understand who's gonna buy it. And like the AE has to go and fill this information.

The idea is that you're using that data to then drive some sort of behavior like in the daily workflow of an AE, right? And so you're using it to drive practices or you're trying to use marketing automation tools for practices. And so it's not just about the dashboards. And so like the metric side of the equation for engineering teams should like a, having a way to store all this data in a meaningful way because it can just be metrics.

It needs to be like, what is the actual like data structure on which I'm reporting on? So like to us, the way we think about it is like the service catalog, the infrastructure catalog, a catalog of all this information, right? Like just like ACRM, the second part is the ability to like drive behavior around it. So like defining this is what good looks like. This is where I need teams to be. Can we create a shared language as to what good looks like? Because I can say your repo is

30 vulnerabilities, OK? Like is that good? Is it bad? Like it doesn't matter if it's high or like low vulnerabilities. Like what does that actually mean? Like it doesn't mean anything for me to tell you have 30 vulnerabilities, right? There needs to be some distinction for our organization. Like for me, for us as a company, what is good look like OK, for a financial services company, 0 critical

vulnerabilities is great. Zero critical vulnerabilities with, you know, resolving them within seven days is excellent, right? And like 0 critical vulnerabilities, resolving them within seven days and you're resolving medium vulnerabilities within 60 days is like top of the blind. Like that's where we want to aspire to. So again, now not only do we have a metric, we have like a graduated window of like how to get better. So like the platform should be

able to tell you that. And the final bit is reporting. It's an engineering metrics. It's, and it's like, OK, like based on the data that we have, based on the practices of what we're following, are we seeing the impact on the data? So like cycle time and, you know, dura metrics and things like that, those things can't live in isolation, right? It's like you can go and tell a developer improve your MTTR. It's like, OK, like I don't know where to start, right?

So it's like, instead it's like, hey, we're using MTTR as a measurement. And so we're gonna see, we believe that in order to improve MTTR, we need to change these five practices. So we're gonna run change the five practices. We're gonna come back and see the MTTR change. So it's the engineering metrics are not about measuring productivity or like, you know, like checking if you're like taking advantage of your teams. It's about hypothesis, hypothesis generation and

hypothesis testing, right? It's like based on the metrics, I have a hypothesis that like we can, it's all about like continuous improvement, right? It's one of the pillars of injuring excellence. We consider it's like continuous improvement. It's not like good versus bad. It's, I'm better than I was yesterday, but that's a very important part of injuring excellence. And so like injuring metrics should be used to say, today our cycle times X, we want to move faster.

The time to 1st review is really long. Our hypothesis is that the CI build time is taking up, you know, good chunk of that effort by reducing our CI build time, our cycle time will go down, which means that our throughput will go up. That's the hypothesis. And then you go and you say, OK, well, how do we, you know,

change our build time? Well, then you run an initiative and this is where of course it's gonna help is like, OK, we're going to migrate our teams from, you know, legacy Jenkins servers to get up actions. So we have better caching. But like in a big organization right now without a toilet cortex, not to sales plug, but like it takes a lot of time to

track a migration like that. And so having the right tooling in place to like track a migration like that and like make sure everyone's doing that migration. OK, you do that migration and then you go back to your metric and say they didn't move the needle. So the energy metrics are a way to like create those hypotheses and test them. But if you're not doing that, how do you know if your efforts are actually moving the needle, if you're actually making an impact?

So injuring metrics are very, very important. The data under the hood is very, very important and the ability to set standards and Dr. behavior is also really important. It's like all those things together is what creates the flywheel of a data-driven, high visibility, high trust injury culture that is focused on excellence. Like that's how I think about how metrics fit into the broader ecosystem. Right. I like the angle where you mentioned about continuous improvement, right.

So obviously excellence is kind of like the North Star division that we want to be. Obviously, I don't think any kind of team can say, hey, I'm excellent, you know, like you can't be excellent forever anyway. So the continuous improvement aspect, I think it's very important and kind of like the motion of how to improve yourself from, you know, wherever you are today and then tomorrow and so on and so forth, right? So I think that's really crucial.

So the other thing that you mentioned is about driving the behaviour. I believe this is touching into the aspect of culture, right? I think in an engineering organization, culture is really important. What kind of culture drive a good engineering excellence, kind of initiatives and those kind of things.

So maybe if you can elaborate, I know culture is a bit big topic, open-ended, but maybe from your experience, right, what kind of culture do you think drive this kind of engineering excellence? Yeah. So I'll start with kind of a Segway from the last question. So injury metrics, the right culture is one that is transparent and has high

visibility. And what I mean by that is like injuring metrics are not this like ivory tower thing that the, you know, your VPS and CTOS are looking at and they're like coming down and like smiting the teams based on those metrics. It's like if every team has visibility into your SL OS and your latency and stuff in APM, why can't your teams look at their own metrics and injuring metrics too, right. So it's like visibility up and down the stack.

So everybody gets access to the metrics, everybody understands this is not a measurement tool. This is a way for us to like find improvements. So that is really important. So a culture around metrics, a culture around visibility, everyone looking at the same data. So that's one part of it. The second part of it is a shared language. So does everyone actually know what good means? If you ask three people on the team what does production readiness look like, and you get

3 different answers. Immediate fail. So like having a shared language as to what good looks like, having a shared language like This is why, you know, companies do OK Rs and like, you know, North Star goals and North Star metrics and all these things. It's like if everyone at least is thinking of the same thing, right? So if you're like a, a social media company, you probably have a North Star metric. It's like, hey, we want to

improve retention. Like that's our number one thing where like this year, that's the only thing that matters. OK, well, everybody knows that. Everyone can say like retention is the only thing that matters. I can ask myself, I'm actually doing something about that. So the same thing holds true for injuring process. So does everyone know what good looks like and what that shared definition is? How much can you dumb down that definition?

So like your definition of good can be shared, but if it's like 60 criteria for like production readiness, it doesn't matter, right? It's like no one's gonna remember all that stuff. But like it's like that confluence page over there. And so like the ability to create like a clear path to greatness I think is really important. It's like, hey, these are the basics. This is like, you know, the non

negotiables for production. This is what like the gold standard looks like to be able to kind of like buck it up. What good looks like in these categories I think is really important because then you're as a team lead, you can say like, hey, we've all agreed that like these 15 things are like the bare minimum to go to production. We're not doing those things. And so like I can use that now

as a way to advocate for time. So like I can go to my manager or my VP and be like, hey, we all agree that these 15 things are really important. We're not getting time to meet those things. Like we need time. And so now you've created like that share language. The VPS cannot say like, I mean, yes, they can say no, but the idea is that yes, we have agreed to those things. I can make that trade off very clearly. And so that communication is very important.

The third thing is repeated messaging. And so how much of the same data can you use in multiple places? So, and I, if we're doing a migration, like I mentioned earlier, talk about it in your all hands, talk about it in your monthly operation license reviews, talk about it in your team meetings and team retros, right? Is there enough data in your, in whatever you're using from tooling standpoint for each team to be able to self report on

these things, right? It's like This is why teams spend so much time around like, OK, our tracking is like each team can like very quickly iterate. And so it's like the CEO saying something, the CTO saying something and like it trickles down and like, I can check my own work against that. So for engineering practices,

the same thing. It's like does your team, your manager, your directory VP, they all have a slice of the data where they can their level come in and see like, hey, how are we tracking against those practices? How are we tracking against those things? And so the ability to kind of create that, like instant visibility and repeated communication is really important. This is like a common, like,

adage in business, right? It's like you have to keep repeating things until you feel like you've repeated yourself so many times that people are sick of you. And at that point, people have finally realized what you're talking about. And so it's the same thing for engineering practices. Like, keep repeating yourself. It's like, hey, congratulate people, celebrate the wins. Like, hey, Ganesha's team has finished 80% of migrating 80% of their services to the new platform.

You know, congratulations, right? Like do you have data to be able to celebrate those wins? And like, if you say that in an all hands meeting, people are like, oh, like clearly this is important enough that like getting a slide at the all hands, like are we actually tracking towards it and whatnot? So like, can you create that culture? It's about creating momentum. It's about creating visibility. It's about shared language.

It sounds like cult behavior, but like really like every organization, like culture in some ways is like, how can you create a cult like behaviors with an organization like healthy and like try the right outcomes, of course, but like so that's kind of the framing I like to think about kind of tongue in cheek. Yeah, so I in my experience also the bigger you are, you know, the bigger you grow, right, the more important all these things, right, Especially the repeating

of the message, right? Because when you have like hundreds of engineers, for example, right, it's very difficult to kind of like align everybody. So a few things that I picked from what you're sharing, right? So high transparency, maybe have the metrics in place that you can see all the time. Shared language. I can also agree to, you know, use this kind of shared language because when you have multiple engineering teams, everyone thinks excellence differently, right?

So if you don't have a shared language, what good looks like? I think it's very difficult to align everybody. And then, yeah, repeated message, building a clear path. I think it's also important because you can say here's the initiative and let people do it. But if there's no good clear path and you kind of like streamline the process, I think it's very hard for people to achieve that as well.

So the other aspect that I wanted to dive deeper is about, you know, platform engineering because you are building, you know, one for yourself, right? So the Cortex dot IO. So I think people these days talk about platform engineering, you know, internal developer platform and things like that. So maybe the first question is at what point in, you know, engineering stage do you think everyone should try thinking seriously about having this platform, engineering and

internal developer platform? The interesting thing, I kind of break up the two aspects of this internal developer platform, internal development portal. There's a whole debate about like what each thing means, like when you need them, like it's the whole thing. But basically, I would argue that do you need to start with data? So every organization should have some sort of data. So like, do you have a system where you can track your software assets, infrastructure assets?

You have a single place where you can determine accountability and ownership. You can probably get away without any of this stuff, you know, up until about like 30 to 40 engineers. I want to say like roughly speaking at that point, like you have enough kind of clusters in your team graph that having a system where you can say like. The Asia team is working on X, you know, Henry seems working on Y. Like this is their, you know, sphere of accountability. They, they own these different

repos. Having that in one place is really important. You should do that like very, very early on. And so usually that comes in the form of an internal developer portal, which is like a service catalog or something like that. Around that same time, you probably want to use, you know, ideally your portal already provides this. We're also starting to measure some of the key metrics, so like cycle time, review time and so

on around 30 to 40 engineers. Anything before that, like it's a little bit of noise, honestly, like you can get some value out of it, but it's not honestly worth it. Ideally your portal gives you this data, but if not like you're getting it in in a manual way, you're tracking some key metrics and like the things at a 30% team, it's probably a 30% like injuring organization, I'm saying is like probably more on

moving fast. So like cycle time, throughput incidents, keeping the lights on, those kind of metrics are probably pretty important. From there, once you get to around like 60 to 75 engineers is where platform esque investments start to come into play. Now it doesn't have to be a platform engineering team, but some sort of like collective group of like infra cloud staff engineers, like senior engineers and maybe like one or two platform people like kind of coalesce and started to work on

org wide initiatives. Because at about like 50 to 60 people, you're getting to a point where like practices are starting to diverge. Like people are trying to do things in weird ways. And so starting at that stage I think is really important. However, I will say at that point in like you want to be very, very tactical about the types of investments you're making. So even from a platform machine perspective, like what is the thing that is slowing you down at a 60 percent, 70% engineering

team? So like it's usually around like deployments, build systems and tooling, infrastructure provisioning, like, you know, are we having repeatability around those things? Like it's not like the quote of a sexy platform engineering stuff that people are doing, but it's like tactical things that really matter. It's like if you hit a point where you're like 60 or 70 engineers, you probably have really slow builds or like something like that. You probably have like preview

bottlenecks. You may have started the company and I'm seeing from experience like click OPS in Google Cloud or ABS, whatever. And so like around 60 engineers, you want to start automating and terraforming or infrastructures, coding, some of that stuff like thinking about the next phase like, yeah, what's going to break when I get to 100 engineers, like start to get out of that.

So around 60 to 70 engineers, you want to start investing in platform practices, but very tactically against specific initiatives. I think once you get to around like 120 ish engineers, like you have enough independent work streams across the organization that like true platform engineering stuff starts to have a real impact.

So like a standard set of like deploy pipelines and deploy capabilities where you're standardizing on Helm, where you're standardizing on Terraform or Bloomy or Spacelift or cross lane or Craddicks or whatever kind of platform tool you want. Like those kind of decisions start to become really important because they like compounding

effects. And so I would say like somewhere between like the 60 to 120 range issues, like when platform engineering starts to become a thing, anything bigger than that, like you absolutely need platform engineering. My hot take though, is that like at whatever point you start bringing in like SRE and security and stuff, you probably also want to start thinking about platform engineering. And I would argue we're starting to see this practice a little

bit more. But why not have those teams roll into an intern excellence leaders rather than like all of them, like kind of reporting to different places. You want your platform engineering teams to be working with your security teams and your SRE teams, right? As if they all their work depends on each other. Like your SRE team cannot build reliable software if your platform doesn't take that into account, right?

Or like security cannot do their job if you're like infrastructure as code tooling is not thinking about security from day one. So like, why is platform engineering over here and security over here? Like bring those things closer together. It's an easy way to do that is to like bring them together into an injuring excellence team. So like instead of having a head of developer experience or a head of SRE or whatever, like have a head of injuring excellence and like have these

orgs roll up into that. So you have like, especially up until like you're like a really large enterprise, at which point each of those things ends up becoming their own. Like VPS, have them roll into a single leader. So that way like all their work is really, really aligned to each other. It makes hiring easier as well. So that's kind of like my heart takes from like an organization

design perspective. Yeah, I think thanks for sharing such a, you know, good analogy of like how big is the injuring team before you start thinking about certain things? And especially when you have hundreds or even more thousands of engineers, having such kind of a platform capability I think is really important because otherwise people will be doing the same thing with different ways.

And you cannot rationalize when things going wrong, right, or especially when you want to improve something, you kind of like double the effort and things like that. So definitely when you grow in size, you need this.

So maybe from your experience building this internal developer platform, what do you see some biggest misconception people have when they think they want to adopt platform, maybe some kind of platform engineering or IDP, right, versus actually what

actually IDP is? Yeah. So kind of going back to the data question, one of the biggest misconceptions with portals in particular is do I have to get all my data in order first before I put it into the portal, Like to get any value out of the portal? Like if I want engineering metrics, if I want scorecards and like best practices and all these things, do I have to clean all my data up first before I buy a portal or am I wasting time with a portal? That's the biggest

misconception. And the reason I say that is because if you don't have a system that can hold data and like tell you what's wrong with the data, how are you ever going to fix it in the first place, right? It's like right now everything is an unknown unknown and you can't, you can be like, I'm going to clean up my data, but like, what are you really doing? And what does that actually mean? And so like using a portal is a way to go from the unknown unknowns to the known unknowns.

So it's like, OK, well, before we didn't know anything. Now we know, we don't know. And then now we can start to clean up the data and be like, OK, well, now we know about these things. We don't know about these things is you can actually clean up your data using a port. Like that is a whole point of having a system record, right? Like a sales leader when they come in. And I love this analogy. I'm gonna keep using it.

But like when a sales leader comes into a new sales organization, they're not going to say like, first we're going to take, you know, all of our calendar invites and like, put it into a spreadsheet and then clean it up and then go by Salesforce. It's like, no, we're going to come by Salesforce, dump everything in there. And then we're going to figure out how to like make sense of this data because I need a system that's going to help me see the world. That's the first misconception.

The second misconception is if you build it, they will come. So like think people think about portal and platform initiatives as like, hey, we're going to build this like really cool stuff from like these great self-serve experiences and like it's going to be so good that people will just come and use it. Completely false. This is like basic product management, you know, product

thinking, right? It's like it's very hard for some for people to change their behaviors or the people are used to doing things a certain way, especially. And I speak for personal experience as developers, we have our VMR CS, like, you know, we spend so much time like creating our setups and like our practices, right? Like we, that's kind of who we are as an engineer. It's like we'd like to tailor our workflows and our tooling. And so if you're like, oh, there's this other tool, you're

using a platform. I've been doing these things in other ways. Seems fine to me. Like you go build your platform, I'll do my thing, right? It's like, that's a very common issue we see. And so instead, it's really important to think about starting with the definition of what good looks like, right? So it's like, hey, we're going to start with, and this is how we built our product, starting with scorecards next.

So it's like, OK, before we go off and build all these self-serve tools and platform engineering things, we're gonna build a scorecard that says like, hey, in order to go to production, these are all the things you should be doing, right? Like these are all the practices you should be following. One of our customers calls it like the Golden State. What is the Golden State of a service? And so if you define that, then your golden path makes a lot more sense.

It's like, hey, this is what every service needs to do. It's very easy to get people to buy into that, especially because most organizations have a production process already, right? Like 99% organizations of something, it's like a confluence page or some process. It's like, hey, this is what production ready looks like. And so you tell that, you tell your team. It's like, hey, we're not trying to introduce a new process.

It's nothing new. We're taking that old thing that we used to do, we're automating it and we're just gonna give you tell you exactly where you stand from a pressure ready standpoint. So we're just, we're doing a thing that we already used to do. We're just doing it better. Like, OK, that seems fine. Like I can buy into that. And so now everyone agrees like, OK, well, this is what pressure readiness looks like. Then you tell people, OK, well, you can do it your old way to

get to production ready. Sure. We built the self starter kit on our platform that like click a button, you got a new service in 5 minutes. It's going to meet all of your requirements within 5 minutes. So do you want to use the self-serve kit or do you want to go to your old thing? One in 20 people will do their old thing, but like they still have to meet all those requirements. So at least you're still getting

the same outcome. But next time that 20 people will use a new tool because it's like, well, if you're telling me I need to do all these things, that's what good looks like, which I agree with, then I'm just going to use a new tool. So now you've told people the Golden Path and the Golden State, you brought them together. That's an A, our platform is serving a very key purpose. So hold a key bottleneck and you've got that buying from the

people. So that's another misconception of like if you build it, there will come. It's absolutely not true. That's where we see a lot of IDP initiatives fail. And last but not least, it's very important to tie to a thing that they're already doing. I kind of mentioned this in this answer. You don't want to come and introduce a completely new workflow or a completely new process. Find the thing that the team is doing already and make that better and that will get bind to your platform.

So a platform doesn't have to be brand new platform doesn't have to be one thing. A platform can be collection of best of breed capabilities, right? Like that's the other things like we're going to deliver a whole platform like no, no, no, like your platform can be infrastructure as code, it can be CICD, it can be all these

things. And you can like iteratively like you can bounce around like you don't have to go and deliver a whole platform on once and see if you think about incremental value like we talked about earlier, business outcomes, Olving the thing that already exists and making that better, you will naturally say like, OK, we're just going to deliver like the smallest slice of a latform that we can continue iterating on it. So have that product management

mindset. Those are kind of like the biggest things that we see wrong with a lot of reaching ractices today. Thanks for sharing such a great misconceptions. I think some people might, you know, especially those who have embarked this journey, right? I'm, I'm sure many people can relate to this, especially the

platform as a product thing. I think still many people maybe build a platform and think people just use it or maybe worse, they kind of like force it to teams without actually, you know, explaining the reason why and you know, how it benefits them and things like that.

So obviously Cortex is one way of doing this. So maybe a little bit of plug about Cortex, how do you think people can use Cortex to help all these things? Maybe some features? I know that you have this concept of called engineering intelligence. So if you tell us a little bit more, how can you use Cortex to actually solve all these kind of things? Yeah, absolutely. So Cortex is an internal developer portal, but we like to think about it as an engineering

excellence platform. At the end of the day, it starts with the catalog. So we help you catalog all of your services, your infrastructure, your teams, and then automatically determine ownership for them. So within minutes we have an ML model that can go through all of your repos and automatically assigned teams that we believe owns each repo. So within, you know, 10 minutes of setting up Cortex, you have a list of all your repos and which teams are accountable. For each of those.

We have a product called Scorecard which allows you to define best practices and standards. So like for example, automating production readiness, tracking migrations and audits, package upgrades, security standards and what not. So being able to define as best practices and standards. And then from there we have a tool called work flows. And so workflows is basically kind of like a wizard builder where you can build experiences

for developers. So like spinning up a new service deploys, you know, infrastructure provisioning, just in time, credentials access and so on. So we have a really, really easy and powerful way to build those self server experiences, including code scaffolding and project bootstrapping. And then finally we have an engineering intelligence product which is around engineering metrics. So like to our metrics, cycle time metrics, MTTR, things like that.

And the idea is that you should get all of these things in a single platform. So you shouldn't have to go to reporting in one place and self-service in one place. And like cataloging in one place, we bring all those things to the same platform because at the end of the day, those things

are a flywheel. So measure the metrics, figure out your practices, try them using scorecards, you know, use the catalog data that like underpins all this stuff and build self-service experiences that make those things better. So at the end of the day, that's what Cortex is. We built a lot of native integration. There's a lot of automation into it. So, you know, it usually takes very, very little time to get started with it to get those metrics and catalog up to date.

Sounds like a really great tools, especially if you are like big engineering organizations. So you mentioned something about embedding AI model, right. So I think obviously the biggest thing these days people talk about, you know, AI, generative AI. So what do you think are some cool cases that you have seen maybe in your experience as well using generative AI and internal developer platform or platform engineering, any kind of like cool use cases that you can share today?

Yeah, that's a really interesting question. So there's some stuff that we're working on that I can share just yet, but I'll kind of, you know, give you like a high little idea of how we think about generative AI and like how it applies to the space. And then some of the cool use cases we've seen with it as well.

You know, we have been working with, you know, one of the BIG4 consulting firms and it's really interesting the way they use generative AI. You know, as they're doing transformation projects and modernization projects, you know, they're able to use generative AI to kind of rapidly accelerate the code transformations, the migrations

and things like that. And so rather than going in with a ton of manual effort, they build like a really powerful tool chain around platform engineering to help with the adoption of their platform. So it's not like the platform isn't about Gen. AI itself, but it's about, hey, we know this platform is going to help, you know, drive these different use cases and user journeys. Can't we use generative AI to like migrate existing things in the new world and stuff like that?

So that was really interesting use case. Another thing that I think is really important, and I call this example out, is I think a lot of tools have gone down the path of just these like generic chat bots. Like, hey, we have all this data, let's just throw a chat bot on it with some rag. Like, OK, like it's not it's cool. It's like a nice demo, but I guess it doesn't actually do anything.

And so I think like, you know, from our perspective, the application of generative AI is really going to shine when it applies to specific use cases, specific types of data. Like that's, I think that's one way to think about it. So like internally, you know, if you're on the SRE team, we've seen folks use generative AI for like, you know, analyzing their

incidents and things like that. If you are on the platform measuring team, using generative AI to summarize your own feature backlog or like requests from your end users internally. So can you find patterns of like feature requests and things like that? That's been a really interesting

use case. It's like if you had like a junior analyst on your team that you could like give a problem, be like, hey, can you go and like figure out the synthesis and like, here's how you should think about it. Those are kinds of things that it's really, really good at. Obviously, like, you know, coding assistance and the like, but like, you know that that's fairly obvious from a platform

engineering perspective. It's about getting another brain on your team that can help you reason about like, are we working on the right things? Are we finding the right patterns and so on. So that's kind of how we've seen some really interesting use cases. Right. I don't know what you're building, but I'm guessing that if you have some kind of assistant within cortex, right, that you can ask some questions and find patterns. I think that would be cool.

Definitely. Maybe that's one use case of generative. Yeah.

So Dinesh, it's been a pleasant conversation. So I have a tradition in my podcast to ask one last question for all my guests. I call this the three technical leadership wisdom. You can think of them just like an advice that you want to give to the listeners. Maybe if you can share your version today that would be great. Yeah, absolutely. My first one, then this little one I strong by very much is be

a good storyteller. It doesn't matter if you're an engineer, it doesn't matter if you're an engineering leader. Be a great storyteller. A lot of what you do in any role is telling stories, whether it's giving one of your reports advice. If you're telling the story, it's like, hey, imagine if we improve these things? Like how much better could it be? Like what kind of behaviour do we want to see? Like, how do I help my reports see the light?

You're telling a story, right? You're managing up, you're flying risk to your manager about some project. You're telling a story, right? It's not about like making up excuses or fabricating a story. It's about like, can I communicate beginning, middle and can I be concise? Can I give clear information? Can I bring people with me in my thought process? So being able to tell stories very important, especially as an engineering leader, you're

making a big decision. How do you help the team see that? How do you, like, explain to them the trade-offs, the thought that went into this, why we're doing a certain thing? What does it mean for the business? Like tell a story.

It's really, really important. The second thing I'll say is deeply understand your product, especially as an engineering leader, having a above average understanding of the product that you're working on will help you make very quick judgements and reason about the space that you're operating in, right? Like you of course will lean on your own team and the experts on your team for, you know, tactical advice and like they're the experts at the end of the day.

But if you have a deep understanding of your product, then you are able to reason about trade-offs and route information much more quickly. So I think deeply understanding your product is the second thing that I would say. And I would say probably the third thing is think, and this kind of goes back to the early part of our conversation, Think

about the culture. I know that sounds like a very vague thing to say, but the specific advice I want to give is to think about your operational cadence in particular. So the rituals and the practices that you set up help dictate the way your organization operates, especially as it's larger, right? So like, for example, if you create an operational excellence review, that itself starts to create the conversation of like, what metrics should we be looking at?

How often should we be looking at these metrics? Who should be involved? You know, are we bringing the right people? Just the fact that you have an operational excellence review creates this conversation, right? But then go on a little bit more granular. OK, In the operational excellence review, what outcomes do I wanna do I care about? And so like, how am I gonna structure the meeting agenda to

drive those outcomes, right? Like, imagine just the fact that you say like, hey, we're gonna stop our conversation 10 minutes before the end of the meeting and with the only thing we're gonna be talking the last 10 minutes are action items, right? It completely changes the format of the meeting, right? You're like, you were creating culture that like it's not just to talk about things, we want to do something about it, right?

And so it's like, how can you structure your operational cadence, your rituals to create the culture that you want? You know, it's like if you want to celebrate shipping and like, hey, like we want to create momentum, create a weekly demo meeting for your engineering team, right? It's like no matter what you built, you have to come and demo. Like you just have to demo something. Even if it's an API, come show us your code. It doesn't matter. Like show your team what you're working on.

Show us, show the interesting things we're doing across the organization. That's a ritual, right? Those rituals can also be part of other teams as well. So like maybe a ritual could be your team, like an injuring team and the support team get together for hackathon once 1/4. So it's like, OK, well what I want to hear is like cross pollination of information that's going to reduce the support load and escalations from support to engineering. Like that's the thing that I'm thinking about.

But like I'm creating a ritual that like creates that natural cross pollination between those two teams. Like what are the actual rituals that I can do on a recurring basis that even if I'm gone, if I'm on PTO or whatever, like those systems are in place that the wheels are turning and it is creating a culture where when I'm not in the room that the behaviors are still happening the way I think about it. So that would be my third thing is like think about culture from

the lens of operational cadence. So those would be my 3. I really love the last one, right? Because any times when you are, you know, into the mode of like operations production and all that, right? So you think about just the problems solving, right? But not necessarily the culture that you want to build and creating a cadence, be intentional, right? Creating a cadence. Maybe the rituals, you know, the meetings that you want to have, right?

The cross pollination thing. I think that's really important for any engineering leader. So Ganesh, if people love this conversation, they want to reach out to you, ask more questions or maybe find out more about your product and things that you built. Is there a place where they can find you online? I'm on LinkedIn to enter my name and you can also e-mail me at Ganesh cortex dot IO. All right, lovely. So thank you so much for today's

conversation. So I believe people have learned a lot of things about building engineering excellence and hopefully they can achieve that. So thanks again for that. Thank you for having me enjoy the conversation.