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

0:04I think you have such an interesting, given your set of experiences, likely have an interesting point of view on building teams and 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 it's like one hat and there are many hats but let's say one hat is 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 a curtain right it's 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.

1:15I think about all of this as like one system, right? And I think that's where people, technologists, our 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.

1:55And 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, and 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?

2:27Yeah, 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, do you want, 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, etc. etc. 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.

3:06People don't know what to do with it. If you're, as an engineering leader, dictating like all of the 1051 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 division or 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.

3:49So for me, for a long time, Brett, I like really focus on this like week over week progress, right? And you can have big, that 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're in a really intense period.

4:28But 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 it 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.

5:15And 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.

6:01And 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?

6:40I'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.

7:29These things are hard and everybody just feels like, hey, it's not, 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 at the company, you have the CEO and or founder, depending on the stage of the company. you have the functional lead, GM, line level lead, manager.

8:07There's probably a few other variables, but like, how do you think about driving and maybe a way to sort of frame it as 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 out of, you know, fresh out of school and they're trying to grow as an IC or as a manager, whatever it might be.

8:55So 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, 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.

9:38So when I talk about culture, it's really that, you know, 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, you know, 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.

10:19because 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.

10:59And 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, processes for process sakes 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, CO, 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?

11:43And 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.

12:25And 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 want 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 bread 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, 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.

13:03I 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 on the CEOs, like, you know, you got to move faster, right? We going to move faster. I'd say there's like a set of data that needs to be collected.

13:38And it's what we did when I joined and we created this CoreEI 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 and 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 focus time.

14:16And that was like, we wanted more and more focused time. And then what we do with that focus time was like another thing we had to go do, but we wanted to get more of your time spent into focus 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 focus 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 and you care about learning quickly and you show up and that's what you care about it's going to be spill over into the people that you work with and like you know one event 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.

15:21I'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.

15:58And 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, you might get it done once or twice with that type of edict. it is not generally going to be a durable like behavior or like a culture that it gets stronger over time 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 understand.

16:39Then 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 lead by example here, right? So some part of this is 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 in 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?

17:20Like they want to land the impact. So what are all the things that are in some ways, the things that are slowing them down are 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 this transition right it's like get one release maybe you do it a week or two earlier than september 30th then the next week 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 your shipping every day.

18:03In fact, that's kind of what played out when I was at Facebook, when I joined, we did just 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. And, 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 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 and balance as an executive leading a product or tech team is that investment in automation and that toil reduction we talked about.

18:58What'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're 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 a newer product, so they don't have lots of tech debt and whatnot.

19:38But 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.

20:18Like, 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 I 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, 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 clear leader that has the context, that has the agency, and you trust that team to go do what they need to go do?

21:01They 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 it's 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?

21:33so 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 their way so that they can go through 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.

22:16In 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 consumed right so the 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?

22:54So 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 and sort of a shared fate. I had no tolerance for this, like, hey, just because you're in infra, you don't need to care about, you know, the customer. I had zero talents 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.

23:35I 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, 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, I 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?

24:19And it's like, I'm like, everybody on the team, you have to be an FDE. Not literally, but you have to have that mindset, right? You have to connect what you're working with in terms of how somebody's using that thing or building that thing. Or, 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.

24:57And 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 that just builds a more durable organization, right? And great people want to come there, great people want to stay at that point. Number two is 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 it 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.

26:04And 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 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 miss 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?

27:01So 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.

27:44So 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 used to express their concern or their frustration or their disagreement were strong, but actually their intent, if you spend 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 to the feedback and ideas that could actually help the company.

28:30So part of that is like being a really good listener to understand this stuff, right? And, you know, 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 can do no wrong and everything is up and to the right, then that doesn't last. 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, 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.

29:21What'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, and 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 etc 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 uh 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 and this is right after the initial iphone was launched this is i joined in 2009 and iphone was seven and eight yes honestly when i joined Facebook was all web.

30:45I 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. Now, as 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.

31:34Do 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 to 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?

32:12It'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 where we need to build this part of the technology in such a way to give us this scale or this price performance or this security or whatever it might be. And then how do you go find those people and bring them in? Some of these people come from very, very different backgrounds, very different cultures.

32:48So onboarding of folks into a company like Facebook or even in our team at Microsoft was something that our teams meet 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 they want 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 organ 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.

33:29And even my onboarding into both Facebook and Microsoft followed this path, right? Where for the first month or two, I was mostly an 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?

34:09Again, 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 S, these T-Best 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.

34:48I 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 deep 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 tops down type of approach.

35:53right? 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.

36:36One 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, that 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?

37:19And 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 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.

37:58It's not an input. And the half-life of the, as I will talk about the typical software development lifecycle or the product development lifecycle, 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 or 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 And nobody ever sees them or pays you for it, right?

38:33And these are, I think, very hard, unsolved 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 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 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?

39:27Yeah, 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, Adams-level infrastructure, because those do still take a while. But if it's 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.

40:10We can't see this thing, right? So that I think is just like, hey, maybe I had a 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, you know, four bets, five bets in the same period of time in that year with the same number of people.

40:46So for me, the shots on goal go up, right? And I think that's super great for 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 with 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 % kind of improvements, right? This is something that you do see the step function, right? There's some discontinuous kind of impact to the business, right?

41:22And 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 a 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.

42:09So 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. 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.

42:59So 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 in 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.

43:36But 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, that was like a decent 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 that 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.

44:19So having a culture of taking these like big bads 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 a kind of the typical SKUs for storage and database and networking and all of those done in a very, very short period of time.

45:03There 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 to do that and some of these then just you know these are became things that we cannot fail at some point right and we had to really really make sure those were 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 better than but when i didn't know, I would try to take multiple parallel bets.

46:07I 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.

46:42And 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, then 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.

47:30But 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 And Facebook, AWS, 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.

48:10I would say there's a few things here which I believed in terms of my time at Facebook or my time at Akamai. 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 tops 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 unobtainable because you don't have the people, you don't have the capital to do it.

48:55So you have to pay to do this. But as you get bigger and bigger and bigger, then this isn't a trivial amount, right? And so you 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 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.

49:33So 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 a 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 etc etc 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?

50:25So 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 an entire and watch 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.

50:59So 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 wanted 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.

51:38And then after a couple of months, ended up at Microsoft. But where I feel the learning has really propelled is a lot deeper understanding of the mechanics of go-to-market, of sales, of sales terminology, of sales metrics, all of the machinery around a great operating sales team, which I get to learn a tremendous amount at Microsoft with our go-to-market team. Now I understand that stuff 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.

52:21you 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 managed support the ecosystem of partners that we had so you know going through that journey afforded all 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?

53:08And let's remove sort of this last chapter of Microsoft and you look back at the previous couple decades. kids, 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.

53:49I 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, And when I feel like it's starting to curve or arc, bend over, flatten, then I'm always trying to find the next thing. Many a times that's been afforded in the same company and other times it's required to change 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 I'm really like intently focused on.

54:35Right. 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 is 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? There 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.

55:29so 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're building to our customers to our prospects and I did a number of different roles and biz dev and back into PM and product marketing back into 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?

56:09So it was like lots of buzz about this company. But in many ways, if you look at this was like the dot-com boom, 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'd never been through that before in terms of how do you manage layoffs and how do you communicate to your team?

56:51Here I am a line manager, right? Like, how do we communicate this to our team and friends, colleagues above are here yesterday. They're no longer here today. Then in 9-11, Danny, our founder, co-founder, passed away in 9-11. And, you know, Danny was a force of nature for us. It was like people that were early 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.

57:49And this is like stuff where 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, 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?

58:33Because 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 and the companies, He'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 more 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?

59:11I mean, you know, I would say that obviously 9-11 was, I 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're 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.

59:47But 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.

1:00:19And we had to hustle, right, in figuring that out. So how we did that, the intensity, the team work, 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 P &L under order because we were losing a lot of money. 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.

1:01:13And 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, this vertical integration, but also big bets in terms of efficiency and a very data-driven approach around saving and being frugal with how we consume the capex that we spent, right?

1:01:51And 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 the early, early days. We didn't have to fix it later. We inceptionized that culture early because I was not going to have the nightmare that we lived through as we grew up as leaders at Akamai. Nice place to end. Thank you so much for spending the time. Thank you, Brett. Pleasure.