You Are Not Netflix: How to learn from conference talks

You Are Not Netflix: How to Learn from Conference Talks

Speakers: Rami McCarthy

Conference: fwd:cloudsec North America 2025

YouTube: https://www.youtube.com/watch?v=pRrK9PNz2GM

Overview

Rami McCarthy, a security researcher at Wiz, delivered a meta-talk about how security practitioners should critically evaluate conference presentations to extract genuine value rather than blindly copying architectures, tools, and approaches that may not fit their organizations. The talk's thesis is that public security information — whether conference talks, blog posts, or social media — is always partial, shaped by organizational constraints, contractual obligations, social incentives, and time limitations. McCarthy argues that practitioners should come to conferences with specific problems to solve rather than treating talks as a buffet of things to build, and that speakers should provide more organizational context about why they made the choices they did.

Background

▶ Watch: Audience participation: have you always been 100% honest in public talks? (1:30)

The title references the common pattern of practitioners seeing impressive technical achievements from large-scale companies (Netflix, in particular) and attempting to replicate those solutions without understanding the specific constraints that necessitated them. McCarthy credits a 2014 blog post by Dave Shackleford, "Rethinking the Security Con," as early precedent for this critique, arguing that the problem of misapplied conference learnings has existed for at least a decade.

The underlying dynamics are well-understood but rarely discussed explicitly: speakers want to be accepted to conferences and look smart on stage, organizations restrict what can be shared publicly (contracts, legal risk, embarrassing context), and time constraints force speakers to present a curated narrative that necessarily omits tradeoffs, failures, and organizational politics. None of this is malicious — it is the structural incentive landscape of public knowledge sharing in security.

Key Findings

▶ Watch: Netflix multi-cloud architecture: impressive, but you should not build it (7:30)

Conference talks are structurally incomplete. McCarthy identifies several categories of missing context: why a build decision was made (budget constraints, vendor politics, headcount allocation), what alternatives were considered beyond the build-buy-adopt framework, organizational dynamics that drove technical decisions (not just technical requirements), cost externalization to other teams, and the long-term maintenance burden of custom-built systems.

Netflix's multi-cloud architecture is not for you. McCarthy uses Netflix's well-known account segmentation pattern (identity in one account, compute in another, data elsewhere) as the canonical example of an impressive architecture that most organizations should not attempt to replicate. Netflix built it because they have 10+ years of data gravity, enormous resource volumes that blow out account service limits, and legacy systems they must accommodate. If you are in three AWS accounts with one SaaS product, you are probably fine with simpler patterns.

Chris Farris's AntiPE is instructive. The distributed Lambda-based inventory system was a good solution for its time and organization, but the blog post describing it omits the specific cost, scale, and organizational constraints that drove the decision. In 2025, there are better first-party products, third-party solutions, and open-source options. Practitioners discovering the talk today might build something similar without realizing the landscape has changed.

Build talks rarely address outcomes. Many talks present a system or program at the moment of completion — when the speaker is excited about the achievement — without waiting to see if it delivers sustained value. McCarthy notes that speakers frequently leave the company within a year, the system becomes unmaintainable, and the organization eventually buys a commercial product anyway. A talk given three years into a system's lifecycle would be far more valuable than one given three months after launch.

Security practitioners are bad at evaluating statistics. Numbers cited in talks (e.g., "66% of cloud incidents are caused by leaked IAM keys") rarely come with source attribution or methodology. McCarthy references the "Myths and Lies in InfoSec" work as a deeper exploration of commonly bandied-about statistics that do not withstand scrutiny.

The marketing-substance matrix matters. Every talk exists somewhere on a spectrum from pure marketing to pure substance. Sponsor talks warrant slightly more skepticism as they may not have gone through a full CFP process. McCarthy is explicit that some marketing is fine — 10% marketing and 50% useful substance is a good ratio — but practitioners should consciously evaluate where each talk falls.

Technical Deep Dive

▶ Watch: Yuba Disaster: hidden PKI predicate that may block implementation (10:00)

This is not a technical talk in the traditional sense. McCarthy does not present tools, architectures, or code. The technical content is in the framework for evaluating technical talks:

Predicate identification. Every technical achievement has prerequisites that the speaker may not enumerate. Yuba Disaster (YubiKey-based break-glass access from fwd:cloudsec 2024) either requires a sophisticated PKI infrastructure that you need to build first, or McCarthy's understanding of PKI is wrong and it is easier than it looks. Identifying which predicates your organization has and which it lacks determines whether a solution is applicable.

Temporal relevance. Netflix's RepokiD was innovative when it screen-scraped Access Advisor because Access Advisor did not have APIs. Access Advisor has APIs now. The solution is no longer relevant to your environment even if the problem still is.

Organizational context extraction. The most valuable questions to ask speakers are often not about the technical implementation but about the organizational decisions: Was build-versus-buy actually evaluated? What was the inciting problem? How long has the system been running? What would you do differently? These questions are usually not answerable from the talk itself but speakers are generally happy to discuss them in person.

Demo / Proof of Concept

▶ Watch: Dave Shackleford's 2014 critique: worry about your S3 buckets first (12:00)

No demo was presented. The slides are available on Speaker Deck (linked during the talk). McCarthy also publishes detailed CFP submissions on his personal website as examples of thorough talk proposals.

Defensive Implications

▶ Watch: What good looks like: HashiCorp IAM scaling talk shows bumps over six years (16:00)

The primary defensive implication is meta-cognitive: security teams should develop disciplined evaluation habits for conference content before attempting to implement what they see. Specific practices include:

Come to conferences with a written list of problems your organization needs to solve. Use talks to find solutions to those problems rather than discovering new problems to worry about. When a talk presents an impressive solution, ask yourself: do I have this problem, do I have the same predicates, and is this still relevant in the current landscape?

Connect with speakers personally and ask the questions that were not answered in the talk: Was this a build-versus-buy decision? What organizational dynamics drove it? How long has the system been running and is it still in use? What alternatives were considered? Speakers generally want to share this context but cannot do so on stage.

For speakers: include at least one slide of organizational context explaining why you built what you built. Consider adding a "questions to ask me after the talk" slide that signals which topics you are willing to discuss but could not cover on stage.

Key Takeaways

• Come to conferences with problems, not an empty basket: Treating talks as a buffet of things to build leads to implementing solutions without having the problems they solve.
• You are not Netflix: Impressive architectures from large-scale companies exist because of constraints you do not have; simpler patterns are probably right for you.
• Build talks rarely address outcomes: The system that sounded amazing at launch may be unmaintained and replaced within two years.
• Ask speakers the hard questions in person: Why did you build instead of buy? What alternatives did you evaluate? How long has this been running? Speakers are usually happy to share this context privately.
• Check the timestamps: Technical solutions become obsolete as platforms evolve; a tool built to screen-scrape an API that now exists is no longer relevant.
• Give better talks: Be more vulnerable about organizational context, failures, and constraints; the community benefits more from honest experience than polished success stories.

About the Speaker(s)

Rami McCarthy is a security researcher at Wiz. He previously held other security roles, with three out of four jobs found through the fwd:cloudsec Slack community. He is a regular attendee and speaker at fwd:cloudsec and also advises startups. He publishes detailed CFP submissions on his personal website and talk slides on Speaker Deck. McCarthy explicitly acknowledged the irony of critiquing conference talks at a conference, and framed the talk as an invitation for the community to raise the bar on context and honesty in public knowledge sharing.