The most expensive mistake in outsourcing your tech stack | Jay Parikh (EVP CoreAI, Microsoft)

Brett Berson 0:05 I 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, um, the role as there's the people and direction you're setting is like one hat, and th-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.

Brett Berson 0:36 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?

Jay Parikh 0:58 It's never as clean in the inside as it looks from the outside, you know? 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 wanna look behind the curtain" [chuckles]

Brett Berson 1:10 Right, right. Exactly.

Jay Parikh 1:10 "In terms of just the brute force-

Brett Berson 1:12 Exactly

Jay Parikh 1:12 ... 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, uh, one system, right? And I think that's where people, technologists, uh, where managers and others kinda 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, "Oh, 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, um, 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, um, I've always thought about it not just as like, oh, engineering. Like, to me, ultimately, you've gotta get value to your end users.

Jay Parikh 2:21 We all play different roles, you know, at, in Facebook, I had different roles, and especially running and, like, being the head of all of engineering, um, I had to think differently about the whole system.

Brett Berson 2:31 So I mean, maybe building on that, how do you define excellence in engineering leadership?

Jay Parikh 2:36 Yeah, so for me, there's like five things maybe that come together. One is, you know, you, 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, 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 gotta 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 gotta 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, uh, 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've, like, really focused 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 gonna 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. 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, m-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 gonna slow you down, and all sorts of things spiral. And then the fifth thing is, is, like, 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, w-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?

Brett Berson 6:27 Do you think all five of those are equally important?

Jay Parikh 6:30 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 l- 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 the, 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 a, 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, it's not... I can't do anything about it," right?

Jay Parikh 7:51 And that's a culture that in some ways has just sort of regressed into the, 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.

Brett Berson 8:06 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, and manager. There's probably a few other variables, but, like, how do you think about driving it? 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, 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?

Jay Parikh 8:49 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, you know, the, 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 s- you know, 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, you know, 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, you know, minute-by-minute, hour-by-hour, I'd say, interactions between people. So 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, as 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 that di- 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, 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 gonna 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 gotta 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, processes for process sakes is terrible, but what is the relevant and right structure so people can do their, their, their, like, 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,

Jay Parikh 12:05 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.

Brett Berson 12:28 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?

Jay Parikh 12:42 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 wanna go faster, the, the things that you, 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, uh, 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, 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 two X, five X, 10X faster than my competitors in the fullness of time, I li- 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, in a team, and you're like, "We gotta move faster," right? And we're hundreds or thousands of people, and the CEO's like, "You know, you gotta move faster," right? "We gotta 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 CoreAI team, right? Which is, first of all, get, uh, 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 w- 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 productive time or we called it focus time, and that was like we wanted more and more focus time. And then com-- you know, 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.

Brett Berson 15:05 What's the role of, uh, 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 gonna be spill over into the people that you work with and like, you know, one of eng- your engineering leads talks about some project, and they're like, "It's gonna ship on September thirtieth," and you're like, "Well, what do we have to do to get to ship on August fifteenth?" And like sort of is that a disproportionate effect, or it's a minority of what's required to increase cadence?

Jay Parikh 15:44 It really depends on kind of where the, you know, again, what your business is, where your, 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 do-- we have been doing things this way, and, you know, this September thirtieth 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 twentieth, you know, what could we ship by then?" Like, or, "Walk me through kind of why and everything that goes into the September thirtieth 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 thirtieth, and if you just say, "Get it all done on August fifteenth," you might get it done once or twice with that type of edict. It is not generally gonna be a durable, like behavior or like a culture that it gets stronger over time. So in some ways, like one, you gotta 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're, you have to just go, like understand. Then you're trying to say, "Okay, well now we gotta change the way we're working." So first thing is I gotta share, I gotta talk, I gotta like, I gotta lead by example here, right? So some part of this is like you gotta communicate the culture aspects versus being in the weeds on this one date. You gotta shape and talk and story tell almost, right? It also helps bringing the voice of the customer in here, you know, and, and having the, 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 th- that are slowing them down or unnecessary in this, in this process, or they could be dealt with after, uh, the launch, right? So those are the things where you wanna 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 thirtieth. Then the next week, you know, the next release, you kinda 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 kinda what played out when I was at, 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, and... But that was, like, really fast, being like, "Hey, we're shipping software to 300 million people around the world

Jay Parikh 18:57 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 gotta hold in balance as an executive leading a product or tech team is that investment in automation and that toil reduction we talked about.

Brett Berson 19:29 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?

Jay Parikh 19:48 I think there's multiple examples. I think it just depends on the, kind of the part of the system that we were, we were building, right? I mean, we have teams now in CoreAI and, and, 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. But these are not big teams. These are super small teams, and they are just really quick in terms of, like, understanding kinda where the customer's at, bringing kind of high-taste designs. And, you know, with AI now, w- we can crank out a lot of things, fix a lot of things very quickly, right? So this is, uh, 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... And, and whether it be at, you know, uh, Facebook or other companies, being able to have these small teams. And, and for me, it's like, it doesn't make sense to me. Like, large teams don't ma- 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 wanna call them, B team, squads. Like, 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 these, 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, well, we have to talk to our manager, who talks to their manager, who then comes to me two weeks later. So it's, 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? 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 their way so that they can go do what they, they need to do. And, like, you have to, 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? Um, because sometimes you pick the wrong person, or that person's just not cut out for that leadership role.

Brett Berson 22:42 You know, you did a lot of prolific

Brett Berson 22:44 work in, 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, at Facebook is their customer, and they need to delight the customer and meet the customer where they are?

Jay Parikh 23:06 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 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 in 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 were shipping to, and sometimes you were shipping to internal people, and other times you were 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 a 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, the customer." I had zero tolerance for that. Like, I think it's really important that we understand how this ladders up.

Brett Berson 24:05 Explain why that is. Maybe it'll be obvious to people, but it feels like the average company is not that customer obsessed, is not like, "I wanna meet the needs of this customer. I wanna delight them." You know? Like, they're just kind of doing things.

Jay Parikh 24:20 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 y-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, uh, just as a cultural thing right now is like, you know, there is this like FDE thing out there, right? And 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 S five hundred company, right? And be curious about that. Get-- 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, et cetera. Because I think one, it-- 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 dur- a more durable organization, right? And great people wanna come there, great people wanna 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,

Jay Parikh 26:20 there's basically, um, there's sort of like loose layering here, right? So like y- the top layer can, uh, can snap to a trend they see in the ecosystem. But because the connection between them and maybe the front-end engineering team and then the back-end engineering team and then some infra thing and some ops thing, th-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, 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.

Brett Berson 27:01 And 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 gonna 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?

Jay Parikh 27:37 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 gonna 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 gonna work on something that is of meaning in the world and at a very large scale, you're not gonna 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 under- 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 spent time with them and understood their intent, and many of them were actually trying to like help the company,

Jay Parikh 29:07 but they were frustrated, and the words were maybe masking kind of their intent of 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, I, I-- we're all trying to work on this skill. Having a, a, 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's 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.

Brett Berson 29:53 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, 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, um, more legible?

Jay Parikh 30:25 I think there's a few things which is, you know, and when I look at, let's say Akamai or, 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 the, 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, the, 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, 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, pretty simple.

Brett Berson 31:23 And this is right after the initial iPhone was launched, that period?

Jay Parikh 31:27 This is... I joined in 2009.

Brett Berson 31:28 Right. iPhone was seven and eight.

Jay Parikh 31:30 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, you know, it 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 gonna keep scaling from 300 million monthly actives to, you know, 500 to 800 to a billion five to two 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 gonna keep up with it, right? So we, in many ways, had to go think about the talent hiring over a v- 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, at, 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, or 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. 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, and sort of I have always this moniker of like go slow to go fast in terms of an onboarding thing.

Jay Parikh 33:58 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, like, you know, go for it. And then there's all sorts of like, you know, 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. And 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 CoreAI. But onboarding, I think, is a, a really big part of how you build a durable organization over, over time.

Brett Berson 34:56 What else can you say about what's important about running engineering organizations in these sort of steepest part of the S-curves?

Jay Parikh 35:03 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, uh, where they are in their maturity of adopting these S, 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 CoreAI 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 tops-down type of approach, right? Because both are kind of needed. There's structure that, like, managers can, 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 deep 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, 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

Jay Parikh 37:41 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, 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, are parallel. It's not a promotion to be a manager. These are parallel career tracks.

Brett Berson 38:09 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?

Jay Parikh 38:35 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, is, is different, right? Because, you know, we're not, like, typing code and writing code is not the long pole in the tent anymore, and code is the, 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 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 nobody ever sees them or pays you for it, right? And these are like, I think, very hard unsolved kind of problems right now.

Brett Berson 39:37 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? Like, what, what, what are your sort of reflections on sort of that set of questions around, like, technical direction and the bets that we're gonna make at the technology or product level when so much is changing?

Jay Parikh 40:30 Yeah, I would say, first of all, I, 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, 'cause those do still take a while. But if it's in, you know, in, 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, a prototype. It maybe is not production ready, but we can put some load on it. We can 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've 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 kinda monthly

Jay Parikh 41:35 snapshots or milestones here. So now in the... 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. So for me, the shots on goal go up, right? Um, and I think that's super, I think that's super great for building a great team.

Brett Berson 41:58 You wanna have more short-term bets.

Jay Parikh 42:01 They're long term, but I can get them done short term.

Brett Berson 42:03 Right. What would have been long term.

Jay Parikh 42:05 Yeah.

Brett Berson 42:05 But they instantiate themselves as shorter term bets.

Jay Parikh 42:07 Correct. Correct. Uh, I would say, like, the-

Brett Berson 42:11 What's a good example of it?

Jay Parikh 42:12 Well, and for me, it's like, you gotta remember, like, a bet to me is not something that gains me like ten 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, you know, impact to the business, right? And there are places where, like in the past, you know, at, at, 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. 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, you know, what they're constrained to be able to, 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, or 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 wanna be able to have some measurable kind of pro-- You don't want this to just kind of-

Brett Berson 44:02 Go into a hole for three years

Jay Parikh 44:03 ... go in a hole for three years and then come out with something you don't need. So the burden is on the team to kinda make sure they're gaining context. If something's zigging in the market or internally and they're zagging, they need to go and, 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, that 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 kinda meh and the other two failed, like that was like a decent-

Brett Berson 44:52 Mm-hmm. Batting average

Jay Parikh 44:54 ... batting average. And then you've also created a culture where people know that as a leader, I am willing to,

Jay Parikh 45:01 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 f- we know the, 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, to try to be ready for what's coming at us next.

Brett Berson 45:42 And so in the, in the Facebook days, what are like the canonical examples of what was a big bet at the time?

Jay Parikh 45:47 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. 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, to do that. And some of these then just, you know, these are became things that we cannot fail at 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-

Brett Berson 47:11 Superior

Jay Parikh 47:11 ... worked better than... But when I didn't know, uh, I would try to take multiple parallel bets.

Brett Berson 47:16 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, I can't forecast that accurately."

Jay Parikh 47:27 We spend, I think, uh, having been in lots of different teams, spend a inordinate amount of time arguing A or B.

Jay Parikh 47:35 You know, it's kind of a funny thing that my team will say about me, 'cause when they bring those things to me, I'm like, "Well, 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, then that takes me four months to figure that out, versus doing two in parallel and I learn in two months what I would've done in four, that is like a trade I'll make all day long.

Brett Berson 48:17 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, 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 You know, leveraging AWS, you build your own and optimize your own data centers. Why is that so often the correct thing to do?

Jay Parikh 49:03 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 or even, you know, or my time at Akamai, was one is the, 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, in the beginning, that maybe is unobtainable because you don't have the people, you don't have the capital to do it, so 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, a speed, there's a control your own destiny argument that I al- 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'd be waiting on them to do something, you would, uh, 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

Jay Parikh 51:46 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 w- would take too long to change that, right? So we could reimagine an entire and launch a, 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, um, uh, 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, is done, and it's built together, and it's customized for the experience that we, 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.

Brett Berson 52:38 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?

Jay Parikh 52:50 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, at, uh, 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, with our, um, 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 downmarket in our offering, and we had to move upmarket 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, uh, afforded all us, but me, like, a ton of learning, and that carries over to being way more, like, I, I would say, in tune with what needs to happen or what we're doing at, at Microsoft.

Brett Berson 54:20 When you think about your role as an engineering leader today, what is the, 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, the previous couple decades. What's, like, the, the period that comes to mind? And maybe you could tell a little bit about the story of, like, what, what, what you figured out, how you evolved, why it sort of was so formative in terms of who you are today as a, as an engineering leader.

Jay Parikh 54:55 Yeah, I would say in, you know, maybe right up front is- Whether it be, um, you know, being maybe just a, 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. Um, 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, they're all different chapters in, in, 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-

Brett Berson 56:39 Right. [chuckles]

Jay Parikh 56:39 ... but it was like, you know, one of the-

Brett Berson 56:41 Exactly

Jay Parikh 56:41 ... one of the unicorn companies, right? And it was, 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. So I joined as an IC, did a bunch of roles, as I said, uh, earlier, which is like I joined in sales 'cause 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 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? So it was like lots of, 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 r- like I'd never been through that before in terms of how do you manage layoffs and how do you, 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 9/11, um, Danny, our founder, co-founder, passed away in 9/11. And, you know, Danny was a force of nature for, for us as 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 like 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? 'Cause and back to, you know, just like being real about it, being transparent, and this is like stuff for... Nobody, 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, and not having been through that before, it was 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, and the company's, you know, uh, still, uh, 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 m- mostly right and, and but we made a lot of mistakes too. So I would say that was a very, I'd say dense, condensed, uh, period of learning in terms of just growing up as a-

Brett Berson 1:00:49 Was there like a big thing, like one big idea you took from that, or was the hundreds of, of, of little things that you had to figure out?

Jay Parikh 1:00:56 It was a lot of... I mean, you know, I, I would say the obviously Uh, 9/11 was, I just say it's a, 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, and what we, 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

Jay Parikh 1:01:26 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, your business because a lot of our business in the beginning was all dotcom 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, to the enterprise." Like, we had no, 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 partner ecosystem, you don't have solutions, you don't have support that can service, you know, the Global 2000. You're, and you, you're, 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, 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, "Yeah, we can, you know, we, we, 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 gonna work on efficiency 'cause I'm not gonna go through that journey that we all went through at Akamai. And so we're gonna be efficient, and we're gonna build a great product, but we're not gonna do just product and ignore efficiency. So we're gonna be really diligent. We're gonna build kinda 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 gonna have the nightmare that we lived through at, you know, as, as we grew up as leaders at, at Akamai.

Brett Berson 1:04:12 Nice place to end. Thank you so much for spending the time.

Jay Parikh 1:04:15 Thank you, Brett. Pleasure.