The fastest way to learn is to run two competing bets | Jay Parikh (EVP CoreAI, Microsoft)
First Round
AI-assisted summary of The fastest way to learn is to run two competing bets | Jay Parikh (EVP CoreAI, Microsoft) — original source. Check the original for full context.
Source published:
Key ideas
- Engineering leaders should resolve architectural deadlocks by funding parallel competing bets rather than debating forecasts, generating empirical performance benchmarks within 30 to 60 days. (44:10)
- At scale, organizations must replace traditional org charts with operational 'work charts' composed of small squads led by Directly Responsible Individuals (DRIs) with a mandatory 24-hour escalation rule. (20:00)
- Generative AI is shifting code from a human input into an automated computational output, creating a critical operational mismatch with human-speed go-to-market functions. (37:41)
- Full-stack vertical integration across hardware, data centers, and network cables shields scaling tech firms from unaligned third-party vendor roadmaps and median yield curves. (47:35)
Detailed notes
## Background Published by First Round on August 27, 2026, as an episode of the Executive Function podcast hosted by Brett Berson, this conversation features Jay Parikh, Executive Vice President of CoreAI at Microsoft and former global head of engineering at Facebook and CEO of Lacework. The episode explores Parikh's five pillars of engineering leadership, the mechanics of scaling organizational culture, and why running parallel competing technical bets yields faster learning than predictive forecasting.
## TL;DR Drawing from his leadership tenures at Akamai, Facebook, Lacework, and Microsoft, Jay Parikh details how to maintain execution speed and cultural coherence through exponential growth. He outlines the five essential ingredients of engineering leadership, highlighting the need to actively combat operational toil, replace traditional org charts with DRI-led 'work charts,' and empower manager-free IC brain trusts. Parikh also demonstrates why executing parallel, competing technical bets unblocks deadlocks faster than endless forecasting and explains how vertical integration preserves organizational agility. Finally, he reflects on the crisis leadership forged during Akamai's post-dot-com restructuring, which prompted him to instill strict operational and infrastructure efficiency at Facebook from day one.
## Atmosphere & style The conversation carries a crisp, battle-tested, and pragmatically rigorous tone, functioning like an executive-level masterclass in organizational engineering. Brett Berson steers the dialogue with targeted, structural inquiries, allowing Parikh to articulate complex operational mechanics without falling into corporate platitudes or hollow management speak. The mood remains fast-paced and analytical, yet deepens into genuine gravitas when Parikh recounts steering Akamai through mass layoffs and the tragic loss of co-founder Danny Lewin on September 11. Throughout, Parikh exudes the calm, decisive clarity of an operator who has repeatedly navigated steep technical S-curves under immense external pressure.
## Bulletin - `44:10` Engineering leaders should resolve architectural deadlocks by funding parallel competing bets rather than debating forecasts, generating empirical performance benchmarks within 30 to 60 days. - `20:00` At scale, organizations must replace traditional org charts with operational 'work charts' composed of small squads led by Directly Responsible Individuals (DRIs) with a mandatory 24-hour escalation rule. - `37:41` Generative AI is shifting code from a human input into an automated computational output, creating a critical operational mismatch with human-speed go-to-market functions. - `47:35` Full-stack vertical integration across hardware, data centers, and network cables shields scaling tech firms from unaligned third-party vendor roadmaps and median yield curves.
## Key takeaways - `02:21` Great engineering leadership rests on five foundational ingredients: team composition, strategic abstraction around core business metrics, operational drumbeat, combating toil, and intentional culture building. - `05:00` Operational toil is often a symptom of learned helplessness at the leadership level, such as assuming deployment friction is an immutable law or requiring headcount to solve every problem. - `10:00` Organizational scaling acts like an expanding circle where completing a single learning revolution takes longer as headcount increases, requiring continuous recursion back into small squads. - `12:05` To systematically combat operational drag, engineering leadership must instrument developer friction and focus time with telemetry rather than issuing arbitrary speed decrees. - `18:57` Small squads unburdened by legacy technical debt and equipped with generative AI tools can prototype, debug, and ship software multiple times per day. - `22:44` Cross-functional teams should adopt a Forward Deployed Engineer (FDE) mindset; isolating infrastructure engineers from customer reality leads to churn and coordination breakdowns. - `26:20` Leaders must insulate engineering organizations from wild swings in public perception by recognizing that internal criticism often reflects deep employee care rather than hostility. - `30:00` Steep inflection points on an S-curve ruthlessly expose talent gaps, requiring proactive multi-year talent acquisition rather than relying on current benches. - `33:58` Executive onboarding requires an initial period of operating as an individual contributor without direct reports to embed in the culture and diagnose architecture without triggering rejection. - `35:00` Creating manager-free 'brain trusts' of senior individual contributors unlocks unfiltered technical debates and prevents frontline engineers from deferring to managerial consensus. - `40:00` Meaningful 'big bets' must deliver order-of-magnitude discontinuous improvements across multiple teams rather than 10% to 30% incremental optimizations. - `44:10` Running competing technical paths in parallel preserves option value, allowing teams to gather empirical results in two months rather than losing four months to sequential evaluation. - `47:35` Vertical integration down to custom silicon and data center design becomes essential at hyperscale because third-party vendors design hardware for median enterprise customers. - `51:46` Experience as a startup CEO highlights that technological innovation must be tightly paired with go-to-market mechanics, sales incentives, and pricing models. - `01:01:26` Instilling an efficiency and frugality mindset early is vital because retrofitting fiscal and architectural discipline into a bloated engineering organization is nearly impossible.
## Detailed walkthrough ### `00:00` Viewing Engineering as a Whole System
Looking back across major technology shifts over the last 30 years—from the early commercial Internet through mobile, the cloud, and now AI—engineering leadership cannot be cleanly split between people management on one side and technology strategy on the other. Outside observers often look at generational tech successes like Facebook and assume everything was cleanly architected from day one. In reality, scaling through those early steep curves was dominated by brute force behind the scenes. As Jay Parikh puts it: “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, you didn't want to look at the curtain.”
The core failure mode for many engineering executives is treating people, product, and business functions as isolated silos. Effective leaders view the entire enterprise as a single interconnected system whose sole objective is delivering value to end users. That perspective stems directly from wearing multiple cross-functional hats early on: - At Akamai, Jay’s first role was stepping into technical sales simply because the company had no one else to do it, helping the team close customer deals directly. - He was then pulled into business development to negotiate and build out the physical server network across data centers. - Later, he transitioned back into engineering and product, rotating through roles as an engineer, product manager, product marketer, director, and VP before ultimately leading all of engineering at Facebook.
`02:21` The Five Ingredients of Great Engineering Leadership
Excellence in engineering leadership breaks down into five foundational ingredients that must work in tandem rather than in isolation:
```mermaid flowchart TD accTitle: The Five Ingredients of Engineering Leadership accDescr: A visual representation of the five interdependent components that define engineering leadership excellence.
subgraph Foundation["1. Organization & Strategy"] T["High-Performing Team<br/>• Composition & Balance<br/>• ICs, Specialists, Generalists"] S["Strategic North Star<br/>• Right Abstraction Level<br/>• Avoid Top-Down Micromanagement"] end
subgraph Operation["2. Operating Rhythm"] D["Drumbeat of Execution<br/>• Week-over-Week Progress<br/>• Relentless Tempo"] H["Fighting Headwinds & Toil<br/>• Squish Operational Drag<br/>• Combat Learned Helplessness"] end
subgraph Catalyst["3. Cultural Engine"] C["Intentional Culture<br/>• Prescriptive Behaviors<br/>• Fast Learning Loops"] end
Foundation --> Operation Operation --> Catalyst C -.->|"Enables & Rate-Limits"| Foundation ```
1. **Building a high-performing team:** Recruiting top talent is only the starting point; leaders must intentionally design the structural composition of the organization. This requires deciding the exact ratio of early-career talent to senior individual contributors (ICs), balancing deep domain specialists against versatile generalists, and positioning high-leverage technical leads throughout the ranks. 2. **Setting strategy and vision at the right abstraction level:** If an engineering leader sets a North Star that is too abstract or high-level, it becomes completely opaque and teams do not know what to execute on Monday morning. Conversely, if a leader dictates all 1,051 individual OKRs, the team stops thinking autonomously. The leader's job is to define the right layer of abstraction—centering on core metrics such as revenue, active users, or retention—so teams are empowered to solve the problems themselves. 3. **Establishing a relentless drumbeat of execution:** Executives often believe their job is merely to delegate, but senior leadership must set the operational tempo. Even for massive architectural overhauls or multi-year product initiatives that take two years to materialize, teams must demonstrate concrete, quantifiable, week-over-week progress (or day-over-day during critical sprints) across efficiency gains, user growth, or product delivery. 4. **Combating toil and operational headwinds:** As systems scale and run for years, operational drag compounds. Especially in the modern AI era, where iteration speeds are unprecedented, organizations must possess an active intolerance for toil. Without a dedicated effort to squish this drag down, systems accumulate friction and execution spirals downward. 5. **Intentional culture building:** Culture has recently been unfairly downplayed or viewed as uncool to discuss, but it remains the foundational baseline that dictates execution speed.
`05:00` Toil, Learned Helplessness, and Real Culture
The relative weighting of these five ingredients shifts depending on the maturity of the organization. While early-stage startups focus heavily on team assembly and strategy, mature enterprises spend an enormous amount of energy battling toil. Crucially, toil is merely an effect; the root cause is frequently an underlying leadership mindset of learned helplessness.
When organizations stagnate, leaders and teams start offering reflexive excuses: - Claiming an issue cannot be resolved without incremental headcount. - Treating security reviews, compliance roadblocks, or deployment hurdles as unchangeable laws of nature. - Accepting extreme friction to push code into production as simply "the way things are."
Jay explains how this defeats an engineering organization from the inside out: “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?”
To reverse that decline, leadership must recognize that culture is not about superficial workplace perks: - It is not free snacks, branded swag, lifestyle jobs, or "warm and fuzzies." - Culture is highly prescriptive: it is defined by how people communicate, how decisions are made, the behaviors rewarded under pressure, and how values are actively expressed hour by hour and minute by minute. - A company can print slogans like "Move Fast" or "Customer Obsession" on posters, but they are hollow unless mirrored in operational reality. - Ultimately, culture acts as the rate-limiter for everything else: an organization with a broken, passive culture will fail at hiring, vision, execution, and eliminating toil. - The true engine of an enduring organization is its internal "learning loop"—the speed at which individuals and teams share insights, adapt to rapid technological shifts, and execute on feedback across expanding headcounts.
`10:00` The Geometry of Scale and the Learning Loop
Jay Parikh describes organizational scaling through the metaphor of an expanding circle where every single revolution represents exactly one unit of learning. When a startup is tiny, that circle has a small diameter, meaning the team traverses it rapidly and learns at high frequency. As a company finds success, hires more people, and launches more products, the diameter expands relentlessly. Not only does the physical distance required to complete one full revolution grow vastly longer, but the organization also moves through that circumference far slower. Everything in organizational physics begins working against speed. Jay explains that his primary obsession as an engineering executive is figuring out how to actively fight that expansion and systemic slowness.
Fighting that drag requires constantly recursing operating models back into the system rather than letting legacy habits calcify. A meeting cadence that was essential a year prior when eight people were in the room stops functioning when the attendee list balloons to forty people; leadership must actively dismantle those forums and reset them back to small, eight-person working groups with clear Directly Responsible Individuals (DRIs) and prescriptive goals. While many engineers are allergic to process, Jay emphasizes that while process for process’s sake is terrible, organizations require the right relevant structure so individuals can do their best work. Furthermore, building a resilient culture means treating production outages, churned customers, and technical missteps not as catastrophic surprises, but as raw fuel for improvement. As Jay Parikh puts it:
> “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.”
```mermaid flowchart LR accTitle: The Scale and Learning Loop Tension accDescr: Contrasting the small, rapid learning cycle of early-stage startups against the wide, sluggish learning loop of scaled organizations.
subgraph Startup["Small Startup Loop"] direction TB A1["Idea / Hypothesis"] --> B1["Rapid Build & Ship"] B1 --> C1["Direct Feedback"] C1 -->|"Fast revolution\nSmall circumference"| A1 end
subgraph Scaled["Scaled Enterprise Loop"] direction TB A2["Idea / Hypothesis"] --> D2["Cross-Team Reviews"] D2 --> B2["Extended Build Cycle"] B2 --> E2["Staged Releases"] E2 --> C2["Customer Churn / Outage Data"] C2 -->|"Slow revolution\nExpanding circumference"| A2 end ```
`12:05` Speed as an Unforgiving Competitive Advantage
When Brett Berson asks why company building seems governed by an inescapable law where everything decelerates over time, Jay responds that maintaining velocity is neither optional nor a cosmetic "nice to have"—it is an existential competitive edge. If a team can establish a cadence that lets them learn two, five, or ten times faster than their rivals, their probability of winning in the fullness of time approaches certainty.
When stepping into an established, sluggish engineering organization as a new leader, demanding speed without empirical evidence fails. When Jay helped establish the CoreAI team at Microsoft, the leadership team initiated a comprehensive audit collecting both qualitative sentiment and quantitative telemetry on developer friction: - **Qualitative headwinds:** Gathering candid subjective anecdotes directly from builders about the daily bureaucratic and technical detractors impeding their work. - **Quantitative time tracking:** Categorizing engineering hours into productive work versus administrative overhead, establishing a core metric known as "focus time." - **Focus time visibility:** Implementing real-time dashboards so engineering leaders across the organization could observe the exact percentage of uninterrupted focus time their teams actually possessed.
`15:00` Mindset Shifts, Socratic Pushes, and the Evolution of Deployment Cadence
Addressing the role of executive impatience, Brett asks whether an engineering leader simply demanding an August 15th release instead of a planned September 30th date actually accelerates an organization. Jay cautions that arbitrary management decrees might brute-force an early delivery once or twice, but they fail to produce durable behavioral shifts. Leaders must first understand the foundational assumptions and historical constraints baked into why the team chose September 30th in the first place. Using a Socratic approach—asking what subset of scope could ship by August 20th, or what friction points could be deferred until post-launch—uncovers hidden toil and lets leadership challenge assumptions collaboratively.
Jay highlights that shifting engineering cadence requires bringing the voice of the customer directly into conversations about learning speed, storytelling around culture rather than micromanaging individual dates, and adopting a deliberate "crawl, walk, run" progression. He illustrates this journey with Facebook's deployment transformation: - **Daily deployments:** When Jay originally joined Facebook, shipping the core codebase once per day to 300 million users worldwide was considered industry-leading, yet it required a daily Herculean effort that periodically broke down. - **Three times a day:** As once-per-day releases became a bottleneck for developer iteration, the company re-architected internal processes to push code three times daily. - **Continuous deployment:** By the end of Jay's decade-long tenure, massive sustained investments in internal infrastructure, testing automation, and toil reduction enabled continuous deployment, pushing code seamlessly throughout the day.
`18:57` The Velocity of Small Teams and Modern AI Tooling
Reflecting on the fastest teams he has ever witnessed, Jay notes that peak velocity rarely comes from massive divisions; it emerges from tiny, unencumbered groups tackling targeted problems. Within the CoreAI teams he supports at Microsoft, certain small units ship software daily and even multiple times per day. Because these squads build newer products, they are not anchored down by decades of technical debt or legacy infrastructure.
Crucially, these ultra-fast pods combine extreme product taste and direct intimacy with customer needs with modern AI-assisted workflows. By utilizing generative AI tooling, engineers can crank out functional prototypes, iterate on designs, and diagnose and fix bugs at a pace previously impossible for legacy engineering groups.
`20:00` Small Teams, the "Work Chart," and Fast Escalations
Jay emphasizes that organizations and teams move rapidly when they are structured into tightly knit units, pointing out that scale and customer type dictate execution velocity. Having led teams at Facebook and other organizations, he remains skeptical of massive groups: "Like large teams don't move fast. It's just like not possible to me, right?" To counter this dynamic, he disregards conventional organizational structures in favor of operational ones:
> "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."
Whether these are labeled B-teams, squads, or pods, the model requires very small units staffed with the right talent and led by a clearly designated Directly Responsible Individual (DRI) who possesses full context and agency. Jay stresses that leadership must genuinely trust these squads to do their jobs while holding them accountable through regular updates, check-ins, and clear metrics.
Critically, organizational roadblocks must be dismantled by removing the stigma around elevating issues. Parikh insists that "escalation is not a bad word in this world." Rather than letting friction linger through intermediate layers of management, he implements a direct rule:
> "It's like I've told teams and 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."
When disagreements occur or decisions stall, the team must route the problem immediately to someone who can decide so everyone can move on. Maintaining this speed hinges on high talent density, full context, clearing away distractions, and candid evaluations: if a chosen DRI turns out to be ill-suited for the role, leadership must replace them quickly.
```mermaid flowchart TD accTitle: The Work Chart Operating Model accDescr: Diagram illustrating how high talent density squads operate under the work chart model with direct escalation.
subgraph OrgModel["Structure: Work Chart vs Org Chart"] Squad["Small Dedicated Squad"] DRI["Clear DRI / Leader<br/>(Context & Agency)"] Metrics["Guided by Concrete Metrics"] Squad --- DRI Squad --- Metrics end
subgraph Execution["Execution & Speed"] Action["Autonomous Daily Execution"] Stuck{"Blocked > 24 Hours?"} DirectEsc["Direct Escalation to Leadership<br/>(Bypass Multi-Week Management Ladders)"] Resolution["Immediate Decision & Unblock"] end
DRI --> Action Action --> Stuck Stuck -- "Yes" --> DirectEsc DirectEsc --> Resolution Resolution --> Action ```
---
`22:44` Shared Fate and Fostering an "FDE Mindset"
Addressing the prolific infrastructure stack he oversaw at Facebook, Brett asks whether infrastructure teams must view internal software engineers as customers whom they need to delight. Jay explains that at Facebook, the infrastructure organization was not just responsible for hardware; it owned all the software and went far up the stack to end-user consumption, including running much of the mobile engineering stack. He enforced an organizational ethos where every engineer had to be close to the customer, warning that if the infrastructure layer performed but the final product failed, the entire initiative 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 the customer. I had zero tolerance for that."
When asked why so many companies lack this customer obsession, Parikh attributes it to deficits in vision, strategy, and organizational culture. Understanding customer requests requires judgment and intuition, recognizing that users sometimes ask for one thing while actually needing something entirely different.
At Microsoft, Jay instills a similar philosophy across his CoreAI organization, telling his engineers that everyone needs to adopt the mindset of a Forward Deployed Engineer (FDE). While they are not literally deployed on site as FDEs, they must deeply connect their work to how Fortune 500 enterprises actually deploy and interact with the platform. He expects engineers to actively join briefings, ride along in customer calls, review interviews, and read direct user feedback.
Connecting every layer directly to customer reality yields two major benefits: - **Durable sense of purpose:** It galvanizes the team by showing how their code creates real value and emotion for end users, rather than simply moving internal metrics, which aids in attracting and retaining top talent. - **Organizational responsiveness:** In loosely layered companies where only executives connect to customers, the top layer recognizes market shifts while downstream engineering, infrastructure, and operations remain isolated, causing massive coordination delays. Parikh notes that in today's landscape, the penalties in lost market share and customer churn from these slow reaction times have grown devastatingly high.
---
`26:20` Navigating Wild Swings in Public Perception
Brett observes that over his career, Jay has navigated dramatic swings in external sentiment—moving from being praised as the most brilliant team on earth to being dismissed as completely irrelevant, sometimes over the span of three months or three years. Jay explains that navigating these vibe shifts requires emotional modulation:
> "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."
Rather than tuning out external noise entirely, Jay welcomes criticism and praise alike as a byproduct of working on consequential, meaningful things at massive scale: "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?" The critical leadership discipline is separating people's literal words from their underlying intent.
He recalls moments during internal controversies at Facebook when employees voiced strong frustration or disagreement. By sitting down with them and listening deeply, he discovered that harsh words often masked constructive intent from people who genuinely cared and were trying to help the company navigate problems.
Parikh highlights that maintaining and refining a grounding narrative is an unrelenting leadership responsibility. When a company is riding high and appears to do no wrong, leaders must remind teams that good times are often partly driven by luck; headwinds and serious challenges will inevitably hit.
---
`29:07` Leading Through the Steepest Part of the S-Curve
Turning to broader technological epochs—from the dawn of the commercial internet through mobile, cloud, and now AI—Brett asks Jay what distinguishes building technology and teams during the steepest inflection points of the S-curve compared to when a technology asymptotes and becomes predictable.
Looking back at his experiences at Akamai and Facebook, Jay points out that the steep part of the S-curve is defined by hyper-rapid learning, constant adaptation, and unrelenting external churn. Because everyone becomes completely consumed by building and shipping technology under extreme velocity, leaders must make deliberate space to learn and absorb changes as they happen, rather than letting the sheer volume of daily tasks obscure what is unfolding.
`30:00` Scaling the Stack: Facebook’s Shift to Mobile and Infrastructure In-Sourcing
When an organization hits the steepest climb of an S-curve, the sheer momentum ruthlessly exposes every vulnerability in its talent bench. Leaders suddenly discover whether they have the right managers or the specialized technical depth required across each individual layer of the architecture. Reflecting on his arrival at Facebook in 2009, Jay recalls stepping into an engineering organization of just a few hundred people where the overall technology footprint was conceptually straightforward. The entire company operated around the web at Facebook.com. Mobile was an afterthought relegated to a tiny outpost: roughly five people huddled in the corner of a basement hacking on an iOS application that barely anyone touched. The real mobile shockwave did not strike until the run-up to the IPO and the years immediately following—spanning roughly 2011 through 2014—forcing the engineering organization to reinvent itself under immense pressure.
```mermaid flowchart TD accTitle: Facebook Technical Stack Evolution accDescr: The progression from off-the-shelf software to fully insourced vertical infrastructure.
subgraph Early["Early Facebook (2009)"] A["All Web Architecture<br/>(Facebook.com)"] B["5 Engineers in Basement<br/>(Early iOS App)"] C["Off-the-Shelf Commercial<br/>Servers & Data Centers"] end
subgraph Transition["Scaling Pressure (2011-2014)"] D["Massive User Scale<br/>(Hundreds of Millions)"] E["Mobile Inflection Point<br/>(IPO Era Pivot)"] F["Commercial Price-Performance<br/>Limits Reached"] end
subgraph Insourced["Vertical Integration"] G["Custom Data Center Design"] H["Bespoke Server Hardware"] I["Global Subsea Fiber Cables"] end
Early --> Transition Transition --> Insourced ```
At that scale, commercial off-the-shelf infrastructure could no longer satisfy Facebook's aggressive price-performance and capacity targets. Instead of reacting when systems broke, leadership had to map out multi-year talent acquisition plans to systematically take ownership of every layer of the underlying stack. Facebook evolved from renting colocation space and buying standard rack servers to designing its own data centers, inventing custom server hardware, and laying intercontinental subsea cables. Jay notes that such massive technological pivots cannot be executed on the fly; they require anticipating gaps years in advance and recruiting specialists from radically different corporate backgrounds and engineering cultures. As Jay explains:
> “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.”
---
`33:58` Onboarding with "Go Slow to Go Fast" and Meeting Customers Where They Live
Integrating senior talent from outside cultures is notoriously fraught with danger, and Jay warns against the common executive blunder of instantly burdening new hires with massive scope. Companies routinely invest immense effort and capital to recruit top-tier leaders, only to drop them into a division of hundreds of engineers on their very first day, triggering immediate organizational rejection. To counter this, Jay adheres strictly to a guiding philosophy: go slow to go fast. Both when he joined Facebook and when he later stepped into Microsoft, he spent his opening one to two months operating essentially as an individual contributor. That buffer allowed him to embed within the teams, learn the institutional landscape, listen directly to engineers, and understand the company's authentic strengths before architecting CoreAI.
```mermaid flowchart LR accTitle: Customer Horizon Framework accDescr: Segregation of customer archetypes across technology inflection curves.
subgraph CustPast["Living in the Past"] P1["Legacy Systems"] P2["Need Guidance into Present"] end
subgraph EngTeam["Engineering Organization"] E1["Differentiated Engagement"] E2["Value Beyond Dollar Spend"] end
subgraph CustFut["Living in the Future"] F1["Pioneering Edge Tech"] F2["Co-Innovation Partners"] end
CustPast -->|"Help Modernize"| EngTeam EngTeam -->|"Move Fast & Co-Build"| CustFut ```
That same patience and calibration must extend to understanding customers during steep platform inflections. While tech organizations often pay lip service to being customer-obsessed, Jay points out that many engineering teams fail to recognize that customer maturity falls along a wide spectrum that cannot simply be measured by annual contract value. Some customers are functionally stuck in the past and depend on the vendor merely to drag them into the present day, whereas pioneering customers already live in the future and require a completely different, high-velocity co-development posture to help push the state of the art forward. Jay emphasizes that organizational endurance depends directly on mastering these deliberate transitions:
> “But onboarding, I think, is a really big part of how you build a durable organization over time.”
- **The Executive Onboarding Trap:** Handing a new leader hundreds of direct and indirect reports on day one frequently causes severe "organ rejection" within the existing engineering culture. - **The IC Immersion Period:** Spending 30 to 60 days without managerial reports gives senior leaders the freedom to diagnose architecture and culture authentically before making structural changes. - **Customer Maturity Segmentation:** Valuing accounts strictly by dollar volume blinds teams to the true technological split between legacy clients needing modernization and forward-leaning clients accelerating platform capabilities.
---
`35:00` Cultivating an IC-Led Culture: Manager-Free "Brain Trusts"
To maintain velocity through aggressive technology cycles, Jay believes organizations must counteract the gravitational pull of managerial bureaucracy by deliberately elevating individual contributors. While management provides essential scaffolding—handling cross-team dependencies, personnel development, and performance reviews—it is the frontline ICs who possess the deepest comprehension of emerging platform inflections like mobile or AI. Over-indexing on hierarchical, top-down directives invariably stalls development because technical decision-making slows to the pace of managerial consensus. High-performing engineering cultures intentionally protect senior ICs, hold them directly accountable for technical vision, and treat engineering and management as parallel career tracks of equal status rather than treating management as the sole path to promotion.
```mermaid flowchart TD accTitle: Management vs Brain Trust Organizational Model accDescr: Comparison of administrative management functions versus technical brain trust dynamics.
subgraph Administrative["Managerial Scaffolding"] M1["Cross-Team Dependencies"] M2["People & Career Development"] M3["Performance Management"] end
subgraph Technical["IC Brain Trusts (Zero Managers)"] B1["6 to 8 Senior & Mid-Level ICs"] B2["Deep Technical Stack Debate"] B3["Customer & Inflection Forecasting"] end
Administrative -.-|"Parallel Peer Tracks"| Technical ```
At Microsoft, Jay puts this conviction into practice across the CoreAI division by operating specialized forums known as brain trusts. Each brain trust focuses on a distinct slice of the technology stack and consists of six to eight senior and mid-level individual contributors—with zero managers permitted in the room. This boundary creates an uninhibited space where technical leaders can argue aggressively, test hypotheses, and dissect shifts in technology and customer behavior without diplomatic posturing. By isolating technical debate from administrative hierarchy, the organization stays tethered to ground truth. As Jay explains:
> “And not have this like culture where they defer or they report into managers because everything just gets slow at that point, right?”
---
`37:41` The Inversion of Software Development and the Disappearing Multi-Year Bet
Addressing the modern artificial intelligence wave, Jay challenges the conventional wisdom that current shifts simply mirror historical platform cycles like the shift to client-server, the web, or mobile. In this era, foundational software development assumptions have been turned inside out: writing code is no longer the bottleneck or the long pole in the tent. Code has transitioned from being an explicit human input to an automated computational output, causing the half-life of traditional software development and product development lifecycles to collapse dramatically. However, this creates a stark operational friction point: while technical code generation has accelerated toward zero latency, the downstream business machinery—sales enablement, marketing campaigns, pricing, packaging, and partner channel distribution—still operates at human speed.
```mermaid flowchart LR accTitle: The AI Development Mismatch accDescr: The velocity mismatch between automated AI code generation and human downstream operations.
subgraph HighVelocity["Near-Zero Latency (AI-First)"] C1["Code as an Output"] C2["Compressed Feature Lifecycles"] end
subgraph Bottleneck["Human Latency Gate"] H1["Pricing & Packaging"] H2["Sales Enablement & Marketing"] H3["Partner Ecosystems"] end
HighVelocity -->|"Rapid Production"| Bottleneck Bottleneck -->|"Execution Lag"| R1["Customer Adoption & Revenue"] ```
This structural compression fundamentally reshapes how leaders formulate technical vision and evaluate risk. While physical infrastructure—the "atoms" layer of data centers, power, and specialized hardware—still demands multi-year planning horizons, committing to multi-year software roadmaps has become an obsolete practice. With cutting-edge developer tooling, projects that previously took an entire engineering team a full calendar year to write can now be realized in fractions of that time, making lengthy roadmap commitments counterproductive. Jay emphasizes the radical nature of this transformation:
> “Because we're not typing code and writing code is not the long pole in the tent anymore. Code is an output now. It's not an input.”
- **The Output Shift:** AI inverts the software paradigm; programming is no longer the primary human input that gates product delivery. - **The Human Bottleneck:** Rapidly generating functional software creates an organizational mismatch if sales, marketing, and channel partners cannot digest and monetize features at the same pace. - **Shrinking Time Horizons:** With code creation compressed by modern tooling, multi-year roadmaps in the software layer are obsolete, even while physical atoms-level infrastructure continues to require long-range planning.
`40:00` Compressing Timelines and Defining What Makes a Big Bet
With modern prototyping capabilities and rapid iteration cycles, long-running research efforts can be compressed dramatically. Instead of locking up a team of engineers on a twelve-month bet just to observe two or three intermediate milestones, teams can now deliver durable prototypes under load within two months, setting check-ins every two to three weeks or on a monthly cadence. Jay points out that shrinking these cycles allows an organization to expand its shots on goal without increasing head count: rather than committing a single team to one high-stakes bet over a whole year, leadership can launch four or five distinct bets across that same span.
```mermaid flowchart TD accTitle: Big Bet Architecture accDescr: Diagram contrasting isolated local optimization with cross-functional big bets targeting global maxima.
subgraph AntiPattern["Fragmented Local Maxima"] T1["Team 1: Local Optimization"] T2["Team 2: Local Optimization"] T3["Team 3: Local Optimization"] end
subgraph BigBet["Cross-Functional Big Bet"] CF["Unified Initiative (3-5 Teams)"] Discontinuous["Discontinuous Step-Function Impact"] GlobalMax["New Global Maxima"] CF --> Discontinuous --> GlobalMax end ```
For Jay, a genuine big bet cannot be defined by modest ten, twenty, or thirty percent efficiency gains. It must deliver discontinuous, step-function impact across the enterprise. At Facebook, he curated and maintained an active portfolio of these multi-year initiatives, evaluating them against strict structural criteria:
- **Discontinuous impact:** The initiative must produce an order-of-magnitude step change rather than an incremental linear improvement. - **Cross-functional footprint:** A big bet should span three to five distinct teams. When isolated groups build in a silo, they inevitably optimize for their own local maxima while closing off the broader organization's global maximum. - **Continuous environmental sensing:** Teams must never disappear into a three-year vacuum. The burden rests on them to maintain context with internal shifts and external market dynamics, adjusting and pivoting whenever the landscape zigs while they zag. - **Acceptance of failure and derivative value:** Jay does not expect every initiative to succeed. A portfolio of five big bets where two take off, one ends up mediocre, and two fail represents a strong batting average. Even failed efforts generate valuable architectural derivatives, code, and insights that accrue to other parts of the business.
Safeguarding these ambitious initiatives serves as a critical defense against organizational decay. As companies expand and rack up commercial wins, an insidious reversion to the mean sets in. Jay emphasizes how quickly that slide occurs: “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 you get complacent, that complacency breeds mediocrity, and then people don't want to take risks, and we know the rest.”
---
`44:10` Parallel Bets and Learning Velocity
Inside Facebook, these discontinuous bets reshaped every layer of the technology stack. When the company initially chose to design its own server hardware, it started small with a single custom server design before taking an aggressive leap to overhaul the full lineup of storage, database, and networking SKUs in rapid succession. At the storage layer, teams pursued massive architectural changes aimed at delivering a 10x improvement in cost, performance, and scaling limits. Higher up the stack, major product transformations—such as completely rethinking video delivery and messaging infrastructure—demanded sweeping, simultaneous modifications across the entire platform.
When engineering teams reached an impasse between two competing technical architectures, Jay frequently broke the deadlock by running both paths in parallel instead of wasting time debating forecasts:
- **Bypassing endless debate:** When faced with two viable paths with roughly equal probabilities of success, teams often burn months in committee trying to forecast an uncertain outcome. - **Preserving option value:** Launching both architectures simultaneously preserves flexibility and generates real-world empirical data on performance within 30 to 60 days. - **Halving time to insight:** Running parallel bets for two months reveals the winning strategy far faster than pursuing a single path for two months, failing, and then spending another two months trying the alternative.
Jay summarizes his operational bias toward parallel execution: “And back to this 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.”
---
`47:35` Why Vertical Integration Wins at Scale
While classical economic doctrine favors specialization and buying modular components from third-party vendors who amortize R&D across thousands of customers, elite technology companies almost always vertically integrate as they scale. At Facebook, this dynamic drove the transition away from off-the-shelf components toward fully custom hardware, networking equipment, and purpose-built data centers. Jay explains that this decision is primarily governed by extreme scale and operational efficiency across the infrastructure stack.
```mermaid flowchart LR accTitle: Vertical Integration Trade-Off accDescr: Comparison of third-party vendor limitations versus in-house vertical integration at extreme scale.
subgraph VendorRoute["Third-Party Vendor Path"] V1["Vendor Core Stack"] --> V2["Built for Average Customer"] V2 --> V3["Margin Markup & Unaligned QA Yield"] end
subgraph VerticalRoute["Vertically Integrated Path"] VI1["In-House Architecture"] --> VI2["Engineered for N of 1 Workloads"] VI2 --> VI3["Maximum Efficiency & Destiny Control"] end ```
Early in a startup's lifecycle, building proprietary data centers or custom silicon is impossible due to capital and staffing constraints. As an organization scales into an industry giant, however, the math shifts:
- **Margin recapture and stack-wide efficiency:** Outsourcing core infrastructure layers leaves financial margin on the table at every tier of the vendor ecosystem. Vertically integrating allows the organization to optimize end-to-end performance and eliminate compounding third-party markups. - **Escaping average-customer design compromises:** Standard vendors inevitably design, QA, and regression-test their products to satisfy the median customer profile, not an organization operating at unprecedented scale. - **Eliminating edge-case friction:** When operating as an *N-of-1* enterprise, the company consistently hits the bleeding edge of a vendor's operational capabilities, leaving the team stranded on an unfavorable portion of the vendor's yield curve and slowing development velocity.
Jay makes the ultimate case for controlling the underlying stack: “Back to there's a speed, there's a control your own destiny argument that I always felt. 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 kind of N of 1 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.”
`50:00` The Power of Vertical Integration: Speed, Control, and Product Agility
Jay Parikh details the operational payoff of full-stack vertical integration at Facebook, showing how controlling every component avoided the friction of vendor dependency. In a fragmented vendor architecture, teams constantly wait on third parties to implement updates or fix bugs, which grinds momentum to a halt. In contrast, when Facebook decided to launch fundamentally new product experiences—such as live video or rich messaging features—the rollout demanded sweeping alterations across every tier of the technical infrastructure: client code on mobile devices, caching logic across the edge network, application server compute, and backend storage architectures.
Because Facebook owned and engineered its entire stack in-house, these massive cross-layer overhauls could be coordinated and deployed to hundreds of millions or billions of users in a matter of weeks rather than years. Cross-functional alignment happened organically because every person touching the stack worked directly for the company. Parikh distills the core rationale for vertical integration into three foundational pillars: driving down unit costs, maintaining total control over the company's technical destiny, and sustaining blinding execution speed.
```mermaid flowchart TD accTitle: Full-Stack Vertical Integration for Rapid Feature Delivery accDescr: Diagram illustrating how Facebook's vertically integrated stack enabled rapid cross-layer updates for experiences like live video.
subgraph ClientAndEdge["Edge & Client Layer"] A["Mobile Client"] B["Edge Network & Caching"] end
subgraph CoreInfra["Compute & Storage Layer"] C["Application Servers"] D["Custom Backend Storage"] end
A <--> B B <--> C C <--> D
subgraph Outcomes["Strategic Benefits"] E["Radical Delivery Speed<br/>(2-8 weeks to billions)"] F["Dramatic CapEx & Unit Cost Reductions"] G["Total Control Over Product Destiny"] end
ClientAndEdge -.-> Outcomes CoreInfra -.-> Outcomes ```
- Parikh summarizes the organizational agility of vertical integration: “And everybody that built that was employees, engineers on our team. So you could just say... This is what we're doing, you know, two weeks, three weeks, one month, two months, whatever. And the whole thing is done.” - Vertical integration provided Facebook with three distinct advantages: structural cost efficiency, autonomy without reliance on third-party roadmaps, and unmatched product velocity.
---
`51:46` How the Startup CEO Experience Reshaped Jay's Leadership
Reflecting on his tenure as CEO of Lacework before joining Microsoft as Executive Vice President of CoreAI, Parikh explains how running a standalone venture fundamentally expanded his executive vocabulary and operational intuition. Stepping outside the purely engineering realm forced him to build and master the mechanics of go-to-market (GTM) execution, sales compensation, enterprise sales metrics, and pipeline machinery. Rather than viewing sales as an abstract downstream function, he experienced firsthand the rigor required to operate a high-performing go-to-market engine.
This CEO perspective became particularly acute as Lacework executed a strategic pivot from a down-market offering to an enterprise-grade platform targeting the Global 2000. That evolution touched every corner of the business: overhauling product architecture, reconstructing pricing and packaging, refining the sales pitch, hiring a different profile of account executives, reimagining enterprise support, and cultivating an ecosystem of channel partners. Having navigated these systemic transitions as chief executive, Parikh returned to enterprise leadership at Microsoft with an intuitive, firsthand empathy for GTM challenges.
- Parikh reflects on the depth of learning gained from holding the top seat: “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.” - Moving upmarket required transforming seven core systems in lockstep: the core product capabilities, pricing and packaging models, enterprise pitch narratives, sales organization composition, ongoing support delivery, partner networks, and customer retention mechanisms.
---
`53:40` Hunting for Steep S-Curves and the Crucible of Early Akamai
When Brett asks Parikh to pinpoint the single most transformative growth phase of his multi-decade career, Parikh points to his first four to five years at Akamai Technologies. Parikh frames his entire career philosophy around an intentional hunger for difficult, uncomfortable problems, describing himself as almost addicted to seeking out hardship. He visualizes professional development strictly through the lens of S-curves: his objective is always to spend the maximum amount of time on the steepest part of the learning curve, deliberately moving to new challenges the moment that trajectory begins to bend or flatten out.
Parikh arrived at Akamai in 1999 when the startup had only a few dozen employees. Long before the term “unicorn” entered Silicon Valley parlance, Akamai generated an electric buzz as a generational tech phenomenon. The company was packed with brilliant academic PhDs who had cracked the code on novel, complex algorithms capable of routing and scaling the massive traffic explosion hitting the early internet. Despite having no formal background in enterprise sales engineering, Parikh joined as an individual contributor in sales because the company urgently needed someone who could translate deep computer science algorithms into tangible business value for customers, later cycling through business development, product management, and product marketing before returning to engineering leadership.
- Parikh articulates his framework for career progression: “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 flattened, then I'm always trying to find the next thing, right?” - Parikh describes the mythos surrounding Akamai's early algorithmic culture: “And there was this buzz, there was this meme, there was this energy about this company that had all of these PhDs cracking this code with these sophisticated algorithms to scale massive traffic explosion on the internet.”
---
`55:38` Leading Through Layoffs, the Dot-Com Crash, and the Tragedy of 9/11
Akamai’s public debut was an extraordinary financial event—marking the fourth-largest tech IPO in history at that time—fueled by the dizzying heights of the dot-com boom. But when the bubble burst, the company was plunged into an existential crisis. Parikh found himself operating as a first-time line manager navigating traumatic corporate realities for which traditional education offers no preparation. He had to lead his team through successive, grinding rounds of layoffs, facing the emotional toll of having close friends and respected colleagues sitting beside him one day and laid off the next.
The crisis reached its darkest moment on September 11, 2001, when Akamai co-founder Danny Lewin was murdered aboard American Airlines Flight 11. Lewin had been the vibrant soul and driving force of the entire organization; losing him dealt an unexplainable psychological blow to the company's early team. Parikh and the management team had to lead through profound grief while operating without a roadmap, holding team meetings hour by hour, maintaining radical transparency, and supporting shattered employees. Throughout this crucible, Parikh closely observed and learned from senior executives—CEO George Conrades, Paul Sagan, and Tom Leighton—discovering how authentic leaders navigate compounding crises, make agonizing trade-offs, and ensure an indispensable infrastructure company survives.
- Parikh highlights the sudden shock of going from industry darling to fighting for survival: “And not having been through that before, there's just countless learnings every day in terms of 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 learning, like observing them, right, because here I am as a first-time manager learning from them.” - Describing the devastating void left by co-founder Danny Lewin's death on 9/11, Parikh notes: “And, you know, Danny was a force of nature for us as like people that were early in the company and got to work with him closely, losing him was sort of unexplainable in terms of what it did to shift the way we all thought about the mission of the company, what we had to go do.”
---
`59:22` Pivoting to the Enterprise and the Survival Mindset of Efficiency
Following the dot-com crash, Akamai faced an immediate commercial crisis: the dot-com startups that made up its customer base were going bankrupt en masse. Parikh describes the sudden, harsh realization that Akamai had virtually no foundation for surviving in a normalized corporate economy. The company possessed no enterprise-grade product features, no enterprise sales force, no pricing or packaging tailored to traditional corporations, no systems integration partners, and no enterprise support organization capable of serving the Global 2000.
The company had to pull off a desperate, high-velocity transformation over a two- to three-year span while hemorrhaging cash. With its burn rate threatening solvency, the leadership team had to bring its P&L into balance through severe operational efficiency. Parikh explains that this intense focus on efficiency often came at the direct expense of pure product innovation, but it was the only path to survival. Through sheer hustle, intense teamwork, and cultural evolution, Akamai rebuilt its business model from scratch, turning itself into the foundational enterprise infrastructure company it remains today.
| Operational Dimension | Pre-Crash Akamai (Dot-Com Bubble) | Post-Crash Turnaround (Enterprise Pivot) | |:--- |:--- |:--- | | **Customer Base** | High-flying dot-com startups | Global 2000 multinational enterprises | | **GTM & Sales Motion** | Inbound-driven, hype-fueled selling | Structured, consultative enterprise sales force | | **Pricing & Packaging** | Ad-hoc, high-valuation boom pricing | Rigorous enterprise tiering and SLA-backed contracts | | **Support Infrastructure**| Informal, startup-tier response | 24/7/365 mission-critical enterprise support | | **Financial Philosophy** | High cash burn chasing raw top-line growth | Extreme operational efficiency and P&L discipline |
- Parikh recalls the stark vulnerability the company confronted: “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 the Global 2000. And we had to hustle in figuring that out.” - He emphasizes the painful operational trade-offs forced by survival: “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.”
---
`01:01:26` Overruling Zuckerberg: Inceptionizing Efficiency at Facebook
The psychological scars and operational wisdom Parikh acquired during the Akamai near-death experience became the foundation of his technical leadership when he joined Facebook. At the time, Facebook was experiencing explosive top-line growth and had abundant cash reserves. Parikh recounts a pivotal early confrontation with CEO Mark Zuckerberg, who argued that because the company was flush with cash, engineering should direct 100% of its resources toward building consumer-facing product features while ignoring infrastructure efficiency.
Parikh explicitly rejected Zuckerberg's approach. Having survived the dot-com bust, Parikh knew that reckless infrastructure spending is catastrophic when business conditions shift, and attempting to retrofit discipline into a bloated engineering culture later is nearly impossible. Parikh told Zuckerberg: “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.”
Parikh embedded an uncompromising culture of data-driven frugality, custom infrastructure engineering, and CapEx optimization from the earliest days. This deliberate focus led directly to Facebook's radical vertical integration—including custom servers, data center designs, and networking hardware. By systematically squeezing waste out of the compute and storage footprint early on, Parikh preserved billions of dollars in free cash flow, giving Facebook immense capital allocation optionality and strategic resilience for decades to come.
- Parikh recounts the debate with Zuckerberg: “I remember talking to Mark and Mark was like, we have money, so we should just build features and we should put all the engineers working on product. And I said, cool, but I'm going to work on efficiency because I'm not going to go through that journey that we all went through at Akamai, and so we're going to be efficient.” - Parikh explains the strategic dividend of establishing engineering discipline early: “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.”
## Notable quotes > `37:41` Code is an output now. It's not an input. — Jay Parikh
## Mentioned Akamai, Akamai Technologies, American Airlines Flight 11, AWS, Brett Berson, CoreAI, Danny Lewin, Facebook, Facebook.com, First Round, First Round Capital, Fortinet, George Conrades, Global 2000, iOS, Jay Parikh, Lacework, Mark Zuckerberg, Microsoft, Paul Sagan, Tom Leighton
## Video description In the latest episode of Executive Function, Brett sits down with Jay Parikh, Executive Vice President of CoreAI at Microsoft. Before joining Microsoft, Jay spent over a decade as Facebook's global head of engineering, scaling the company from a few hundred engineers to billions of users, then ran the cybersecurity company Lacework as CEO through its acquisition by Fortinet. In this conversation, he breaks down the five ingredients of great engineering leadership, discusses why he'd rather run two competing bets in parallel than forecast a winner, and explains why company culture remains more important than ever for teams to get right.
In today's episode, we discuss:
The five ingredients that separate excellent engineering leadership from the rest
How to protect your team from large shifts in public perception
The mindset shift organizations need to maintain speed at scale
How every layer of the organization needs to stay connected to the customer
Why Jay runs "brain trusts" of senior ICs with zero managers in the room
References
Akamai: https://www.akamai.com/
AWS: https://aws.amazon.com/
Facebook: https://www.facebook.com/
George Conrades: https://www.linkedin.com/in/georgeconrades/
Mark Zuckerberg: https://x.com/finkd
Microsoft: https://www.microsoft.com/
Paul Sagan: https://www.linkedin.com/in/paul-sagan-59654a1/
Tom Leighton: https://www.linkedin.com/in/tleighton/
Where to find Jay
LinkedIn: https://www.linkedin.com/in/jayparikh/
Twitter/X: https://x.com/jayparikh
Where to find Brett
LinkedIn: https://www.linkedin.com/in/brett-berson-9986094/
Twitter/X: https://twitter.com/brettberson
Where to find First Round Capital
Website: https://firstround.com/
First Round Review: https://review.firstround.com/
Twitter/X: https://twitter.com/firstround
YouTube: https://www.youtube.com/@FirstRoundCapital
This podcast on all platforms: https://review.firstround.com/podcast
Timestamps
00:00 Introduction
00:36 How leadership changes through exponential growth
02:21 The five ingredients that define excellent engineering leadership
07:51 What actually drives culture at a company as it scales
12:05 The physics behind why everything slows down at scale
18:57 The fastest team of Jay's career, and why size mattered
22:44 Why every team should think like an FDE
26:20 Managing a team through wild swings in public perception
29:07 What's different about leading through the steepest S-curve moments
33:58 Why onboarding well means going slow to go fast
37:41 Is AI actually new, or is history just repeating?
41:35 What actually counts as a "big bet" worth taking
45:01 The concrete big bets that reshaped Facebook's entire technology stack
47:35 Why vertical integration keeps being the right call as companies scale
51:46 How being a startup CEO reshaped Jay as a leader
1:01:26 Why Jay overruled Zuckerberg's instinct to skip efficiency
[Source](https://traffic.megaphone.fm/FRCH6497933461.mp3)