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
Dinesh Sukhija (00:00):
I've been part of large organizations where literally there were walls between development teams and operations teams that you build something in a sallow, you push it over the wall to an operations team and then they take all the documentation to push things. That's a very slow painstaking process. And you look at product companies or tech companies or teams that want to move fast in a growth environment, you want to be able to identify ways to ship things more seamlessly without having to depend on teams, make things more autonomous, making teams self-reliant so that you could ship things more faster and you can stay more competitive and deliver more with less.
Ganesh Datta (00:39):
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. Today with me, I have Danesh, who I've had the pleasure of working with in the past. He runs SRE Security Infra and has done a lot in his past. So Danesh, very excited to have you on.
(01:43):
If you don't mind introducing yourself real quick.
Dinesh Sukhija (01:45):
Absolutely. Hey, thanks for inviting me, Danesh. Yeah, my name is Dinesh Sukhija. I'm currently a director of engineering for some security teams at Okta using my SRE data engineering and security skills and teams to deliver security outcomes in the cyber defense organization and enterprise security tooling teams. But as you said, we had a pleasure to work together in the past before Okta was at Opendoor, leading infrastructure and DevEx teams. We were early adopters for Cortex and one thing or two about how to run a DevEx organization, how to fail and how to learn from those failures, adopt a culture of reliability using some tools like Vortex and others. Happy to dive into that. And yeah, excited to be here.
Ganesh Datta (02:29):
Very excited to have you on. Obviously, what's top of mind today for everyone is AI is changing everything, as I'm sure you know, working in cyber defense, we've saw the recent issues with Tanstack and the NPM ecosystem and all this stuff. And so I want to talk about that, but I want to maybe zoom back five years ago pre AI and talk about platforms as they were initially designed and then talk about the evolution of those today. And so like you mentioned, you have had the experience of building platform SRE infrastructure security teams from scratch in organizations that didn't have a very mature team for those kinds of things. And so I want to zoom back and talk about before AI agents, when you started building out a platform and you started building out developer experience, what were your core goals?What were you working towards?
(03:20):
Why were you brought in to build these organizations? What was the point of all that?
Dinesh Sukhija (03:23):
Yeah, I think the whole transition has moved from building teams to pivot away from operations to platform. And that's effectively been the major theme for DevEx and platform teams emergence. We are seeing the term DevOps being dropped quite a bit and we are hearing SRE teams or effectively platform teams and DevEx teams. What effectively they're doing is taking the toile away from infrastructure engineers and building paved paths and platforms and abstraction capabilities for product engineers and other engineers to just deliver things without having to depend a lot on infrastructure to teams and driving value there. So I think that's really been the major driving Ethos or practice that's given the rise to a lot of the ITPs and DevEx as a practice in general. If you just hit DevEx and Google trends, you'll see in the last three years, that term has really spiked and that's correlates with how teams are operating now.
(04:26):
Most modern teams now have less operations focused infrastructure teams and more platform focused teams where you do a lot of self-service enablement, paved paths, you create capabilities to discover things more easily and take the complexity away from product teams so that they can focus on their core capabilities and you leverage tooling and capabilities to deliver infrastructure of platform level capabilities.
Ganesh Datta (04:52):
Why is that? Why the shift away from ops and traditional interfer teams to platform and self-service type things?
Dinesh Sukhija (04:59):
Yeah, I think productivity, I think that's the main driver as teams are starting to ship more with less and productivity becomes a big focus and you start to look at which are the teams that are being blockers. I've been part of large organizations where there were literally there were walls between development teams and operations teams that you build something in a sallow, you push it over the wall to an operations team and then they take all the documentation to push things. That's a very slow painstaking process. And you look at product companies or tech companies or teams that want to move fast in a growth environment, you want to be able to identify ways to ship things more seamlessly without having to depend on teams, make things more autonomous, making teams self-reliant so that you could ship things more faster and you can stay more competitive and deliver more with less.
Ganesh Datta (05:54):
Is it safe to say the ideas around removing bottlenecks and giving people autonomy? Is that the point? You talk about dependencies and productivity, was that the primary thing you were trying to solve? It seems like developer experience is about let's give people a great experience for shipping stuff, but the way you're describing it sounds more like, "Hey, we actually want to elevate productivity and reduce bottlenecks." Is that kind of the underlying assumption?
Dinesh Sukhija (06:20):
Yeah, that is definitely the underlying assumption. And along the journey, we also realize, and this term is kind of overuse, but I think it's really important, which is developer happiness. I think happier developers tend to deliver more. They tend to stay more focused by removing these blockers like minor annoyances that add up during the day so much to the effect that the developer says, "Let's do this. I'm not going to work anymore. I'm going to take a break or what have you. " There have been studies that show that developers that don't have a good DevEx platform tend to move away from those organizations as well. So it's really important to measure developer happiness as well and that trend also picked up. And I think abstraction capabilities, IDPs, they kind of lead into that happiness factor as well that developers can ship things more seamlessly and happily without having to be blocked by things.
(07:08):
So I think that's an important side benefit.
Ganesh Datta (07:11):
That makes sense. I think what you're describing is maybe what I've seen to be the success case for platform teams in the past where developer experience and developer happiness is a desired byproduct of the platform investments, but the core thing you're trying to solve is like, how do we unblock people from moving forward and not having to depend on other teams to do that? And the second order effect of that is like, well, if you're not stuck and you're not blocked by things, not only does productivity go up, but happiness also goes up. But I think a lot of people kind of get stuck on one or the other. They focus entirely on just developer happiness and they lose sight of the core business value driving parts of the platform.
Dinesh Sukhija (07:51):
As
Ganesh Datta (07:52):
You were building out your platform teams, how did you think about making sure that you always stayed aligned to those business outcomes?
Dinesh Sukhija (07:58):
Yeah, it's really important to build something that will be used by somebody. And that's the product mindset. We feel like product engineering teams build out their roadmap, they do experimentation, they do interviews. I think the similar tactics need to be followed by platform leaders. So as to define what we are going to be building on an IDP, because that's going to define whether this is something that's somebody's vanity project or is this going to be effectively used by engineers. So my way is a lot of interviews. So speaking to engineers, speaking to leaders and managers on a daily basis, pairing them and pairing with them and watching them, like what's really bothering or hitting them in the software development lifecycle, which are the key blockers and validating those problems across teams and then defining, this is something that we should be solving for. So being very intentional about what should be on your DevEx roadmap.
(09:01):
It could be a process improvement, it could be a technology improvement and that needs to be, you need to be really lockstep with your product teams on what you want to ship. And you also want to think about usage, like how are the teams going to be using it? You want to make it very Amazon one click-like capabilities. So you don't want them to like, "Hey, look at this documentation. You don't want to make it fragmented." You don't want to build a half developer experience. You want to build something that's seamless that engineers can just go onto the portal or one click deployments and so on so that that can build a lot of adoption. So two things, just making sure that you're building something that's going to deliver real outcomes and then you build it in a way that you have strong developer experience mindset.
(09:46):
I want to quickly go back to your previous question as you were talking about key reasons why teams want to look at a developer experience or a platform mindset is also business continuity. What I've seen is that over time teams develop tribal knowledge, teams leave. We have a very complex distributed architecture right now. So over time knowledge is lost. If we are not taking steps right now to build some sort of framework that can capture this knowledge so that tribal knowledge can be aggregated somewhere so that you have good business continuity. So if teams can move on, they can still come to that one single source of truth to discover things, to still ship things and not be a person dependent process. So business continuity, productivity, developer happiness, I think these are key outcomes that we want to pursue.
Ganesh Datta (10:39):
That's a really interesting point. Yeah. I haven't heard a lot of platform leaders talk about the continuity piece of it, but it makes sense. I mean, the reason design patterns are a thing, like being able to go into a new code base and generally understand how things are being done, that's one of the reasons why design patterns are useful. And so why is that any different the lower you go in the stack, like being able to go and understand this is how things are provisioned, this is how the system is set up. And being able to consume those things without being dependent on the one info guy who has all this knowledge around how things are done makes a lot of sense.
Dinesh Sukhija (11:12):
Discoveries have become a lot easier now. Of course, I think post the November 2025 AI agent inflection point, it's become a lot easier to dig up past graves and understand why we did some things. But I think till now it was very important to have some sort of a structure to make sure that you capture tribal knowledge and make it less people dependent.
Ganesh Datta (11:33):
So yeah, let's talk about that. Clearly software engineering has changed drastically even in just the last six to eight months. A lot of platform engineering in the past was focused on golden paths and self-service because spinning up an S3 bucket of some kind or spinning up a new repo with a bunch of boilerplate would for on average take a long time and a lot of approvals in that process. Today I can open up CloudCode and say, "Give me a fully baked SpringBoot application with these 15 things and it will do that in the next 15 minutes." Why invest in things like GoldenPath? Should you invest in GoldenPaths today? Are they even still relevant or does that go out the door entirely now with AI?
Dinesh Sukhija (12:17):
Yeah, I think the GoldenPath and the PavedPath/guardrails will continue to exist. They're just changing I feel. So we are creating different PayPals. It's a different control plane right now and there are different dimensions to this. The dimensions for golden paths were at the code level there still are, but we are now elevating them to a different dimension. It could be like a security guardrail for AI or say token usage or the models that we want to choose which need to be the approved ones. So there are different types of golden paths for AI delivery code and now being in the security domain for the last one year, I have a very different perspective. So I've been in platform infrastructure space for the last, I was there for about eight years and the last one year, it's my first foray into a security engineering leadership role.
(13:10):
So a very different perspective of what a pave path should look like from a security perspective. So I think that's how the narrative is changing is that where the PayPal used to be scaffolders and like a single click deployment options on a portal, I think they're shifting more towards how do you guardrail AI shipped code and what the PavePath looks like for that.
Ganesh Datta (13:31):
That makes sense. One of the things that I think about when it comes to GoldenPaths, there was a big value proposition around standardization. If everyone does things the same way, then there's some intangible benefit that you get because it's easier to operate or whatnot. AI has definitely made some of that less relevant because you don't necessarily have to understand the code base in its entirety to go and build in it or operate it. Is there still value in the standardization aspect of different projects doing things the same way?
Dinesh Sukhija (13:59):
100%. 100%. And there's standardization from, again, from a business continuity point of view, but even during wartime situations, if you're going through an incident, you're an engineer looking at a service that you don't have exposure to, some level of standardization helps a lot. For example, and when one of my previous companies, we had standardizations around what observability should look like for a service and even just the layout. So there's less cognitive effort dispensed that, hey, if I'm going to look for something, I know top lift is going to look like this. I know right pain is going to look like this. So it really adds up in if you're operating on a day-to-day basis, especially during incident time. So that's one. Also, it helps with predictions as an engineering leader, if I have to predict a spend or a compute usage or my buying needs, I think some level of standardization helps with that as well.
(14:53):
So yeah, I still think it matters a lot and you can still enforce standardization even obviously in agentic development as well, guardrailing your skills and your agentic capabilities and your AI gateways so that you still ship code. Yeah, you're shipping it through AI, but it's still very contextual to us. It's still following our standards. It still looks more cookie cutter, which has its own benefits.
Ganesh Datta (15:18):
That makes sense. And I think even from a standardization perspective, traditionally think about humans, when look at a dashboard, it's like it's the same no matter which service I go to or I'm going to get the key signals out of the box every time because those things are really important. It's not necessarily different for agents. The more consistent things are, the more you can fine tune your own skills internally to build on different systems. It's like, hey, if you're building your own incident management agent internally, latency metrics are always going to look a certain way. This is the cardinality. These are the properties that are being tracked. And so rather than the agent having a reason about this every single time for every single service, you can fine-tune skills that are like, okay, now we can get straight to the problem versus trying to reason about the world.
(16:03):
Is
Dinesh Sukhija (16:04):
That
Ganesh Datta (16:05):
An accurate way of thinking about standardization from agent?
Dinesh Sukhija (16:08):
Yeah, no, absolutely. And absolutely. And one thought was kicking into my head when you were saying that is that as you standardize, you also give your models an opportunity to limit the sprawl. That gives you an opportunity to maybe in the future you can deploy your own micro model for a specific thing and that will obviously help you with cost metrics. I think one of the things that stop mind for many engine leaders, not just platform leaders, is the cost of AI. I feel we are right now in a very discounted phase of adoption and it's only a matter of time when token cost, but took costs are going to increase. So organizations will need to find ways to self host a micro model. And as you standardize, you limit your sprawl and your patterns through PayPal. I think that can also lead into some efficiencies in the future.
Ganesh Datta (16:59):
That's a really interesting point. Yeah, because maybe in a micro level, individual changes you're trying to make or an individual incident, the tokens don't add up. But in aggregate, those tokens add up. And if at the beginning of every incident, if your agent is trying to figure out, okay, which metrics do I need to look at? How do I get those metrics? Which system am I talking to? Maybe for that one incident, it's not a ton of tokens, but across a hundred incidents trying to do that every single time is quite a bit. But then being able to short circuit that and say, "This is exactly what you need to know. Now go and explore the world based off of that is a much different proposition and the same thing is true for code bases as well. The other thing that I think about is from a security standpoint or even from a cost standpoint, do you want agents producing Terraform files willy-nilly like, okay, I want an S3 bucket, let me just vibe code a Terraform file for a bucket that's just grossly doesn't have the right security permissions or I'm going to provision a cluster that is just grossly over-provisioned." My guess is we probably don't want that.
(18:02):
And so those things are still constrained by like here is the paved road for provisioning a cluster or a piece of infrastructure because that's not a thing you want agents doing. Is that the right way of thinking about it or how do you think what agents are allowed to do versus what things are deterministic pre-baked parts of the process?
Dinesh Sukhija (18:21):
Yeah. Yeah. So I mean at this point the Genie is out of the bottle. You can't stop teams using agenting development and I think that's detrimental to your own growth as well. So the way we are approaching secure agentic development is to continue to focus on guardrails and paved paths to make sure that we are not accidentally shipping code that can be detrimental or it could expose us in a security incident. But at the same time, we don't want to cost too many blockers. So we are approaching security guardrails in a more developer friendly way. Our focus continues to be that, hey, less 10x of productivity both on the development side, but also on the security side. So it's not going to be helpful if your product teams have 10X there capabilities, but the security teams are still hinged on traditional processes to control this.
(19:19):
So you meet AI with AI, how do you improve your product security capabilities? How do you increase your cyber defense capabilities, detection capabilities, and at the same time not slowing down product teams. I think it's a very interesting opportunity for security engineering teams to step up to this challenge.
Ganesh Datta (19:40):
I'd love to hear more about that actually. What's the most exciting thing that you found recently applying AI to verify AI from a security standpoint? Because I mean, obviously it's top of mind for everyone today. We've seen the TanStack issues and the Shih Lud type things and the kinds of attack vectors are growing quicker than we can even imagine. So yeah, how are you thinking about that? What is something you've done recently that has really delivered a lot of value?
Dinesh Sukhija (20:06):
Yeah, I can confirm on what we've done, but I'll tell you what's cooking in the industry and potentially in our organizations is on both front. So obviously AISRI is a big domain that's kicking in, but there's also AI SOC and Agent Tick SOC, which is security operations center capabilities. So making sure that while threat actors are leveraging AI to identify exploits quickly, the defense teams are also looking at tooling both custom and off the shelf to make sure that before a threat is even exploitable, identifying a threat model, writing capabilities and rules that can detect and respond to those rules in a more AI fashion. So think about agentic flows that can identify that is watching for a published threat, quickly writing its own detections, deploying them, and then also creating some sort of SOAR and alert playbooks. So that's where I feel the whole SOC industry is moving, but even the AppSec and the SBOM and the SEA capabilities are looking at various AI infusions to make sure that teams that are leveraging say packages that might be easily exploited now, how do we intercept them in our AppSec capabilities to make sure that they're not getting shipped when the vulnerabilities is active.
(21:50):
So those are some of the ways that we are looking at meeting AI with AI.
Ganesh Datta (21:54):
Is there a worry that if AI can introduce threat vectors on the development side that meeting AI with AI with the same risks introduces new risk factors on the detection side? I guess you said differently, are there non-deterministic properties of applying AI to the detection side that is causing concern? Or how do you think about that from a security landscape perspective?
Dinesh Sukhija (22:22):
Yeah, I mean, you have to rely on your existing set of detection capabilities from the tools that are happening. So as you look at say developer station workflows, we're looking at endpoint security capabilities, there's new domain in the AI DR space, which is again, looking at a developer's AI use cases and detecting any intent, malicious intent there at the development phase. So the detection response space traditionally has been like, hey, you collect a lot of logs, you write a bunch of rules based on threat actors, but then you're also now looking at deploying agents, and these are endpoint agents to do AI detection and response capabilities in the developer workstations as well. So the whole DSPM space space is also kind of expanding. So that's data security posture management that's extending now into what does it mean for AI as well? Are there agents that are using some of the data that they shouldn't be?
(23:26):
Are we accidentally exposing any sensitive data to AI agents? So that's a capability that a lot of teams are looking at as well and how do you bring in DSPM offerings that can give you an AI security posture management as well?
Ganesh Datta (23:39):
That makes sense. It sounds security has always had this mindset, which is there's stuff happening in the development life cycle and you kind of want to guardrail against that so that bad things don't happen on the other side. And the way we do that and the things that we're looking at are maybe changing other parts of the organization, platform and SRE have been more, I guess, enablers versus guardrails on the system. And do you think that platform and SRE are kind of going the way of security where it's like more of a safety net where it's not just about convenience and the experience anymore, but it's more like, "Hey, if you mess up, we're there to catch you type of a system where security
Dinesh Sukhija (24:23):
Has
Ganesh Datta (24:23):
Always been a little bit about that.
Dinesh Sukhija (24:25):
" Oh yeah, yeah, yeah. I think there is definitely an aspect of secure coding if that's extended to platform teams now. For example, when we talk about how do you guardrail, what's the right model for our organization? Potentially the answer to that is maybe develop an AI gateway and then use that gateway capabilities to enforce a lot of the things like model choice, cost controls, data security controls and so on. So I definitely think platform teams are creating secure paved paths now as well, keeping security in mind for developers.
Ganesh Datta (25:02):
What about SRE? One of the things that we've seen in the data is that the forward pressure of PR, the amount of code we're producing is just straining systems so much. And historically in the traditional SRE model, you see that SRE is kind of like the "first line of defense." Obviously there's nuances to it, but when things start to degrade, SRE at the end of the day is accountable for aggregate reliability of the systems. And how do they keep up with this? Is there more the way security is like, "Hey, these are just non-negotiables. We must follow these things, otherwise you cannot go to production." SRE has historically been more of guidance and influence and like, "Hey, here are the things you should be doing so that you can improve reliability." Is SRE becoming more security in the sense of the only way to keep up with the amount of stuff we're producing is to be more of a systemic back pressure of like, you cannot do these things or you must follow these practices.
(25:57):
How is SRE evolving from your perspective?
Dinesh Sukhija (26:00):
Yeah, I think all these guardrails need to continue to shift left. We cannot just keep it on the SRE teams. So with the practices of obviously making sure that you have paved paths, like the traditional pay paths, you have AI pay paths, but you also continue to improve your shift left security tooling to make sure that when code is actually getting reviewed, I know it's up to snuff your organization standards and obviously AI code review capabilities are getting a lot more mature now and you can build skills and context in your AI code review tools as well to make sure that it's taking care of SRE, reliability capabilities and security capabilities. And obviously you eventually have a lot of SRE engineers, the human in the loop that goes to play in the delivery lifecycle as well. But I'm actually quite bullish about the whole AI SRE product suite as well.
(26:55):
I think it's really become important just because of the volume of code. And traditionally, the toilet SRE teams have been a lot. I've managed many teams. I've never seen as much stress in SR with SRE teams. They're always stressed. The happiness index is always the lowest with SRE teams. So I think AISR is a great opportunity for some of the teams to lower the toil and improve not just the security posture, but the reliability posture as well in a more autonomous way.
Ganesh Datta (27:23):
As these teams are becoming, I guess, even more critical than ever before, everyone is a builder, anyone can ship stuff, more code going into production. These teams are all becoming more of a safety net. Are there opportunities for these teams like security and platform and SRE to work together as a more cohesive unit than they have in the past to provide that more holistic guardrail? I think you've had a unique experience where you have managed more holistic groups that touch on all of these pieces, but you don't always see that in organizations. Is there an opportunity there for those teams to work more closely together?
Dinesh Sukhija (28:01):
I think that's a fascinating point. I think one good question would be what an org of the future could look like and the future is already here. And we are seeing these amalgamation of roles now, right? We saw with CTO, CPO roles, we are seeing a lot of CTPO roles now. We are seeing a lot of product engineers shipping code. I encourage my engineers to put on the product hat in the security space to build that. So I think we'll continue to see a fusion of product and engineering, but also product engineering and security engineering as complexity shifts upwards now, you're not just worried about your algorithms or your core code or the guts of the code, but you're worried about the ecosystem now. So I think there is a great opportunity for senior leadership to think about like, hey, maybe we need to reimagine our organization, maybe we need to bring security SR teams together.
(29:01):
Maybe we hire or our hiring bar needs to race for engineers that can think about reliability, but can also think about security and not just product security. Can again, they also think about SOC security and so on. So I think I don't know what the answer for that could be, but I definitely see that it could continue to infuse in some way as everybody's getting superpowers with AI.
Ganesh Datta (29:24):
It also seems like those teams need to work more closely together than they have in the past where you were talking about this earlier where you want more of the security practices shifted left. So it's more of it is embedded in the platform itself. And if you're building out AI SRE capabilities, then the ability to pull data from the platform to reason about the world becomes more important. And so should those functions, especially in small organizations, let's say like sub 500 person engineering teams especially, should SRE and Infra and platform and security be part of the same And function with the same leader or how do you see that part of the organization shifting in the coming year?
Dinesh Sukhija (30:07):
Yeah, I think especially for smaller organizations, their mandate is to move fast. I think it'll be beneficial for security and product leadership to be under one leader, or at least platform and security to be under one leader. It's very important for the organization to have a good technical leadership that can make the influence. I've seen organizations that are run by non-technical teams or just pure product teams and they tend to suffer on the platform and security roadmap. So it's really important, especially now as everybody's shipping code, sometimes they don't know what they're shipping, that they have strong culture and appreciation of what could go wrong and what the op structure should look like so that product and security teams can appreciate each other's mandate and build something together. So organizations start off small, then they branch off, then you have different leadership and then you tend to see some tension between them.
(31:05):
But I think there's relevant questions being asked right now. Maybe it's time to bring the teams together under one leadership now.
Ganesh Datta (31:13):
We're almost up on time. And so I want to shift gears to maybe a final topic a little bit about your own personal learnings and your advice for other engineering leaders. You've had a very interesting career compared to a lot of folks that I talked to where you've done a little bit of the entire spectrum from product engineering to infra to developer experience to platform to security. You've done it all and they're very different fields with their own challenges. What mindset has helped you be successful in this wide spectrum? Yeah, what's the secret?
Dinesh Sukhija (31:50):
I've always believed in saying yes to hard things and just believing in my own capability to grind it out, fail, learn, and being brutally honest about what I can deliver and what I can't. So I'm personally driven by growth mindset and a lot of hustle within me, just tenacity that I've built with that just allowed me to like, "Hey, I've never done security, but I'll be interested in learning more about it. " And every couple of years I've learned something new. And so I mean, one advice I give to everybody, my friends, my teams is say yes to hot things. Do the hard things because that's the only way you could grow. So don't have the courage to say that, "Yeah, I don't know this yet, but yeah, I'll continue. I'll figure this out and then I'll do this. " So that's what I believe in and that's what's taken me through different types of roles and different domains.
Ganesh Datta (32:44):
I guess on that similar vein, if you were talking to another engineering leader who's about to start at a company that's all in on AI, 90% of their PRs are written by coding agents, but they're building out a security platform SRE team for the first time, what advice would you give them to make sure that that initiative succeeds and is not just relegated to the side?
Dinesh Sukhija (33:08):
Yeah, I definitely want them to look at what a paved path for a security team looks like. So what guardrails, systemic guardrails do you want to build in your coding lifecycle or your delivery lifecycle to make sure that the codes that again ship is up to not just your product engineering or SRE standards, but also security standards. And also making sure that being mindful of what security theater was actual outcome, because you want to make sure that you build these guardrails that actually move the needle for your organization at that stage of your organization. Your security roadmap will continue to change as you mature in your own organization's journey. At some point, SRE will become very important. At some point, security, very important is very important for the security leadership to pivot based on what the organization's journey is and not just continue to stay stuck to their own view of what security should look like.
Ganesh Datta (34:07):
Is there anything you would recommend they do to make sure that they influence works and shaping the culture? If they're building security or platform or something like that for the first time, there's probably a mindset of like, oh, shipping features is the most important thing, but you're probably building this function because there's a real need for it. Is there anything that you would share to make sure that, hey, you can shift the mindset of the organization to care about these things and not just shipping features, anything that you would share around that?
Dinesh Sukhija (34:39):
Yeah. I mean, I'm a strong believer of measurable outcomes. One thing that I recall is this capability that Cortex, by the way, built, which was around scorecards. I think we built security scorecards. At one of my previous organizations, we built scorecards for everything and then we presented those and that can really drive impact when you really start seeing data behind speak. So definitely make sure that if you want to make an impact, make sure that you can bring measurable outcomes or measurable problems that can help the decisions move in your favor.
Ganesh Datta (35:16):
Makes a lot of sense. Dinesh, thanks so much for joining the podcast. A lot of interesting learnings in here for folks as they're thinking about the evolution of security and platform and SRE in this AI era. Thanks so much for joining.
Dinesh Sukhija (35:27):
Thank you so much, Ganesh.
Ganesh Datta (35:34):
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.