The fastest way to learn is to run two competing bets | Jay Parikh (EVP CoreAI, Microsoft)

I think you have such an interesting, given your set of experiences, likely have an interesting point of view on building teams in technology through sort of these different points in the last 30 years. Like, if you think about the role as there's the people and direction you're setting is like one hat, and there are many hats, but let's say one hat is all the people stuff of running an engineering organization, and then you have all the technology strategy pieces, and like those two sit next to each other. Like, I'm really curious when you think about engineering leadership in internet, mobile, cloud, AI, what does it mean on sort of any part of those S-curves to be like leading, managing, setting direction, particularly over the last few years where it feels like, or it's never been harder to orient in technology? It's never as clean in the inside as it looks from the outside. Yeah, I was like, I always joke about, you know, from everybody thinks it's like, Oh, you built Facebook. I was like, trust me, the first few years, like, you didn't want to look behind the curtain. Right, exactly. Just the brute force. Exactly. That we had there. But, you know, again, it comes back to the, you know, people. It's like I don't think of it just as people. I think about all of this as like one system, right? And I think that's where people, technologists, or managers and others kind of get this wrong. And I think with me, I've always straddled this kind of not just, you know, yes, I've done a lot in engineering, but product design, you know, being a CEO, go-to-market, sales. In fact, my first role at Akamai, believe it or not, was to help them out with technical sales because they didn't have anybody. I was like, I'll do that, you know. And, you know, so I was out there like trying to help the team close deals for a while, and then they pulled me into doing biz dev to help us build out the network. And then I went back into engineering and product. But I wore, you know, multiple hats there in terms of like engineer, PM, product marketer, engineering leader, director, VP, et cetera. So I've always thought about it not just as like, Oh, engineering. Like, to me, ultimately you've got to get value to your end users. We all play different roles, you know. At Facebook, I had different roles, and especially running and, like, being the head of all of engineering, I had to think differently about the whole system. So, I mean, maybe building on that, how do you define excellence in engineering leadership? Yeah, so for me, there's like five things maybe that come together. One is you have to build a high-performing team. So that is all about how do you recruit the top people, you know, and then thinking about, like, the composition of the team, right? Because you need to think about how many early career folks do you want, how many specialists do you want, how many generalists do you want, how many senior tech lead type of people do you want, senior ICs, et cetera. Second then is the, in some ways, like setting that strategy, setting that vision, like where is that North Star going? But it's got to be at the right level because if it's too high level, then it's too opaque. People don't know what to do with it. If you're, as an engineering leader, dictating, like, all of the 1,051 OKRs for the team, then the team doesn't think on its own. So you've got to come with the right level of that abstraction of the strategy, the vision, the North Star, kind of maybe the higher-level metrics or goals that you have, whether it be revenue or users or whatever it might be. Then thirdly is that in my world, it's really important to have this cadence, this drumbeat of execution. And people get lost in this, I think, because, you know, you're an executive, you delegate this stuff, but you really have to set the tempo of the organization that you want it to. So for me, For a long time, Brett, I like really focus on this, like week-over-week progress, right? And you can have big bet type of products or projects that may take a year or two to actually materialize, but you need to demonstrate week-over-week progress, right? And that is going to be something that is objective, quantifiable, that you're looking at how you're doing, whether it be doing efficiency work, doing stuff that accrues revenue or grows users or retention, whatever it might be. But that drumbeat has to be just everywhere in the organization where there is this, like, week-over-week, you know, sometimes day-over-day if you are in a really intense period. But that's like number three. Number four is, as an organization scales, as you're running a service for longer and longer, you need to have this, like, moment or this thing in your culture that cares about the toil and about the headwinds that are created and knows how to go and, like, collect that stuff and squish it down or get rid of it, right? Because this stuff, especially now with AI, we're building, we're growing, we're iterating, we're experimenting way faster than we ever have. And if you don't go back and have a culture where you are in some ways, like, fighting allergic, recognizing that this toil can't just infinitely keep accruing or kind of piling up for you, then that just is going to slow you down and all sorts of things spiral. And then the fifth thing is being convicted and also being intentional about building a great culture, right? And I think in some ways. My view on this is even just in recent times, maybe in the last year or two, the airtime that we give as leaders to the importance of, like, building a great culture is totally seems to be, like, minimized or maybe not even cool to talk about these days, right? And I don't mean culture in terms of, like, swag and snacks and, like, a lifestyle job and warm and fuzzies and those types of things. Like, for me, culture is, like, very prescriptive around, like, the ways you work, the values that you have, the behaviors that you want the team to, like, embody because it aligns with the mission and sort of what we're trying to do. And you want this organization, especially now with everything changing every 24 hours on us, you want it to be able to adapt faster and faster, right? Do you think all five of those are equally important? No, it depends on kind of where you are as an organization, right? Because I'd say if you're a new organization, you may have a different balance of those. If you're an older organization, maybe you have a lot more in four, which is that toil, and that's, like, harder to fix because in some ways that toil may come with, and the toil may be at a place where one of the causes—this is an effect, right? I'm talking about the toil being an effect. The cause actually is having built an organization and a leadership that has an ethos of maybe learned helplessness, where, hey, I can't do that, or, hey, we would fix that if we had more people, or I could do this if we could—you know, like, there's a lot of that. There could be a lot of that learned helplessness that then outputs this toil, which just people feel defeated by, right? And you have to change the culture. You have to change potentially some of the incentives around the leaders as well to go tackle this. Sometimes it's not even quantifiable because it's just sort of an amorphous thing that this is hard to do, you know, to get things into production or to go get these, like, security reviews done or to hire people or to whatever it might be. These things are hard, and everybody just feels like, hey, I can't do anything about it, right? And that's a culture that in some ways has just sort of regressed into the mean, right? And, like, you have to change that. That's why the fifth one around building a great culture oftentimes, you know, rate-limits your ability to, like, be great at the other four. Do you think on the fifth one culture, what are the primary input drivers to that? You have the people... How do you think about driving, and maybe a way to sort of frame it is if I'm working on your team 10 years ago at Facebook, and I'm working on your team today at Microsoft, are the cultures of those teams surprisingly similar or stratospherically different? And what is then the input driver to that, and how much of it is you? So I would say the inputs to those things, you captured a bunch of them, right? Because you do have to think about the people that you have, right? It's like hiring the best people you can, whatever competencies you need, and then also developing people as people are growing their career. Maybe they're moving roles, maybe they're fresh out of school and they're trying to grow as an IC or as a manager, whatever it might be. So those two go hand in hand. It's the development of the org. Number two, I think it comes back to, sure, you can have the strategy, you can have a roadmap, you can have all of that really dialed in, but then it's like the execution of that, right? And it's like the ways of working, the execution, the delivery of that. You can start with values, right? You can embody certain values, and lots of companies have great values, customer obsession or like move fast or whatever it might be. Those can not be very deep. Those can be just things that people put on posters on a wall somewhere. But how are those embodied in terms of the behaviors and the minute-by-minute, hour-by-hour, I'd say interactions between people? So when I talk about culture, it's really that, the connection of people to other people in the organization and how they are really driving that execution and more importantly that learning, because you want the organization, because I talk about this concept of a learning loop. So think about a circle, and as an organization gets more people, as it gets more successful, it tends to be that circle, the diameter gets bigger. And you traverse that circle slower, right? And every kind of revolution around the circle is kind of one unit of learning. And that basically you have kind of everything going against you as you get bigger and more successful and more people, because not only does the distance travel for learning something get longer, but you also go slower through it, right? So everything that I think about is like how to fight that expansion and that slowness, right? And how do you continue to, as you get more scale, more people, more success, more products, culturally, how do you fight that, right? So those are going to be things like making sure that you are adjusting, you know, your way of operating, right? So it's like, hey, we used to have these meetings. A year ago, and that worked then. These meetings no longer apply because now they're 40 people, and we got to get back to when the meeting's eight people. And here's ways to communicate. Here's ways to, like, set more prescriptive goals to, you know, talk about DRIs or fast-moving teams. But you've got to keep recursing that into the system. And a lot of people are allergic to process. And I'd say, you know, process is, for process' sake, is terrible. But what is the relevant and right structure so people can do their best work? So there's a lot of ingredients: people, CEO, different values, et cetera. But it's how you put it all together and, like, communicating to the team, how you learn from the mistakes, from the challenges, from the outages, from the churn customers, and really facing those things as a, hey, this is curiosity for us, right? And we can get better by those—sure, by the things that go well. But generally, when you're scaling fast and successful, not everything goes well forever, right? And if you have an organization that's not surprised by the failure and not thrown off by the failure, then I think you really kind of galvanize people, and that culture really starts to help you accelerate. One of the points that you hit on multiple times is sort of the speed piece. Why is, like, the basic laws of company building, as you grow and mature, everything slows down? And what do you actually do about it? So I think there's the things that you want to install and have as you're building an organization from small to big, and then there's the things that, if you are at a larger organization and you are slow and you want to go faster, the things that you ought to do, right? And I think I've been fortunate to have seen kind of many flavors of this kind of push on speed. I'd say also part of this, Brett, is just maybe, like, it's something I believe in and sort of I don't think it's optional. I don't think it's a nice to have. I think it is just part of who I am in terms of— Of, you know, what I think is important from building great products and building great businesses is, like, speed really does matter because I think it's a competitive edge. I think back to that learning loop that I talked about. I think it is all about if I can learn 2x, 5x, 10x faster than my competitors in the fullness of time, I like my chances at that point, right? So for me, I'd say, you know, let's take the, you know, coming into an organization and, like, okay, you're the new head of product or the new head of eng in a team, and you're like, we got to move faster, right? And we're hundreds or thousands of people, and the CEO is like, you know, you got to move faster, right? We got to move faster. I'd say there's, like, a set of data that needs to be collected, and it's what we did when I joined and we created this core AI team, right? Which is, first of all, get both qualitative and quantitative data in terms of what is going on in terms of, like, that pace. What are, in many ways, the detractors? What are the headwinds? So we did a number of things to basically get that in subjective, almost like anecdotes or anecdata around this. And then we also had a bunch of quantitative data in terms of how product folks, builders, engineers were spending their time, and we broke it up into what we call kind of like either you call it productive time or we called it focused time. And that was like, we wanted more and more focused time. And then, you know, what we do with that focused time was like another thing we had to go do, but we wanted to get more of your time spent into focused time. But we could measure this, right? And then we could actually have dashboards. We could have all of the engineering leaders see kind of where their teams were on this focused time. What's the role of people in important roles that are just impatient? In driving speed. And, like, how much of it is just, as you articulated, you care about speed, you care about learning quickly, and you show up, and that's what you care about. It's going to spill over into the people that you work with. And, like, you know, one of your engineering leads talks about some project, and they're like, It's going to ship on September 30th, and you're like, Well, what do we have to do to get to ship on August 15th? And, like, sort of, is that a disproportionate effect, or it's a minority of what's required to increase cadence? It really depends on kind of where the, you know, again, what your business is, where your team's at. I'd say a few things here, which is one is you have to, I think coming into a new team, you have to kind of assess and understand where the team is in terms of their mindset, their thinking, right? Because some part of this is mindset, which is, hey, we have been doing things this way, and, you know, this September 30th date is the normal way of doing things, right? Then you have those, in some ways, the kind of the Socratic method, right? Saying, okay, if we had to ship something on August 20th, you know, what could we ship by then? Like, or walk me through kind of why and everything that goes into the September 30th date. And in some ways, when you're trying to maybe change the culture and trying to get pace, you know, there's probably some good reason why it's September 30th. And if you just say, Get it all done on August 15th. So in some ways, like one, you got to kind of meet the team where they're at, understand where they're at in terms of both mindset, technology. And a lot of this is just what assumptions do they carry into the way they work today, right? Because there may be certain things that you have to just go, like, understand. Then you're trying to say, okay, well, now we got to change the way we're working. So first thing is, I got to share, I got to talk, I got to, like, I got to lead by example here, right? So some part of this is like you got to communicate the culture aspects versus being in the weeds on this one date. You got to shape and talk and storytell almost, right? It also helps bringing the voice of the customer here and having the customer also join you in this speed of learning conversation with your team. The other thing is back to the toil part of it. You know, I think all engineers want to ship great things and deliver value to their end users, right? Like they want to land the impact. So what are all the things that are, in some ways, the things that are slowing them down or unnecessary in this process, or they could be dealt with after the launch, right? So those are the things where you want to go back and just look at all the assumptions that they carry. The third thing to me is it's like a crawl, walk, run in terms of this transition, right? It's like get one release. Maybe you do it a week or two earlier than September 30th. Then the next, you know, the next release, you kind of shave off another couple weeks. The next release, you're at, you know, August 15. The next release, you're shipping every week. The next release, you're shipping every day. In fact, that's kind of what played out when I was at Facebook when I joined. We did, which was like really fast at the time, we used to ship the main core of Facebook once a day. And it was like a Herculean effort that, you know, most of the time went okay, but sometimes it didn't go okay. But that was like really fast, being like, hey, we're shipping software to 300 million people around the world every day. And then we're like, okay, this isn't fast enough. So then we went to three times a day. And then we went, by the time I left, we were doing basically continual deployments, right? And that was like culture, but also a big investment in our own internal kind of central systems to go do this. And so, you know, again, that's like what the, in some ways, the thing you got to hold in balance as an executive leading a Being a product or tech team is that investment in automation and that toil reduction we talked about. What's the period in your multi-decade career where the team you were working with was the fastest you've ever experienced? And what was going on in that moment, or that three months or six months, or the, like, what's the story around it? I think there's multiple examples. I think it just depends on the kind of the part of the system that we were building, right? I mean, we have teams now in Core AI and Microsoft that, you know, that I support, that I work with, that are shipping daily, sometimes multiple times a day. And, you know, some of this stuff is, like, newer products, so they don't have lots of tech debt and whatnot. But these are not big teams. These are super small teams, and they are just really quick in terms of, like, understanding kind of where the customer's at, bringing kind of high taste designs. And, you know, with AI now, we can crank out a lot of things, fix a lot of things very quickly, right? So these are organizations, these are teams that are moving, I think, super fast for our scale and for our type of customers that we serve. You know, in other places, like being able to, whether it be at Facebook or other companies, being able to have these small teams. And for me, it's like, it doesn't make sense to me. Like, large teams don't move fast. It's just, like, not possible to me, right? So it's all about how do you get, if you have a large team, how do you get this broken down into what, you know, I call, we call the work chart, not the org chart. Just get rid of that nonsense around the org chart. Have this thing and emphasize this thing called the work chart. And these are, you know, whatever you want to call them, V-team squads. There's lots of different terms for this. But how do you have that very small team with the right people and a clear DRI or a clear leader that has the context, that has the agency, and you trust that team. To go do what they need to go do. They can check in, they can update. They're guided by their metrics. Another thing for me is, like, escalation is not a bad word in this world, right? It's like I've told teams, I'm like, listen, if you get stuck for more than 24 hours in anything that you're doing, you call me, right? Because I don't want this to be like, oh, we have to talk to our manager, who talks to their manager, who then comes to me two weeks later. So that speed of execution is like, hey, if you don't know or you can't make a decision or there's disagreement, then just, like, get it to somebody who can help us make a decision and move on, right? So it's all about getting the right, again, high talent density, small teams with the context, and then in some ways, like, getting all this stuff out of the way so that they can go do what they need to do. And, like, you have to assess, you have to develop them, give them feedback. Sometimes you put people in that DRI or lead role that are actually just not the right people, and you have to be able to make that call quickly, right? Because sometimes you pick the wrong person or that person is just not cut out for that leadership role. You know, you did a lot of prolific work in building the infrastructure that Facebook was built on top of and the engineering teams. You know, all the tooling and a lot of the magic of what allowed the teams to move so quickly was built on top of the stuff that you were working on. In that case, do you think it's important that those folks that are working on that think that the software engineering team at Facebook is their customer and they need to delight the customer and meet the customer where they are? At Facebook, the infrastructure team was not just the hardware, it was all of the software. And we actually went quite a bit up the stack to the end consumer, right? So a lot of the mobile stack even, in fact, was, like, run by the infrastructure team, right? So we were, and I pushed in our ethos as a culture and the teams that I supported, even if teams were more infra or more product, everybody had to get closer to the customer, right? So you had to understand. Who you're shipping to. And sometimes you're shipping to internal people, and other times you're shipping to something that, like if our part worked and the product piece didn't work, then, like, we still failed. So those teams had to be fused together in sort of a shared fate. I had no tolerance for this, like, hey, just because you're an infra, you don't need to care about, you know, the customer. I had zero tolerance for that. Like, I think it's really important that we understand how this ladders up. Explain why that is. Maybe it will be obvious to people, but it feels like the average company is not that customer obsessed, is not like, I want to meet the needs of this customer. I want to delight them, you know? Like, they're just kind of doing things. I don't disagree with you, and I think this comes back to kind of that vision, that strategy, that mission orientation, but then also that culture. Because if you don't have that curiosity of—and, like, listen, sometimes customers say they want X, but they really meant Y. Sometimes they meant X; they didn't really need X. So, you know, you have to have processing to understand and judgment and intuition, right? And hopefully you get it more right than wrong. Even in, you know, the team at Microsoft, my team, Corey, like one of the things we have just as a cultural thing right now is, like, you know, there is this, like, FDE thing out there, right? And it's— You know, this platform is operating in this S500 company, right? And be curious about that. Watch, you know, join these briefings with these customers, ride along in a customer meeting, watch a, you know, a customer interview, read, like, the feedback, etc. Because I think one, there's two things here, which is one is it actually allows the organization to have purpose. And I think this builds a much more cohesive organization. So if everybody knows kind of how their work ladders up in some way, shape, or form to not only just some numbers and some goals, but how it creates, you know, value, emotion, whatever it is in the customer, then I think it really drives that higher sense of purpose and galvanizes the team. And I think this just builds a more durable organization, right? And great people want to come there. Great people want to stay at that point. Number two as part of this is we adapt faster, right? Because what ends up happening is if you only have, say, you know, the top layer of your organization connected to the customer, there's basically, there's sort of like loose layering here, right? So, like, the top layer can snap to a trend they see in the ecosystem, but because the connection between them and maybe the front-end engineering team and the back-end engineering team and then some infra thing and some ops thing, they're not all kind of wired more closely together, then there's this delay in the organization responding. And I think these delays are, like, really the penalties in terms of your business, in terms of market share, in terms of, you know, success with the customers. I think these penalties are Have you just gotten really, really large today. One of the unique things I think about your career is that you've been at places where, in different chapters, company was on top of the world. There's no better place to work. There's no more brilliant team. To these people have no idea what they're doing. They missed the boat. They're going to be irrelevant. To there's no better place to be. There's no—sometimes it takes three months, sometimes it takes three years. How do you manage a team and talent through all the vibe changes that happen? Either way, like, you're never as good as people say you are. At least you shouldn't feel that way, and you're probably never as bad as, like, what people say externally, right? So to me, you have to modulate some of this. And not that you should ignore it, because I do think that, you know, if you're going to work on something like I've been afforded in my career that is consequential and important in the world, then I welcome the fact that people care and are critical or congratulatory either way, right? So to me, if you're going to work on something that is of meaning in the world and at a very large scale, you're not going to make everybody happy, right? And some part of that is, like, you can't just ignore it, but you have to, like, understand maybe the intent of the feedback versus the actual literal words of things. So that, I think, is one thing where, okay, well, let's—even internally, you know, there were times at Facebook where, you know, there was various things happening and, you know, the company did this and there was, you know, people who disagreed with that thing internally. And in many ways, like, you spending time with these individuals, like trying to get—and really maybe, like, the words that they use to express their concern or their frustration or their disagreement were strong, but actually their intent, if you spent time with them and understood their intent—and many of them were actually trying to, like, help the company, but they were frustrated and the words were maybe masking kind of their intent or the feedback and ideas that could actually help the company. So part of that is, like— Being a really good listener to understand this stuff, right? And, you know, listen, we're all trying to work on this skill. Having a strong narrative that's adjusting with the team is like a nonstop job, right? Again, if you're doing really well and, you know, you can do no wrong and everything is up and to the right, then that doesn't last. That's, you know, there's some bit of luck or some bit of, like, it's good times. But at some point you will hit some challenges, some headwinds, something will happen. When you started building products, you know, it was sort of the dawn of the internet. Then you had mobile, cloud, and AI as sort of maybe the most important technology changes, with many things underneath that. What's sort of interesting about building teams and building technology in the steepest part of the S curve? What's different about that than maybe when you're asymptoting a little bit or things are more legible? I think there's a few things, which is, you know, when I look at, let's say, Akamai or Facebook, when you're in that growth and/or you're kind of in the steep part of the S curve and you're learning really quickly and adapting really quickly and things are changing really quickly on you, spending time, because you get really busy doing all the things, right, like building some technology thing, meeting with customers, et cetera. But that steep part also then requires you, it will expose and you will see kind of where you have holes from a talent perspective, whether do you have the right managers or do you have the right technical, like, expertise in this layer of the stack or this thing. So in some ways, being, I would say, kind of proactive about that. So if I look at what happened when I got to Facebook was, you know, we were just like, wow, a few hundred engineers when I joined, and the stack was arguably pretty simple. And this is right after the initial iPhone was launched, that period? I joined in 2009. And the iPhone was seven and eight. Yes. Honestly, when I joined, Facebook was all web. I mean, everything was facebook.com. There was, you know, I guess there was like five people in the corner of the basement working on our iOS app. You know, nobody really used that, right? So still, mobile really hit us in, I would say, 2000, in the IPO area. So like 11, 12, 13, 14 was kind of that whole mobile wave for us that we were challenged by. But in the beginning there, like the stack, the technology of Facebook was, it was arguably pretty simple. It was pretty big, massive in terms of hundreds of millions of people, but it was arguably pretty simple. That was, we thought about how we're going to keep scaling from 300 million monthly actives to, you know, 500 to 800 to a billion five to 2 billion, et cetera. It did require not just only looking at the technology, but every layer of the stack, we had to think about, do we have people that can go and build or take control of that layer of the stack, right? Like when I got to Facebook, we weren't building our own data centers. We weren't building our own hardware. We weren't laying our own subsea cables and, you know, those types of things. But over the years, as we saw, one, kind of the scale that we needed to operate, two, the price performance points that we needed to operate our business on, the off-the-shelf offerings were not going to keep up with it, right? So we, in many ways, had to go think about the talent hiring over like a very long period of time, right? It's like, okay, every layer of the stack, we need to be able to, in some ways, insource it at the time. That's what required to do it really fast at Facebook, right? But that's not something you react to. You think about proactively, right, in terms of like, we need to become experts in this layer of the stack. And bring them in. Some of these people come from very, very different backgrounds, very different cultures. So onboarding of folks into a company like Facebook or even in our team at Microsoft was something that our teams, me, put a lot of time into, right? And sort of I have always this moniker of, like, go slow to go fast in terms of an onboarding thing. We oftentimes make such a tragic mistake. You go out there and spend all this time and money to hire great people, and then you're like, day one, here, you know, here's like a team of X hundred people, you know, go for it. And then there's all sorts of, like, org rejection and other types of problems that come out. But I have this other view of it, which is like go slow to go fast. And even my onboarding into both Facebook and Microsoft followed this path, right, where for the first month or two, I was mostly in IC. At Microsoft, I spent the first two months, you know, as an IC meeting people, learning all of, like, all of the great cool things that happen at Microsoft, and then, you know, landed on this idea of what now has, like, formed the core of Core AI. But onboarding, I think, is a really big part of how you build a durable organization over time. What else can you say about what's important about running engineering organizations in these sort of steepest part of the S-curves? Again, it's like being close to your customer is really important. And we talk, a lot of people talk about being, you know, customer obsessed or whatnot. And in these moments, like, you have to understand that the customers, where they are in their maturity of adopting these steep S-curve technologies. And not all customers are equal, right? There are customers that, in many ways, what I kind of think about is they're in the past. And they're looking to you to get into the present. And then there's customers that you will work with that are living in the future, and, like, you need to work differently with them to move faster and to get into the future faster. I think it's really important. I think many engineering teams don't understand this, like, spread between kind of where the customers are. And it could be that you just rate it by dollars or something like that, and it's actually not by dollars. And in order to, like, be successful in one of these technology waves or inflections, I'd say the other part of this also is it's really important to think about your leadership bench, right? And for me, one of the other, I think, shifts we're trying to make in Core AI at Microsoft is this balance between more ICs leading things. And what I also saw and what we did at Facebook is when these things like mobile or other things came in that were these steep inflections for us, is, like, having the right balance of IC-led or kind of an IC-prominent culture in product and eng, and not just this, like, manager-heavy, kind of layered, top-down type of approach, right? Because both are kind of needed. There's structure that, like, managers can offer: managing dependencies, people development, performance management, those types of things. But if you want to be able to really, like, accelerate through one of those steep technology inflections, the people who generally know the best about the technology are actually the ICs. So you have to, like, elevate them, you have to, like, protect them, you have to, like, expect more of them, and not have this, like, culture where they defer or they report into managers, because everything just gets slow at that point, right? So you really have to make sure you're pulling the ICs out, holding them accountable. One of the things that I do at Microsoft is I have these brain trusts, and they're in different parts of our stack, and these brain trusts are formulated with, like, six to eight senior ICs, mid-level ICs only. And no managers, right? So we get to talk and learn and push and debate and argue about these inflections that we see in our customers or with the technology. And we have other representations of this as well. So I think that's also really important, is to, like, have in my mind the career tracks are parallel. It's not a promotion to be a manager. These are parallel career tracks. When you think about what's happened in AI in the past few years, in what way does it remind you of things of the past? And what is, like, wholesale net new, and that either you overly pattern match to the past or it's, like, so abundantly clear to you that nothing in the past is useful in trying to model and understand what it means to, like, either where we go or what it means to win or how do we position ourselves or sort of those types of things. I would say a few things here, which is, like, first of all, I think there's, like, good arguments to say, like, nothing's the same and everything is different, right? Because we're not typing code, and writing code is not the long pole in the tent anymore. And code is an output now. It's not an input. And the half-life of the, as I will talk about the typical software development life cycle or the product development life cycle, the half-life of that is dramatically shorter if you are kind of an AI-first organization. So what does that mean in terms of how you think about everything, not just, like, building a feature, building some code, and you think about how you get that, you know, into sales and marketing and pricing and packaging into your partner ecosystem? Like, that's all still a lot of humans, right? And so you can generate a lot of cool things, and nobody ever sees them or pays you for it, right? And these are, like, I think, very hard unsolved kind of problems right now. When you're in an environment right now where enabling technology is changing so quickly. Even for the people at the cutting edge, it's often hard to forecast. How does that impact the way that you think about, like, the technical vision that you're outlining for a team? And does it change the time horizon? Like, you're much less willing to make a big multi-year bet when things are so unstable. Does it change the way, the rate at which you'll change your mind when technology changes? Does it make you more risk-seeking or less risk-seeking? What are your sort of reflections on sort of that set of questions around, like, technical direction and the bets that we're going to make at the technology or product level when so much is changing? Yeah, I would say, first of all, I think it is hard these days to take a bet that is multi-year at this point. Maybe not on the, I would say, atoms-level infrastructure, because those do still take a while. But if it's in, you know, in product, in software, because I don't know that it needs to take that long anymore, right? Because of the power of the tools that we have accessible. So the thing that may have taken, you know, in my career, a software team a year to write, well, I actually think we can get something pretty good in a month, maybe, you know, at least as a prototype. It maybe is not production-ready, but we can put some load on it. We can't see this thing, right? So that I think is just like, hey, maybe I had n number of people locked up doing this quote-unquote big bet for 12 months to see something, and maybe we would have seen two or three milestones. Now I can durably see that same thing get done in two months with, you know, every two-week or every three-week or like kind of monthly snapshots or milestones here. So now I'm being optimistic here in the fullness of time. Instead of taking one bet with this team for 12 months, now I can take— Building a great team. You want to have more short-term bets. They're long-term, but I can get them done short-term. What would have been long-term, but they instantiate themselves as shorter-term bets. Correct, correct. I would say, like, the— What's a good example of it? Well, and for me, it's like, you got to remember, like, a bet to me is not something that gains me like 10 or 20 or 30 percent kind of improvement, right? This is something that you do see the step function, right? There's some discontinuous kind of impact to the business, right? And there are places where, like, in the past, you know, at Facebook, we used to have a whole set of projects and that we and I would curate and sort of track and work with the team that was like our big bets list. And these, in that time, were like multi-year bets, right? And these things, there's like really strong characteristics of what I think is a big bet, right? Which is, one is they have to bring that discontinuous impact to the business. Number two is, generally speaking, they should be cross-functional in nature, because if it's just a single team with some discontinuous thing, they may be seeking a local maxima, but you may be closing off a global maxima. So I push to have these big bets span multiple teams, seeking some new global maxima for the organization, versus each team kind of like trying to max out what they're constrained to be able to do, because I don't know that it's enough. So a lot of our big bets at Facebook and our team were three, four, five teams that had to come together to get that discontinuous impact, and all teams had to come together to try to achieve that some new global maxima, versus five teams all trying to get a little bit, right? So, and then the other thing too is, you know, you want to be able to have some measurable kind of—you don't want this to just kind of go into a hole for three years and then come out with something you don't need. So the burden is on the team to kind of make sure they're gaining context. If something's zigging in the market or internally and they're zagging, they need to— Go and adjust and pivot. I also think that many big bets, it's okay for them to fail. Like, I don't think and prescribe that all of these should work. So, you know, some of them should fail. Oftentimes when we saw these things fail at Facebook, the derivative that they landed somewhere else, right? And the learning or some part of it ended up accruing to something else we did. So there was always goodness and learning that came out of it. But if I, you know, had five big bets and two of them really took off, then that was success. And if one was kind of meh and the other two failed, like that was like a decent batting average. A batting average. And then you've also created a culture where people know that as a leader, I am willing to and I want to take risks, right? And so that does, I think, drive a certain level of passion and energy and curiosity and learning in an organization. Because you have to fight, as we talked about earlier, as the organization gets bigger, you get more successful, this reversion to the mean happens, right? And like you get complacent. That complacency breeds mediocrity, and then people don't want to take risks, and we know the rest. So having a culture of taking these, like, big bets and these discontinuous or disruptive projects and curating them and sort of protecting them, I think is really important to try to be ready for what's coming at us next. And so in the Facebook days, what are, like, the canonical examples of what was a big bet at the time? I mean, it was at every layer of the stack, right? I mean, it was when we were, you know, we didn't build hardware, and that was like a big bet to go build hardware. We started in some ways simple with one type of server, and then we took a big bet to get all of the other pieces of kind of the typical SKUs for storage and database and networking, and all of those done in a very, very short period of time. There was other bets in terms of, like, how we handled different storage systems, and those were things that would give us that proverbial, like, 10x improvement either in cost or performance or scale. There was other things that we did from a product perspective, working with, you know, the videos team or working with the messaging team, and these were like disruptive bets to bring a new product experience, but it required kind of changing a lot of layers of the whole stack, right, together, not independently. And so those were things that, you know, they would take a year maybe or more to do that. And some of these then just, you know, these became things that we cannot fail at some point, right? And we had to really, really make sure those worked. There was other places where we, you know, we took multiple bets in the same area and kind of had these run parallel to see which one would be best. Sometimes we ended up blending some of these. Other times there was a clear, like, this option worked better than. But when I didn't know, I would try to take multiple parallel bets. I feel like that's underappreciated. Like if there's a 50% chance X works and another 50% chance Y works, maybe you should just do both. And I just, it's okay to say I can't forecast that accurately. We spend, I think, having been in lots of different teams, spend an inordinate amount of time arguing A or B. You know, it's kind of a funny thing that my team will say about me because when they bring those things to me, I'm like, we'll just do both. They're like, well, that sounds way harder. I'm like, well, neither one of you, we don't know, so let's just do both. We can talk in a month or two months and see where we're at, and maybe we don't need to do both then, or maybe something else emerges. But why not, in some ways, keep the option value open at this point? Keep learning. Again, back to this, like, learning point. It's like if I can do both and learn faster versus do one, fail at it, and then do something else after that, and that takes me four months to figure that out versus doing two in parallel and I learn in two months what I would have done in four, that is like a trade I'll make all day long. Why did it often make sense to vertically integrate? And is there sort of a pattern to this that it feels like, you know, the benefit of specialization is that you have a whole group of people trying to make this widget better and better for you. And a thousand other customers or 10,000 customers, and you have economies of scale, and you have all these people going to work every day to make, like, this little widget for you better. But it feels like in so many cases, at least in the case of Facebook and many other extraordinary companies, over time, you become more and more vertically integrated, and it's the correct thing for the company. And so instead of leveraging AWS, you build your own and optimize your own data centers. Why is that so often the correct thing to do? I think it's a matter of scale. And, you know, when I joined Facebook, AWS and the public cloud was fairly nascent at that point, so I don't think it was a real option at that point. Unclear what the counterfactual would look like today if that were happening today in the age of massive hyperscalers. I would say there's a few things here which I believed in terms of my time at Facebook and even, you know, or my time at Akamai was one is the vertical integration. It's the most optimal, and it's the most optimal when you look at the overall kind of efficiency of the stack. So you think about just top to bottom, if you are, you know, having to buy a lot of different things from different people, you can think about, you know, all the different places where you're giving other people margin, so to speak. So from a dollar perspective, there is an argument or like a calculation that needs to be made there. And, you know, in the beginning that maybe is Have to look at that. That's number one. Number two is back to there's a speed. There's a control your own destiny argument that I, you know, always felt, right? Because when you take some layer of your kind of core stack and it's, like, outsourced to this vendor, and vendor, you know, could be great. But when I was at these companies that were, you know, kind of N of one in terms of what they were doing scale-wise, they weren't making a product for us. They were making a product for the normal customer. So we were always on, like, the bleeding edge of their capabilities, their ability to service our needs, to regression test, to QA things for our kind of scale, our operations. So we were always kind of on the, not in an optimal place of their yield curve, right? And so that was another thing where it would slow us down, right? Because, like, you would be waiting on them to do something, you would have bugs, et cetera, et cetera. Those things would all slow us down. And so, and then the third thing is, like, when we would reimagine or come up with a new product experience, right? So when we started thinking about live video or video or something in messaging or whatever it be, that did actually require a lot of changes throughout the whole stack, right? So it was like, hey, here's what needs to happen in mobile. Here's what needs to happen in the edge network. Here's what happens in this app server. Here's what happens in storage. Here's what happens here. And if that was not all vertically integrated, that stack doesn't change. It would take too long to change that, right? So we could reimagine and launch an entire new experience to tens, hundreds of millions of people, billions of people, in a shockingly short amount of time because it was all vertically integrated. And everybody that, like, built that was, like, employees, engineers on our team. So you could just say, this is what we're doing, you know, two weeks, three weeks, one month, two months, whatever, and the whole thing is done. And it's built together, and it's customized for the experience that we want, we want it to deliver. So I'd say it's cost. It's also kind of just controlling your own destiny. And three, it's like speed. How did it change you as an engineering leader again? Like, if you had not had that experience of being a CEO, in what ways are you, you know, would you be different? The things were lots of learnings, right? I mean, just it's a long list as I was reflecting as I was moving from that company and then after a couple months ended up at Microsoft. But where I feel the learning has really propelled is a lot deeper understanding of the mechanics of, you know, go-to-market, of sales, of sales terminology, of, like, sales metrics, all of the machinery around a great operating sales team, which, you know, I get to learn a tremendous amount at Microsoft with our go-to-market team. Now I understand that stuff very at a much more intuitive level, right? It's not foreign to me. So that was like a deeper appreciation being a CEO, where you had to put all of that together, understanding the go-to-market and how that evolves. You know, we were down market in our offering, and we had to move up market into the enterprise. That was a changing of the system. It was a changing of the product. It was a changing of pricing and packaging. It was a changing of our pitch. It was a changing of the sales team, how we manage support, the ecosystem of partners that we had. So, you know, going through that journey afforded all of us, but me, like a ton of learning. And that carries over to being way more, like I would say, in tune with what needs to happen or what we're doing at Microsoft. When you think about your role as an engineering leader today, what is the six months or a year of your career you did the most learning, transformation, growth into who you are right now? And let's remove sort of this last chapter of Microsoft, and you look back at the previous couple decades. What's like the period that comes to mind, and maybe you could tell a little bit about the story of, like, what you figured out, how you evolved, why it sort of was so formative in terms of who you are today as an engineering leader. Yeah, I would say, and, you know, maybe right up front is whether it be, you know, being maybe just a glutton for punishment or not, I always seem to go running after hard, like hard problems, right? It's just something where when it's, I'm sort of addicted to it or I'm just like I fall into it, I don't know. So for me, and I talk about this in these S-curves, right? So for me, it's like maximizing my professional time and being on that steep part of the S-curve is what I always think about, right? And when I feel like it's starting to curve or arc bend over, like flatten, then I'm always trying to find, like, the next thing, right? Many a times that's been afforded in the same company, and other times it's required a change, right? Because I don't want to waste and spend my time on any part of that flat curve for me. So maximizing kind of that time spent on the steep part of the S-curve is something that I think about and I, like, am really, like, intently focused on, right? So that is, you know, and some of these are like, you know, all different chapters in my career. But to give you a specific example where I think I would say I grew up a lot as a leader was the first probably four or five years when I was at Akamai, right? Because I joined and there was maybe a few dozen people when I joined the company. And, you know, this was a company that was one of the, like, I guess, you know, we didn't have the term unicorn back then, but it was like, you know, one of the unicorn companies, right? And it was this buzz, there was this meme, there was this energy about this company that had all of these, you know, PhDs cracking this code with these sophisticated algorithms to scale massive traffic explosion on the internet. So I joined as an IC, did a bunch of roles, as I said earlier, which is like I joined in sales because they—did I know anything about being a technical sales engineer? No, but they needed somebody to help translate the technology and what we were building to our customers, to our prospects. And I did a number of different roles in biz dev and back into PM and product marketing, back in engineering. But, you know, that journey in the first few years was like, hey, we had this kind of rocket company that, you know, had at that time when we went public, was the fourth largest or biggest IPO ever in tech, right? So it was like lots of buzz about this company. But in many ways, if you look at this, was like the dot-com boom when everything was—you kind of look at these valuations and stuff like that and scratch your head. And then, you know, we went through obviously the phase where the dot-com bust crash happened. So that company, Akamai at the time, had to go through a lot of changes, right? So many things happened. One is we endured multiple rounds of downsizing of the company, right? And, you know, that was like—I had never been through that before in terms of how do you manage layoffs and how do you communicate to your team. Here I am a line manager, right? Like, how do we communicate this to our team and friends, colleagues of ours are here yesterday, they're no longer here today. Then in— In the company, and got to work with him closely. This was, you know, losing him was like, it was sort of unexplainable in terms of what it did to shift the way we all thought about kind of the mission of the company, what we had to go do. But, you know, like having Danny, you know, one day, not having Danny the next day, it was hard, right, in terms of like, how do you lead through that? How do you adjust? How do you adapt? How do you communicate to people? And back to, you know, just like being real about it, being transparent. And this is like stuff, nobody trains you on this stuff, right? Like when you come in out of school, you end up, you know, in a job like this, and you have this like, oh my God, you can do no wrong, you know? And everybody's like buying your stuff, and your stock price goes up and up and up and up and up, and then something happens in the world, and all of a sudden you're on the other side of this hill, right? And not having been through that before, there's just countless, like, learnings every day in terms of like the one-on-one interactions I'm having, the team meetings, I'm watching, you know, the other execs lead, you know, the CEO and George and Paul and Tom lead through this and learning and like observing them, right? Because here I am as a first-time manager learning from them. So I grew up a lot in terms of that, this and this, and, you know, still managing to survive in the company's, you know, still an important infrastructure company in the world today, and having been a part of that journey and helping the company make all these adjustments and, you know, hopefully we got it mostly right, but we made a lot of mistakes too. So I would say that was a very I'd say dense, condensed period of learning in terms of just growing up. Was there like a big thing, like one big idea you took from that, or was the hundreds of little things that you had to figure out? It was a lot of, I mean, you know, I would say that obviously 9/11 was, I'd just say it's sort of a very stark kind of memory in terms of like being an employee, but also then being a leader in the company and what you had to do. And like, again, we weren't prepared for this, right? And it was like, how do you work with each other and the leadership team to figure this out and take it kind of, you know, hour by hour in terms of what we're learning and how we communicate this stuff and how we're there for the employee base, for customers and stuff like that. Because the business was changing, right? And it wasn't kind of an overnight thing, but, you know, you're doing these reductions and then you're building and then you're having to shift your business because a lot of our business in the beginning was all dot-com companies. And now you're like, oh wait, we don't have a product, we don't have a sales team, we don't have pricing and packaging, we don't know how to like sell to the enterprise. Like we had no right to talk to them, you know? And like, wait, you don't have a product, you don't have a sales team, you don't have pricing and packaging, you don't have a partner ecosystem, you don't have solutions, you don't have support that can service, you know, the Global 2000. And we had to hustle, right, in figuring that out. So how we did that, the intensity, the teamwork, the culture that had to, in some ways, be evolved to do that in whatever it was, probably around two, three years or so. And then also just we had to go and get our finances, our, you know, P&L under order because like we were losing a lot of money, like we were burning a ton of money. So we had to go build product and grow the top line, but we also had to, you know, do a ton of efficiency work. And so, you know, that efficiency work came at potentially at the expense of innovation, but that was survival to us, right? So yeah. And so, you know, for example, when I went to Facebook, even though Facebook was like doing great top line, you know, I remember talking to Mark and Mark was like, we have money, so we should just build features and we should put all the engineers working on product. And I said, Cool, but I'm going to work on efficiency because I'm not going to go through that journey that we all went through at Akamai. And so we're going to be efficient, and we're going to build a great product. But we're not going to do just product and ignore efficiency. So we're going to be really diligent. We're going to build kind of great data systems and a great culture of engineers doing very significant efficiency work, and that led to, you know, this vertical integration, but also big bets in terms of efficiency and a very data-driven approach around, like, saving and being frugal with how we consume the CapEx that we spent, right, and being really, really diligent about that efficiency. But that afforded us lots of capital allocation options down the road, right, because we weren't wasteful from, you know, the early, early days. We didn't have to fix it later. We, like, inceptionized that culture early because I was not going to have the nightmare that we lived through at, you know, as we grew up as leaders at Akamai. Nice place to end. Thank you so much for spending the time. Thank you, Brett. Pleasure.