If we had the best product engineering organization, what would it look like?

Organizational structure and culture

  • Many commenters like the “de-FAANGed” org vision: inverted structure, tactical decisions by ICs, emphasis on simplicity, maintainability, and Extreme Programming (XP).
  • Others are skeptical, saying similar promises are common but rarely match where budgets, hiring power, and real authority sit. Some think genuine inversion is only realistic in cooperatives.
  • Several see the post as a rare example of a technically competent, grounded executive versus typical senior leadership seen as detached and obsessed with stack-ranking and “impact.”

Measuring engineer productivity

  • Strong disagreement over the claim that productivity can’t be measured.
  • Some call that a cop-out: managers must distinguish performance to hire, promote, and fire.
  • Others argue you can’t get precise, objective metrics, only noisy proxies plus judgment.
  • Proposed metrics include: shipped, used, low-bug, maintainable code; stakeholder satisfaction; qualitative peer feedback; and tracking deltas over time rather than absolutes.
  • Concerns: easy metrics (LOC, PR count, story points) are gameable, bias toward shallow work, and miss invisible enabling work. Some engineers appear productive but create long-term cost.

XP, pair programming, and collaboration

  • A number of commenters endorse XP and fast tests, citing real incidents where good internal quality enabled very rapid bug fixes.
  • Others dislike enforced pair programming, describing it as cult-like. Clarifications offered: classic pairing means two people at one machine (or shared screen), one driving and one navigating; variants like “mob programming” exist.
  • Some doubt XP can work in typical orgs with language barriers, uneven skills, and low psychological safety.

“The company way” and onboarding

  • There is appreciation for having an explicit engineering philosophy and onboarding that aligns new hires, with Amazon cited as an example (design docs, APIs, SOA).
  • Debate over “Amazon does not use relational databases”: some say RDBMS use is discouraged and requires justification; others give concrete examples of internal MySQL/Postgres use. Overall consensus: RDBMS are used, but often de-emphasized.

Leadership, hierarchy, and CEO decisions

  • Some commenters criticize “leadership skills” as often meaning managing up, hoarding information, and building fiefdoms; others counter with more constructive definitions (seeing risks early, coordinating teams, clarifying conflicts).
  • A side thread debates whether CEOs are really uniquely capable decision-makers versus beneficiaries of hierarchical structures.
  • Meta’s metaverse push is framed by some as a rational high-upside bet, by others as unfocused FOMO and poor execution, with no agreement.

Reception of the article and visuals

  • Many find the talk/article refreshing, well-structured, and practically useful, especially around rewrites, quality, and a behavior-focused career ladder.
  • Others see it as buzzword-heavy “corporate fiction” and story-driven management theater.
  • Several strongly dislike the AI-generated illustrations, calling them low-quality “slop” that undermines credibility and adds no value.