On June 24, 2026, John Carmack posted a long thread on X. It was a rare reflection on management failures — calm and specific, a stark departure from his usual graphics opinions or VR technology analyses. The thread closed with two understated words: “Sorry, Sandy” — an apology that had been silent for decades in id Software’s history. By then the post had surpassed a million views, and the related discussion on Hacker News had accumulated 468 votes and 235 comments in half a day. Beneath the heat, the thread touched on a question that transcends gaming history: when a technical genius is also the core decision-maker of a team, where are his blind spots?
I have never worked in the game industry, nor have I managed an engineering team. The following analysis is based entirely on Carmack’s public statements, Sandy Petersen’s interview records over the years, and engineering management insights that surfaced in HN and other community discussions. This is a neutral examination of the boundaries of technical leadership.
What the Thread Actually Said
Carmack’s reflection listed four specific items.
The first was excessive ambition in technical choices. Quake introduced full 6DOF environments and 3D character models in 1996, which was revolutionary at the time. But he now believes they could have built multiplayer and mod systems on a “Doom++” engine, letting level designers work on a more stable foundation without being repeatedly “rug-pulled” by underlying tech changes. True full 3D could have been saved for the next title.
The second was runaway work intensity. He admitted he “pushed everyone too hard,” failing to understand that a maturing company needs more buffer — “sustaining startup-intensity indefinitely burns people out.” This was when he truly hit the ceiling of his personal capacity during Quake’s development — even working at what was arguably the limit of human endurance, he was still slipping past his own target dates.
The third was flaws in the company’s equity structure and acquisition terms. The founding team wanted to ensure ownership only rested with those “actively killing themselves on the current project,” but in hindsight, the standard Silicon Valley vesting mechanism would have been a better choice.
The fourth was the most nuanced. Carmack made a point of stating: the requirement that level designers also possess strong visual art skills — “I won’t take blame for that.” He explained that John Romero had established this expectation early on. The real problem was their failure to establish a “artist-designer pairing” mechanism sooner. But there was internal infighting among designers at the time, and those who could handle both visual presentation and design took pleasure in belittling those who couldn’t.
Then came the closing three words: “Sorry, Sandy.”
Who Sandy Petersen Is, and Why “Sorry, Sandy” Matters
Sandy Petersen joined id Software in 1993, just ten weeks before Doom’s official release. In that short window, he built 19 of Doom’s 27 levels — fewer than half of which were based on frameworks left by previous designer Tom Hall. He then contributed 17 of Doom II’s 32 levels.
Petersen’s levels had a distinctive signature. By his own account, his maps were “usually not the prettiest,” but they contained elaborate encounter choreography — rows of explosives leading into monster hordes, pools of water floating in midair, environmental storytelling that hinted at danger ahead. His design was rooted in years of tabletop RPG experience, emphasizing “playability” over “visual appeal.”
The problem was that as 3D technology advanced and material and lighting systems grew complex, id Software’s visual expectations for level designers kept rising. Petersen lacked professional art skills; his maps began to look “not good enough” by Quake-era aesthetic standards. Meanwhile, newcomers like Tim Willits — who possessed both art and design abilities — rose in prominence, and an implicit hierarchy formed within the team: those who could draw looked down on those who could only design.
In Sandy Petersen’s own account, there was serious office politics within the team during Quake’s development. He stated in multiple interviews that the central figure behind the team’s fragmentation was not Carmack, but “someone I refuse to name” — widely interpreted by the community as Tim Willits. Petersen left id Software in 1997, joining Ensemble Studios. Around the same time or slightly earlier, John Romero and several other core members also departed — according to HN user jpgvm’s tally, of the roughly 11-12 people on the Quake team, about 7 eventually left.
And in the original thread that sparked this entire discussion, Sandy Petersen himself wrote a line, partially collapsed by X’s interface: “If my corollary holds — that Quake destroyed id Software — was it worth it? I would say, absolutely. Games matter more than game companies, and Quake is an iconic monument in the world of games.”
Key Perspectives from the Community Discussion
The HN comments weren’t one-sided sentiment or condemnation; the most interesting aspect was the tension within them.
User georgemcbay commented that Carmack’s candid technical and management lessons were certainly valuable, but what he appreciated most was the closing “clear, direct, empathetic apology.” He noted Carmack could have easily used “I was only 24 or 25” as a justification — perfectly acceptable in public perception — but he chose to apologize directly. That carries more weight than any excuse.
User hiddencost took the exact opposite reading, viewing the entire thread as essentially an “insult dressed up as professional courtesy” — Carmack publicly saying “Sandy is a bad designer who lacks visual aesthetics” — “reads as quite uncomfortable and mean-spirited.”
These two readings surface a deeper tension: Carmack, while accepting the boundaries of reflective responsibility, simultaneously refused to take blame for one specific decision. His logic: aesthetic standards were set by Romero early on, belonging to company-level consensus, not his personal failing. But as the company’s technical core and one of its decision-makers, does this posture of “partial responsibility” adequately cover the obligations of a decision-maker’s role? There’s no standard answer, but it’s a question worth every technical leader asking themselves when facing their own “Sorry, Sandy” moment.
User CamperBob2 defended Carmack’s technical ambition: “The ‘could have done Doom++’ argument ignores the fact that everyone was hungry for the next leap back then. Ken Silverman’s Build engine (Duke Nukem 3D) was already on the way, releasing about six months before Quake. Shortening Quake’s timeline would have put both products in direct competition, hurting both sides. Imposing technical dominance was Carmack’s duty. He did it, and shouldn’t apologize or second-guess himself for that.”
User tombert cited the narrative from the book Masters of Doom, leaving this impression: “John Carmack is an extremely intelligent person who is also a person who was potentially a huge asshole.” He said if he had been on the Quake development team, “I would have probably told Carmack to go to hell about halfway through” — even though Quake remains his favorite classic FPS.
User grim_io’s comment was a single line, but possibly the most precise summary of the entire discussion: “Perhaps, extreme excellence is inherently unsustainable.”
The Orthogonality of Technical Ability and Management Ability
From an engineering management perspective, the most thought-provoking aspect of Carmack’s thread is a more structural question: technical ability and management ability are orthogonal.
The quality of Carmack’s technical decisions is well-documented — Quake’s rendering pipeline, QuakeC virtual machine, client-server network architecture, each defined industry standards at the time. But when the lens shifts from “how to build the optimal system” to “how to build and sustain the optimal team,” the same judgment framework can fail. Technical problems have a well-defined solution space — you can enumerate, benchmark, and prove. Human problems don’t.
Specific to id Software’s situation, several management-level observations can be distilled:
First: the trap of the “full-stack talent” preference. Early teams were small, with everyone wearing multiple hats — Romero himself coded, designed levels, and made design decisions. This model worked beautifully in a six-person team, but when the team expanded to a dozen-plus and technical demands escalated sharply, insisting that “level designers must also have art skills” ceased to be elitism and became an overly narrow talent filter. It excluded not just those who didn’t meet standards, but potentially those who were exceptional in a single dimension.
Second: the structural risk of the single-genius model. id Software’s success in the Doom era was largely built on a dual-core structure: Carmack’s technical engine + Romero’s design drive. But when a genius’s individual capacity ceiling is reached (Carmack himself admitted he was “working as hard as humanly possible” during Quake’s development), the system’s growth headroom is simultaneously exhausted. A genius individual can delay this day, but cannot eliminate it.
Third: the absence of a conflict mediator role. Carmack mentioned “internal infighting” among designers — those who could produce good visual work took pleasure in belittling those who couldn’t — but it seems no one stepped in to stop or mediate this behavior. In technology-driven teams, management (if it exists at all) often defaults to “output first,” treating interpersonal friction as a secondary issue. But friction left unaddressed eventually converts to talent loss.
These three problems are hardly unique to Carmack — I saw a flood of empathetic comments from engineers in the HN discussion, noting that similar “technical leader can’t manage people” stories repeat throughout the industry. The difference this time is that the principal himself wrote it out.
Humility Statement
This article is based entirely on Carmack’s public thread, Sandy Petersen’s public interviews, and public discussions from HN and other communities. I have no first-hand exposure to id Software’s internal operations; all management-level inferences are drawn from public materials and do not constitute qualitative judgments about any individual or company. AI tools were used to assist in organizing materials and structuring the article; core judgments and written expression were done by a human.
The management blind spots of technical geniuses are not a problem that needs to be eliminated — they may simply be the cost of a certain kind of creativity. The question is whether, as those who come after, we can see it before the cost is paid.