🚫 Not Invented Here Syndrome 🚫

“Not invented here” syndrome isn’t automatically a virtue or a flaw—it’s a management reflex that can either protect a company’s core advantage or waste years rebuilding what already works. The central tension running through the discussion is credit and control versus engineering pragmatism: teams may reject outside libraries and platforms to avoid losing ownership, yet that same instinct can also be the only way to build a defensible moat when the dependency is truly central to the product.

The conversation starts with a personal audit of Netflix-era engineering decisions, including building bespoke networking components and a WebSocket implementation. That raises the question of intent: was the work a strategic move to enable live updates and tight integration, or a “we’ll do it ourselves” habit? The takeaway is that the label “not invented here” can hide two very different realities—sometimes reinvention is necessary for performance, reliability, or differentiation; other times it’s just organizational pride.

A broader critique follows, aimed at the culture of reinventing everything even when the cost is obvious. The discussion points to dependency bloat and “reinventing the wheel” as a recurring software failure mode, illustrated by the absurd popularity of tiny utilities like left-pad—an example used to argue that modern teams often overvalue self-reliance while underestimating the operational drag of maintaining custom code. The speaker also pushes back on simplistic “always reuse” thinking: code reuse becomes harmful when it turns into over-abstraction, feature flags, and boolean-parameter spaghetti that makes systems harder to reason about and harder to change.

The most concrete guidance emerges as a rule of thumb: destroy dependencies at the level where the business truly needs control. Hand-rolling core infrastructure like HTTP servers is usually unnecessary, but building or owning the parts that define the product’s competitive edge can be justified. Examples range from Netflix’s internal tooling evolution (moving from a custom build system toward webpack and then questioning tradeoffs) to work at companies like Workiva, where custom rendering and platform-specific capabilities were built because they were essential to the core product experience.

The transcript also tackles the organizational side. “Not invented here” is described as a classic management pathology—teams refusing outside tech not because it’s worse, but because they can’t take credit for it. Yet the counterweight is that mediocre teams may need fewer dependencies to reduce cascading upgrade failures and brittle integration. In practice, the right balance depends on team quality, incentives, and whether external components deliver on time and with the reliability the product requires.

Finally, the discussion broadens into outsourcing and platform dependence. Outsourcing can be a nightmare when customer-facing functions are involved, because partners may interpret “prompt delivery” differently and customers can’t reach the company directly. Even cloud infrastructure like AWS is treated as “good enough to get it done,” with the surrounding ecosystem often requiring extra layers to make it usable. Across these examples, the throughline is consistent: reuse and reinvention both have costs, and the decision should be tied to business-critical differentiation—not ego, credit, or blanket ideology.