Aug 27, 2026 · 1h 4m · in-depth
The most expensive mistake in outsourcing your tech stack | Jay Parikh (EVP CoreAI, Microsoft)
0:00 / 0:00
▶ Watch on YouTube →
gold bands on the timeline = statements, start to end. Hover to read, click to jump. CC turns on captions
Microsoft EVP of CoreAI Jay Parikh shares essential engineering leadership frameworks, detailing how to compress organizational learning loops, vertically integrate critical infrastructure, and build high-agency, customer-obsessed engineering cultures.
How this conversation actually went
Every chapter scored 0–10 on four independent dynamics. Hover any point for the reasoning behind the score. Brett holds 12.8% of the talking time here. How this is scored →
Brett as informed peer 3.7 Guest teaching 6.0 Guest disagreement 1.3 Brett pushing back 0.9
speaking balance: gold is Brett, purple is the guest (3 minute bins)
Sharpest disagreement ▶ 47:27 Rejecting endless A vs B architectural debates
Parikh dismisses the conventional paralysis of engineering debates between two options, explaining how he cuts through team friction by mandating they build both in parallel to find empirical answers faster.
Hardest push from Brett ▶ 48:17 Challenging the economic case for vertical integrationBerson pushes back against the trend of in-house vertical integration, highlighting the traditional economic and specialization benefits of relying on scaled commodity platforms like AWS.
Biggest teaching moment ▶ 9:30 The mechanics of organizational learning loopsParikh breaks down how company scale compounds learning friction, illustrating with a geometric analogy how expanding organizational diameter slows down cycle times.
Brett holds their own ▶ 15:28 Synthesizing executive impatient cadence dynamicsBerson demonstrates strong operational insight by framing how leadership impatience interacts with delivery milestone scheduling and inquiring whether arbitrary date pressure creates durable velocity.
the scores for every segment, with the reasoning behind each
| Chapter | Topic | Brett as informed peer | Guest teaching | Guest disagreement | Brett pushing back | Why |
|---|---|---|---|---|---|---|
| Holistic Systems Thinking in Engineering Leadership | 4 | 5 | 1 | 0 | Berson opens by framing engineering leadership across 30 years of technology paradigm shifts. Parikh explains that leadership cannot separate tech strategy from people, reframing the organization as a holistic socio-technical system based on his cross-functional career at Akamai and Facebook. | |
| Five Pillars of Engineering Leadership Excellence | 3 | 6 | 1 | 0 | Berson prompts Parikh to define excellence in engineering leadership. Parikh delivers a structured five-pillar framework covering talent composition, appropriate strategic abstraction, weekly execution drumbeats, actively squishing organizational toil, and cultivating adaptable culture. | |
| Battling Learned Helplessness and Cultural Friction | 4 | 7 | 2 | 2 | Berson probes whether all five pillars are equal and asks about the fundamental drivers of culture across Facebook and Microsoft. Parikh directly rejects the equality premise, diagnosing how learned helplessness breeds engineering toil and explaining how organizational growth expands the learning loop diameter. | |
| Measuring and Accelerating Organizational Execution Pace | 3 | 6 | 1 | 1 | Berson asks why organizations inevitably slow down with scale and what tactical actions combat it. Parikh details his onboarding playbook at Microsoft CoreAI, combining qualitative headwinds feedback with quantitative engineering focus time dashboards. | |
| Tactical Shifts from Phased Deadlines to Continuous Deployment | 5 | 6 | 2 | 2 | Berson asks if raw executive impatience and demanding arbitrary target date pull-ins drive speed. Parikh argues that top-down edicts are unsustainable and outlines Facebook's crawl-walk-run progression from daily deploys to continuous delivery backed by infrastructure automation. | |
| Work Charts, Small Teams, and Rapid Escalation | 3 | 6 | 1 | 0 | Berson asks for historical examples of peak team velocity. Parikh explains why large teams cannot move fast, advocating for small squads centered around dynamic work charts rather than static org charts and enforcing a strict 24-hour escalation rule. | |
| Shared Fate and Customer Obsession Across the Stack | 4 | 6 | 1 | 2 | Berson notes that infra teams often view internal developers as customers, but questions why many tech companies lack real customer obsession. Parikh explains the principle of shared fate at Facebook, where infrastructure teams owned full stack outcomes all the way to mobile end-users. | |
| Navigating Hype Cycles and Public Perception | 3 | 5 | 1 | 0 | Berson asks how to manage engineering morale and talent during volatile external sentiment swings. Parikh discusses filtering external noise by focusing on underlying intent rather than literal rhetoric and maintaining internal narrative consistency. | |
| S-Curve Transitions and Deliberate Talent Onboarding | 4 | 6 | 1 | 1 | Berson inquires about managing technology and talent during the steep inflection point of an S-curve. Parikh recounts Facebook's shift into proprietary datacenters and subsea cables, emphasizing his go-slow-to-go-fast philosophy of onboarding leaders as ICs first to avoid organ rejection. | |
| Empowering Individual Contributors and Technical Brain Trusts | 3 | 6 | 1 | 0 | Berson asks for further tactics on leading through steep technology inflections. Parikh details elevating individual contributors over management hierarchies, establishing manager-free IC brain trusts at Microsoft to debate architectural inflections directly. | |
| The AI Shift and Shortening Big Bet Horizons | 4 | 6 | 1 | 1 | Berson asks how AI disrupts historical pattern matching and changes multi-year product horizons. Parikh explains that because code is now an output with a collapsing development half-life, teams must replace rigid multi-year bets with rapid iterative prototypes to maximize shots on goal. | |
| Structuring Cross-Functional Big Bets and Parallel Experiments | 4 | 6 | 2 | 1 | Berson explores what constitutes a canonical big bet. Parikh outlines criteria for discontinuous step-function improvements across cross-functional teams seeking global maxima, noting his preference for running parallel experiments simultaneously rather than debating A versus B endlessly. | |
| The Strategic Imperative of Vertical Integration | 5 | 6 | 1 | 2 | Berson challenges Parikh on why companies vertically integrate instead of leveraging specialized vendor economies of scale like AWS. Parikh details Facebook's calculations around margin capture, custom scale requirements, and the agility needed to release full-stack features without waiting on third-party vendor roadmaps. | |
| CEO Insights on Go-to-Market and Enterprise Transitions | 3 | 7 | 2 | 0 | Berson asks how acting as a startup CEO reshaped Parikh's perspective and what historical chapter proved most formative. Parikh shares deeply personal lessons from surviving Akamai's post-dot-com crash and 9/11, explaining how that trauma led him to insist on engineering efficiency early at Facebook despite Mark Zuckerberg's initial product-only focus. |
Statements from this episode (22)
Dictating granular OKRs prevents engineering teams from thinking independently
“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, the North Star, or kind of maybe the Highe…”
Even multi-year engineering projects must show quantifiable weekly progress
“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 h…”
Operational engineering toil stems from a leadership culture of learned helplessness
“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 t…”
Scaling organizations traverse their learning loops at slower speeds
“As an organization gets more people, as it gets more successful, it tends to be that, that, 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 t…”
Microsoft CoreAI tracks engineering focus time via internal quantitative dashboards
“I'd say there's like a set of data that needs to be collected, and it's what we did when I joined and we created this core AI team, right? Which is, first of all, get both qualitative and quantitative data in terms of what is going on in terms of like that pac…”
Executive edicts for earlier deadlines cannot build a durable speed culture
“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.”
Parikh: Facebook scaled deployment from daily to continuous release cadence
“When I was at Facebook, when I joined, we did, which was like, really fast at the time. We used to ship The main core of Facebook once a day, and it was like a Herculean effort that, you know, most of the time went okay, but sometimes it didn't go okay, and, b…”
Small Microsoft CoreAI teams ship code multiple times per day
“We have teams now in Core AI and Microsoft that, you know, that I support, that I work with, that, Are shipping daily, sometimes multiple times a day, and, you know, some of this stuff is, like, newer products, so they don't have lots of tech debt and whatnot,…”
Parikh demands teams escalate 24-hour blockers directly to him, bypassing managers
“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.”
Facebook's infrastructure team controversially managed software up through the mobile stack
“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, righ…”
Parikh: Infrastructure teams must share fate and accountability with product teams
“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 it was 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, …”
Off-the-shelf infrastructure could not match Facebook's massive scaling requirements
“When I got to Facebook, we weren't building our own data centers, we weren't building our own hardware, we weren't laying around 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 operat…”
Assigning large teams to new external senior hires causes 'organ rejection'
“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, …”
Steep technology inflections demand IC-led cultures rather than managerial hierarchies
“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 hav…”
Microsoft CoreAI runs manager-free 'brain trusts' of individual contributors
“One of the things that I do at Microsoft is I have these brain trusts. And they're in different parts of our stack, and these brain trusts are formulated with, like, six to eight senior ICs, mid-level ICs only, and no managers, right?”
AI makes code an output and dramatically shortens software development lifecycles
“Writing code is not the long pole in the tent anymore, and code is an output now. It's not an input, and the half-life of the, as I will talk about, the typical software development life cycle or the product Development life cycle. The half-life of that is dra…”
AI prototyping velocity makes multi-year software engineering bets completely obsolete
“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, you know, in, in product, in software, because I don't know that it ne…”
Parikh: Major bets must span multiple teams to find global maxima
“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 team…”
Running competing technical bets in parallel resolves uncertainty and accelerates learning
“If I can do both and learn faster, versus do one, fail at it, and then do something else after that, and that takes me four months to figure that out, versus doing two in parallel, and I learn in two months what I would have done in four, that is like a trade …”
Hyper-scale technology companies fundamentally cannot rely on third-party infrastructure vendors
“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'…”
Full-stack vertical integration drastically accelerates massive new product launch cycles
“So we could re-imagine an entire and launch an entire new experience to 1000 of millions of people, billions of In a shockingly short amount of time, because it was all vertically integrated, and everybody that like, built that was, like, employees, engineers …”
Parikh pushed Zuckerberg to prioritize engineering efficiency over pure product features
“You know, I remember talking to Mark and Mark was like, yeah, we can, you know, we have money, so we should just build features and we should put all the engineers working on product. And I said, cool, but I'm going to work on efficiency because I'm not going …”