1 00:00:00,040 --> 00:00:02,840 I imagine if a sales leader said like I don't need Salesforce, I 2 00:00:02,840 --> 00:00:06,200 don't need CRM, we're just going to sell and hope for the best. 3 00:00:06,200 --> 00:00:07,840 Like you would fire that sales leader tomorrow. 4 00:00:07,840 --> 00:00:11,040 So why is it that injuring leaders are not treated the same 5 00:00:11,040 --> 00:00:13,160 way? Every single other function has 6 00:00:13,160 --> 00:00:15,520 a system of record, right? Like sales teams have CRM, 7 00:00:16,000 --> 00:00:18,240 finance has ERP, but what does injuring have? 8 00:00:18,400 --> 00:00:21,280 It's like the wild, Wild West. Today I have with me Ganesh 9 00:00:21,280 --> 00:00:24,000 Dutta. He's the Co founder and CTO of 10 00:00:24,000 --> 00:00:27,400 Cortex dot IO. Reliability practices, security 11 00:00:27,400 --> 00:00:30,800 practices, efficiency practices, and velocity practices. 12 00:00:31,200 --> 00:00:33,600 Those four are the kind of like pillars of injuring excellence 13 00:00:33,600 --> 00:00:35,600 to us. Injuring excellence basically 14 00:00:35,600 --> 00:00:38,520 means like the alignment of injuring practices with business 15 00:00:38,520 --> 00:00:40,320 outcomes. Think about those business 16 00:00:40,320 --> 00:00:42,040 outcomes that injuring excellence ties into. 17 00:00:42,400 --> 00:00:44,080 It tends to buck into these three things. 18 00:00:44,080 --> 00:00:47,000 It's time to value, time to market, and innovation. 19 00:00:47,160 --> 00:00:49,680 It's not just about the metric. What you need is like an end to 20 00:00:49,680 --> 00:00:53,040 end platform that helps you understand like your software 21 00:00:53,040 --> 00:00:55,160 ecosystems. At what point in engineering 22 00:00:55,160 --> 00:00:58,280 stage do you think everyone should try thinking seriously 23 00:00:58,280 --> 00:01:00,080 about having this platform engineering and internal 24 00:01:00,080 --> 00:01:01,760 developer platform? You need to start with data. 25 00:01:01,760 --> 00:01:04,200 Do you have a system where you can track your software assets, 26 00:01:04,200 --> 00:01:06,640 infrastructure assets? A single place where you can 27 00:01:06,640 --> 00:01:08,400 determine accountability and ownership. 28 00:01:08,560 --> 00:01:11,680 What do you see some this misconception people have when 29 00:01:11,680 --> 00:01:13,320 they think they want to adopt A platform? 30 00:01:13,520 --> 00:01:16,080 One of the biggest misconceptions with portals in 31 00:01:16,080 --> 00:01:19,120 particular is do I have to get all my data in order first 32 00:01:19,120 --> 00:01:22,080 before I put it into the portal? The second misconception is. 33 00:01:38,720 --> 00:01:40,720 Hey guys, welcome back to another new episode of the 34 00:01:40,720 --> 00:01:43,520 Technical Journal podcast. Today I have with me Ganesh 35 00:01:43,520 --> 00:01:46,920 Dutta. He's the Co founder and CTO of 36 00:01:46,920 --> 00:01:49,880 Cortex dot IO. So today we'll be talking a lot 37 00:01:49,880 --> 00:01:53,200 about how to build a great engineering team best in class. 38 00:01:53,360 --> 00:01:54,760 So welcome to the show Ganesh. Thanks. 39 00:01:55,360 --> 00:01:58,120 For having me. Right Ganesh, I always love to 40 00:01:58,120 --> 00:02:01,560 start by maybe having my guests explaining about themselves. 41 00:02:01,560 --> 00:02:03,080 Maybe. Any current turning points that 42 00:02:03,080 --> 00:02:04,720 you think we all can learn from you? 43 00:02:05,240 --> 00:02:07,640 So my name is Ganesh, I'm one of the Co founders and CTO Cortex. 44 00:02:07,640 --> 00:02:10,720 Like you mentioned, I was a software engineer before 45 00:02:10,720 --> 00:02:15,640 starting Cortex. I was at a fintech startup and I 46 00:02:15,640 --> 00:02:18,000 got to see the mullet to micro service journey while I was 47 00:02:18,000 --> 00:02:21,400 there. And it was a very interesting 48 00:02:21,400 --> 00:02:24,440 opportunity because there are quite a few turning points. 49 00:02:24,440 --> 00:02:27,360 And I'll kind of give you the story of the journey that I went 50 00:02:27,360 --> 00:02:28,720 through and some of those turning points. 51 00:02:28,720 --> 00:02:32,800 So when I started at this company, I was working on a team 52 00:02:32,880 --> 00:02:37,280 and there was an initiative to break the first microservice out 53 00:02:37,280 --> 00:02:39,960 of the monolith. I eventually got added to that 54 00:02:39,960 --> 00:02:44,600 team and it was interesting because at the time that 55 00:02:44,600 --> 00:02:48,080 particular project was successful, but kind of 56 00:02:48,080 --> 00:02:49,760 struggling. And so like, it was a first 57 00:02:49,920 --> 00:02:51,680 microservice. There's a lot of learning, a lot 58 00:02:51,680 --> 00:02:55,360 of things we had to do. And it was an interesting time 59 00:02:55,360 --> 00:02:58,080 because at face value was like, OK, a lot of things are broken, 60 00:02:58,080 --> 00:03:00,640 like lots of bugs, like a lot of bug fixing. 61 00:03:01,080 --> 00:03:05,120 And it was, especially as an early career engineer, it felt 62 00:03:05,120 --> 00:03:07,160 like, Oh my God, I'm just like fixing bugs all day long. 63 00:03:07,160 --> 00:03:10,160 Like, what's the point here? But I would say it was actually 64 00:03:10,160 --> 00:03:13,640 a turning point in my career because it allowed me. 65 00:03:13,640 --> 00:03:16,520 And this is where I think my manager coaching helped a lot 66 00:03:16,520 --> 00:03:19,560 was, hey, like, don't look at these as just bugs, right? 67 00:03:19,560 --> 00:03:22,600 Like if you want to become a, you know, very senior engineer 68 00:03:22,600 --> 00:03:25,400 one day, the whole point is to be able to look at these things 69 00:03:25,400 --> 00:03:27,160 and say, what are the patterns we're seeing here, right? 70 00:03:27,160 --> 00:03:29,640 And so like, I think that framing really, really helped. 71 00:03:29,640 --> 00:03:32,840 I was like, OK, well, I started thinking about them as bugs and 72 00:03:32,840 --> 00:03:36,600 let me start thinking about them as patterns of issues in this 73 00:03:36,600 --> 00:03:40,640 particular micro service. And so eventually I, you know, 74 00:03:40,640 --> 00:03:43,360 saw a ton of patterns and I got the opportunity to propose like 75 00:03:43,360 --> 00:03:46,920 a new architecture for the way we were computing, like account 76 00:03:46,920 --> 00:03:49,840 management data for credit cards and loans and things like that. 77 00:03:50,440 --> 00:03:53,600 And so we got by in to work on this big project. 78 00:03:53,600 --> 00:03:56,920 And it was great because having had that personal pain of going 79 00:03:56,920 --> 00:03:59,600 through all these different bugs, I knew exactly the impact 80 00:03:59,600 --> 00:04:01,160 it would have to do this RE architecture. 81 00:04:01,160 --> 00:04:03,320 And like I know every engineer wants to do a RE architecture, 82 00:04:03,600 --> 00:04:07,360 but I think the the point was I was able to articulate a very 83 00:04:07,360 --> 00:04:09,560 clear business value and like the types of bugs we were 84 00:04:09,560 --> 00:04:11,640 running into and the customer impact and whatnot. 85 00:04:12,200 --> 00:04:14,680 And so I've got to take on that project and there was a ton of 86 00:04:14,680 --> 00:04:17,480 learnings around that, you know, the way you communicate it, the 87 00:04:17,480 --> 00:04:19,160 way you set timeline. So that I would say like that 88 00:04:19,160 --> 00:04:20,480 was a really pivotal project for me. 89 00:04:21,120 --> 00:04:23,960 Another thing that, you know, I got to do while I was there was 90 00:04:24,560 --> 00:04:26,160 a lot of performance based things. 91 00:04:26,160 --> 00:04:29,120 It was like these small issues that kept popping up. 92 00:04:29,160 --> 00:04:31,960 And it was an opportunity for me to be much more proactive. 93 00:04:31,960 --> 00:04:35,000 Like, without anybody saying, like, you just go in and dig 94 00:04:35,000 --> 00:04:37,280 through Datadog and say, like, where are we seeing like our 95 00:04:37,280 --> 00:04:41,560 highest P90 fives and, you know, P90 requests and what are the 96 00:04:41,560 --> 00:04:43,040 patterns, What are the bottlenecks we're seeing? 97 00:04:43,040 --> 00:04:45,320 And can we start attacking those more aggressively? 98 00:04:45,320 --> 00:04:49,120 And so in my spare time, I would go and try to fix these issues 99 00:04:49,120 --> 00:04:51,960 and eventually it was a really fun thing we would do at every 100 00:04:51,960 --> 00:04:55,840 endpoint that we fixed our P 90s and P90 fives, we would print 101 00:04:55,840 --> 00:04:58,400 out a chart of like the latency graph and I would stick it up on 102 00:04:58,400 --> 00:05:00,240 the wall next to me. So eventually I had like a 103 00:05:00,240 --> 00:05:02,200 trophy case of these like latency charts. 104 00:05:02,360 --> 00:05:04,440 It's like, look at all the things that we fixed, you know, 105 00:05:04,440 --> 00:05:06,000 over the over the last year or so. 106 00:05:06,320 --> 00:05:09,000 And it was just a way to show like, hey, I'm, it's a way for 107 00:05:09,000 --> 00:05:12,680 you to represent the kind of like sloping work that you have 108 00:05:12,680 --> 00:05:14,800 to do to keep services and systems up and running. 109 00:05:14,800 --> 00:05:16,000 So I would say that's another turning point. 110 00:05:16,000 --> 00:05:19,880 And the last one I'll say was really investing time and energy 111 00:05:19,880 --> 00:05:23,280 into how can I take all the things that we learned and share 112 00:05:23,280 --> 00:05:25,640 them across the organization. And it was another thing that 113 00:05:25,640 --> 00:05:30,800 was just like it came from personal pain, which is I as an 114 00:05:30,800 --> 00:05:32,840 engineer that was on call for service, I would get paid for 115 00:05:32,840 --> 00:05:35,040 something. I'd go to another service and I 116 00:05:35,040 --> 00:05:36,280 try to like figure out what's going on. 117 00:05:36,280 --> 00:05:38,640 It was it was like a downstream or upstream service on an issue. 118 00:05:39,000 --> 00:05:40,600 And like the logs look totally different. 119 00:05:40,600 --> 00:05:42,320 The metrics are named completely different. 120 00:05:42,520 --> 00:05:44,960 Like, why is my service doing one thing and your service is 121 00:05:44,960 --> 00:05:47,000 doing another thing? Like it sucks to manage these 122 00:05:47,000 --> 00:05:48,600 services. I took it upon myself to say, 123 00:05:48,600 --> 00:05:50,520 OK, we're going to standardize this thing. 124 00:05:50,520 --> 00:05:52,160 And it was more out of frustration than anything else. 125 00:05:52,160 --> 00:05:54,120 I was like, we just got to do things the same way. 126 00:05:54,120 --> 00:05:56,720 Otherwise I'm going to like, I'm going to lose it. 127 00:05:57,080 --> 00:06:00,360 And so put together this like what I eventually realized was a 128 00:06:00,360 --> 00:06:03,000 production readiness checklist, but it was just like list of 129 00:06:03,000 --> 00:06:05,440 best practices and standards and like login formats. 130 00:06:05,440 --> 00:06:07,120 And I was like, OK, nobody's following these practices. 131 00:06:07,120 --> 00:06:09,360 So I'm going to make it really easy to do these things. 132 00:06:09,360 --> 00:06:12,520 I built like standard libraries that like would pre configure 133 00:06:12,520 --> 00:06:14,040 your request tracing and your logging. 134 00:06:14,040 --> 00:06:16,480 And then we built like cookie cutter templates to spin up 135 00:06:16,480 --> 00:06:19,200 these services and without realizing it was like I was kind 136 00:06:19,200 --> 00:06:22,720 of doing these like grunt work, dev experience type things. 137 00:06:22,720 --> 00:06:25,360 And now obviously like teams have come up around that, but 138 00:06:25,360 --> 00:06:28,520 the time was not really a thing. And it was an example of like, 139 00:06:28,560 --> 00:06:32,720 hey, if you can make your peers lives better, you will get that. 140 00:06:32,720 --> 00:06:35,240 You will earn that respect. You will earn the right to kind 141 00:06:35,240 --> 00:06:36,960 of take on bigger and bigger projects. 142 00:06:37,280 --> 00:06:39,080 And like, don't wait for permission for a lot of these 143 00:06:39,080 --> 00:06:40,480 things. Like you can make things better. 144 00:06:40,800 --> 00:06:42,400 And so that was another turning point for me. 145 00:06:42,400 --> 00:06:44,960 And like, the reason I tell these stories is also it helped 146 00:06:44,960 --> 00:06:47,400 me in my own personal career and growth as a software engineer. 147 00:06:47,840 --> 00:06:49,600 But those were the things that led me to Cortex as well. 148 00:06:49,600 --> 00:06:52,240 So like the idea of like, hey, how do we help bigger and bigger 149 00:06:52,240 --> 00:06:55,080 organizations do like production readiness and ownership and 150 00:06:55,080 --> 00:06:57,920 standardizing the way you you operate And like Dr. Excellence 151 00:06:57,920 --> 00:07:00,360 and standards like that became a bigger and bigger, bigger 152 00:07:00,360 --> 00:07:02,920 question for me until it was like, I got to do this a better 153 00:07:02,920 --> 00:07:03,960 way. And that's going to have Cortex 154 00:07:03,960 --> 00:07:05,400 started. So it was a kind of a series of, 155 00:07:05,800 --> 00:07:07,400 you know, turning points for me and my career. 156 00:07:07,400 --> 00:07:09,880 And then eventually the biggest turning point was like I quit 157 00:07:09,880 --> 00:07:12,000 and started Cortex. So like, yeah, those those are 158 00:07:12,000 --> 00:07:14,600 kind of the things that I found really impactful as part of my 159 00:07:14,600 --> 00:07:16,960 journey. Thank you for sharing such a 160 00:07:16,960 --> 00:07:19,200 good story, right? So I feel there are many things 161 00:07:19,200 --> 00:07:21,080 that we can learn just from your sharing, right? 162 00:07:21,080 --> 00:07:23,320 The first is about like looking for patterns, right? 163 00:07:23,440 --> 00:07:26,600 Maybe it could be bugs, could be issues, incidents, whatever that 164 00:07:26,600 --> 00:07:28,480 is, right? Because sometimes when we are 165 00:07:28,560 --> 00:07:31,720 tested in those moments, right, we feel frustrated or why is 166 00:07:31,720 --> 00:07:33,880 this happening to me? But actually, if you want to 167 00:07:34,000 --> 00:07:37,160 level up and step up, right, So you can probably solve the root 168 00:07:37,160 --> 00:07:40,320 cause instead of just the bugs, the symptoms of the issues, 169 00:07:40,320 --> 00:07:42,280 right? And I think learning, learning 170 00:07:42,280 --> 00:07:44,600 and sharing, I think that's really a good thing as well for 171 00:07:44,600 --> 00:07:46,840 any engineers, right? It could be internal, it could 172 00:07:46,840 --> 00:07:49,680 be also publicly, maybe through blog post or whatever that is, 173 00:07:49,680 --> 00:07:51,840 right? So maybe I would like to pick a 174 00:07:51,840 --> 00:07:53,880 little bit about finding the patterns, right? 175 00:07:53,880 --> 00:07:56,800 Because I'm sure in most engineering teams, they will 176 00:07:56,800 --> 00:08:00,000 always have these issues, incidents that they have to 177 00:08:00,000 --> 00:08:02,080 face, especially when things are in production, right? 178 00:08:02,560 --> 00:08:05,800 So for engineers that want to, I don't know, improve their skills 179 00:08:05,800 --> 00:08:09,120 in finding the root cause and fixing it, what will be your 180 00:08:09,120 --> 00:08:13,360 advice to, you know, look for patterns instead of just fixing 181 00:08:13,360 --> 00:08:15,600 the issues? Is there any practices or things 182 00:08:15,600 --> 00:08:18,280 that you do normally? Yeah, I think it's, it's 183 00:08:18,280 --> 00:08:20,720 important to be very systematic about it. 184 00:08:21,040 --> 00:08:25,040 If we're a marketing team and we're trying to find like which 185 00:08:25,040 --> 00:08:28,440 cold emails work best, we're not just going to like look at our 186 00:08:28,440 --> 00:08:32,280 emails and pray like, OK, well, let's hope we get the best 187 00:08:32,280 --> 00:08:33,280 e-mail. It's like, OK, we're going to 188 00:08:33,280 --> 00:08:35,360 send out three different types of emails from look at the 189 00:08:35,360 --> 00:08:37,240 response rates. And like you're very systematic 190 00:08:37,240 --> 00:08:38,760 about it. Like, why not do the exact same 191 00:08:38,760 --> 00:08:42,280 thing for engineering practices? And so if you were like a very 192 00:08:42,280 --> 00:08:44,720 junior engineer and you're feeling frustrated by incidents, 193 00:08:44,880 --> 00:08:47,560 let's take an example. One of the things that you can 194 00:08:47,560 --> 00:08:52,560 do is think about, OK, am I frustrated at the fact that I'm 195 00:08:52,560 --> 00:08:55,000 being alerted? Am I frustrated at like constant 196 00:08:55,000 --> 00:08:56,840 interruptions? Am I being frustrated? 197 00:08:56,840 --> 00:09:00,560 Am I frustrated about the lack of of information when something 198 00:09:00,560 --> 00:09:03,040 goes wrong? Like something is it something 199 00:09:03,040 --> 00:09:04,680 is going wrong and I don't know what to do about it. 200 00:09:04,680 --> 00:09:08,440 Something is going wrong and it's the same thing has happened 201 00:09:08,440 --> 00:09:10,480 multiple times. Nothing is going wrong and I'm 202 00:09:10,480 --> 00:09:13,440 being alerted about it. Nothing is going wrong or it 203 00:09:13,440 --> 00:09:15,120 looks like nothing is going wrong, but something is going 204 00:09:15,120 --> 00:09:16,160 wrong. When you realize like there's 205 00:09:16,160 --> 00:09:17,880 kind of these buckets you can bucket it into. 206 00:09:17,880 --> 00:09:19,920 And so I was like, OK, I'll start there, but how would I 207 00:09:19,920 --> 00:09:22,680 like, assess my own view of the world in some sort of like 208 00:09:22,680 --> 00:09:24,120 meaningful way? And it doesn't have to be 209 00:09:24,120 --> 00:09:26,240 perfect because if you start with some simple like 210 00:09:26,520 --> 00:09:28,880 categorization of these things, like as you go through, you will 211 00:09:28,880 --> 00:09:31,440 naturally realize, hey, there's actually another class of things 212 00:09:31,440 --> 00:09:33,360 that I didn't think about. Let me go back and like it right 213 00:09:33,360 --> 00:09:36,480 on my pattern, the patterns I want to match against and so on. 214 00:09:36,480 --> 00:09:38,760 And so like starting with like even something rudimentary is 215 00:09:38,760 --> 00:09:40,920 really important. The thing that, you know, I 216 00:09:40,920 --> 00:09:43,000 started with as a very junior engineer was like alert 217 00:09:43,000 --> 00:09:44,880 categorization. It was like this bucketing of 218 00:09:44,880 --> 00:09:46,360 alerts. And I was like, OK, like I don't 219 00:09:46,360 --> 00:09:48,400 even know what the patterns are, but I know that there's like 220 00:09:48,920 --> 00:09:51,640 general things that like I'm getting alerted for that I 221 00:09:51,640 --> 00:09:54,000 shouldn't be or what not. As I went through and I got a 222 00:09:54,000 --> 00:09:55,960 list of like all the alerts in the last three months and I 223 00:09:55,960 --> 00:09:57,920 literally just went through and marked them like, there 224 00:09:57,920 --> 00:09:59,600 shouldn't be alert, there should be alert, there shouldn't be 225 00:09:59,600 --> 00:10:01,080 alert, here's a run book, blah, blah. 226 00:10:01,480 --> 00:10:03,680 And then share it with a team. I was like, I don't even know if 227 00:10:03,680 --> 00:10:05,800 I'm doing this right. Let's get the team's feedback. 228 00:10:05,800 --> 00:10:07,840 And it was like, hey, actually this alert is really important 229 00:10:07,840 --> 00:10:10,000 because of X or this alert doesn't make sense. 230 00:10:10,000 --> 00:10:12,840 We can like quiet it or, you know, it's kind of like that, 231 00:10:12,920 --> 00:10:15,440 that conversation of why are we even doing these things? 232 00:10:16,000 --> 00:10:17,600 And then you go back and you kind of iterate and it's like, 233 00:10:17,600 --> 00:10:19,400 OK, well, if this alert's important, then why is it 234 00:10:19,400 --> 00:10:20,720 frustrating? Is it because I don't know what 235 00:10:20,720 --> 00:10:22,080 to do about it? Then you go back with the 236 00:10:22,080 --> 00:10:24,560 proposal and like, I think that iteration loop is really 237 00:10:24,560 --> 00:10:26,840 important. I think the other thing to do is 238 00:10:26,840 --> 00:10:30,240 like, honestly, I mean, now with LLMS, you can even like take a 239 00:10:30,240 --> 00:10:33,760 list of your JIRA tickets and put it into an LLM and say like, 240 00:10:33,760 --> 00:10:35,160 hey, like, tell me what you, what do you see here? 241 00:10:35,160 --> 00:10:38,400 All right, like it's much easier now than I think it was like 10 242 00:10:38,400 --> 00:10:40,360 years ago. But the ability to kind of go 243 00:10:40,360 --> 00:10:44,320 through and say, if you're on a product team, can you categorize 244 00:10:44,320 --> 00:10:47,160 the types of things you're working on into the highest 245 00:10:47,160 --> 00:10:48,800 level abstraction? It's it's like basic software 246 00:10:48,800 --> 00:10:50,040 engine practice. You're like, what is the highest 247 00:10:50,040 --> 00:10:52,840 level abstraction possible? Before you go really low, Like, 248 00:10:52,840 --> 00:10:54,920 OK, these tickets that I'm working on, these bugs I'm 249 00:10:54,920 --> 00:10:57,240 working on are on this part of the product and this part of the 250 00:10:57,240 --> 00:10:58,720 product. OK, let me go into that part of 251 00:10:58,720 --> 00:11:00,800 the product. Now make it a little bit more 252 00:11:00,920 --> 00:11:02,280 granular, a little more granular. 253 00:11:02,520 --> 00:11:04,840 It's like, OK, well now I'm not able to break it down into any 254 00:11:04,840 --> 00:11:07,680 patterns, but you naturally found patterns that way by like 255 00:11:07,680 --> 00:11:09,880 starting at the biggest abstraction layer and whittling 256 00:11:09,880 --> 00:11:12,400 it down more and more granular. Then you can work your way up 257 00:11:12,400 --> 00:11:14,240 and see how things relate. And so I think going through the 258 00:11:14,240 --> 00:11:16,120 like that systematic exercise is really important. 259 00:11:16,840 --> 00:11:19,720 Yeah, so many great tips for those of you engineers who want 260 00:11:19,720 --> 00:11:22,520 to kind of like improve your skills in terms of maybe we call 261 00:11:22,520 --> 00:11:24,560 IT system thinking also sometimes, right, how to 262 00:11:24,560 --> 00:11:26,800 actually identify this kind of root cause patterns. 263 00:11:27,160 --> 00:11:30,560 And I like the tips where you mentioned using LLM, right. 264 00:11:30,560 --> 00:11:34,000 So maybe try give it a try. You know, LLM is sometimes very 265 00:11:34,000 --> 00:11:37,160 good at summarizing things and seeing things that we don't see 266 00:11:37,160 --> 00:11:39,000 normally. So I think that's a good tips as 267 00:11:39,000 --> 00:11:41,160 well. So the next today we plan to 268 00:11:41,160 --> 00:11:44,440 talk about building a best in class engineering team or 269 00:11:44,440 --> 00:11:46,960 building engineering excellence within that team, right? 270 00:11:47,280 --> 00:11:49,960 So maybe could you start a little bit by defining first 271 00:11:50,160 --> 00:11:53,440 what is engineering excellence to you now that you are ACTO at 272 00:11:53,560 --> 00:11:56,520 a company and a previous job as well you have seen like big 273 00:11:56,520 --> 00:11:59,360 engineering teams operate. How do you define engineering 274 00:11:59,360 --> 00:12:01,520 excellence? It's a great question. 275 00:12:01,520 --> 00:12:03,680 The one thing I'll add is like, I feel like I have a unique 276 00:12:03,680 --> 00:12:06,040 perspective here because you have been a sophomore 277 00:12:06,040 --> 00:12:10,640 engineering being ACTO now, but then also the kind of goal of 278 00:12:10,640 --> 00:12:13,400 cortexes of companies to help our customers with their 279 00:12:13,400 --> 00:12:16,320 injuring excellence initiatives. I've seen like how the world's 280 00:12:16,320 --> 00:12:18,520 best like e-commerce companies and financial services 281 00:12:18,520 --> 00:12:20,920 companies, healthech companies have tried to do this as well. 282 00:12:20,920 --> 00:12:23,080 Until like as I, you know, answer your questions, I'm going 283 00:12:23,080 --> 00:12:25,280 to try and weave in like the things that I've learned from 284 00:12:25,440 --> 00:12:28,000 our own customers and are like the other CTOS that we work 285 00:12:28,000 --> 00:12:30,480 with. I think to us injuring 286 00:12:30,480 --> 00:12:33,920 excellence basically means like the alignment of injuring 287 00:12:33,920 --> 00:12:36,440 practices with business outcomes, right? 288 00:12:36,440 --> 00:12:38,680 So like of course, every engine organization needs to build 289 00:12:38,680 --> 00:12:39,960 features and products and all that stuff. 290 00:12:39,960 --> 00:12:44,320 Like that's table stakes, but it's the practices that we adopt 291 00:12:44,320 --> 00:12:47,280 as an engine organization that lead to the outcomes that we 292 00:12:47,280 --> 00:12:49,680 care about. And so again, kind of going back 293 00:12:49,680 --> 00:12:52,240 to the, the sales and marketing analogy, like sales excellence 294 00:12:52,240 --> 00:12:56,720 is like given an account, given an opportunity, how likely am I 295 00:12:56,720 --> 00:12:58,280 to close it at what dollar amount, right? 296 00:12:58,280 --> 00:13:00,440 Like that's like the, the obvious business outcome. 297 00:13:00,440 --> 00:13:01,920 There's practices I can do to do that, right? 298 00:13:01,920 --> 00:13:04,080 It's like, am I asking the right questions? 299 00:13:04,080 --> 00:13:06,000 Am I talking to the right personas? 300 00:13:06,000 --> 00:13:07,880 Am I, you know, using the right decks? 301 00:13:07,880 --> 00:13:09,760 Am I, you know, helping them see the value of the product 302 00:13:09,760 --> 00:13:11,360 properly, like all the right practices. 303 00:13:11,720 --> 00:13:13,880 It makes it more likely for a customer to see value and buy 304 00:13:13,880 --> 00:13:15,920 the product, right? And like sales organizations 305 00:13:15,920 --> 00:13:18,360 have been doing this for like, you know, a century, at least at 306 00:13:18,360 --> 00:13:21,120 this point of like, you know, it's a very well studied thing 307 00:13:21,120 --> 00:13:23,840 like bookkeeping and like tracking your like CRMS. 308 00:13:23,840 --> 00:13:26,040 The idea of CRMS existed way before Salesforce, right? 309 00:13:26,360 --> 00:13:29,440 Like this idea of like, if we can build a high functioning 310 00:13:29,440 --> 00:13:32,880 machine and we like really operationalize the way we do 311 00:13:32,880 --> 00:13:34,800 sales, we're going to drive more revenue. 312 00:13:35,200 --> 00:13:37,520 Engineering is like slowly coming to that same realization 313 00:13:37,520 --> 00:13:40,600 of like, hey, if we build the right systems and the right 314 00:13:40,600 --> 00:13:43,680 processes and the way we do engineering, we will get those 315 00:13:43,680 --> 00:13:45,760 business outcomes we care about. And so when I think about this 316 00:13:45,760 --> 00:13:47,640 business outcomes that engineering excellence ties 317 00:13:47,640 --> 00:13:50,040 into, it tends to buck into these three things. 318 00:13:50,040 --> 00:13:51,280 And this is what we think about as well. 319 00:13:51,760 --> 00:13:54,800 It's time to time to market and innovation. 320 00:13:54,800 --> 00:13:56,600 So are we, are you innovating as much as you can? 321 00:13:56,600 --> 00:13:58,680 Are you getting your product into the market as quickly as 322 00:13:58,680 --> 00:14:01,160 possible? The second one is around cost 323 00:14:01,160 --> 00:14:03,240 efficiency. So like are you managing your 324 00:14:03,240 --> 00:14:05,040 cost and you're being as efficient as you can? 325 00:14:05,040 --> 00:14:06,120 Like are you doing more with less? 326 00:14:06,120 --> 00:14:09,320 And the third one is around product quality and customer 327 00:14:09,320 --> 00:14:10,800 reliability. So like are we delivering a 328 00:14:10,800 --> 00:14:13,960 world class product is reliable, you know, is the customer happy 329 00:14:13,960 --> 00:14:15,960 with it? I use these three examples 330 00:14:15,960 --> 00:14:19,720 because depending on where you are in your company journey, 331 00:14:19,720 --> 00:14:21,840 what type of company you are, the outcome you care about might 332 00:14:21,840 --> 00:14:24,400 be totally different, right? Like as a start up at the very 333 00:14:24,400 --> 00:14:26,440 beginning of the cortex journey, all we care about was time to 334 00:14:26,440 --> 00:14:28,160 market. Like it was like, we don't care 335 00:14:28,160 --> 00:14:30,720 if there's quality, like it's going to break, but we want to 336 00:14:30,720 --> 00:14:32,560 see what works and we want to see what people care about. 337 00:14:32,560 --> 00:14:33,680 So like, let's move really quickly. 338 00:14:34,200 --> 00:14:36,400 And then from there it became like, OK, well now we have a ton 339 00:14:36,400 --> 00:14:38,320 of customers. They really care about 340 00:14:38,320 --> 00:14:39,560 reliability. We want to build a great 341 00:14:39,560 --> 00:14:41,840 customer experience. Time to market is still really 342 00:14:41,840 --> 00:14:43,320 important and we don't want to lose that. 343 00:14:43,640 --> 00:14:46,480 But it's an ebb to flow. Like OK, these next couple 344 00:14:46,480 --> 00:14:48,440 months we're going to really focus on reliability. 345 00:14:48,440 --> 00:14:49,520 That's the thing that really matters. 346 00:14:50,000 --> 00:14:52,280 But you talk like a larger organization, maybe they care 347 00:14:52,280 --> 00:14:54,640 about cost efficiency. Like, hey, we hired 1000 348 00:14:54,640 --> 00:14:57,120 engineers in the last like 3 years and like, you know, 349 00:14:57,120 --> 00:14:59,160 there's a lot of pressure from investors and blah, blah, blah. 350 00:14:59,160 --> 00:15:00,800 And we got to like, you know, focus on cost. 351 00:15:00,800 --> 00:15:02,160 We're going to really double down on that. 352 00:15:02,200 --> 00:15:05,000 You know, maybe a company's trying to go IPO and they need 353 00:15:05,000 --> 00:15:07,240 to get their cost in order. There's some outcome that your 354 00:15:07,240 --> 00:15:10,320 processes can relate to. And so injuring excellence is 355 00:15:10,320 --> 00:15:13,720 like the connection of injuring process to those outcomes. 356 00:15:14,240 --> 00:15:16,600 We bucket those. In my head, I think about 357 00:15:16,600 --> 00:15:18,160 injuring excellence. I break into kind of these 4 358 00:15:18,160 --> 00:15:20,880 buckets underneath that. So it's like it's reliability 359 00:15:20,880 --> 00:15:25,640 practices, security practices, efficiency practices and 360 00:15:25,640 --> 00:15:28,400 velocity practices. And so those four are the kind 361 00:15:28,400 --> 00:15:30,640 of like pillars of injury excellence, if you will. 362 00:15:31,080 --> 00:15:33,960 And so it's like it spans the entire SDLC, right? 363 00:15:33,960 --> 00:15:35,560 When you think about like developer experience, for 364 00:15:35,560 --> 00:15:38,920 example, it's like it's about the tools for a developer in 365 00:15:38,920 --> 00:15:40,200 their like day-to-day work, right? 366 00:15:40,200 --> 00:15:42,960 It's like very localized interior excellence is more 367 00:15:42,960 --> 00:15:44,680 broad. It's like architecture review 368 00:15:44,680 --> 00:15:46,920 process to incident management to security. 369 00:15:46,920 --> 00:15:49,400 Like all those things are like the excellence of your 370 00:15:49,400 --> 00:15:51,440 engineering organization, right? And like developer experience is 371 00:15:51,440 --> 00:15:54,200 part of it. It's like, hey, are we giving 372 00:15:54,200 --> 00:15:56,520 our developers tools and making it easy to be excellent? 373 00:15:56,520 --> 00:15:57,800 But it's like not the entire thing. 374 00:15:57,800 --> 00:16:00,080 And I think that's where I really focus on injuring 375 00:16:00,080 --> 00:16:02,560 excellence because in some, in some cases, like maybe the 376 00:16:02,560 --> 00:16:05,520 developer experience sucks, but like right now it's a trade off 377 00:16:05,520 --> 00:16:08,000 I'm willing to make because we need to improve our security or 378 00:16:08,000 --> 00:16:09,880 something like that. So thinking about like the 379 00:16:09,880 --> 00:16:12,960 business outcome first, the part of the injuring process that I 380 00:16:12,960 --> 00:16:15,760 want to change to drive that outcome and then thinking about 381 00:16:15,760 --> 00:16:17,640 how I'm going to do it. Like that's to me what injuring 382 00:16:17,640 --> 00:16:20,440 excellence is. It's like our practices in 383 00:16:20,440 --> 00:16:23,880 service of business outcomes. Well, thanks for outlining such 384 00:16:23,880 --> 00:16:27,040 a great, you know, the way you pitch it like from outcomes to 385 00:16:27,040 --> 00:16:29,000 pillars. So I think at the end of the 386 00:16:29,000 --> 00:16:30,600 day, it's all about business outcomes, right? 387 00:16:30,600 --> 00:16:32,720 Engineering is just one organization within the company. 388 00:16:32,720 --> 00:16:35,720 Obviously, engineering needs to also drive business outcomes, 389 00:16:35,720 --> 00:16:37,600 right? So in many various companies, I 390 00:16:37,600 --> 00:16:39,000 believe there are many challenges. 391 00:16:39,000 --> 00:16:41,280 I think what you mentioned, right, time to market, right, 392 00:16:41,360 --> 00:16:44,120 innovation, right, bringing some new features, maybe even new 393 00:16:44,120 --> 00:16:46,960 things into your system as fast as you can. 394 00:16:47,200 --> 00:16:50,120 And then the second one is about reliability and quality, right? 395 00:16:50,240 --> 00:16:53,080 Bugs, incidents and maybe security issues and things like 396 00:16:53,080 --> 00:16:54,880 that. And so the third thing is about 397 00:16:54,880 --> 00:16:57,520 cost efficiency, which I think in many companies these days, 398 00:16:57,840 --> 00:17:00,840 they're kind of like looking back at the cost, how much they 399 00:17:00,920 --> 00:17:03,240 spend and try to, you know, optimize a little bit. 400 00:17:03,400 --> 00:17:05,480 So I think every company might go through this journey 401 00:17:05,480 --> 00:17:07,079 differently as well. Like what you mentioned, maybe 402 00:17:07,079 --> 00:17:09,400 startups prioritize something different than their big 403 00:17:09,440 --> 00:17:12,599 organizations. So maybe if we can dive slightly 404 00:17:12,599 --> 00:17:14,920 deeper into all this, right? So obviously, there are many 405 00:17:14,920 --> 00:17:16,440 dimensions to all of this, right? 406 00:17:16,480 --> 00:17:18,920 One of the most important thing in any engineering excellence is 407 00:17:18,920 --> 00:17:21,240 about leadership. Maybe I'll start from there, 408 00:17:21,240 --> 00:17:23,960 because most likely you can't do anything if the leadership 409 00:17:23,960 --> 00:17:25,640 doesn't support all these things, right? 410 00:17:25,880 --> 00:17:28,359 So how important the role of the leaders? 411 00:17:28,359 --> 00:17:31,360 Do you think an organization such that the injuring team can 412 00:17:31,360 --> 00:17:35,040 achieve this excellence? I think it is extremely, 413 00:17:35,040 --> 00:17:39,400 extremely important and especially because if every team 414 00:17:40,000 --> 00:17:42,280 that is working on injuring excellence initiatives does not 415 00:17:42,280 --> 00:17:45,400 know how their work ties to a business outcome, it doesn't go 416 00:17:45,400 --> 00:17:47,000 anywhere. But I'll give you a concrete 417 00:17:47,000 --> 00:17:49,600 example of this. A lot of organizations in the 418 00:17:49,600 --> 00:17:53,480 last two years have spent a lot of time investing in platform 419 00:17:53,480 --> 00:17:57,640 engineering. And platform engineering should 420 00:17:57,640 --> 00:18:00,040 in theory enable quite a few outcomes, right? 421 00:18:00,040 --> 00:18:01,440 It should help you go to market faster. 422 00:18:01,440 --> 00:18:03,880 Like if you build up the right platform, your developers are 423 00:18:03,880 --> 00:18:06,320 more autonomous, but they're also following your best 424 00:18:06,320 --> 00:18:09,560 practices. Your platform is secure, it's 425 00:18:09,560 --> 00:18:10,920 modernized. So you're, you're being 426 00:18:10,920 --> 00:18:13,160 efficient, you're using your resources effectively. 427 00:18:13,520 --> 00:18:17,960 So a face value platform engineering should be a great 428 00:18:17,960 --> 00:18:19,120 way to drive injuring excellence. 429 00:18:19,600 --> 00:18:23,320 But platform engineering, especially large organizations 430 00:18:23,680 --> 00:18:25,920 sometimes can become like this kind of corner of the 431 00:18:25,920 --> 00:18:28,200 organization where it's not really tied to leadership or the 432 00:18:28,200 --> 00:18:31,120 leadership is not able to articulate to that team like how 433 00:18:31,120 --> 00:18:33,200 their work ties into the broader business outcome. 434 00:18:33,840 --> 00:18:37,200 And I think it's really important for an injury leader 435 00:18:37,200 --> 00:18:40,960 to say, hey, this quarter or this year or this half or 436 00:18:40,960 --> 00:18:44,880 whatever, the thing that we really care about is business 437 00:18:44,880 --> 00:18:45,840 outcome. Actually we want to move to 438 00:18:45,840 --> 00:18:47,720 market faster or we want to improve security or whatever 439 00:18:47,720 --> 00:18:51,520 that is. And interrogating kind of each 440 00:18:51,520 --> 00:18:55,040 set of initiatives as to like how exactly does this initiative 441 00:18:55,040 --> 00:18:58,000 tie back to that? And can I then tell that story 442 00:18:58,000 --> 00:19:00,280 to the rest of the organization? So like, hey, our platform 443 00:19:00,280 --> 00:19:02,280 engineering team is going to be headed down for three months. 444 00:19:02,280 --> 00:19:04,120 You're not going to see anything, but it's because we 445 00:19:04,120 --> 00:19:07,680 are building out a, you know, the very first slice of our 446 00:19:07,680 --> 00:19:11,040 organization, very first slice of that product that is going to 447 00:19:11,040 --> 00:19:13,480 improve security of the way we provision infrastructure. 448 00:19:13,720 --> 00:19:15,440 OK, I understand how it connects back to that. 449 00:19:15,440 --> 00:19:19,000 As an engineering leader also challenge your teams to steal 450 00:19:19,000 --> 00:19:20,560 thread. So rather than saying we're 451 00:19:20,560 --> 00:19:22,480 gonna build a whole platform or we're gonna deal with this whole 452 00:19:22,480 --> 00:19:25,120 thing and then like solve the business outcome, it's like, no, 453 00:19:25,120 --> 00:19:27,080 there's like choose a business outcome. 454 00:19:27,360 --> 00:19:29,320 What is the number one thing blocking that today? 455 00:19:29,560 --> 00:19:32,200 And what is the bare minimum slice across the entire stack 456 00:19:32,200 --> 00:19:35,360 that I can deliver to move that needle just a little bit for 457 00:19:35,520 --> 00:19:37,400 right. And so it's like when I think 458 00:19:37,400 --> 00:19:40,160 about reliability, if, you know, MTTR is top of mind and see, my 459 00:19:40,160 --> 00:19:42,160 CEO is saying like, hey, we have too many incidents. 460 00:19:42,160 --> 00:19:43,960 Like we're paying too much in SLA fees. 461 00:19:44,320 --> 00:19:45,800 We need to improve our incident costs, OK? 462 00:19:45,800 --> 00:19:48,520 We're, I'm not gonna like go and rebuild all of our services and 463 00:19:48,520 --> 00:19:50,080 like, you know, fix all of our tech that all at once. 464 00:19:50,080 --> 00:19:52,360 It's like, you know, what is the number one thing that's stopping 465 00:19:52,360 --> 00:19:54,200 us? OK, it's you know, we're 466 00:19:54,200 --> 00:19:57,120 spending too much time fighting fires. 467 00:19:57,120 --> 00:19:58,880 OK, why are we spending too much time finding fires? 468 00:19:59,040 --> 00:20:01,040 Well, there's like 10 reasons. Like the number one reason is 469 00:20:01,040 --> 00:20:03,400 like. We don't know which teams are in 470 00:20:03,400 --> 00:20:06,160 the critical path for these key outages. 471 00:20:06,160 --> 00:20:08,360 And so we spend 30 minutes per incident getting the right 472 00:20:08,360 --> 00:20:10,360 people in the room. After that, there's still a lot 473 00:20:10,360 --> 00:20:12,080 of other problems, but like we spend 30 minutes there. 474 00:20:12,080 --> 00:20:13,720 OK, like let's take that one level firmly. 475 00:20:13,720 --> 00:20:15,880 What is the next thing we can do to standardize that and so on. 476 00:20:16,120 --> 00:20:18,080 And so it's like now up and down the entire stack, you have a 477 00:20:18,080 --> 00:20:20,320 single thread. And so as an engineering leader, 478 00:20:20,320 --> 00:20:22,480 it's really important to maintain that focus and like 479 00:20:22,880 --> 00:20:24,600 challenge the teams. It's like, do we have to do all 480 00:20:24,600 --> 00:20:26,280 this? Like what is the bare minimum 481 00:20:26,280 --> 00:20:27,600 thing? Like if a product leader is 482 00:20:27,600 --> 00:20:30,520 doing that for the product, engineering excellence is like 483 00:20:30,520 --> 00:20:33,280 the engineering teams pruned in some sense. 484 00:20:33,280 --> 00:20:35,120 It's like the thing, the practices and the tools and the 485 00:20:35,120 --> 00:20:37,360 stuff we're building for those engineering and business 486 00:20:37,360 --> 00:20:38,880 outcomes. And so like we should have that 487 00:20:39,120 --> 00:20:43,200 same product management mindset of like, what is the minimum 488 00:20:43,200 --> 00:20:46,680 viable or minimum lovable, like process or, you know, tool that 489 00:20:46,680 --> 00:20:48,360 we can build for this particular issue. 490 00:20:48,360 --> 00:20:52,680 And so I think being able to carve out small slices of value 491 00:20:52,680 --> 00:20:56,000 that drive to business outcomes by telling that story more 492 00:20:56,000 --> 00:20:58,040 broadly across our organization, making sure everyone's bought 493 00:20:58,040 --> 00:21:00,760 into the business outcome and holding teams accountable to not 494 00:21:00,760 --> 00:21:03,280 building, not just doing science experiments all the time, but 495 00:21:03,280 --> 00:21:06,640 like driving towards something very clear means that the next 496 00:21:06,640 --> 00:21:08,880 time you want to do one of those things your CE OS bought into, 497 00:21:08,880 --> 00:21:11,960 it's like, hey, this investment in like this random engineering 498 00:21:11,960 --> 00:21:14,760 process resulted in us moving the business outcome. 499 00:21:15,040 --> 00:21:16,920 So the next time as an engineering organization, we 500 00:21:16,920 --> 00:21:18,760 want to go and say, hey, we need to fix this tech debt. 501 00:21:19,160 --> 00:21:21,480 You've earned those stripes. You've said, hey, the last time 502 00:21:21,480 --> 00:21:23,400 we made this argument, we moved the business needle. 503 00:21:23,960 --> 00:21:25,640 We're not lying to you. Like we have another thing we 504 00:21:25,640 --> 00:21:26,880 want to do. Like you've bought that, you 505 00:21:26,880 --> 00:21:29,160 created the feedback loop. And so as an engineering leader, 506 00:21:29,160 --> 00:21:32,240 it's your duty to like bring those business outcomes from the 507 00:21:32,240 --> 00:21:35,600 business to engineering and then use the same business outcome to 508 00:21:35,600 --> 00:21:38,120 tell the story back to the business of like, hey, here's 509 00:21:38,120 --> 00:21:39,520 how our investments impacted the business. 510 00:21:39,520 --> 00:21:41,520 And so as an engineering leader, you're gonna be thinking about 511 00:21:41,640 --> 00:21:44,600 both sides of that equation. Well, I think that's a really 512 00:21:44,600 --> 00:21:46,440 great tips, right. Again, it all comes back to the 513 00:21:46,440 --> 00:21:49,520 business outcomes. First try to tie to maybe like 514 00:21:49,520 --> 00:21:52,880 one single business outcome and identify the initiative that you 515 00:21:52,880 --> 00:21:54,520 want to do. And I think I like that you 516 00:21:54,520 --> 00:21:57,480 mentioned create a slice, right? You know, maybe people call it 517 00:21:57,480 --> 00:21:59,200 thin slice in product management, right? 518 00:21:59,200 --> 00:22:01,560 So the same thing you can do in your technology stack. 519 00:22:01,960 --> 00:22:05,120 And platform engineering is also like the most common examples I 520 00:22:05,120 --> 00:22:07,720 think these days for engineering team to try to improve things. 521 00:22:07,720 --> 00:22:10,760 But obviously introducing technology itself might not be 522 00:22:10,760 --> 00:22:13,400 sufficient, right? Because I think many people try 523 00:22:13,400 --> 00:22:16,760 to use technology as the solution for improving their 524 00:22:16,760 --> 00:22:19,000 engineering excellence and cannot convey that to the 525 00:22:19,000 --> 00:22:20,800 stakeholders. I think this is one of the 526 00:22:20,800 --> 00:22:23,480 challenges simply because maybe there are gaps in technical 527 00:22:23,480 --> 00:22:26,000 understanding versus the business stakeholders who are 528 00:22:26,000 --> 00:22:28,120 non-technical. And the other thing is about 529 00:22:28,120 --> 00:22:30,520 building the story around what kind of outcomes that you want 530 00:22:30,520 --> 00:22:33,280 to build, right? So for people who probably still 531 00:22:33,280 --> 00:22:35,760 rely on kind of like implementing tools, be it, I 532 00:22:35,760 --> 00:22:38,960 don't know like cloud, AI, platform engineering, whatever 533 00:22:38,960 --> 00:22:41,000 that is, right? Maybe also sometimes re 534 00:22:41,000 --> 00:22:43,280 architecturing certain things to improve the engineering 535 00:22:43,280 --> 00:22:45,120 excellence. What will be your advice for 536 00:22:45,120 --> 00:22:48,120 those kind of people right before they approach these kind 537 00:22:48,120 --> 00:22:49,920 of thing with such new technologies and new 538 00:22:49,920 --> 00:22:52,000 architecture? Is there anything that they can 539 00:22:52,000 --> 00:22:53,880 do before they embark on that journey? 540 00:22:54,760 --> 00:22:56,080 Yeah. I think it's understanding what 541 00:22:56,080 --> 00:22:59,760 the North Star is like. We should understand either what 542 00:22:59,760 --> 00:23:02,240 metric we're trying to move within our organization and 543 00:23:02,240 --> 00:23:06,480 which business metric we're trying to move, or even if it's 544 00:23:06,480 --> 00:23:09,000 not an immediately move, a metric like the hypothesis as to 545 00:23:09,000 --> 00:23:11,880 like the series of things that will eventually move some 546 00:23:11,880 --> 00:23:14,200 specific needle. And it doesn't have to be a 547 00:23:14,200 --> 00:23:17,720 business outcome necessarily. Like if you are are on kind of a 548 00:23:17,720 --> 00:23:20,960 hands on team, you know, insecurity or something like 549 00:23:20,960 --> 00:23:23,720 that, buying a new tool, you can still tie it back to one of 550 00:23:23,720 --> 00:23:26,160 those pillars, right? It's like, you know, hey, I'm 551 00:23:26,160 --> 00:23:27,920 improving our security, improving our reliability, I'm 552 00:23:27,920 --> 00:23:29,440 doing these things. And like your agent leader 553 00:23:29,440 --> 00:23:32,360 should then be able to tell that story to the business, but like, 554 00:23:32,640 --> 00:23:34,520 as long as you can tie it back to one of these pillars. 555 00:23:34,520 --> 00:23:37,840 And so the way I think about it, for example, is going back to 556 00:23:37,840 --> 00:23:39,560 the platform engineering example, let's say you're a 557 00:23:39,560 --> 00:23:43,200 platform engineer and you want to spend two months building out 558 00:23:43,320 --> 00:23:45,400 a self starter kit for new services. 559 00:23:46,040 --> 00:23:48,280 On it's face, it's not a particularly interesting project 560 00:23:48,280 --> 00:23:50,280 to the business, right? It's like, hey, I'm trying to 561 00:23:50,280 --> 00:23:54,240 invest in Terraform. I'm investing in, you know, like 562 00:23:54,240 --> 00:23:57,200 I am policy tools and like I'm doing, I'm buying a bunch of 563 00:23:57,200 --> 00:23:59,600 stuff and like setting all these things and I'm spending all this 564 00:23:59,600 --> 00:24:01,480 time and energy, but why does it matter? 565 00:24:01,480 --> 00:24:05,080 It's like, OK, well actually the reason all that stuff matters is 566 00:24:05,680 --> 00:24:06,600 this. And this is where like the 567 00:24:06,960 --> 00:24:08,800 measuring the current state of the world is really important. 568 00:24:09,040 --> 00:24:12,840 Today, it takes us 1 1/2 weeks to spin up a new service and go 569 00:24:12,840 --> 00:24:16,480 through all the approvals. It takes us four days for 570 00:24:16,680 --> 00:24:18,480 security review. Once it's ready to go to 571 00:24:18,480 --> 00:24:21,560 production, it takes us four days for SRU review, and then 572 00:24:21,560 --> 00:24:23,680 finally it goes to production. So on like either sides of the 573 00:24:23,680 --> 00:24:26,560 equation, we're spending, you know, minimum of two weeks 574 00:24:27,160 --> 00:24:29,000 outside of like the actual writing of code. 575 00:24:29,280 --> 00:24:32,640 And so therefore, if I can reduce those two weeks down to 576 00:24:32,800 --> 00:24:34,760 days or hours, then like the ROI is there. 577 00:24:34,760 --> 00:24:37,360 So by investing in a self starter kit, you know, through 578 00:24:37,360 --> 00:24:39,760 the platform measuring team and buying all the right tools for 579 00:24:39,760 --> 00:24:43,840 it over the 50 services that we create per quarter, you know, 580 00:24:43,840 --> 00:24:47,560 across the organization times a reduction of two weeks, we've 581 00:24:47,560 --> 00:24:50,720 saved X dollars of money and we've improved our security 582 00:24:50,720 --> 00:24:54,840 posture because now every team is by default registered with 583 00:24:54,840 --> 00:24:57,440 our vulnerability management tool, the moment to create a new 584 00:24:57,440 --> 00:24:59,120 service. And so the likelihood of a 585 00:24:59,600 --> 00:25:01,720 breach is much lower by, you know, some amount. 586 00:25:01,720 --> 00:25:04,320 So like, now I've made a case for these tools from a 587 00:25:04,680 --> 00:25:07,680 efficiency perspective and a security perspective. 588 00:25:07,680 --> 00:25:10,240 And so it's not just like, oh, I'm like creating a cool, like 589 00:25:10,240 --> 00:25:13,160 experience for my developers. It's like, does the CEO really 590 00:25:13,160 --> 00:25:14,800 care about that? Like, maybe, you know, it's 591 00:25:14,800 --> 00:25:17,000 like, yeah, I want my developers to be happy and like, and 592 00:25:17,000 --> 00:25:19,040 there's a retention aspect and all those things about like 593 00:25:19,320 --> 00:25:21,520 sentiment. But like, fundamentally, if you 594 00:25:21,520 --> 00:25:23,720 tell me like, hey, not only are my developers going to be happy, 595 00:25:24,280 --> 00:25:26,080 I'm saving us X weeks per service. 596 00:25:26,080 --> 00:25:28,520 I'm increasing our security posture and like our incident 597 00:25:28,520 --> 00:25:31,120 rates should go down. That's a much easier way to make 598 00:25:31,120 --> 00:25:33,080 that case. And the other thing like you 599 00:25:33,080 --> 00:25:34,800 mentioned, like coding assistance is the same thing. 600 00:25:34,800 --> 00:25:37,120 It's like, OK, well, can we measure the impact of that? 601 00:25:37,280 --> 00:25:39,040 That's an interesting one. Actually, though, coding 602 00:25:39,040 --> 00:25:41,800 assistance, just kind of a side tangent here is like I had a 603 00:25:41,880 --> 00:25:44,400 customer recently tell me it's like, hey, why are you making 604 00:25:44,400 --> 00:25:48,440 such a big fuss about, you know, measuring the impact of 50 bucks 605 00:25:48,440 --> 00:25:51,600 a month or whatever? You wouldn't ask like, does my 606 00:25:51,600 --> 00:25:55,560 developer really need like 16 gigs of RAM, like versus 8? 607 00:25:55,560 --> 00:25:57,120 Or like do they really need Intellij? 608 00:25:57,240 --> 00:26:00,600 Like can't they just use them? It's obvious that it's one of 609 00:26:00,600 --> 00:26:01,640 the tools in their tool kit, right? 610 00:26:01,640 --> 00:26:04,160 It's like you wouldn't question a developer who's like trying to 611 00:26:04,160 --> 00:26:05,720 get an Intellij or something like that. 612 00:26:05,960 --> 00:26:09,440 So why are we making a big fuss about spending 50 bucks for a 613 00:26:09,440 --> 00:26:10,440 tool? And it's just part of your 614 00:26:10,480 --> 00:26:13,760 general tool kit. It's like laptop IDE, terminal 615 00:26:13,960 --> 00:26:15,920 coding assistant, like it's part of our general tool kit, right? 616 00:26:15,920 --> 00:26:17,480 So it's like, it's an interesting idea. 617 00:26:17,480 --> 00:26:19,200 So the same thing should hold true for your injuring 618 00:26:19,200 --> 00:26:22,360 excellence platform. That's another topic as well as 619 00:26:22,360 --> 00:26:25,400 like, you know, why are more engineering leaders not thinking 620 00:26:25,400 --> 00:26:28,160 about injuring excellence? But yeah, I kind of a side 621 00:26:28,160 --> 00:26:30,120 tangent there, but hope I answered the question. 622 00:26:30,280 --> 00:26:31,600 Yeah. I think that's a great example 623 00:26:31,600 --> 00:26:32,760 that you outlined just now, right? 624 00:26:33,000 --> 00:26:35,400 So I think one thing that I picked from your explanations 625 00:26:35,400 --> 00:26:36,880 also in your career journey, right? 626 00:26:36,880 --> 00:26:40,040 So engineering also needs to be able to measure things, right? 627 00:26:40,200 --> 00:26:43,840 Be it in the maybe software telemetry or even like their, I 628 00:26:43,840 --> 00:26:46,960 don't know, velocity metrics that you mentioned or those kind 629 00:26:47,080 --> 00:26:50,520 of measurements that I think must be in place, right, for us 630 00:26:50,520 --> 00:26:53,600 to build engineering excellence. How important for leaders to 631 00:26:53,600 --> 00:26:56,520 actually build an initiative to actually gather these kind of 632 00:26:56,520 --> 00:26:58,440 measurements? Because sometimes, sometimes 633 00:26:58,440 --> 00:27:01,480 it's easy to you can come out from a systems, right? 634 00:27:01,720 --> 00:27:04,360 But sometimes, especially when you touch multiple running 635 00:27:04,360 --> 00:27:06,560 elements, right? So it's very hard to actually 636 00:27:06,560 --> 00:27:09,400 quantify the metrics. So how important do you think 637 00:27:09,520 --> 00:27:13,160 for engineering organization to actually put an effort, invest 638 00:27:13,160 --> 00:27:16,320 time and actually come up with metrics and maybe do like a good 639 00:27:16,320 --> 00:27:19,160 cadence around, you know, looking back at the metrics, how 640 00:27:19,160 --> 00:27:20,440 to improve them and things like that? 641 00:27:20,760 --> 00:27:22,280 So maybe any tips on this? Yeah. 642 00:27:23,120 --> 00:27:25,080 Yeah, absolutely. That's a very, very important 643 00:27:25,080 --> 00:27:28,880 question. So I think it is a must and I'll 644 00:27:28,880 --> 00:27:31,320 explain why. Going back to the sales analogy 645 00:27:31,320 --> 00:27:34,000 again, like imagine if a sales leader said like I don't need 646 00:27:34,000 --> 00:27:37,400 Salesforce, I don't need a CRM, we're just gonna sell and hope 647 00:27:37,400 --> 00:27:39,040 for the best. Like you would fire that sales 648 00:27:39,040 --> 00:27:40,960 leader tomorrow. Like any sales leader that 649 00:27:40,960 --> 00:27:43,160 doesn't have a CRM that's not using that data to make 650 00:27:43,600 --> 00:27:46,320 judgments about the organization and where to invest is going to 651 00:27:46,320 --> 00:27:47,440 be laughed out of the room, right? 652 00:27:47,440 --> 00:27:51,120 Any data leader that doesn't have data tooling is going to be 653 00:27:51,120 --> 00:27:53,720 laughed out of the room. So why is it that engineering 654 00:27:53,720 --> 00:27:55,040 leaders are not treated the same way? 655 00:27:55,040 --> 00:27:57,840 Like why is engineering leaders do we not say, of course I need 656 00:27:57,840 --> 00:28:01,200 a system of record like every single other function has a 657 00:28:01,200 --> 00:28:03,600 system of record, right? Like sales teams of CRMS, 658 00:28:03,960 --> 00:28:07,800 marketing teams are marketing automation, finance has ERPIT 659 00:28:07,800 --> 00:28:10,240 has CMDBS like ITSM tools at service. 660 00:28:10,240 --> 00:28:13,760 Now every single function has a system of record, But what does 661 00:28:13,760 --> 00:28:16,240 engineering have? We're just like caution to the 662 00:28:16,240 --> 00:28:18,240 wind, like do whatever you want. Like every team just out there 663 00:28:18,240 --> 00:28:21,120 like it's like the wild, Wild West and it's really insane if 664 00:28:21,120 --> 00:28:23,720 you think about it like, you know, like every other function 665 00:28:23,720 --> 00:28:25,880 is treated so differently and engineering is the most 666 00:28:25,880 --> 00:28:28,760 expensive organization. We should be much more 667 00:28:29,080 --> 00:28:32,880 systematic and data-driven and methodical about the way we 668 00:28:32,880 --> 00:28:35,760 build our engine organizations. And what I would challenge 669 00:28:35,760 --> 00:28:37,760 though, is like, it's not just about the metrics. 670 00:28:37,760 --> 00:28:40,800 Like imagine if all Salesforce said was like fancy reports, 671 00:28:40,800 --> 00:28:42,400 right? Like just like a funnel 672 00:28:42,400 --> 00:28:44,680 dashboard or something like you wouldn't need that either. 673 00:28:44,680 --> 00:28:49,280 What you need is like an end to end platform that helps you 674 00:28:49,280 --> 00:28:51,200 understand like your software ecosystem. 675 00:28:51,200 --> 00:28:54,480 So it's like accountability and given a service, which team is 676 00:28:54,480 --> 00:28:56,120 accountable for it? Where's it deployed? 677 00:28:56,120 --> 00:28:57,880 Where's it running? You know, how many 678 00:28:57,880 --> 00:29:00,120 vulnerabilities does it have? What is the code coverage? 679 00:29:00,120 --> 00:29:01,360 Like what is the on call rotation? 680 00:29:01,360 --> 00:29:03,120 Like where can I collect this data? 681 00:29:03,560 --> 00:29:06,200 How do I use that data to drive best practices? 682 00:29:06,400 --> 00:29:09,440 So like in, for example, in Salesforce, again, I can use the 683 00:29:09,440 --> 00:29:13,800 CRM to drive practices in sales. It's like, hey, before you start 684 00:29:14,040 --> 00:29:17,560 Apoc with a customer, you need to fill out all these fields. 685 00:29:17,560 --> 00:29:20,000 You need to make sure you understand if they have budget, 686 00:29:20,000 --> 00:29:21,640 you need to make sure they understand who's gonna buy it. 687 00:29:21,640 --> 00:29:23,840 And like the AE has to go and fill this information. 688 00:29:24,080 --> 00:29:26,480 The idea is that you're using that data to then drive some 689 00:29:26,480 --> 00:29:29,960 sort of behavior like in the daily workflow of an AE, right? 690 00:29:29,960 --> 00:29:32,680 And so you're using it to drive practices or you're trying to 691 00:29:32,680 --> 00:29:34,440 use marketing automation tools for practices. 692 00:29:34,840 --> 00:29:36,920 And so it's not just about the dashboards. 693 00:29:36,920 --> 00:29:40,240 And so like the metric side of the equation for engineering 694 00:29:40,240 --> 00:29:43,640 teams should like a, having a way to store all this data in a 695 00:29:43,640 --> 00:29:45,320 meaningful way because it can just be metrics. 696 00:29:45,320 --> 00:29:47,720 It needs to be like, what is the actual like data structure on 697 00:29:47,720 --> 00:29:50,840 which I'm reporting on? So like to us, the way we think 698 00:29:50,840 --> 00:29:53,000 about it is like the service catalog, the infrastructure 699 00:29:53,000 --> 00:29:55,440 catalog, a catalog of all this information, right? 700 00:29:55,440 --> 00:29:59,000 Like just like ACRM, the second part is the ability to like 701 00:29:59,000 --> 00:30:01,760 drive behavior around it. So like defining this is what 702 00:30:01,760 --> 00:30:03,800 good looks like. This is where I need teams to 703 00:30:03,800 --> 00:30:05,840 be. Can we create a shared language 704 00:30:05,840 --> 00:30:08,840 as to what good looks like? Because I can say your repo is 705 00:30:08,840 --> 00:30:12,120 30 vulnerabilities, OK? Like is that good? 706 00:30:12,120 --> 00:30:14,440 Is it bad? Like it doesn't matter if it's 707 00:30:14,440 --> 00:30:16,480 high or like low vulnerabilities. 708 00:30:16,480 --> 00:30:17,480 Like what does that actually mean? 709 00:30:17,480 --> 00:30:19,480 Like it doesn't mean anything for me to tell you have 30 710 00:30:19,480 --> 00:30:21,280 vulnerabilities, right? There needs to be some 711 00:30:21,760 --> 00:30:23,800 distinction for our organization. 712 00:30:23,800 --> 00:30:26,760 Like for me, for us as a company, what is good look like 713 00:30:26,760 --> 00:30:29,360 OK, for a financial services company, 0 critical 714 00:30:29,360 --> 00:30:32,600 vulnerabilities is great. Zero critical vulnerabilities 715 00:30:32,600 --> 00:30:35,840 with, you know, resolving them within seven days is excellent, 716 00:30:36,240 --> 00:30:37,920 right? And like 0 critical 717 00:30:37,920 --> 00:30:41,320 vulnerabilities, resolving them within seven days and you're 718 00:30:41,320 --> 00:30:44,920 resolving medium vulnerabilities within 60 days is like top of 719 00:30:44,920 --> 00:30:46,000 the blind. Like that's where we want to 720 00:30:46,000 --> 00:30:47,880 aspire to. So again, now not only do we 721 00:30:47,880 --> 00:30:51,080 have a metric, we have like a graduated window of like how to 722 00:30:51,080 --> 00:30:52,800 get better. So like the platform should be 723 00:30:52,800 --> 00:30:55,040 able to tell you that. And the final bit is reporting. 724 00:30:55,040 --> 00:30:57,560 It's an engineering metrics. It's, and it's like, OK, like 725 00:30:57,560 --> 00:31:00,560 based on the data that we have, based on the practices of what 726 00:31:00,560 --> 00:31:03,360 we're following, are we seeing the impact on the data? 727 00:31:03,360 --> 00:31:06,080 So like cycle time and, you know, dura metrics and things 728 00:31:06,080 --> 00:31:08,320 like that, those things can't live in isolation, right? 729 00:31:08,320 --> 00:31:11,240 It's like you can go and tell a developer improve your MTTR. 730 00:31:11,240 --> 00:31:13,440 It's like, OK, like I don't know where to start, right? 731 00:31:13,440 --> 00:31:16,360 So it's like, instead it's like, hey, we're using MTTR as a 732 00:31:16,360 --> 00:31:18,680 measurement. And so we're gonna see, we 733 00:31:18,680 --> 00:31:21,440 believe that in order to improve MTTR, we need to change these 734 00:31:21,440 --> 00:31:23,520 five practices. So we're gonna run change the 735 00:31:23,520 --> 00:31:25,360 five practices. We're gonna come back and see 736 00:31:25,360 --> 00:31:27,880 the MTTR change. So it's the engineering metrics 737 00:31:27,880 --> 00:31:31,160 are not about measuring productivity or like, you know, 738 00:31:31,160 --> 00:31:33,840 like checking if you're like taking advantage of your teams. 739 00:31:33,840 --> 00:31:37,560 It's about hypothesis, hypothesis generation and 740 00:31:37,560 --> 00:31:40,560 hypothesis testing, right? It's like based on the metrics, 741 00:31:40,560 --> 00:31:43,560 I have a hypothesis that like we can, it's all about like 742 00:31:43,560 --> 00:31:45,400 continuous improvement, right? It's one of the pillars of 743 00:31:45,400 --> 00:31:47,240 injuring excellence. We consider it's like continuous 744 00:31:47,240 --> 00:31:49,160 improvement. It's not like good versus bad. 745 00:31:49,160 --> 00:31:51,440 It's, I'm better than I was yesterday, but that's a very 746 00:31:51,440 --> 00:31:52,760 important part of injuring excellence. 747 00:31:53,280 --> 00:31:56,640 And so like injuring metrics should be used to say, today our 748 00:31:56,640 --> 00:32:00,040 cycle times X, we want to move faster. 749 00:32:00,560 --> 00:32:02,600 The time to 1st review is really long. 750 00:32:03,440 --> 00:32:06,560 Our hypothesis is that the CI build time is taking up, you 751 00:32:06,560 --> 00:32:09,240 know, good chunk of that effort by reducing our CI build time, 752 00:32:09,240 --> 00:32:11,760 our cycle time will go down, which means that our throughput 753 00:32:11,760 --> 00:32:13,480 will go up. That's the hypothesis. 754 00:32:13,480 --> 00:32:16,240 And then you go and you say, OK, well, how do we, you know, 755 00:32:16,240 --> 00:32:19,080 change our build time? Well, then you run an initiative 756 00:32:19,080 --> 00:32:21,040 and this is where of course it's gonna help is like, OK, we're 757 00:32:21,040 --> 00:32:24,520 going to migrate our teams from, you know, legacy Jenkins servers 758 00:32:24,520 --> 00:32:26,280 to get up actions. So we have better caching. 759 00:32:26,680 --> 00:32:28,760 But like in a big organization right now without a toilet 760 00:32:28,760 --> 00:32:31,400 cortex, not to sales plug, but like it takes a lot of time to 761 00:32:31,400 --> 00:32:34,000 track a migration like that. And so having the right tooling 762 00:32:34,000 --> 00:32:35,960 in place to like track a migration like that and like 763 00:32:36,160 --> 00:32:37,680 make sure everyone's doing that migration. 764 00:32:38,000 --> 00:32:40,000 OK, you do that migration and then you go back to your metric 765 00:32:40,000 --> 00:32:41,680 and say they didn't move the needle. 766 00:32:42,120 --> 00:32:44,920 So the energy metrics are a way to like create those hypotheses 767 00:32:44,920 --> 00:32:46,880 and test them. But if you're not doing that, 768 00:32:47,280 --> 00:32:49,720 how do you know if your efforts are actually moving the needle, 769 00:32:49,720 --> 00:32:50,840 if you're actually making an impact? 770 00:32:51,160 --> 00:32:53,040 So injuring metrics are very, very important. 771 00:32:53,360 --> 00:32:55,560 The data under the hood is very, very important and the ability 772 00:32:55,560 --> 00:32:57,640 to set standards and Dr. behavior is also really 773 00:32:57,640 --> 00:32:59,120 important. It's like all those things 774 00:32:59,120 --> 00:33:03,040 together is what creates the flywheel of a data-driven, high 775 00:33:03,040 --> 00:33:07,680 visibility, high trust injury culture that is focused on 776 00:33:07,680 --> 00:33:09,200 excellence. Like that's how I think about 777 00:33:09,440 --> 00:33:11,200 how metrics fit into the broader ecosystem. 778 00:33:12,040 --> 00:33:13,600 Right. I like the angle where you 779 00:33:13,600 --> 00:33:15,160 mentioned about continuous improvement, right. 780 00:33:15,160 --> 00:33:17,960 So obviously excellence is kind of like the North Star division 781 00:33:17,960 --> 00:33:20,440 that we want to be. Obviously, I don't think any 782 00:33:20,680 --> 00:33:23,160 kind of team can say, hey, I'm excellent, you know, like you 783 00:33:23,160 --> 00:33:24,560 can't be excellent forever anyway. 784 00:33:24,920 --> 00:33:27,040 So the continuous improvement aspect, I think it's very 785 00:33:27,040 --> 00:33:29,960 important and kind of like the motion of how to improve 786 00:33:29,960 --> 00:33:32,440 yourself from, you know, wherever you are today and then 787 00:33:32,440 --> 00:33:34,160 tomorrow and so on and so forth, right? 788 00:33:34,160 --> 00:33:35,440 So I think that's really crucial. 789 00:33:35,840 --> 00:33:38,280 So the other thing that you mentioned is about driving the 790 00:33:38,280 --> 00:33:41,120 behaviour. I believe this is touching into 791 00:33:41,120 --> 00:33:43,760 the aspect of culture, right? I think in an engineering 792 00:33:43,760 --> 00:33:45,600 organization, culture is really important. 793 00:33:45,920 --> 00:33:48,960 What kind of culture drive a good engineering excellence, 794 00:33:48,960 --> 00:33:50,600 kind of initiatives and those kind of things. 795 00:33:50,760 --> 00:33:53,600 So maybe if you can elaborate, I know culture is a bit big topic, 796 00:33:53,600 --> 00:33:56,440 open-ended, but maybe from your experience, right, what kind of 797 00:33:56,440 --> 00:33:59,000 culture do you think drive this kind of engineering excellence? 798 00:33:59,880 --> 00:34:01,840 Yeah. So I'll start with kind of a 799 00:34:01,840 --> 00:34:05,080 Segway from the last question. So injury metrics, the right 800 00:34:05,080 --> 00:34:09,560 culture is one that is transparent and has high 801 00:34:09,560 --> 00:34:11,760 visibility. And what I mean by that is like 802 00:34:12,320 --> 00:34:14,760 injuring metrics are not this like ivory tower thing that the, 803 00:34:14,760 --> 00:34:17,159 you know, your VPS and CTOS are looking at and they're like 804 00:34:17,480 --> 00:34:19,679 coming down and like smiting the teams based on those metrics. 805 00:34:19,679 --> 00:34:22,880 It's like if every team has visibility into your SL OS and 806 00:34:22,880 --> 00:34:26,199 your latency and stuff in APM, why can't your teams look at 807 00:34:26,199 --> 00:34:28,400 their own metrics and injuring metrics too, right. 808 00:34:28,400 --> 00:34:30,360 So it's like visibility up and down the stack. 809 00:34:30,360 --> 00:34:33,159 So everybody gets access to the metrics, everybody understands 810 00:34:33,480 --> 00:34:35,840 this is not a measurement tool. This is a way for us to like 811 00:34:35,840 --> 00:34:37,960 find improvements. So that is really important. 812 00:34:37,960 --> 00:34:40,239 So a culture around metrics, a culture around visibility, 813 00:34:40,520 --> 00:34:41,800 everyone looking at the same data. 814 00:34:42,120 --> 00:34:44,880 So that's one part of it. The second part of it is a 815 00:34:44,880 --> 00:34:47,920 shared language. So does everyone actually know 816 00:34:47,920 --> 00:34:50,120 what good means? If you ask three people on the 817 00:34:50,120 --> 00:34:53,120 team what does production readiness look like, and you get 818 00:34:53,120 --> 00:34:55,480 3 different answers. Immediate fail. 819 00:34:55,480 --> 00:34:58,280 So like having a shared language as to what good looks like, 820 00:34:58,280 --> 00:35:01,000 having a shared language like This is why, you know, companies 821 00:35:01,000 --> 00:35:04,080 do OK Rs and like, you know, North Star goals and North Star 822 00:35:04,080 --> 00:35:06,400 metrics and all these things. It's like if everyone at least 823 00:35:06,400 --> 00:35:07,480 is thinking of the same thing, right? 824 00:35:07,480 --> 00:35:09,800 So if you're like a, a social media company, you probably have 825 00:35:09,800 --> 00:35:11,520 a North Star metric. It's like, hey, we want to 826 00:35:11,520 --> 00:35:13,280 improve retention. Like that's our number one thing 827 00:35:13,280 --> 00:35:15,120 where like this year, that's the only thing that matters. 828 00:35:15,120 --> 00:35:17,960 OK, well, everybody knows that. Everyone can say like retention 829 00:35:17,960 --> 00:35:20,120 is the only thing that matters. I can ask myself, I'm actually 830 00:35:20,120 --> 00:35:22,480 doing something about that. So the same thing holds true for 831 00:35:22,480 --> 00:35:25,120 injuring process. So does everyone know what good 832 00:35:25,120 --> 00:35:27,240 looks like and what that shared definition is? 833 00:35:28,240 --> 00:35:30,160 How much can you dumb down that definition? 834 00:35:30,160 --> 00:35:33,800 So like your definition of good can be shared, but if it's like 835 00:35:34,000 --> 00:35:37,680 60 criteria for like production readiness, it doesn't matter, 836 00:35:37,760 --> 00:35:38,880 right? It's like no one's gonna 837 00:35:38,880 --> 00:35:40,320 remember all that stuff. But like it's like that 838 00:35:40,320 --> 00:35:42,840 confluence page over there. And so like the ability to 839 00:35:42,840 --> 00:35:45,120 create like a clear path to greatness I think is really 840 00:35:45,120 --> 00:35:46,160 important. It's like, hey, these are the 841 00:35:46,160 --> 00:35:49,160 basics. This is like, you know, the non 842 00:35:49,160 --> 00:35:51,880 negotiables for production. This is what like the gold 843 00:35:51,880 --> 00:35:54,400 standard looks like to be able to kind of like buck it up. 844 00:35:54,840 --> 00:35:56,880 What good looks like in these categories I think is really 845 00:35:56,880 --> 00:35:59,560 important because then you're as a team lead, you can say like, 846 00:35:59,560 --> 00:36:02,920 hey, we've all agreed that like these 15 things are like the 847 00:36:02,920 --> 00:36:04,240 bare minimum to go to production. 848 00:36:04,720 --> 00:36:07,760 We're not doing those things. And so like I can use that now 849 00:36:07,760 --> 00:36:10,520 as a way to advocate for time. So like I can go to my manager 850 00:36:10,520 --> 00:36:13,480 or my VP and be like, hey, we all agree that these 15 things 851 00:36:13,480 --> 00:36:15,640 are really important. We're not getting time to meet 852 00:36:15,640 --> 00:36:16,880 those things. Like we need time. 853 00:36:16,880 --> 00:36:18,960 And so now you've created like that share language. 854 00:36:18,960 --> 00:36:22,280 The VPS cannot say like, I mean, yes, they can say no, but the 855 00:36:22,280 --> 00:36:24,280 idea is that yes, we have agreed to those things. 856 00:36:24,760 --> 00:36:26,000 I can make that trade off very clearly. 857 00:36:26,080 --> 00:36:27,560 And so that communication is very important. 858 00:36:28,160 --> 00:36:31,040 The third thing is repeated messaging. 859 00:36:31,040 --> 00:36:35,560 And so how much of the same data can you use in multiple places? 860 00:36:35,560 --> 00:36:39,160 So, and I, if we're doing a migration, like I mentioned 861 00:36:39,160 --> 00:36:42,080 earlier, talk about it in your all hands, talk about it in your 862 00:36:42,080 --> 00:36:44,920 monthly operation license reviews, talk about it in your 863 00:36:45,040 --> 00:36:46,600 team meetings and team retros, right? 864 00:36:47,080 --> 00:36:50,120 Is there enough data in your, in whatever you're using from 865 00:36:50,120 --> 00:36:52,920 tooling standpoint for each team to be able to self report on 866 00:36:52,920 --> 00:36:55,200 these things, right? It's like This is why teams 867 00:36:55,200 --> 00:36:57,960 spend so much time around like, OK, our tracking is like each 868 00:36:57,960 --> 00:37:00,040 team can like very quickly iterate. 869 00:37:00,040 --> 00:37:02,920 And so it's like the CEO saying something, the CTO saying 870 00:37:02,920 --> 00:37:05,400 something and like it trickles down and like, I can check my 871 00:37:05,400 --> 00:37:08,120 own work against that. So for engineering practices, 872 00:37:08,120 --> 00:37:10,440 the same thing. It's like does your team, your 873 00:37:10,440 --> 00:37:14,160 manager, your directory VP, they all have a slice of the data 874 00:37:14,160 --> 00:37:17,320 where they can their level come in and see like, hey, how are we 875 00:37:17,320 --> 00:37:18,520 tracking against those practices? 876 00:37:18,520 --> 00:37:19,720 How are we tracking against those things? 877 00:37:20,320 --> 00:37:22,120 And so the ability to kind of create that, like instant 878 00:37:22,120 --> 00:37:24,200 visibility and repeated communication is really 879 00:37:24,200 --> 00:37:25,920 important. This is like a common, like, 880 00:37:25,920 --> 00:37:28,360 adage in business, right? It's like you have to keep 881 00:37:28,360 --> 00:37:30,560 repeating things until you feel like you've repeated yourself so 882 00:37:30,560 --> 00:37:32,360 many times that people are sick of you. 883 00:37:32,960 --> 00:37:34,760 And at that point, people have finally realized what you're 884 00:37:34,760 --> 00:37:36,240 talking about. And so it's the same thing for 885 00:37:36,240 --> 00:37:38,080 engineering practices. Like, keep repeating yourself. 886 00:37:38,080 --> 00:37:40,800 It's like, hey, congratulate people, celebrate the wins. 887 00:37:40,840 --> 00:37:45,400 Like, hey, Ganesha's team has finished 80% of migrating 80% of 888 00:37:45,400 --> 00:37:46,920 their services to the new platform. 889 00:37:47,400 --> 00:37:48,400 You know, congratulations, right? 890 00:37:48,400 --> 00:37:50,400 Like do you have data to be able to celebrate those wins? 891 00:37:50,720 --> 00:37:53,000 And like, if you say that in an all hands meeting, people are 892 00:37:53,000 --> 00:37:55,120 like, oh, like clearly this is important enough that like 893 00:37:55,160 --> 00:37:57,600 getting a slide at the all hands, like are we actually 894 00:37:57,600 --> 00:37:59,440 tracking towards it and whatnot? So like, can you create that 895 00:37:59,440 --> 00:38:01,600 culture? It's about creating momentum. 896 00:38:01,600 --> 00:38:04,480 It's about creating visibility. It's about shared language. 897 00:38:04,880 --> 00:38:07,360 It sounds like cult behavior, but like really like every 898 00:38:07,360 --> 00:38:10,120 organization, like culture in some ways is like, how can you 899 00:38:10,120 --> 00:38:12,720 create a cult like behaviors with an organization like 900 00:38:12,720 --> 00:38:15,480 healthy and like try the right outcomes, of course, but like so 901 00:38:15,480 --> 00:38:17,240 that's kind of the framing I like to think about kind of 902 00:38:17,240 --> 00:38:20,160 tongue in cheek. Yeah, so I in my experience also 903 00:38:20,160 --> 00:38:22,920 the bigger you are, you know, the bigger you grow, right, the 904 00:38:22,920 --> 00:38:25,320 more important all these things, right, Especially the repeating 905 00:38:25,320 --> 00:38:27,720 of the message, right? Because when you have like 906 00:38:27,720 --> 00:38:29,840 hundreds of engineers, for example, right, it's very 907 00:38:29,840 --> 00:38:31,360 difficult to kind of like align everybody. 908 00:38:31,520 --> 00:38:33,600 So a few things that I picked from what you're sharing, right? 909 00:38:33,600 --> 00:38:36,760 So high transparency, maybe have the metrics in place that you 910 00:38:36,760 --> 00:38:38,760 can see all the time. Shared language. 911 00:38:38,800 --> 00:38:42,320 I can also agree to, you know, use this kind of shared language 912 00:38:42,480 --> 00:38:45,200 because when you have multiple engineering teams, everyone 913 00:38:45,200 --> 00:38:47,000 thinks excellence differently, right? 914 00:38:47,200 --> 00:38:49,560 So if you don't have a shared language, what good looks like? 915 00:38:49,560 --> 00:38:51,280 I think it's very difficult to align everybody. 916 00:38:51,760 --> 00:38:54,800 And then, yeah, repeated message, building a clear path. 917 00:38:54,800 --> 00:38:57,440 I think it's also important because you can say here's the 918 00:38:57,440 --> 00:39:00,640 initiative and let people do it. But if there's no good clear 919 00:39:00,640 --> 00:39:02,840 path and you kind of like streamline the process, I think 920 00:39:02,840 --> 00:39:04,600 it's very hard for people to achieve that as well. 921 00:39:05,320 --> 00:39:07,840 So the other aspect that I wanted to dive deeper is about, 922 00:39:07,880 --> 00:39:10,400 you know, platform engineering because you are building, you 923 00:39:10,400 --> 00:39:13,000 know, one for yourself, right? So the Cortex dot IO. 924 00:39:13,440 --> 00:39:16,080 So I think people these days talk about platform engineering, 925 00:39:16,120 --> 00:39:18,200 you know, internal developer platform and things like that. 926 00:39:18,680 --> 00:39:21,880 So maybe the first question is at what point in, you know, 927 00:39:21,880 --> 00:39:26,040 engineering stage do you think everyone should try thinking 928 00:39:26,040 --> 00:39:28,120 seriously about having this platform, engineering and 929 00:39:28,120 --> 00:39:31,360 internal developer platform? The interesting thing, I kind of 930 00:39:31,360 --> 00:39:33,520 break up the two aspects of this internal developer platform, 931 00:39:33,520 --> 00:39:35,480 internal development portal. There's a whole debate about 932 00:39:35,480 --> 00:39:38,000 like what each thing means, like when you need them, like it's 933 00:39:38,000 --> 00:39:41,280 the whole thing. But basically, I would argue 934 00:39:41,280 --> 00:39:43,120 that do you need to start with data? 935 00:39:43,120 --> 00:39:45,160 So every organization should have some sort of data. 936 00:39:45,160 --> 00:39:47,760 So like, do you have a system where you can track your 937 00:39:47,760 --> 00:39:49,600 software assets, infrastructure assets? 938 00:39:49,920 --> 00:39:52,400 You have a single place where you can determine accountability 939 00:39:52,400 --> 00:39:54,320 and ownership. You can probably get away 940 00:39:54,320 --> 00:39:58,280 without any of this stuff, you know, up until about like 30 to 941 00:39:58,280 --> 00:40:00,440 40 engineers. I want to say like roughly 942 00:40:00,440 --> 00:40:03,840 speaking at that point, like you have enough kind of clusters in 943 00:40:03,840 --> 00:40:07,000 your team graph that having a system where you can say like. 944 00:40:07,520 --> 00:40:09,880 The Asia team is working on X, you know, Henry seems working on 945 00:40:09,880 --> 00:40:11,560 Y. Like this is their, you know, 946 00:40:11,560 --> 00:40:13,760 sphere of accountability. They, they own these different 947 00:40:13,760 --> 00:40:15,480 repos. Having that in one place is 948 00:40:15,480 --> 00:40:16,720 really important. You should do that like very, 949 00:40:16,720 --> 00:40:19,720 very early on. And so usually that comes in the 950 00:40:19,720 --> 00:40:23,080 form of an internal developer portal, which is like a service 951 00:40:23,080 --> 00:40:25,640 catalog or something like that. Around that same time, you 952 00:40:25,640 --> 00:40:28,400 probably want to use, you know, ideally your portal already 953 00:40:28,400 --> 00:40:30,520 provides this. We're also starting to measure 954 00:40:30,680 --> 00:40:33,040 some of the key metrics, so like cycle time, review time and so 955 00:40:33,040 --> 00:40:36,560 on around 30 to 40 engineers. Anything before that, like it's 956 00:40:36,560 --> 00:40:39,600 a little bit of noise, honestly, like you can get some value out 957 00:40:39,600 --> 00:40:41,280 of it, but it's not honestly worth it. 958 00:40:42,000 --> 00:40:44,280 Ideally your portal gives you this data, but if not like 959 00:40:44,280 --> 00:40:47,800 you're getting it in in a manual way, you're tracking some key 960 00:40:47,800 --> 00:40:52,320 metrics and like the things at a 30% team, it's probably a 30% 961 00:40:52,320 --> 00:40:55,360 like injuring organization, I'm saying is like probably more on 962 00:40:55,360 --> 00:40:57,640 moving fast. So like cycle time, throughput 963 00:40:57,640 --> 00:41:00,040 incidents, keeping the lights on, those kind of metrics are 964 00:41:00,040 --> 00:41:02,560 probably pretty important. From there, once you get to 965 00:41:02,560 --> 00:41:08,240 around like 60 to 75 engineers is where platform esque 966 00:41:08,480 --> 00:41:10,120 investments start to come into play. 967 00:41:10,600 --> 00:41:14,640 Now it doesn't have to be a platform engineering team, but 968 00:41:14,640 --> 00:41:21,280 some sort of like collective group of like infra cloud staff 969 00:41:21,280 --> 00:41:25,080 engineers, like senior engineers and maybe like one or two 970 00:41:25,080 --> 00:41:28,640 platform people like kind of coalesce and started to work on 971 00:41:28,800 --> 00:41:32,120 org wide initiatives. Because at about like 50 to 60 972 00:41:32,120 --> 00:41:35,280 people, you're getting to a point where like practices are 973 00:41:35,280 --> 00:41:36,920 starting to diverge. Like people are trying to do 974 00:41:36,920 --> 00:41:39,640 things in weird ways. And so starting at that stage I 975 00:41:39,640 --> 00:41:42,080 think is really important. However, I will say at that 976 00:41:42,080 --> 00:41:45,160 point in like you want to be very, very tactical about the 977 00:41:45,160 --> 00:41:46,400 types of investments you're making. 978 00:41:46,400 --> 00:41:49,360 So even from a platform machine perspective, like what is the 979 00:41:49,360 --> 00:41:52,200 thing that is slowing you down at a 60 percent, 70% engineering 980 00:41:52,200 --> 00:41:55,120 team? So like it's usually around like 981 00:41:55,120 --> 00:41:59,000 deployments, build systems and tooling, infrastructure 982 00:41:59,000 --> 00:42:01,680 provisioning, like, you know, are we having repeatability 983 00:42:01,680 --> 00:42:03,920 around those things? Like it's not like the quote of 984 00:42:03,920 --> 00:42:06,000 a sexy platform engineering stuff that people are doing, but 985 00:42:06,000 --> 00:42:08,200 it's like tactical things that really matter. 986 00:42:08,200 --> 00:42:10,960 It's like if you hit a point where you're like 60 or 70 987 00:42:10,960 --> 00:42:14,000 engineers, you probably have really slow builds or like 988 00:42:14,200 --> 00:42:16,560 something like that. You probably have like preview 989 00:42:16,560 --> 00:42:18,560 bottlenecks. You may have started the company 990 00:42:18,600 --> 00:42:21,880 and I'm seeing from experience like click OPS in Google Cloud 991 00:42:21,880 --> 00:42:24,680 or ABS, whatever. And so like around 60 engineers, 992 00:42:24,680 --> 00:42:27,160 you want to start automating and terraforming or infrastructures, 993 00:42:27,160 --> 00:42:29,600 coding, some of that stuff like thinking about the next phase 994 00:42:29,600 --> 00:42:31,800 like, yeah, what's going to break when I get to 100 995 00:42:31,800 --> 00:42:33,200 engineers, like start to get out of that. 996 00:42:33,200 --> 00:42:36,200 So around 60 to 70 engineers, you want to start investing in 997 00:42:36,720 --> 00:42:40,320 platform practices, but very tactically against specific 998 00:42:40,320 --> 00:42:42,800 initiatives. I think once you get to around 999 00:42:42,800 --> 00:42:48,000 like 120 ish engineers, like you have enough independent work 1000 00:42:48,000 --> 00:42:51,160 streams across the organization that like true platform 1001 00:42:51,160 --> 00:42:53,080 engineering stuff starts to have a real impact. 1002 00:42:53,080 --> 00:42:57,960 So like a standard set of like deploy pipelines and deploy 1003 00:42:58,160 --> 00:43:00,360 capabilities where you're standardizing on Helm, where 1004 00:43:00,360 --> 00:43:03,800 you're standardizing on Terraform or Bloomy or Spacelift 1005 00:43:03,800 --> 00:43:06,200 or cross lane or Craddicks or whatever kind of platform tool 1006 00:43:06,200 --> 00:43:08,040 you want. Like those kind of decisions 1007 00:43:08,040 --> 00:43:10,040 start to become really important because they like compounding 1008 00:43:10,040 --> 00:43:11,960 effects. And so I would say like 1009 00:43:12,200 --> 00:43:15,880 somewhere between like the 60 to 120 range issues, like when 1010 00:43:16,000 --> 00:43:18,600 platform engineering starts to become a thing, anything bigger 1011 00:43:18,600 --> 00:43:20,600 than that, like you absolutely need platform engineering. 1012 00:43:21,000 --> 00:43:24,400 My hot take though, is that like at whatever point you start 1013 00:43:24,480 --> 00:43:27,840 bringing in like SRE and security and stuff, you probably 1014 00:43:27,840 --> 00:43:29,600 also want to start thinking about platform engineering. 1015 00:43:30,080 --> 00:43:33,320 And I would argue we're starting to see this practice a little 1016 00:43:33,320 --> 00:43:37,120 bit more. But why not have those teams 1017 00:43:37,120 --> 00:43:41,080 roll into an intern excellence leaders rather than like all of 1018 00:43:41,080 --> 00:43:42,800 them, like kind of reporting to different places. 1019 00:43:43,280 --> 00:43:45,080 You want your platform engineering teams to be working 1020 00:43:45,080 --> 00:43:46,720 with your security teams and your SRE teams, right? 1021 00:43:46,720 --> 00:43:49,280 As if they all their work depends on each other. 1022 00:43:49,280 --> 00:43:53,000 Like your SRE team cannot build reliable software if your 1023 00:43:53,000 --> 00:43:54,840 platform doesn't take that into account, right? 1024 00:43:54,840 --> 00:43:57,360 Or like security cannot do their job if you're like 1025 00:43:57,360 --> 00:44:00,280 infrastructure as code tooling is not thinking about security 1026 00:44:00,280 --> 00:44:01,880 from day one. So like, why is platform 1027 00:44:01,880 --> 00:44:03,480 engineering over here and security over here? 1028 00:44:03,480 --> 00:44:04,960 Like bring those things closer together. 1029 00:44:05,360 --> 00:44:08,000 It's an easy way to do that is to like bring them together into 1030 00:44:08,000 --> 00:44:11,280 an injuring excellence team. So like instead of having a head 1031 00:44:11,280 --> 00:44:14,400 of developer experience or a head of SRE or whatever, like 1032 00:44:14,800 --> 00:44:16,760 have a head of injuring excellence and like have these 1033 00:44:16,760 --> 00:44:19,480 orgs roll up into that. So you have like, especially up 1034 00:44:19,480 --> 00:44:22,000 until like you're like a really large enterprise, at which point 1035 00:44:22,040 --> 00:44:23,520 each of those things ends up becoming their own. 1036 00:44:23,520 --> 00:44:27,600 Like VPS, have them roll into a single leader. 1037 00:44:27,600 --> 00:44:30,240 So that way like all their work is really, really aligned to 1038 00:44:30,240 --> 00:44:32,200 each other. It makes hiring easier as well. 1039 00:44:32,240 --> 00:44:34,680 So that's kind of like my heart takes from like an organization 1040 00:44:34,680 --> 00:44:37,120 design perspective. Yeah, I think thanks for sharing 1041 00:44:37,120 --> 00:44:40,280 such a, you know, good analogy of like how big is the injuring 1042 00:44:40,280 --> 00:44:42,320 team before you start thinking about certain things? 1043 00:44:42,440 --> 00:44:45,440 And especially when you have hundreds or even more thousands 1044 00:44:45,440 --> 00:44:48,760 of engineers, having such kind of a platform capability I think 1045 00:44:48,760 --> 00:44:50,800 is really important because otherwise people will be doing 1046 00:44:50,800 --> 00:44:52,280 the same thing with different ways. 1047 00:44:52,280 --> 00:44:55,600 And you cannot rationalize when things going wrong, right, or 1048 00:44:55,600 --> 00:44:57,920 especially when you want to improve something, you kind of 1049 00:44:57,920 --> 00:44:59,760 like double the effort and things like that. 1050 00:44:59,960 --> 00:45:02,360 So definitely when you grow in size, you need this. 1051 00:45:02,800 --> 00:45:05,880 So maybe from your experience building this internal developer 1052 00:45:05,880 --> 00:45:09,680 platform, what do you see some biggest misconception people 1053 00:45:09,680 --> 00:45:13,160 have when they think they want to adopt platform, maybe some 1054 00:45:13,160 --> 00:45:16,200 kind of platform engineering or IDP, right, versus actually what 1055 00:45:16,200 --> 00:45:19,200 actually IDP is? Yeah. 1056 00:45:19,200 --> 00:45:22,760 So kind of going back to the data question, one of the 1057 00:45:22,760 --> 00:45:26,920 biggest misconceptions with portals in particular is do I 1058 00:45:26,920 --> 00:45:29,560 have to get all my data in order first before I put it into the 1059 00:45:29,560 --> 00:45:31,280 portal, Like to get any value out of the portal? 1060 00:45:31,560 --> 00:45:33,800 Like if I want engineering metrics, if I want scorecards 1061 00:45:33,800 --> 00:45:36,600 and like best practices and all these things, do I have to clean 1062 00:45:36,600 --> 00:45:39,520 all my data up first before I buy a portal or am I wasting 1063 00:45:39,520 --> 00:45:42,400 time with a portal? That's the biggest 1064 00:45:42,400 --> 00:45:43,800 misconception. And the reason I say that is 1065 00:45:43,800 --> 00:45:46,680 because if you don't have a system that can hold data and 1066 00:45:46,680 --> 00:45:49,120 like tell you what's wrong with the data, how are you ever going 1067 00:45:49,120 --> 00:45:50,240 to fix it in the first place, right? 1068 00:45:50,240 --> 00:45:54,200 It's like right now everything is an unknown unknown and you 1069 00:45:54,200 --> 00:45:56,240 can't, you can be like, I'm going to clean up my data, but 1070 00:45:56,240 --> 00:45:57,880 like, what are you really doing? And what does that actually 1071 00:45:57,880 --> 00:46:00,080 mean? And so like using a portal is a 1072 00:46:00,080 --> 00:46:03,640 way to go from the unknown unknowns to the known unknowns. 1073 00:46:03,640 --> 00:46:05,960 So it's like, OK, well, before we didn't know anything. 1074 00:46:06,440 --> 00:46:09,360 Now we know, we don't know. And then now we can start to 1075 00:46:09,360 --> 00:46:11,360 clean up the data and be like, OK, well, now we know about 1076 00:46:11,360 --> 00:46:12,720 these things. We don't know about these things 1077 00:46:12,720 --> 00:46:14,920 is you can actually clean up your data using a port. 1078 00:46:14,920 --> 00:46:16,760 Like that is a whole point of having a system record, right? 1079 00:46:16,760 --> 00:46:18,720 Like a sales leader when they come in. 1080 00:46:18,720 --> 00:46:20,280 And I love this analogy. I'm gonna keep using it. 1081 00:46:20,280 --> 00:46:22,240 But like when a sales leader comes into a new sales 1082 00:46:22,240 --> 00:46:24,840 organization, they're not going to say like, first we're going 1083 00:46:24,840 --> 00:46:27,640 to take, you know, all of our calendar invites and like, put 1084 00:46:27,640 --> 00:46:29,480 it into a spreadsheet and then clean it up and then go by 1085 00:46:29,480 --> 00:46:30,720 Salesforce. It's like, no, we're going to 1086 00:46:30,720 --> 00:46:32,640 come by Salesforce, dump everything in there. 1087 00:46:32,640 --> 00:46:34,880 And then we're going to figure out how to like make sense of 1088 00:46:34,880 --> 00:46:36,480 this data because I need a system that's going to help me 1089 00:46:36,480 --> 00:46:38,400 see the world. That's the first misconception. 1090 00:46:38,920 --> 00:46:42,120 The second misconception is if you build it, they will come. 1091 00:46:42,280 --> 00:46:44,720 So like think people think about portal and platform initiatives 1092 00:46:44,720 --> 00:46:47,080 as like, hey, we're going to build this like really cool 1093 00:46:47,080 --> 00:46:49,440 stuff from like these great self-serve experiences and like 1094 00:46:49,440 --> 00:46:51,800 it's going to be so good that people will just come and use 1095 00:46:51,800 --> 00:46:53,480 it. Completely false. 1096 00:46:54,120 --> 00:46:57,000 This is like basic product management, you know, product 1097 00:46:57,000 --> 00:46:59,040 thinking, right? It's like it's very hard for 1098 00:46:59,040 --> 00:47:01,800 some for people to change their behaviors or the people are used 1099 00:47:01,800 --> 00:47:03,360 to doing things a certain way, especially. 1100 00:47:03,360 --> 00:47:06,040 And I speak for personal experience as developers, we 1101 00:47:06,040 --> 00:47:08,520 have our VMR CS, like, you know, we spend so much time like 1102 00:47:09,120 --> 00:47:11,080 creating our setups and like our practices, right? 1103 00:47:11,080 --> 00:47:12,640 Like we, that's kind of who we are as an engineer. 1104 00:47:12,640 --> 00:47:15,080 It's like we'd like to tailor our workflows and our tooling. 1105 00:47:15,720 --> 00:47:17,560 And so if you're like, oh, there's this other tool, you're 1106 00:47:17,560 --> 00:47:19,760 using a platform. I've been doing these things in 1107 00:47:19,760 --> 00:47:20,800 other ways. Seems fine to me. 1108 00:47:20,800 --> 00:47:23,160 Like you go build your platform, I'll do my thing, right? 1109 00:47:23,160 --> 00:47:24,720 It's like, that's a very common issue we see. 1110 00:47:25,280 --> 00:47:27,360 And so instead, it's really important to think about 1111 00:47:27,360 --> 00:47:30,400 starting with the definition of what good looks like, right? 1112 00:47:30,400 --> 00:47:32,200 So it's like, hey, we're going to start with, and this is how 1113 00:47:32,200 --> 00:47:34,720 we built our product, starting with scorecards next. 1114 00:47:34,720 --> 00:47:37,040 So it's like, OK, before we go off and build all these 1115 00:47:37,040 --> 00:47:39,920 self-serve tools and platform engineering things, we're gonna 1116 00:47:39,920 --> 00:47:42,520 build a scorecard that says like, hey, in order to go to 1117 00:47:42,520 --> 00:47:45,160 production, these are all the things you should be doing, 1118 00:47:45,360 --> 00:47:46,400 right? Like these are all the practices 1119 00:47:46,480 --> 00:47:48,680 you should be following. One of our customers calls it 1120 00:47:48,680 --> 00:47:50,640 like the Golden State. What is the Golden State of a 1121 00:47:50,640 --> 00:47:53,720 service? And so if you define that, then 1122 00:47:53,720 --> 00:47:55,080 your golden path makes a lot more sense. 1123 00:47:55,080 --> 00:47:56,960 It's like, hey, this is what every service needs to do. 1124 00:47:57,200 --> 00:47:59,160 It's very easy to get people to buy into that, especially 1125 00:47:59,160 --> 00:48:02,160 because most organizations have a production process already, 1126 00:48:02,200 --> 00:48:04,320 right? Like 99% organizations of 1127 00:48:04,320 --> 00:48:06,560 something, it's like a confluence page or some process. 1128 00:48:06,560 --> 00:48:08,880 It's like, hey, this is what production ready looks like. 1129 00:48:09,320 --> 00:48:10,640 And so you tell that, you tell your team. 1130 00:48:10,640 --> 00:48:13,240 It's like, hey, we're not trying to introduce a new process. 1131 00:48:13,720 --> 00:48:15,600 It's nothing new. We're taking that old thing that 1132 00:48:15,600 --> 00:48:18,560 we used to do, we're automating it and we're just gonna give you 1133 00:48:18,600 --> 00:48:20,360 tell you exactly where you stand from a pressure ready 1134 00:48:20,360 --> 00:48:21,720 standpoint. So we're just, we're doing a 1135 00:48:21,720 --> 00:48:22,840 thing that we already used to do. 1136 00:48:22,840 --> 00:48:25,160 We're just doing it better. Like, OK, that seems fine. 1137 00:48:25,160 --> 00:48:28,000 Like I can buy into that. And so now everyone agrees like, 1138 00:48:28,000 --> 00:48:29,560 OK, well, this is what pressure readiness looks like. 1139 00:48:30,280 --> 00:48:33,000 Then you tell people, OK, well, you can do it your old way to 1140 00:48:33,000 --> 00:48:34,960 get to production ready. Sure. 1141 00:48:35,080 --> 00:48:38,360 We built the self starter kit on our platform that like click a 1142 00:48:38,360 --> 00:48:40,200 button, you got a new service in 5 minutes. 1143 00:48:40,720 --> 00:48:43,320 It's going to meet all of your requirements within 5 minutes. 1144 00:48:43,560 --> 00:48:46,200 So do you want to use the self-serve kit or do you want to 1145 00:48:46,200 --> 00:48:49,360 go to your old thing? One in 20 people will do their 1146 00:48:49,360 --> 00:48:50,880 old thing, but like they still have to meet all those 1147 00:48:50,880 --> 00:48:52,160 requirements. So at least you're still getting 1148 00:48:52,160 --> 00:48:54,200 the same outcome. But next time that 20 people 1149 00:48:54,200 --> 00:48:55,880 will use a new tool because it's like, well, if you're telling me 1150 00:48:55,880 --> 00:48:57,600 I need to do all these things, that's what good looks like, 1151 00:48:57,600 --> 00:49:00,120 which I agree with, then I'm just going to use a new tool. 1152 00:49:00,120 --> 00:49:03,280 So now you've told people the Golden Path and the Golden 1153 00:49:03,280 --> 00:49:05,160 State, you brought them together. 1154 00:49:05,440 --> 00:49:07,640 That's an A, our platform is serving a very key purpose. 1155 00:49:07,880 --> 00:49:10,280 So hold a key bottleneck and you've got that buying from the 1156 00:49:10,280 --> 00:49:12,000 people. So that's another misconception 1157 00:49:12,000 --> 00:49:13,160 of like if you build it, there will come. 1158 00:49:13,440 --> 00:49:16,240 It's absolutely not true. That's where we see a lot of IDP 1159 00:49:16,240 --> 00:49:18,800 initiatives fail. And last but not least, it's 1160 00:49:18,800 --> 00:49:21,760 very important to tie to a thing that they're already doing. 1161 00:49:21,760 --> 00:49:23,520 I kind of mentioned this in this answer. 1162 00:49:23,880 --> 00:49:26,200 You don't want to come and introduce a completely new 1163 00:49:26,200 --> 00:49:27,720 workflow or a completely new process. 1164 00:49:28,160 --> 00:49:31,160 Find the thing that the team is doing already and make that 1165 00:49:31,160 --> 00:49:33,920 better and that will get bind to your platform. 1166 00:49:34,000 --> 00:49:36,600 So a platform doesn't have to be brand new platform doesn't have 1167 00:49:36,600 --> 00:49:40,760 to be one thing. A platform can be collection of 1168 00:49:40,760 --> 00:49:42,080 best of breed capabilities, right? 1169 00:49:42,080 --> 00:49:44,280 Like that's the other things like we're going to deliver a 1170 00:49:44,280 --> 00:49:47,280 whole platform like no, no, no, like your platform can be 1171 00:49:47,680 --> 00:49:50,000 infrastructure as code, it can be CICD, it can be all these 1172 00:49:50,000 --> 00:49:51,760 things. And you can like iteratively 1173 00:49:51,760 --> 00:49:54,200 like you can bounce around like you don't have to go and deliver 1174 00:49:54,200 --> 00:49:56,840 a whole platform on once and see if you think about incremental 1175 00:49:56,840 --> 00:49:59,360 value like we talked about earlier, business outcomes, 1176 00:49:59,960 --> 00:50:02,600 Olving the thing that already exists and making that better, 1177 00:50:02,880 --> 00:50:05,000 you will naturally say like, OK, we're just going to deliver like 1178 00:50:05,000 --> 00:50:07,800 the smallest slice of a latform that we can continue iterating 1179 00:50:07,800 --> 00:50:09,040 on it. So have that product management 1180 00:50:09,040 --> 00:50:10,200 mindset. Those are kind of like the 1181 00:50:10,200 --> 00:50:13,240 biggest things that we see wrong with a lot of reaching ractices 1182 00:50:13,240 --> 00:50:15,800 today. Thanks for sharing such a great 1183 00:50:15,800 --> 00:50:17,960 misconceptions. I think some people might, you 1184 00:50:17,960 --> 00:50:20,320 know, especially those who have embarked this journey, right? 1185 00:50:20,320 --> 00:50:22,760 I'm, I'm sure many people can relate to this, especially the 1186 00:50:22,760 --> 00:50:26,040 platform as a product thing. I think still many people maybe 1187 00:50:26,040 --> 00:50:28,760 build a platform and think people just use it or maybe 1188 00:50:28,800 --> 00:50:32,160 worse, they kind of like force it to teams without actually, 1189 00:50:32,160 --> 00:50:34,400 you know, explaining the reason why and you know, how it 1190 00:50:34,400 --> 00:50:35,840 benefits them and things like that. 1191 00:50:36,400 --> 00:50:39,920 So obviously Cortex is one way of doing this. 1192 00:50:40,080 --> 00:50:43,000 So maybe a little bit of plug about Cortex, how do you think 1193 00:50:43,000 --> 00:50:45,600 people can use Cortex to help all these things? 1194 00:50:45,600 --> 00:50:47,600 Maybe some features? I know that you have this 1195 00:50:47,600 --> 00:50:49,720 concept of called engineering intelligence. 1196 00:50:49,960 --> 00:50:52,360 So if you tell us a little bit more, how can you use Cortex to 1197 00:50:52,360 --> 00:50:53,880 actually solve all these kind of things? 1198 00:50:54,560 --> 00:50:57,040 Yeah, absolutely. So Cortex is an internal 1199 00:50:57,040 --> 00:50:59,280 developer portal, but we like to think about it as an engineering 1200 00:50:59,280 --> 00:51:02,080 excellence platform. At the end of the day, it starts 1201 00:51:02,080 --> 00:51:04,480 with the catalog. So we help you catalog all of 1202 00:51:04,480 --> 00:51:07,680 your services, your infrastructure, your teams, and 1203 00:51:07,680 --> 00:51:10,080 then automatically determine ownership for them. 1204 00:51:10,080 --> 00:51:13,480 So within minutes we have an ML model that can go through all of 1205 00:51:13,480 --> 00:51:16,640 your repos and automatically assigned teams that we believe 1206 00:51:16,640 --> 00:51:19,120 owns each repo. So within, you know, 10 minutes 1207 00:51:19,120 --> 00:51:21,640 of setting up Cortex, you have a list of all your repos and which 1208 00:51:21,640 --> 00:51:23,320 teams are accountable. For each of those. 1209 00:51:23,320 --> 00:51:25,800 We have a product called Scorecard which allows you to 1210 00:51:25,800 --> 00:51:27,560 define best practices and standards. 1211 00:51:27,880 --> 00:51:30,840 So like for example, automating production readiness, tracking 1212 00:51:30,840 --> 00:51:35,160 migrations and audits, package upgrades, security standards and 1213 00:51:35,160 --> 00:51:36,600 what not. So being able to define as best 1214 00:51:36,600 --> 00:51:39,120 practices and standards. And then from there we have a 1215 00:51:39,240 --> 00:51:41,960 tool called work flows. And so workflows is basically 1216 00:51:41,960 --> 00:51:44,840 kind of like a wizard builder where you can build experiences 1217 00:51:44,840 --> 00:51:46,160 for developers. So like spinning up a new 1218 00:51:46,160 --> 00:51:49,120 service deploys, you know, infrastructure provisioning, 1219 00:51:49,120 --> 00:51:51,080 just in time, credentials access and so on. 1220 00:51:51,440 --> 00:51:53,920 So we have a really, really easy and powerful way to build those 1221 00:51:53,920 --> 00:51:56,400 self server experiences, including code scaffolding and 1222 00:51:56,400 --> 00:51:58,760 project bootstrapping. And then finally we have an 1223 00:51:58,760 --> 00:52:00,840 engineering intelligence product which is around engineering 1224 00:52:00,840 --> 00:52:02,920 metrics. So like to our metrics, cycle 1225 00:52:02,920 --> 00:52:04,680 time metrics, MTTR, things like that. 1226 00:52:04,920 --> 00:52:07,680 And the idea is that you should get all of these things in a 1227 00:52:07,680 --> 00:52:09,440 single platform. So you shouldn't have to go to 1228 00:52:09,440 --> 00:52:12,240 reporting in one place and self-service in one place. 1229 00:52:12,240 --> 00:52:14,720 And like cataloging in one place, we bring all those things 1230 00:52:14,720 --> 00:52:16,920 to the same platform because at the end of the day, those things 1231 00:52:16,920 --> 00:52:20,000 are a flywheel. So measure the metrics, figure 1232 00:52:20,000 --> 00:52:23,480 out your practices, try them using scorecards, you know, use 1233 00:52:23,480 --> 00:52:26,200 the catalog data that like underpins all this stuff and 1234 00:52:26,200 --> 00:52:28,240 build self-service experiences that make those things better. 1235 00:52:28,520 --> 00:52:30,320 So at the end of the day, that's what Cortex is. 1236 00:52:30,760 --> 00:52:32,240 We built a lot of native integration. 1237 00:52:32,240 --> 00:52:33,560 There's a lot of automation into it. 1238 00:52:33,840 --> 00:52:36,800 So, you know, it usually takes very, very little time to get 1239 00:52:36,800 --> 00:52:39,200 started with it to get those metrics and catalog up to date. 1240 00:52:39,960 --> 00:52:42,160 Sounds like a really great tools, especially if you are 1241 00:52:42,240 --> 00:52:43,800 like big engineering organizations. 1242 00:52:44,000 --> 00:52:47,000 So you mentioned something about embedding AI model, right. 1243 00:52:47,000 --> 00:52:49,760 So I think obviously the biggest thing these days people talk 1244 00:52:49,760 --> 00:52:51,520 about, you know, AI, generative AI. 1245 00:52:51,840 --> 00:52:54,760 So what do you think are some cool cases that you have seen 1246 00:52:54,760 --> 00:52:59,000 maybe in your experience as well using generative AI and internal 1247 00:52:59,000 --> 00:53:01,600 developer platform or platform engineering, any kind of like 1248 00:53:01,600 --> 00:53:03,240 cool use cases that you can share today? 1249 00:53:03,960 --> 00:53:05,400 Yeah, that's a really interesting question. 1250 00:53:05,400 --> 00:53:08,800 So there's some stuff that we're working on that I can share just 1251 00:53:08,800 --> 00:53:12,160 yet, but I'll kind of, you know, give you like a high little idea 1252 00:53:12,160 --> 00:53:15,560 of how we think about generative AI and like how it applies to 1253 00:53:15,560 --> 00:53:17,440 the space. And then some of the cool use 1254 00:53:17,440 --> 00:53:18,680 cases we've seen with it as well. 1255 00:53:19,320 --> 00:53:22,680 You know, we have been working with, you know, one of the BIG4 1256 00:53:23,040 --> 00:53:27,400 consulting firms and it's really interesting the way they use 1257 00:53:27,400 --> 00:53:29,520 generative AI. You know, as they're doing 1258 00:53:29,520 --> 00:53:32,520 transformation projects and modernization projects, you 1259 00:53:32,520 --> 00:53:35,200 know, they're able to use generative AI to kind of rapidly 1260 00:53:35,200 --> 00:53:38,440 accelerate the code transformations, the migrations 1261 00:53:38,440 --> 00:53:40,440 and things like that. And so rather than going in with 1262 00:53:40,440 --> 00:53:42,920 a ton of manual effort, they build like a really powerful 1263 00:53:43,240 --> 00:53:45,800 tool chain around platform engineering to help with the 1264 00:53:45,800 --> 00:53:48,160 adoption of their platform. So it's not like the platform 1265 00:53:48,160 --> 00:53:50,360 isn't about Gen. AI itself, but it's about, hey, 1266 00:53:50,360 --> 00:53:52,440 we know this platform is going to help, you know, drive these 1267 00:53:52,440 --> 00:53:54,280 different use cases and user journeys. 1268 00:53:54,720 --> 00:53:57,400 Can't we use generative AI to like migrate existing things in 1269 00:53:57,400 --> 00:53:58,640 the new world and stuff like that? 1270 00:53:58,640 --> 00:53:59,920 So that was really interesting use case. 1271 00:54:00,560 --> 00:54:02,440 Another thing that I think is really important, and I call 1272 00:54:02,440 --> 00:54:06,280 this example out, is I think a lot of tools have gone down the 1273 00:54:06,280 --> 00:54:08,960 path of just these like generic chat bots. 1274 00:54:08,960 --> 00:54:10,600 Like, hey, we have all this data, let's just throw a chat 1275 00:54:10,600 --> 00:54:14,200 bot on it with some rag. Like, OK, like it's not it's 1276 00:54:14,200 --> 00:54:15,640 cool. It's like a nice demo, but I 1277 00:54:15,640 --> 00:54:17,000 guess it doesn't actually do anything. 1278 00:54:17,360 --> 00:54:19,800 And so I think like, you know, from our perspective, the 1279 00:54:19,800 --> 00:54:23,400 application of generative AI is really going to shine when it 1280 00:54:23,440 --> 00:54:26,200 applies to specific use cases, specific types of data. 1281 00:54:26,680 --> 00:54:28,480 Like that's, I think that's one way to think about it. 1282 00:54:28,480 --> 00:54:32,320 So like internally, you know, if you're on the SRE team, we've 1283 00:54:32,320 --> 00:54:34,440 seen folks use generative AI for like, you know, analyzing their 1284 00:54:34,440 --> 00:54:38,280 incidents and things like that. If you are on the platform 1285 00:54:38,280 --> 00:54:42,600 measuring team, using generative AI to summarize your own feature 1286 00:54:42,600 --> 00:54:45,400 backlog or like requests from your end users internally. 1287 00:54:45,680 --> 00:54:48,120 So can you find patterns of like feature requests and things like 1288 00:54:48,120 --> 00:54:49,120 that? That's been a really interesting 1289 00:54:49,120 --> 00:54:51,640 use case. It's like if you had like a 1290 00:54:51,640 --> 00:54:54,720 junior analyst on your team that you could like give a problem, 1291 00:54:54,720 --> 00:54:57,160 be like, hey, can you go and like figure out the synthesis 1292 00:54:57,160 --> 00:54:58,360 and like, here's how you should think about it. 1293 00:54:58,640 --> 00:55:00,520 Those are kinds of things that it's really, really good at. 1294 00:55:00,760 --> 00:55:02,600 Obviously, like, you know, coding assistance and the like, 1295 00:55:02,600 --> 00:55:04,840 but like, you know that that's fairly obvious from a platform 1296 00:55:04,840 --> 00:55:07,520 engineering perspective. It's about getting another brain 1297 00:55:07,520 --> 00:55:09,920 on your team that can help you reason about like, are we 1298 00:55:09,920 --> 00:55:11,320 working on the right things? Are we finding the right 1299 00:55:11,320 --> 00:55:13,400 patterns and so on. So that's kind of how we've seen 1300 00:55:13,400 --> 00:55:14,600 some really interesting use cases. 1301 00:55:15,360 --> 00:55:16,080 Right. I don't know what you're 1302 00:55:16,080 --> 00:55:18,440 building, but I'm guessing that if you have some kind of 1303 00:55:18,440 --> 00:55:21,600 assistant within cortex, right, that you can ask some questions 1304 00:55:21,600 --> 00:55:23,520 and find patterns. I think that would be cool. 1305 00:55:23,520 --> 00:55:25,320 Definitely. Maybe that's one use case of 1306 00:55:25,320 --> 00:55:26,000 generative. Yeah. 1307 00:55:26,640 --> 00:55:28,840 So Dinesh, it's been a pleasant conversation. 1308 00:55:28,840 --> 00:55:31,800 So I have a tradition in my podcast to ask one last question 1309 00:55:31,800 --> 00:55:33,800 for all my guests. I call this the three technical 1310 00:55:33,800 --> 00:55:36,040 leadership wisdom. You can think of them just like 1311 00:55:36,040 --> 00:55:37,640 an advice that you want to give to the listeners. 1312 00:55:37,800 --> 00:55:39,640 Maybe if you can share your version today that would be 1313 00:55:39,640 --> 00:55:41,680 great. Yeah, absolutely. 1314 00:55:42,160 --> 00:55:47,520 My first one, then this little one I strong by very much is be 1315 00:55:47,520 --> 00:55:49,600 a good storyteller. It doesn't matter if you're an 1316 00:55:49,600 --> 00:55:51,320 engineer, it doesn't matter if you're an engineering leader. 1317 00:55:51,880 --> 00:55:56,120 Be a great storyteller. A lot of what you do in any role 1318 00:55:56,120 --> 00:56:00,240 is telling stories, whether it's giving one of your reports 1319 00:56:00,240 --> 00:56:01,960 advice. If you're telling the story, 1320 00:56:01,960 --> 00:56:05,400 it's like, hey, imagine if we improve these things? 1321 00:56:05,400 --> 00:56:06,680 Like how much better could it be? 1322 00:56:06,680 --> 00:56:08,720 Like what kind of behaviour do we want to see? 1323 00:56:08,720 --> 00:56:10,800 Like, how do I help my reports see the light? 1324 00:56:11,280 --> 00:56:13,840 You're telling a story, right? You're managing up, you're 1325 00:56:13,840 --> 00:56:16,360 flying risk to your manager about some project. 1326 00:56:16,640 --> 00:56:19,200 You're telling a story, right? It's not about like making up 1327 00:56:19,200 --> 00:56:23,000 excuses or fabricating a story. It's about like, can I 1328 00:56:23,000 --> 00:56:26,400 communicate beginning, middle and can I be concise? 1329 00:56:26,760 --> 00:56:29,600 Can I give clear information? Can I bring people with me in my 1330 00:56:29,600 --> 00:56:32,200 thought process? So being able to tell stories 1331 00:56:32,200 --> 00:56:34,160 very important, especially as an engineering leader, you're 1332 00:56:34,160 --> 00:56:36,480 making a big decision. How do you help the team see 1333 00:56:36,480 --> 00:56:38,480 that? How do you, like, explain to 1334 00:56:38,480 --> 00:56:41,360 them the trade-offs, the thought that went into this, why we're 1335 00:56:41,360 --> 00:56:43,120 doing a certain thing? What does it mean for the 1336 00:56:43,120 --> 00:56:44,920 business? Like tell a story. 1337 00:56:44,920 --> 00:56:47,920 It's really, really important. The second thing I'll say is 1338 00:56:48,880 --> 00:56:51,920 deeply understand your product, especially as an engineering 1339 00:56:51,920 --> 00:56:56,800 leader, having a above average understanding of the product 1340 00:56:56,800 --> 00:56:59,520 that you're working on will help you make very quick judgements 1341 00:56:59,520 --> 00:57:02,960 and reason about the space that you're operating in, right? 1342 00:57:02,960 --> 00:57:06,480 Like you of course will lean on your own team and the experts on 1343 00:57:06,480 --> 00:57:09,680 your team for, you know, tactical advice and like they're 1344 00:57:09,680 --> 00:57:10,720 the experts at the end of the day. 1345 00:57:11,320 --> 00:57:14,400 But if you have a deep understanding of your product, 1346 00:57:14,960 --> 00:57:20,240 then you are able to reason about trade-offs and route 1347 00:57:20,240 --> 00:57:23,760 information much more quickly. So I think deeply understanding 1348 00:57:23,760 --> 00:57:25,880 your product is the second thing that I would say. 1349 00:57:26,560 --> 00:57:30,880 And I would say probably the third thing is think, and this 1350 00:57:30,880 --> 00:57:33,920 kind of goes back to the early part of our conversation, Think 1351 00:57:33,920 --> 00:57:36,120 about the culture. I know that sounds like a very 1352 00:57:36,120 --> 00:57:39,800 vague thing to say, but the specific advice I want to give 1353 00:57:39,800 --> 00:57:42,840 is to think about your operational cadence in 1354 00:57:42,840 --> 00:57:46,240 particular. So the rituals and the practices 1355 00:57:46,240 --> 00:57:50,680 that you set up help dictate the way your organization operates, 1356 00:57:50,680 --> 00:57:52,400 especially as it's larger, right? 1357 00:57:52,400 --> 00:57:56,000 So like, for example, if you create an operational excellence 1358 00:57:56,000 --> 00:57:59,400 review, that itself starts to create the conversation of like, 1359 00:57:59,960 --> 00:58:01,080 what metrics should we be looking at? 1360 00:58:01,440 --> 00:58:03,160 How often should we be looking at these metrics? 1361 00:58:03,400 --> 00:58:05,280 Who should be involved? You know, are we bringing the 1362 00:58:05,280 --> 00:58:06,840 right people? Just the fact that you have an 1363 00:58:06,840 --> 00:58:09,000 operational excellence review creates this conversation, 1364 00:58:09,120 --> 00:58:11,480 right? But then go on a little bit more 1365 00:58:11,480 --> 00:58:12,760 granular. OK, In the operational 1366 00:58:12,880 --> 00:58:15,960 excellence review, what outcomes do I wanna do I care about? 1367 00:58:16,320 --> 00:58:18,520 And so like, how am I gonna structure the meeting agenda to 1368 00:58:18,520 --> 00:58:21,200 drive those outcomes, right? Like, imagine just the fact that 1369 00:58:21,200 --> 00:58:24,320 you say like, hey, we're gonna stop our conversation 10 minutes 1370 00:58:24,320 --> 00:58:26,480 before the end of the meeting and with the only thing we're 1371 00:58:26,480 --> 00:58:29,000 gonna be talking the last 10 minutes are action items, right? 1372 00:58:29,360 --> 00:58:31,160 It completely changes the format of the meeting, right? 1373 00:58:31,160 --> 00:58:34,040 You're like, you were creating culture that like it's not just 1374 00:58:34,040 --> 00:58:36,200 to talk about things, we want to do something about it, right? 1375 00:58:36,200 --> 00:58:38,720 And so it's like, how can you structure your operational 1376 00:58:38,720 --> 00:58:41,720 cadence, your rituals to create the culture that you want? 1377 00:58:41,840 --> 00:58:44,480 You know, it's like if you want to celebrate shipping and like, 1378 00:58:44,480 --> 00:58:47,400 hey, like we want to create momentum, create a weekly demo 1379 00:58:47,520 --> 00:58:48,760 meeting for your engineering team, right? 1380 00:58:48,760 --> 00:58:51,040 It's like no matter what you built, you have to come and 1381 00:58:51,040 --> 00:58:52,360 demo. Like you just have to demo 1382 00:58:52,360 --> 00:58:54,760 something. Even if it's an API, come show 1383 00:58:54,760 --> 00:58:55,720 us your code. It doesn't matter. 1384 00:58:55,720 --> 00:58:57,560 Like show your team what you're working on. 1385 00:58:57,560 --> 00:58:59,520 Show us, show the interesting things we're doing across the 1386 00:58:59,520 --> 00:59:01,680 organization. That's a ritual, right? 1387 00:59:02,560 --> 00:59:05,200 Those rituals can also be part of other teams as well. 1388 00:59:05,200 --> 00:59:09,840 So like maybe a ritual could be your team, like an injuring team 1389 00:59:09,840 --> 00:59:14,400 and the support team get together for hackathon once 1/4. 1390 00:59:14,400 --> 00:59:17,400 So it's like, OK, well what I want to hear is like cross 1391 00:59:17,400 --> 00:59:19,560 pollination of information that's going to reduce the 1392 00:59:19,560 --> 00:59:22,240 support load and escalations from support to engineering. 1393 00:59:22,480 --> 00:59:23,880 Like that's the thing that I'm thinking about. 1394 00:59:24,200 --> 00:59:26,640 But like I'm creating a ritual that like creates that natural 1395 00:59:26,640 --> 00:59:28,400 cross pollination between those two teams. 1396 00:59:28,400 --> 00:59:31,280 Like what are the actual rituals that I can do on a recurring 1397 00:59:31,280 --> 00:59:34,400 basis that even if I'm gone, if I'm on PTO or whatever, like 1398 00:59:34,400 --> 00:59:37,360 those systems are in place that the wheels are turning and it is 1399 00:59:37,360 --> 00:59:40,000 creating a culture where when I'm not in the room that the 1400 00:59:40,000 --> 00:59:41,600 behaviors are still happening the way I think about it. 1401 00:59:41,600 --> 00:59:44,200 So that would be my third thing is like think about culture from 1402 00:59:44,200 --> 00:59:46,640 the lens of operational cadence. So those would be my 3. 1403 00:59:47,200 --> 00:59:48,640 I really love the last one, right? 1404 00:59:48,640 --> 00:59:51,840 Because any times when you are, you know, into the mode of like 1405 00:59:51,840 --> 00:59:53,560 operations production and all that, right? 1406 00:59:53,560 --> 00:59:56,120 So you think about just the problems solving, right? 1407 00:59:56,120 --> 00:59:58,680 But not necessarily the culture that you want to build and 1408 00:59:58,680 --> 01:00:00,640 creating a cadence, be intentional, right? 1409 01:00:00,640 --> 01:00:03,160 Creating a cadence. Maybe the rituals, you know, the 1410 01:00:03,680 --> 01:00:05,120 meetings that you want to have, right? 1411 01:00:05,120 --> 01:00:07,240 The cross pollination thing. I think that's really important 1412 01:00:07,240 --> 01:00:10,160 for any engineering leader. So Ganesh, if people love this 1413 01:00:10,160 --> 01:00:12,760 conversation, they want to reach out to you, ask more questions 1414 01:00:12,760 --> 01:00:15,480 or maybe find out more about your product and things that you 1415 01:00:15,480 --> 01:00:17,040 built. Is there a place where they can 1416 01:00:17,040 --> 01:00:20,640 find you online? I'm on LinkedIn to enter my name 1417 01:00:20,720 --> 01:00:24,920 and you can also e-mail me at Ganesh cortex dot IO. 1418 01:00:25,760 --> 01:00:28,280 All right, lovely. So thank you so much for today's 1419 01:00:28,280 --> 01:00:30,600 conversation. So I believe people have learned 1420 01:00:30,600 --> 01:00:32,880 a lot of things about building engineering excellence and 1421 01:00:32,880 --> 01:00:35,160 hopefully they can achieve that. So thanks again for that. 1422 01:00:35,560 --> 01:00:37,120 Thank you for having me enjoy the conversation.