Egoless Engineering

Egoless Engineering argues that software teams work best when they minimize ego, parochial ownership, and heavy process in favor of shared responsibility, high trust, and direct collaboration across roles. Commenters broadly agree that clear team values, end-to-end ownership, and psychological safety can unlock speed and quality, but note that many organizations instead optimize for politics, rigid structures, and risk-avoidance, which erode autonomy and morale. The exchange grapples with how far such “egoless” cultures can scale, how to balance guardrails with freedom, and whether strong individual egos are inherently harmful or sometimes essential to leadership and innovation.

Intentional team values & leadership hypocrisy

  • Many liked explicit, concrete team values (e.g., “no one is above grunt work,” “leave things better than you found them”) and noted most teams never define norms at all.
  • Several warned that “values” are often weaponized: leaders proclaim them but exempt themselves, or reuse them as performance-review tools while real promotion criteria differ.
  • Consensus: only adopt values leaders visibly live; call out purely aspirational or performative ones.

Ownership, process, and politics

  • Strong support for end‑to‑end ownership to production; people find it motivating and productive.
  • Numerous stories where layered roles (PM, staff, lead, senior, EM) turn work into a political turf fight over “credit” and perf‑review talking points, diluting ownership.
  • Many complain about ticket‑driven development, excessive ceremonies, and “reactive” process changes after rare incidents that create long‑term drag.
  • Some describe healthy patterns: slack time, on‑call rotations as “maker weeks,” shared repos without strict codeowners, lightweight guardrails instead of hard gates.

Trust, psychological safety, and access

  • High‑trust environments (especially early‑stage startups and some big‑company pockets) are described as more productive and enjoyable: easy access, low micromanagement, cross‑functional collaboration.
  • Low‑trust orgs hide systems, over‑restrict permissions, and micro‑manage; these are linked to project failure and attrition.
  • Managers who “shield” teams so they can pursue risky, high‑impact bets are praised.

Quality vs features & metrics

  • Debate over prioritizing reliability vs rapid feature delivery.
    • One side: customers prefer working software; orgs should turn down “features dial” and up “ops/quality dial.”
    • Others argue this is a false dichotomy: limited resources and competitive pressure mean features often must win, even with minor bugs.
  • Agreement that metrics (coverage, incident counts, feature counts) can easily be gamed and must be treated with skepticism.

Ego, “egoless” engineering, and incentives

  • Some see ego as natural and even necessary (pride, drive, ownership); the goal is channeling it toward team outcomes, not erasing it.
  • Others argue success comes from aligning self‑interest with collective benefit via incentives and structure, rather than relying on pure selflessness.
  • There’s skepticism that “egoless” cultures can survive in large capitalist orgs where hierarchy, performance management, and politics are structural.

Leaders, “brilliant assholes,” and the Musk example

  • The slide using Musk as a narcissism example was divisive:
    • Some saw it as apt illustration of toxic but effective leadership styles the talk argues against.
    • Others viewed it as gratuitous, political, or hypocritical in a talk on egolessness, and disputed his effectiveness at Twitter/X.
  • Broader point: charismatic “asshole” leaders sometimes succeed, but commenters warn about survivorship bias; most orgs copying that style just become dysfunctional.

Scaling, guardrails, and bad actors

  • Several note that fully “egoless, permissionless” cultures can fail at scale without guardrails: mandatory reviews, tests, security and compliance constraints.
  • A recurring tension: allow designers/PMs/etc. to deploy vs. the real risks of outages, security issues, and burnout of domain experts.
  • For chronically careless or unapologetic people, suggested options are: coaching, eventually firing, or—if that’s impossible—accepting heavier process and bureaucracy as compensation.