If we had the best product engineering organization, what would it look like?
A keynote-derived essay on what a “best in class” product engineering organization might look like prompted debate over metrics, management structures, and culture. Commenters contrasted inverted or XP-style teams that emphasize autonomy, internal quality, and shared engineering philosophy with FAANG-style incentive systems, hierarchical decision‑making, and shallow productivity metrics. Others questioned how realistic or measurable these ideals are in practice, raising concerns about cargo‑cult agile, burnout from poor on‑call training, and the gap between corporate rhetoric and day‑to‑day reality.
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.