HN Debrief

There are a few things that I look back on as my mistakes in the early days

  • Gaming
  • Leadership
  • Startups
  • Programming

The post is a Carmack reply to Sandy Petersen’s anniversary thread arguing that Quake was a masterpiece that also “ruined” id Software by gutting the team that made Doom-era id special. Carmack agrees with more of that diagnosis than many expected. He says he pushed everyone too hard, failed to leave enough slack as the company matured, and handled people issues badly. He also points to a specific structural mistake in how id treated level designers, expecting them to be both strong gameplay designers and strong visual artists instead of pairing those roles earlier. The “Sorry, Sandy” line landed as a genuine apology for failing to resolve that setup and the conflict around it before Petersen left, not as a jab.

If you are building a company around exceptional technical talent, do not assume intensity scales with headcount or that one breakthrough product justifies a broken team. Separate technical ambition from organizational design early, especially once the rewards, autonomy, and job shape stop resembling a founder-led startup.

Discussion mood

Admiring but unsentimental. People still revere Quake and Carmack’s technical achievement, yet the dominant mood is that the game’s brilliance does not excuse burnout, poor people management, and the loss of the team that made id exceptional.

Key insights

  1. 01

    The apology is about management failure

    The key read on “Sorry, Sandy” is not that Petersen was the problem. It is that Carmack is owning a failure to manage team conflict and role design before it drove people out. That framing makes the post less about one design dispute and more about a leader realizing too late that brilliant teams can still blow apart if nobody handles the human side.

    If a senior contributor leaves after months of role friction and status fights, treat that as a management failure even when no single technical decision looks fatal. Fix ownership and collaboration patterns before they turn into personal camps.

      Attribution:
    • jpgvm #1
    • silotis #1
    • wlesieutre #1
    • itishappy #1
  2. 02

    Founder intensity stops scaling with incentives

    Several comments nailed why the same pace feels different as a company grows. Founders may rationally grind because they hold real control and life-changing upside. Employees usually have neither. Once compensation compresses into salary bands, small raises, and limited equity, demanding startup-level sacrifice becomes structurally incoherent, not inspirational.

    Match expectations to actual upside and autonomy. If you need extraordinary effort from non-founders, change the reward structure or narrow the ask to short, explicit pushes instead of treating permanent overwork as culture.

      Attribution:
    • manphone #1
    • fatnoah #1
    • zasz #1
    • steveBK123 #1
  3. 03

    id kept shipping tech after losing product leadership

    The useful distinction is that id did not suddenly become bad. It stayed technically elite while losing the broader lead in what players wanted next. Comments point to Quake III as great but specialized, Doom 3 as a rendering showcase, and later engine bets like MegaTexture as impressive yet not clearly market-shaping. Meanwhile Valve and Epic were defining the next era in storytelling, multiplayer breadth, and engine ecosystems.

    Do not confuse technical excellence with category leadership. If your company is world-class at the stack but rivals are setting user expectations, your lead is already narrower than it looks.

      Attribution:
    • blt #1
    • pizza234 #1
    • vor_ #1 #2
  4. 04

    The hard part is the startup-to-company transition

    The sharpest management comments were about phase change. Founders who thrive in improvisation often struggle when the job becomes delegation, process design, and conflict containment. Technical debt and cultural debt compound together during this stage. If leaders do not adapt, the usual outcome is a crisis followed by outsiders cleaning up the mess after a lot of avoidable damage.

    Treat the shift from scrappy team to durable company as a different job, not a bigger version of the old one. Add managers, operating habits, and role boundaries before growth forces them on you in a panic.

      Attribution:
    • palmotea #1
    • torben-friis #1
    • _doctor_love #1 #2
  5. 05

    Quake succeeded because the leap mattered

    A strong defense of the original decision is that “Doom++” would have missed what the market wanted. Quake’s value was not just a sequel with better levels. It was the package of full 3D, client-server networking, QuakeC, and a mod-friendly engine that became foundation tech for everything from Team Fortress to Half-Life. That helps explain why people still see the project as worth doing even if they reject repeating the process that produced it.

    When choosing between incremental product work and a real platform jump, be clear which bet creates lasting leverage. Then build the team and timeline for that bet instead of pretending a frontier project can be run like a routine sequel.

      Attribution:
    • BiscuitBadger #1
    • pipeline_peak #1
    • LarsDu88 #1
    • ipython #1
  6. 06

    Bottlenecks around one genius distort the whole org

    Comments about Quake’s development bottleneck sharpened a broader lesson. When too much of the roadmap depends on one person finishing foundational technical work, everyone else either stalls, backfills with side work, or scrambles late. That can still yield a masterpiece. It also creates burnout, compromises product quality, and makes departures more likely because the rest of the team spends long stretches adapting to one moving center of gravity.

    Watch for projects where one indispensable builder silently becomes the schedule for everyone else. Split milestones, reduce coupling, or add parallel tracks early so the organization does not inherit the shape of one person’s queue.

      Attribution:
    • BiscuitBadger #1
    • Jare #1
    • georgemcbay #1

Against the grain

  1. 01

    The painful process may have been worth it

    A real minority view is that this kind of wisdom is distorted by success and hindsight. Quake did not merely ship. It changed the medium, and even Sandy Petersen says the result was worth gutting the company because the game itself mattered more. That does not make the management good. It does challenge any neat conclusion that a less punishing path would have produced the same breakthrough on the same timeline.

    Be careful about turning postmortems from exceptional wins into universal process doctrine. Some frontier products probably do require concentrated intensity, but you should name that tradeoff explicitly rather than smuggling it in as normal operations.

      Attribution:
    • avaer #1
    • stephbook #1
    • twoodfin #1
    • somecontext #1
  2. 02

    Quake 2 and Quake 3 were still elite

    Some comments pushed back on the idea that Quake marked a clean creative collapse. They argue id remained dominant for years, with Quake 2 refining multiplayer and Quake III becoming a genre benchmark whose movement and competitive design still hold up. On this view, the company lost its solitary lead, not its ability to make great games.

    Do not overread a founder-era breakup as instant decline. A company can lose its original magic and still have a long period of high performance, especially in narrower product segments.

      Attribution:
    • LarsDu88 #1
    • efficax #1
    • vkazanov #1
  3. 03

    Some studios did absorb the lesson

    Not everyone accepted that breakthrough game development is doomed to eat its own team. Comments pointed to Supergiant as a studio with steady output and low visible turnover, and to modern id releases like Doom 2016 and Doom Eternal as proof that strong games can emerge after the myth of one tortured genius. That weakens the fatalistic story that great games require a broken company.

    If your industry romanticizes burnout as the price of excellence, look for operators who are already disproving it. Use them as benchmarking cases for staffing, cadence, and retention instead of copying the old legends.

      Attribution:
    • malnourish #1
    • hugodan #1
    • pipeline_peak #1

In plain english

client-server networking
A networking model where one machine acts as the server and other players connect as clients, which became standard for multiplayer games.
MegaTexture
A rendering technique, later often called virtual texturing, that streams very large textures so large game worlds can have detailed surfaces.
modding
Players or developers changing a game by adding new content, rules, or features, often using the original game as a base.
QuakeC
A scripting language used in Quake that let developers and modders define gameplay behavior without rewriting the whole engine.

Reference links

Primary source and direct context

Books and long-form history

Game history and live demos

Technical references

  • Shadow volume
    Linked to explain Doom 3’s signature lighting technique
  • Prey (2006)
    Used to clarify which long-delayed Prey game commenters were discussing