Meta Distinguished Eng (IC9) On Influencing Engs, Failures, and Learnings

When Adam Ernst joined Facebook in 2012, the company was on the precipice of its IPO and in the middle of a massive, existential shift from HTML5 to native mobile apps. Over the next decade, Ernst navigated the chaotic growth of one of the world's largest codebases to become a Distinguished Engineer (IC9) at Meta. His journey wasn’t just about writing better code; it was about learning how to steer the ship of a massive organization without holding a management title.

From architectural triumphs like Component Kit to humbling failures like Component Script, Ernst’s career offers a masterclass in technical leadership. He demonstrates that the highest levels of individual contribution aren't achieved in isolation, but through aggressive problem-solving, strategic influence, and the courage to kill your own projects when they don't work.

Key Takeaways

• Influence by execution: The most effective way to convince skeptical teams to adopt a new architecture is to do the migration work for them, transforming a theoretical debate into a simple "yes or no" decision.
• Face-to-face communication wins: When driving controversial technical changes, replace text-based debates with in-person or video conversations to convey empathy and resolve conflicts faster.
• Depth creates breadth: You don't need to study every system in the abstract. By diving "eight levels deep" to fix specific bugs in dependencies, you organically build a broad understanding of the entire stack.
• Fail responsibly: When a project isn't working, admitting defeat early and cleaning up the codebase generates more goodwill than dragging a zombie project along.
• Code reviews are cultural tools: High-volume code reviews (Ernst once did 1,600 in six months) are an underutilized vector for spreading engineering culture and best practices across an organization.

Scaling Native Infrastructure and Influencing Without Authority

When Ernst joined Facebook, the mobile team was small enough to fit in a single conference room. However, the rapid shift to native code created immediate scaling issues. One of the first major hurdles was Apple’s Core Data frameworks. While excellent for small apps, Core Data crumbled under the weight of Facebook's scale, leading to performance bottlenecks and stability issues.

Ernst’s solution was to move toward immutable models, a significant departure from the "vanilla Apple" frameworks that many engineers preferred. The challenge wasn't just technical; it was political. Convincing a growing team of iOS purists to abandon standard Apple tools required more than just a design doc.

The "Coding Machine" Archetype

To overcome resistance, Ernst adopted a strategy he calls the "coding machine." Rather than simply arguing for a new architecture, he built the scaffolding and performed the migrations himself. By reducing the friction for other teams, he shifted the conversation from "should we do this work?" to "is this code acceptable?"

If you show up, you're like, "Hey, I did the work already for you. Here are the benefits. I just need you to sign off." Much easier conversation.

This approach requires significant effort, but it bypasses the paralysis that often plagues large organizations. However, Ernst notes that as codebases grow to the scale of Meta's current monorepo, this "lone wolf" migration strategy becomes harder, necessitating more formal alignment and consensus-building.

Empathy in Technical Debates

Ernst emphasizes that technical correctness is rarely enough to win an argument. When proposing non-standard solutions, he advises acknowledging the opposing viewpoint immediately. By validating that "vanilla" frameworks are generally good, you lower defenses, making the data-driven case for why they fail specifically at your scale more persuasive.

Component Kit: Bringing Declarative UI to iOS

By 2014, Facebook News Feed had become a complex beast, suffering from crashes and layout bugs. Lee Byron, a co-inventor of GraphQL, suggested applying the concepts of React (which was revolutionizing the web) to iOS. This suggestion led Ernst to build Component Kit, a declarative UI framework for iOS that predated SwiftUI by years.

The framework introduced concepts like one-way data flow and view reconciliation to native mobile development. Despite the technical benefits—such as offloading layout calculation to background threads—the pushback was immense. The syntax (Objective-C++) was alien to many iOS developers.

Ernst utilized two main levers to drive adoption:

1. Performance Data: Concrete metrics showing frame rate improvements and crash reductions helped silence subjective arguments about code style.
2. Allies and Compromise: Ernst leaned on senior engineers with high social capital to mediate disputes. Furthermore, he compromised with the "Panels" team—a competing internal framework—by adopting their data source technology. This turned potential rivals into collaborators, unifying the engineering efforts.

Component Script: The Anatomy of a Failure

Not every ambitious project succeeds. Ernst is candid about the failure of Component Script, a project intended to solve the cross-platform dilemma. The goal was to allow engineers to write logic once and deploy it across iOS and Android, without the "all-or-nothing" constraints of React Native at the time.

Despite checking every box on the technical requirements list—type safety, GraphQL integration, and bidirectional interoperability—the project failed to gain traction. Ernst worked on it for nearly two years before pulling the plug.

Why It Failed

The failure was rooted in a misunderstanding of user personas. The framework required writing a variation of JavaScript. Native iOS engineers had no interest in learning JavaScript, and Web engineers preferred standard React Native over Ernst’s custom solution. It was a product with no market.

Additionally, Ernst fell into the sunk cost trap. Despite sleepless nights and a gut feeling that the project was stalling, he doubled down on coding rather than stepping back to reassess the strategy.

I'm a coding machine. So my reaction was I just need to write more code... I should have listened instead to that part of my gut that was telling me this is not going to work out.

The Art of killing a Project

The turning point came when Ernst received a "Meets Most" performance rating—a signal that his effort was not translating to impact. His response to this failure serves as a guide for senior engineers:

• Public Postmortem: He wrote a detailed internal breakdown of why the project failed, preventing others from repeating the mistake.
• Clean Up: He didn't abandon the code. He helped the few teams using Component Script migrate back to native code and deleted the framework entirely.

By handling the shutdown responsibly, Ernst actually garnered goodwill. It demonstrated that he prioritized the health of the codebase over his ego.

The Philosophy of an IC9

Reaching the level of Distinguished Engineer requires a specific mindset regarding depth, breadth, and time management.

Depth vs. Breadth

There is a common debate in engineering about whether to specialize (depth) or generalize (breadth). Ernst argues that the two are not mutually exclusive; in fact, depth is the most effective way to achieve breadth.

When Ernst encounters a bug in a dependency—like the GraphQL codegen—he doesn't just file a ticket for another team. He dives into the source code, often several layers deep, to understand the root cause. By fixing the problem himself, he gains deep knowledge of a system he didn't previously understand. Over a decade, this habit results in a comprehensive map of the entire technical stack.

The Value of Code Reviews

Ernst is known for an absurd volume of code reviews, once logging 1,600 reviews in six months. He views code review not just as error-checking, but as the primary mechanism for organic influence.

Instead of writing abstract strategy documents that no one reads, he uses specific diffs to teach architectural principles. A well-crafted comment on a specific line of code can change an engineer's mindset forever, creating a viral effect as they apply that learning to future work.

IC vs. Management

For engineers eyeing the management track, Ernst offers a simple heuristic: Do you love the code, or do you love the alignment? Ernst recognized early on that he despised writing alignment docs and lacked the patience for high-level "direction setting" that didn't involve looking at code.

By staying on the IC track, he maximized his impact by focusing on what he enjoyed—solving complex logic puzzles—rather than forcing himself into a role that would drain his energy. His career stands as proof that you do not need to become a manager to shape the direction of a trillion-dollar company.

Conclusion

Adam Ernst’s progression to IC9 wasn't a straight line of successes. It was a jagged path of scaling challenges, political maneuvering, and significant failed experiments. His success came from an unrelenting willingness to dive into the "guts" of the system, a proactive approach to unblocking his peers, and the self-awareness to stick to the work that fueled his curiosity.