Utilizing AI internally to iterate faster and empower smaller teams to upskill w/ Vivek Raghunathan #263

Speaker A: This episode is brought to you by Sidero. If your team runs Kubernetes, chances are upgrades can feel risky. That's what the Telos platform is for. It's built on immutable minimal OS designed for Kubernetes. Immutable means clusters cannot drift, so they stay identical and upgrades are a non event. Minimal means there is almost Nothing to attack. 50 binaries, no shell, no ssh. So it's secure by default. Upgrades get boring, security gets boring. And that's exactly the point. Check it out@siderelabs.com that's S I D E R O labs.com I'll tell you what I did.

Speaker B: I told all my leaders you're taking the week off to get your all. Your entire team is taking the week off to upskill themselves. And my attitude is uh, this is the highest leverage thing you can be doing right now. This is how you make sure you can be relevant for the next decade. You know, Eisenhower had this urgent, important framework, right? This is the important thing that should not be trumped by something urgent. When people do it, they come back out of that week and they're like, hey, I wish I could do this more often. So where I'm thinking even of doing it like twice a quarter or twice a quarter. Just getting to a place that having this is not like a one and done right. Keeping people on the bleeding edge is a uh, full time job. Hello and welcome to the Engineering Leadership Podcast brought to you by elc, the Engineering Leadership Community.

Speaker A: I'm Jerry Lee from founder of elc.

Speaker B: And I'm Patrick Gallagher and we're your hosts. Our show shares the most critical perspectives, habits and examples of great software engineering leaders to help evolve leadership in the tech industry.

Speaker A: Hey Vivek, so excited to have you joining us today and share your learning and insights and journey. You know building engineering teams and adopting AI and then looking to the future how organization going to adapt to this new world. Last time when we chat you mentioned a lot about how the whole engineering team and the org at large, how they are adopting AI. Maybe you can take us on journey. Uh, of um, where do we see Snowflake Engineering is uh, currently at in terms of adopting AI and building anyone? Yeah.

Speaker B: First of all I'm super excited to be with you guys. Thank you so much for having me. Some context. Snowflake engineering is about 2,500 people, something like that. So slightly different scale from a uh, small startup or a medium sized company. I used to be at Google and YouTube a while ago. Then did a startup for four and a half years, sold a startup to Snowflake. And so, you know, the answers can sometimes be different for different size companies. The approach we have taken very much is one size does not fit all. To quote, like my stone breaker in reverse, I think there's a set of things that it is very important early on for us not to feel like we are standardizing too quickly, if you will. The paved paths are still being figured out. So at some level we have built and are operating in a way that lets us standardize the things that can be standardized, the things that we know to be good and at the same time leave room for experimentation and for people to push the frontier of how they operate. I see roughly an arc of four stages of maturity, if you will. The first is people adopting AI tools to write code. Right, Just inner loop of software. Can they do more of that? The second is, okay, now they're writing more code. How does that change the act of, how do. How does AI change the act of product development itself? Are we in the uh, you know, yes, they wrote more PRs, but like, are we able to build products in a fundamentally different way? The third is, okay, now we are able to write code in a fundamentally different way. We're able to build products in a fundamentally different way. What does it mean to release those products and operate our systems? I mean we're ultimately, uh, you know, infrastructure software companies use us on a daily basis to run their entire infrastructure. Can we run our infrastructure in a fundamentally different way? Right, in an AI first way. And then finally. And um, this is, I think the thing that is most dear to my heart is what does this mean for how I run the engineering organization and my product counterparts runs the product and design organization? And what are our roles and responsibilities in this new world? And how do we organize our team so that we can maximize velocity while still staying very interconnected? We're ultimately still shipping one product to the customer on each of these paths. We have been pretty good about when we find golden paved paths. We standardize them, we measure them at every level of the organization and we nudge people towards using those paved paths. The same time, there's lots of people really pushing the boundaries of how they can write more code or build process a formally different way, or operate our systems in a fundamentally different way. And it's important for me that we are able to see what those people are doing almost these are our new leaders, right? And how do we elevate them and how do we empower them to Discover new ways for the organization to function. And so we're leaving enough room for that kind of creativity. Uh, the results kind of speak for themselves. Right now I'm going to say about 95% of my teams are active users of coding agents on a weekly basis. I'm pushing that more towards a hundred percent daily usage because I'm like, hey, you don't say, I'll use slack once a week, right? You're like, I use slack every day. This is like coding agents are like slack. In fact, I'm currently using.

Speaker A: You don't need measure anymore, right?

Speaker B: Yeah, using a coding agent actually to use. I'm telling my coding agent is working with slack right now. Like, I'm basically using my coding agent to mediate all my Slack interactions. Yeah, you. I think 100% daily actives is the only bar I can think of. But I'm also looking at who people I would think of as, you know, at the cutting edge. These are people who are running teams of agents, almost acting like tlms of an agent team. You know, that number right now is maybe I'm going to say 10% of the 5 to 10% of organization. And I'm like, how do we 5x that in the next two months? Uh, and this is all the answer is these people can teach the person next to them, right? It's because these are all like, you know, people discovering stuff at the cutting edge. And then in each of my teams, I'm saying, hey, I need at least one experiment that is a fundamentally different way to build product. You know, historically, you went and figured out customer requirements, then you wrote prds, then you wrote functional specs, then you wrote engineering design docs. At every step of the process, you wrote a review. And all of this was there just so we could make sure that we didn't waste engineering code output, which was an expensive, difficult commodity. And in a world where that becomes significantly easier, we can kind of work back and say, are there ways for us to just empower four or five engineers? Engineers, maybe a, uh, PM or a designer, let them cook with gas and get their products to market. How we do this in the enterprise, where the quality bars are much higher, the reliability bars are much higher. That is the thing I'm figuring out in the next three or six months. But it's exciting time. Never been a better time to be an engineer.

Speaker A: I think it feels like based on what you said, the most effective engineers that leveraging, they're the tech lead. They're leading a, uh, team of Agents. So with AI, uh, it's quite bigger distance between the average engineer now that there's 100x engineers. So I'm curious to learn in your organization what separates the most effective and then you're leveraging AI.

Speaker B: Yeah, I think the. I mean it's still. I'm still trying to figure that out. Exactly. But I have some theses. Right. First off, I think it is a mistake to correlate it with seniority. Like, lots of companies have gone, we should only hire senior people. We should not hire junior people. Because senior people know like how to design systems. And now coding agents let them build those systems quickly. Uh, in fact, I'm going the opposite way. 70% of my hires are junior people. 70 or 80% of my hires are junior people. Right. The thing I'm obsessively screening for across the board on things like hires are curiosity and the things that I think distinguish the. To your point, I think it is correct that coding agents are increasing the variance between the average engineer and the uh, outstanding engineer. But I think it is not uniform. The 10x engineer didn't. All 10x engineers didn't become 100x and some 1x engineer suddenly became 100x. Right. And really, I think what separates the ones that are able to take advantage of the new world versus the previous world is just a high degree of curiosity, uh, and ability to think in a structured manner and break problems down. Because if you can break problems down, then you can have like, uh, a bunch of sub agents work on them and generally the ability to map and empathize with customer problems and product problems and bring them back and then design solutions. The folks that I think are used to be incredible and um, not as incredible anymore is people whose primary like USP in the past was they could just write code faster than the person next to them at some level. That is a skill that is less critical in the new world compared to the old world. Many people, including me, got promoted to their career because you happened to be able to write code faster than the person next to you. Right. So at some level there's a selection bias in the senior parts of any organization. People who are there are there because at some point in time they were faster and better 10x software engineers next to them. Now I think all of us have to retool what it means to be 10x in the new world. And I think it is a lot more thinking in a structured way, thinking how you can quickly get from path A to path B, thinking what is the smallest unit of iteration, doing that unit, working with the coding agent to kind of improve that unit to the next level of iteration and at some level figuring out how to build product in a completely different way. It's a scary world. Uh, scary in the sense of unfamiliar, not in the sense of terrifying. Right. It's just new, novel things. And so people who embrace the new and novel are succeeding.

Speaker A: Got it. Another question about engineering adopting AI. I think you talk about what kind of talent that makes they do well in this world and that individually I'm curious to learn from an infrastructure or system perspective, what are the things you do as an organization to create or process, you're going to innovate that helps or accelerates the adoption of AI?

Speaker B: I think there are a number of things and we can kind of walk through each of them. The first and most important thing is as we discover like new ways for people to do stuff, making sure that information percolates through the organization. And so at some level, I think of the teams as three sets of teams that mean I can help my team kind of two. The first is the entire software development life cycle is changing. So us rethinking the software development life cycle for the world of tomorrow is critical. Right. PRs are like up like crazy, like heading, uh, at Snowflake, well over 100% year over year. And that just means that your CI systems, and this is I think consistent with everyone we talk to in the industry, our CI systems have to improve significantly. Right. But it's not just that, like when you're working with AI, you're, you know, historically everybody has talked about a test pyramid that is, you know, lots of unit tests, a small number of integration tasks, very few regression tasks. Snowflake actually has an inverted test pyramid. Don't ask me why, but we have 10 times the number of regression tests as we have unit tests. And the reality is if you have a coding agent having a good verifier, something that tells it that the code it produced was correct for the whole system becomes critical. So all we know is code bases where you are, you know, nationally testable, are generally do better in a world of coding agents than code bases that are more brownfield. And so one big thing that I'm encouraging my teams to think of in a world of AI is historically a company like ours. The rewrite is always like something you. I mean any big tech company, the rewrite is something you fear. Like these are 18 month M projects that sometimes go nowhere. But I think we can scale up our technical ambition. The Cost of testing out whether infrastructure rewrite is going to work is far cheaper than it used to be, especially if you have like a clean set of tests that protect you from regressions. So one is of course improving the SDLC in a big way. Second of course is pushing teams to just be more ambitious technically and embrace the rewrite that they would not have otherwise done because it would have just felt too daunting for them to go run. Right. The third is just rethinking how code is released, uh, and uh, tested and like validated. Right. Our uh, release processes generate a lot of what we call release blockers. These are places where we think a test might fail. We can't run every test on every commit that people send. So we do 95% of the work upfront during CI and then the last 5% of work during the release. But we can automate lots of workaround when there's a release blocker. We can quickly bisect, we can quickly roll back. An agent can generally often suggest the change. And so building infrastructure and agent tools that help engineers just automate some of the tedium of their work starts to become a lot of what we're doing. You know, we think of a maturity model almost of how engineers go from oh, I used autocomplete in GitHub Copilot, that's like two years ago, right. To I am now using a coding agent on a daily basis. Right. You know, I'm uh, doing more things.

Speaker A: Right.

Speaker B: And so what are those things? So we have a bunch of patterns we have discovered. We are in the process of rolling them out to the entire company. We of course do all of the usual like social engineering. Right. You have forums, you have weeks where people, we just tell the whole org, take the week off. Like get yourselves familiar with the tools. We do that for every function in the organization. In fact my admins are doing it right now for the next day or two. But what are the first few ones? One is use skills extensively. Right. Skills are the difference between a new hire and a 10 year veteran. Right. Codifying practices like this is how you write a logger in Snowflake, or this is how your code base does testing, or this is how your code base does monitoring and metrics collection. Right. That's pattern zero. Pattern one, if you will, is don't just ask your coding agent to go write like 10,000 lines of code. Start with a plan, like work in plan more it read on your plan, spend a bunch of time, draft in English. English is far cheaper than code Markdown just works. And once you do that and once you treat in the plan and once you like the plan now get the coding agent to write a bunch of code. This is the second pattern that we know and what we're doing is there's like 11 more, 12 more patterns. Happy to walk you through them, but what we do a lot of is see if we can get people further along on this maturity curve. Examples of patterns. Pattern three, get the agent write test before you write improvement implementation. Right. Pattern four, make sure it has a verifier that you are closing the loop, that you are getting it to run the test as it is generating code. Right. These are I think what I call off as basics. Like you're doing this, you are. Internally we have embraced, uh, all of Steve Yegi's uh, posts and we have a Yegi scale for how mature you are. YEGI7 is like, you know, you're using Asian teams, you're doing a whole bunch of things. And so we're just trying to move people along that Yegi scale. We're going to work through how we then get people to 10x things, right? Git work trees like critical. So agents can work generally very distinct, away from each other. Flat plans. Say no to it. Instead, have task graphs with dependencies, right? There is a, uh, clear like delineation of when to do what, after what. So don't do lists of tasks, do graphs of tasks. The next one that people often discover is just parallel subagents, right? Just work on them in parallel. Code review is the most common sub agent task, right? Which is here's your security code reviewer and here's your API code reviewer and here's your performance code reviewer viewer. Once you got there, there's things like context summarization, there's things like aging teams, uh, there's things like having a master agent that is orchestrating but never actually doing the work. Now we're eventually getting to even fancier listings like species, like design, getting the agent to first write a spec and then kind of going from there to code. Ah, we can go through this. We spent two hours discussing the patterns, right. A lot of these patterns actually come from our CEO experimenting with a bunch of engineers. Uh, Sridhar is about as frontier as it gets when it comes to how much time he is spending with coding agents. Uh, in fact, the deck we use to teach people is the next KCD deck that he produced using a coding agent with a set of elaborate skills and Python script zero. But overall it's a combination of What I'd call social, top down evangelism. Some amount of monitoring and nudging and encouraging, but we don't do too much of that. And a lot of just getting people in local groups to push forward what we have discovered knows works globally and just giving people the time and space to do that.

Speaker A: Yeah, there's a few things that you mentioned, uh, really picked my interest. One is you, um, let a team off for the entire week with department of department to take the time to learn about AI tools. How do you operationalize that? Because, uh, I'm sure there's a lot of things need to be taken, uh, off the plate for that.

Speaker B: I'll tell you what I did. I told all my leaders, you have four weeks and you need to do a focus week in one of those four weeks. It's AI focused week. You're taking the week off to get your all. Your entire team is taking the week off to upskill themselves. We have an engineering systems team which works directly for me. And this team is the one responsible for our broadcast, our CI infrastructure, AI infrastructure, all of our build forms, everything. And they come out to each of these teams and they help them and teach them and they enable them, if you will. We have been pretty consistent on just in everyone, not just, uh, individual contributors. We are asking tls and managers and directors, everyone to go take the time to familiarize themselves. Partly why we did it is, you know, sometimes we see somebody not using AI at all and then we bring them and say, hey, why are you not doing it? And they're like, I'm super busy, why are you bothering me? Just leave me alone. My attitude is this is the highest leverage thing you can be doing right now. This is how you make sure you can be relevant for the next decade. Eisenhower had this urgent, important framework, right? This is the important thing that should not be trumped by something urgent. This is one of the few things we've done top down. As I just told all my leads, you have to do this. You have to do this with the entire teams. And generally speaking, when people do it, they come back out of that week and they're like, hey, I wish I could do this more often. So where I'm thinking even of doing it like this is not like a one and done, right? There's like I told you about like eight patterns. There were seven more and I'm sure there'll be five more in the next four weeks.

Speaker A: Right?

Speaker B: And just keeping people on the bleeding edge is a, uh, full time job.

Speaker A: This episode is Brought to you by Sidero. If your team runs Kubernetes, chances are upgrades can feel risky. One CVE patch can put a whole fleet in doubt. What should be routine takes too much time and it often ends with your best engineers fighting fires instead of shaping a roadmap. The root cause is underneath a general purpose operating system that was never built for this. The moment someone runs a package manager or hotfixes a box at 2am you have a drifting node. And worse, the OS comes with a large attack surface that you never needed. That's what the Talos platform is for. It's built on immutable minimal OS designed for Kubernetes. Immutable means clusters cannot drift, so they stay identical. And upgrades are a non event minimum. Means there is almost Nothing to attack. 50 binaries, no shell, no ssh. So it's secure by default. It handles the fleet's lifecycle for you. Provisioning, upgrading and retiring machines automatically. That design matters most when the stakes are highest, including the edge with no one on site and AI clusters where drift is expensive. Upgrades gets boring, security gets boring. And that's exactly the point. Check it out@siderealab.com that's S I D E R O labs.com uh, you mentioned about uh not only transform how engineering work, it also bleeding into product development because the cost of writing code become a lot lower dramatically. How do you think that what happens to product management and also at a company at your scale, how do you keep the product development consistent?

Speaker B: Yeah, ah, I think there's three different questions in there so we can unpack all three of them. Snowflake, product development and design and data science are all run by my product counterpart. His name is Christian Kleinerman. Uh, and he and I work super closely together including with my CTO Esmeraldar. And the first observation is we went from a period of we would say waterfall and then we said we do like more scrum style. People are continuously building. But even when we did that, when we built enterprise software and I used to be in consumer for a long time I was at Google and then I was at a startup of my own. I was also a consumer startup. Even when you're in consumer you are often doing a bunch of user feedback gathering. In enterprise it is from customers, in consumer it is from implicit like you know, feedback signals in the data. Then you are building hypotheses for what products to build. Then you're going and getting feedback on that. Then you are once you have these user journeys somewhat validated, you are Saying okay, now let me write down a spec for how I want to build this and then you're getting that validated and then you are writing a design doc or an edge design doc for how you would actually build it. They're getting that reviewed a bunch, then you're writing the code. So the lead time is very long. And at every step of the way you know, there's lots of discussions, there's 50 page docs that people are powering through, leaving lots of feedback. And at some level different functions play different roles, right? Like uh, design often represents the voice of the user, uh, product management and design represent voice of the user. So they are more involved in the front, so front of the, of the process, towards the back end of the process, product and engineering are a lot more involved. And you know, we all know how this works. By the time you start from start to finish and you got into finish, the requirements, requirements may have changed, the market may have moved under you, all those things, right? And so when I think of what we have to do, we have to compress the opportunity we have at fast is to compress the iteration of one unit of meaningful progress on the product down to like months or weeks or days, right? If you can do that then you can get quick feedback, right? If the cost of code is as low as it is, then your ability to ship an atomic feature that meets a very narrow need that the customer has, that you know the customer has from the data and get validation from that customer is within a week is now suddenly not like a pipe dream. You know, 5% startups could always do it because 5% startups don't have 15,000 customers that are using them for their critical business needs, right? So As a ah, 45% startup in Neva, sure I could do a bunch of these things like very quickly. It now lets me run a large engineering organization with critical production needs with the uh, velocity of a small ah, startup, but the quality power of a big company. And often people have said you can have features or quality or speed, but not all of them, right? And I think with AI sometimes you can have all of them because suddenly the ability to do more things magically increased. And you can factor your team so that they are more independent of each other and they can run in parallel. Uh, I think the primary thing is to get people into pods. We're still figuring out and experimenting what pods are the right, like this thing. My general sense is Amazon used to have the two pizza box rule, right? Teams should be fed with two pizza Boxes. I think now you can do the one or half pizza box rule, right? It's four people plus a bunch of very capable AI tools. The right four people. I don't think there's a function thing. You need someone who is enough user empathy. So let's call them the product. You need to have at least one person who knows the top level parts of the system. You can call them the TL or the architect, but really they know the system end to end. One person who's at the cutting edge of AI, right. Who knows how to manipulate and use coding agents in ways that no one else can. I think you have that team, you can actually just cook with gas. Right. And roles are fluid. Like you know, PMs may be writing code, engineers may be doing designs, designers maybe building prototypes. The environment I think favors people who are very collaborative, who like to work in teams, you know, not people who are like, hey, you know, I'm going to go sit in my corner and do my thing and I'll come back to you when it's perfectly formed. I think over time things like pair programming will have a renaissance. Like you'll likely have trio programming or programming. But I think it'll. A joke I've often heard is my keyboard needs only four buttons. Yes, no, except reject. Uh, because sometimes, uh, you're often just iterating with the LLM M. It is a mistake to assume these coding agents are just like a few zero shot, one and done. People will have extensive design discussions with them, they'll have product strategy conversations with them, um, especially if you connect them to all your sources of data like Google Drive, Slack, Jira, Snowflake itself, so they know all of the data that they have access to. The third question you had is the most interesting is how do we make sure that we are shipping software that is consistent? Right. At some level, I think coding agents foresight because the world is going to go from more UI centric work to more headless work, more API first designs. Uh, and at some level the API represents the contract of what does the system you're interacting with going to work like. Right. And so those systems almost force consistency, if you will. Snowflake, for example, prides itself on everything is exposed in the RSQL layer as an object that you can interact with. And all objects have some properties. You can share them, you can replicate them, you can govern them and control who can access them, so on and so forth.

Speaker A: Right.

Speaker B: Those properties, I think over time that consistency property will get elevated to the orchestration layer. The implementations may be very different, but the orchestration layer makes things look uniform. The beauty of LLMs is they can translate from one kind of like primitive. I mean remember Transformers came out of the world of machine translation. The original paper metrics they were evaluating were Bluescore and uh, on the WMT batch more. And so at some level they're able to translate across APIs and languages very well. So I think you can use the orchestration layer to kind of hide lots of the underlying complexity. But at some level I feel like if you're a clear thinker in APIs like you will be able to keep your products very consistent.

Speaker A: Yeah, definitely. Increasing importance APIs is definitely, it's a trend. So one thing in terms of consistency is uh, about creating customer value. You mentioned what customers as well. So for coding agent or for AI at large, feeding them to the right and rich context is really important. If the system already knows what a customer, exactly what customer need and what they really need, what are the nuances. And then AI can take that requirement, turn into code, uh, turn into product and run testing automatically, et cetera. So I remember last time we were chatting and there's a huge advantage at Snowflake because all those data are already in one place that are ready to be leveraged to AI. Here's him around that.

Speaker B: You know we've talked about how coding agents can transform how you build code and how you run your systems and how you build products. But one thing I had underappreciated was how coding agents can transform how you add value to customers. Right. They make it far easier. Like too many, like the biggest like challenge I see in lots of our uh, go to market functions, right is product ships, features. But customers want end to end solutions, they want to solve business problems and somebody has to stitch together the solution that maps to the business problem a customer has from the features that your underlying platform provides. Right. So that's number one. And I think I'd underappreciated how much more powerful our coding agents are in the hands of capable sellers and capable solution engineers and sales engineers. I like to joke. I think Snowflake woke up in fiscal year 26 or 27, whichever year we are in. And you know we've roughly told our salespeople you'll write code and we've told our software engineers you will also sell. And I would say while, ah, that's a very like pity summary of where we are. I've seen so many of our salespeople building incredible applications tailored to the customer and being able to deliver customer value. So that's number one. Number two, our ability to do this dramatically depends on the way you said this to the context of that enterprise.

Speaker A: Right.

Speaker B: We're building like an agent control plane here. Right. The control plane is the control plane for your enterprise. What would that control plane ideally look like? Number one, it would know what happened in the past that happens to live a lot in Snowflake. Three, the second is what will happen in the future. The third is what is happening right now that tends to live in JIRA and Slack and teams and maybe Gmail. Right. Um, but MCPs make it very easy to access that. And the fourth is what is allowed to happen. Right. What I call the governance layer. What should be okay to happen and what is not okay to happen. For example, I don't want to myself planning my own compensation. That should not be something that is any enterprise would allow. Right. All of that context, all of that rich information about the enterprise, all of that rich information. And historically, you know, everyone has always pitched this pipe dream has been very difficult to pull off because you know, enterprise data is messy. There's petabytes of data, there's tens of millions of columns of structured data often in messy formats. You're often between migrations, between systems. You've not finished this one while you're doing the next one. And using coding agents to take all that complexity and give you one consolidated view of the enterprise I think is remarkably powerful and given so much of the, of the biggest enterprises in the world that their governance and uh, their data, uh, with Snowflake we have the opportunity to help those enterprises get the most value out of their data for themselves by enriching their coding agent experiences with their data. My view here, my long term vision here is as you use a coding agent with your enterprise's context, it should automatically get better the more you use it. It should get better. I take things like skills. Right now I feel a little bit like there's skill marketplaces, there's like plugin marketplaces. It feels a little bit like Yahoo in 99. Right. Uh, Yahoo was the epitome of where the web was when the web showed up. Right. It was a directory of every website and many of your view listeners were not in the workforce then or not even in school then and so may not have as much empathy for that. And then search engines came along and search engines kind of win that particular battle. Uh, what made them win that particular battle is they said the more you use the search engine the better It'll get, it will learn over time what things are important, what things are not important, and it will replace like, uh, a directory of the web with a ranked collection of the most important things you care about.

Speaker A: Right.

Speaker B: I think those things are going to happen with context, having people build skills and ontology layers and like semantic layers. That is where we are today. Over time, I think we'll start to do these things more implicitly. And there, I think is a big opportunity for companies like mine that use customers trust with their data, to work with customers, partner with them, to deliver them like the best, like enterprise operating system or enterprise control plane for their data.

Speaker A: In terms of getting all the data in one place, creating that broader context for the whole organization, what are the ways your team is working on to intentionally ingesting all the data into one place that are accessible? So for example, I'm talking about not just the product requirements, but also signals you're getting from customer interaction because as you said, you encourage enduring your team to sell as well. So giving people the access to all the insights that eventually leads to customer value can be really liberating. For engineering team can do more, another team can do more as well.

Speaker B: Yeah, I'll kind of throw out like a couple thoughts. I see the mission of a, uh, company like mine as can we help you use your data to make your AI go faster and better? And then can we use your AI to make your data go faster and better? Right. I'll use your data, your AI and can we create a flywheel where your AI makes your data go faster, your data makes your AI go faster? I think there are a number of patterns that customers will take to do this. Some customers, and our, uh, best example is Snowflake on Snowflake. So Snowflake represents all of its internal data in a Snowflake instance. We call the Snowflake instance Snowhouse. And some level we run the whole company on Snow House.

Speaker A: Right?

Speaker B: So workday data gets mirrored there, JIRA data gets mirrored there, GitHub data gets mirrored there. All kinds of data gets mirrored there. And our coding agents can do an incredible job of writing good SQL for this kind of stuff. And so at some level that is one extreme, right? Like that is all the data is in one place. And you can, of course, you get like an incredible experience. And we know how to make customers successful like that because we are an internal customer that is successful like that. And the power of doing that is incredible. The other extreme, you have customers that I'd say have embraced things like Iceberg. And they want their data estate to stay somewhat neutral to all of the providers that can do operations on that data estate. Right. And they want to, you know, the way they say it is may the best engine for the kind of workload that they want kind of win. And we want to be the world's best for those folks as well. Like, we don't want one side, we don't want to tell everyone. The only way you can be successful at Snowflake is by putting all your data in.

Speaker A: Right.

Speaker B: If you're like one of those customers, we would love for us to be able to reason about your metadata. All of this, like these signals, the things that will help with the data can stay like on parquet and S3 or like in whichever source system it is in. So long as we have a way to authenticate to it, authorize to it, merge it like, and reason over it, we will be able to add like deep amounts of value. In practice, I think we have customers that are all across the spectrum. We have a large set of our customers that have bet on us as the one way to do things. We have a bunch of customers that are more like, I would say digital native, that are more at the right end. They want to not be locked into any platform. And like, you know, we respect both those perspectives and we want to make sure we are the best place for both those perspectives. I personally find things like MCPS are also another brilliant way to make systems work across systems. They, uh, don't work for everything. I think if you want to do analytic stuff, having to do like thousands of MCP calls to do point lookups is likely not the way to do it. You probably still want to mirror your analytic data into a place like Snowflake and then start being able to do a more like exhaustive analysis and interactive analysis over it. But we'll work in all those ways. We want to be the best place where you govern your data, you secure your data, you have visibility and observability or everything that's going on and you get real value from your customer data.

Speaker A: As a leader, you're closer with AI, you're closer to the reality.

Speaker B: You can be very close to reality. Exactly. You can know if you're willing to spend a little amount of time to actually dig, you have, uh, no reason to not know what is actually going on because you have a magical chief of staff, if you will, that is tireless, that can go and read every document that you otherwise would not have been able to read and correlate things across documents and tell you what is really going on.

Speaker A: What else does this change in terms of how leadership works?

Speaker B: I think the biggest thing, it changes. And I think this is a thing we have to work through, right? Like, of course we will create a new set of leaders that embrace this new world. The leaders that embrace this new world will be just like we said, software engineers will be 100x more effective. The leaders that embrace this new world will be 100x more effective. Their teams will be 100x more effective. But I think the traditional roles and responsibilities of leaders will itself evolve. Like, if I think of my rubric for my leaders, I have 16 items in my rubric. They are in four different categories, right? What are those four categories? One is I want snowflake first leaders, right? I want team over personal. Those things optimizes for snowflakes, interests at heart. Optimizes, you know, no jerks. All the standard things. That's not going to change, right? Those leaders that. That's even more important in this world where it's really like the weight on that thing might increase over time. The second thing that we often optimize for is are you an incredible people leader? Like, can you hire great people? Can you then motivate them to greatness? Can you take them under your wing and kind of make things happen, right? If they're not working, can you have the hard conversations to turn them around? If that doesn't work, can you actually like take corrective action? Right? So I'd say the people aspect of the job is second big thing third. And I'm almost. This is like a Maslow's hierarchy of needs, right? If you cannot do one of these things, you cannot do the next thing well. So being Snowflake first, that's the uh, base expectation, uh, or being company first, right? Collaborative next expectation is you're incredible people person. Like, you are able to actually build and coach and motivate and grow and demand like greatness. Out of slightly higher layer than that is, can you execute really well? Do you care relentlessly about product? Do you care relentlessly about growing the business? Whatever you define the business as, if you're in the infrastructure teams, Your business is 4, 9. That is your business. Can you do you relentlessly work across the aisle, across stakeholders, right? And then the fourth thing is, are you an incredible practitioner of your craft? Are you deep in the technology? Do you understand your products? Do you understand the code bases you are in, right? Historically, when I think of leaders, we have weighted these aspects differently. We weight that third aspect, which is execution, often at 50, 60% of like the weight, right? We weight the second aspect, like the uh, you know, working cross functional, the people stuff as 30% or 25%. We wait the are you a practitioner of your craft? Maybe 10% and we wait the are you company first, maybe 10%, right? I'm just making these numbers up. Maybe they don't add to 100. I think in this world those weights might change. Being a practitioner of your craft suddenly is like 30, 40% of the weight. You have to be great at that. Things like execution often like, you know, you will find ways to execute in different ways that will dramatically take you out of the loop. So that weight might actually drop a bit. But being able to collaborate, that weight might increase. I think the weights change a lot. And, and you know, as that happens as leaders, I think you have to adapt, right? If you were a great leader because you were a machine, like you knew how to execute. But if you can coach a coding agent to execute like you, then you don't need to be in that this thing. All the other soft aspects of your, of your job become important. So that's kind of the things I care for a lot. That's the things that I am kind of looking to. And I think I'd be lying if I said we did it all figured out, right? The other aspect of things that I see in leaders, which, and we know this, right? Like there's one size does not fit all. Like people are all going through processing change at different rates. There are some, what I'd call pioneers, right? Lewis and Clark, they're going to go and like invade new territory. There are settlers, they will follow in, right? And there'll be some implicit resistors. They may not be resisting it. They were just slower to accept change and just being empathetic as a leader to that reality, which is, you know, people are going through their seven degrees of acceptance at different rates. And you know, I have people who walk into my office or my, uh, I don't have an office. I have a small like conference room I use for lots of my meetings. And they'll walk in and say, hey Vivek, I reached 7 degrees of acceptance today. I'm like, great, now get going, right? And so just being empathetic and being uh, a lot more open to the idea that not everyone is going to process like the change at the same like rate I think is critical in a way.

Speaker A: It's the more AI become advanced and everywhere for leadership actually the sub Part of leadership becomes more critical. The empathy side of things is a reflection of that. Uh, so I have a few quick rapid fire questions.

Speaker B: Let's go.

Speaker A: First one, what are the things you're reading or listening right now?

Speaker B: I'm actually, I don't read, uh, business books. It's my, it's my thing. I read mountaineering books. So I read lots of like, lots of climbing books or like, like incredible, you know, tales of like, adversity and resilience. And I love reading them. My favorite book there is the book of the first climb of Annapurna by this guy called Maurice Herzog. And then I read lots of what I call science science fiction. I'm reading a book called Caliban's War right now and I highly recommend it. It's how I get my brain off, like, whatever I'm working on.

Speaker A: And what tool and methodology has a big impact on you.

Speaker B: I mean, so the tool, Codex code, the tool that Snowflake builds to work with all of Snowflake is. Changed my life. Life outside of Snowflake. Cloud code, same thing. Methodology, no particular methodology. Like, you know, I've kind of, uh, generally adapted to whatever new ways of doing things there.

Speaker A: What is the trend that you are seeing, and that is interesting, but has not hit the mainstream yet, I would

Speaker B: conjecture, is a bunch of people starting to use mobile devices to work with coding agents. And you know, in the Gilded Age, people went from working like crazy. They used to work six days a week to then working five days a week and actually like, leisure increased. Right. And I can almost envisage a world where, you know, you're with your agent, agent farm, they're doing a bunch of work and you're actually working less while working more.

Speaker A: Right.

Speaker B: And I see a bunch of people starting to do that. I don't see enough people doing it.

Speaker A: Is there a, uh, quote or mantra that you leave by?

Speaker B: The quote I often give people is go run towards places where there are more problems than people. Because I find that when there are more problems than people, then, you know, lots of interesting things happen. And so I always try to create environments where there are more problems than people.

Speaker A: Love it. Well, thanks for your time, Bibik. It's really helpful to learn from your insights. I think the audience will have a lot to take away and then go back to their organization.

Speaker B: Thank you so much for having me. It's been a pleasure being on the podcast. If you're listening to this and you're wondering how can I connect with other engineering leaders in my city. Pull up your phone right now and go to ELC dot Community. Click our Chapters page. You can see that on the menu on the left. Find your local chapter and click Join. We're hosting virtual and in person events all the time and this is the best way to help you get involved, expand your network in your city, and support your leadership and career growth. So pull up your phone, head to ELC.community join your local chapter and get involved. A uh, huge thank you to all of our local leaders who make community happen, and thank you for listening to the Engineering Leadership Podcast.