Mike Spitz · 04:54 "Scrum did not survive. We abolished sprint planning, daily standups, and sprint refining. Engineers are no longer the bottleneck — so the old ceremonies are all unnecessary."
Mike Spitz's AI Engineer Europe 2026 talk is an organizational argument with the strong coinage "post-engineer engineering org" as its core thesis. PFF (Pro Football Focus) is a 200-person company that runs a data analysis business for NFL / NCAA teams alongside a consumer fantasy football service (about 20 engineers, fully distributed across India, Spain, and the US). It supports 100M page views/year and 9M drafts/year, but had been stuck — falling behind competitors on the consumer side while focus went to sports betting.
Mike began personal experiments with Claude Opus in November 2025, and over the two months from January to March he ran a case study with two engineers (the strongest front-end engineer and the strongest full-stack engineer). The numbers from that case study are the core data of the talk. The headline figures are striking, but Mike's focus isn't on them — it's on the organizational question: what happens to ceremonies once engineers are no longer the bottleneck?
Summary of results — 25x deploys, 10x output, customer satisfaction up by 1.1
The two-month case study numbers:
- Deploy frequency 25x — two engineers ran 5 deploys per day; the comparator 10-engineer team ran 1 deploy every 5 days
- Output 10x — a blended metric of ticket count by code complexity
- Construction time halved — features estimated at 4 months shipped in 2
- Compounding effect of parallelism — once one engineer is unblocked in a month, other work runs in parallel from there (previously both engineers were blocked for 3 months)
- Customer satisfaction 8.6/10 — a statistically significant survey result, against a historical average of 7-7.5
Mike is candid about the caveats. "A small team will obviously be faster than a big team — part of the multiplier is the team-size effect. But the small tiger team also had to coordinate with the big team, and that overhead is included in the 25x." The most important metric, he says, is customer satisfaction: "no matter how much output and how fast the deploys, if customers aren't happy it doesn't matter." The 8.6 broke PFF's historical ceiling, which had previously capped around 7-7.5.
"Scrum did not survive" — abolishing the ceremonies
The talk's core message is "Scrum did not survive." Ceremonies PFF abolished in two months:
- Sprint planning — ticket estimation no longer carries meaning (estimates don't predict outcomes)
- Daily standup — ticket status is bound to PR state and updates automatically (PR open = in progress; in review = review; merged = closed)
- Sprint refining — replaced by the spec → LDD flow
- Retrospective — replaced by development metrics like customer satisfaction surveys and deployment frequency
- The project manager role — "multiple games of telephone" no longer needed
What remains: a single thing called the huddle. "Every other day, 30 to 60 minutes, one engineer plus one product plus one design. Share what we've built in the last few days, instant feedback, get the MVP shipped to production as fast as possible, maximize feedback." "This is abolishing two decades of process at once — it may sound strange, but hear me out: what was this meeting's purpose? Just that everyone has been doing it until now?"
The new workflow — Spec → LDD → automated tickets → PR → QA agent
The new development flow shifts weight toward documentation, in the space ceremonies used to occupy.
- Spec phase — an agent interviews the engineer to produce the spec (agent asks questions, engineer answers). Feedback goes back into the spec
- LDD (Lightweight Design Document) phase — a skill analyzes every past LDD and generates the new one. This keeps the "same ethos" across all features. Removes the "made by Claude Code" feel and preserves PFF's design taste
- LDD distributed — all engineers give feedback; the design discussion concludes here
- Automated ticket generation — blocking relationships analyzed automatically, tickets emitted to maximize parallelism
- Automated PR generation → tickets auto-update based on PRs
- QA agent after staging deploy — verifies acceptance criteria chronologically, flagging pass / fail
The next step (Mike previews "in the next couple months") is self-healing: when the QA agent finds an unmet acceptance criterion, another agent automatically generates the fixing PR. "We enter the flow of agent fixing agent." Sits between Anthropic's Skills loop and Karpathy's autonomous coding vision — the reality layer PFF is actually implementing.
An era marker called the post-engineer engineering org A coinage Mike Spitz (PFF) introduced at AI Engineer Europe 2026. The past 30 years of software engineering culture — the agile manifesto, software craftsmanship, the standard perks (foosball tables, sleeping pods) — were optimizations premised on engineers being the bottleneck. With AI agents now greatly expanding the supply of engineering capability, the bottleneck has moved from engineers to the domains of decision-making, spec writing, and customer satisfaction. The engineering org itself needs to be redesigned to match: drop the conventional Scrum / sprint planning / daily standup ceremonies and shift to a spec → LDD → automated execution pipeline. PFF's two-month case study showed 25x deploys, 10x output, and a +1.1 customer satisfaction.
The coinage Mike returns to throughout the talk is "post-engineer engineering org." He sets out the past culture of software engineering this way: "The agile manifesto, software craftsmanship, foosball tables, sleeping pods, perks that don't exist in other industries — all of it emerged because engineers were the bottleneck." Engineers were scarce and expensive, so companies built competitive advantage by optimizing for them.
"But things are just changing now." Once engineers stop being the bottleneck, the supporting infrastructure (organizational structure, process, perks) becomes over-optimized ruins. "Engineers are still needed — but the role is different." Moving from writing code into writing specs / LDDs / system designs / agent guardrails.
Mike's definition of "the engineers who'll thrive" vs "the engineers who'll struggle":
- Thriving engineers — the curious. The type who, when they don't understand something, spend time figuring it out themselves. Self-directed learning and experimentation
- Struggling engineers — those who need prescriptive specs. The type who can't move without being told "do this, then this" in detail. Agents take over that role, so the value humans add diminishes
This split aligns exactly with Karpathy's Software 3.0 / Agentic Engineering vision. But where Karpathy speaks of it as the future, Mike speaks of it as the result of a two-month case study run at PFF.
Where engineers remain — Security, Product Feel, Scale
The three domains Mike explicitly says cannot be delegated to agents:
- Security — "agents take shortcuts" — they tend to deprioritize security for efficiency. Engineer judgment is required
- Product feel — "anyone can build anything in an hour now, but many tools feel like they were built by Claude Code." Keeping the PFF product feel is engineer work
- Scale and engineering complexity — agents tend to over-engineer and write 1,000 lines of unneeded code. Preventing this with a prescriptive LDD is engineer work
Engineer value in these three areas cannot be replaced by agents. "Code review, too — review on systems design is engineer work; variable name / style / opinionated review goes to the agent" — a division Mike recommends. A side effect is the removal of emotional friction (human conflict in fine-grained reviews between engineers).
Recommendations — the small-company advantage
Mike's recommendations for other companies:
- Start with boring repetitive tasks — what engineers hate, so buy-in maximizes
- Best engineers first — the ones with the most system / domain knowledge
- Slow and phased — onboarding everyone at once fails
- Experiment in non-critical systems — start in areas where failure costs little
- Delete unnecessary process — re-ask "why this meeting?"
- Finish the guardrails before moving to autonomous flow
- Encode engineering culture and patterns into a skill — for example, "API: service-repository pattern"
A structural advantage Mike emphasizes: "Small companies clearly have an advantage over big enterprises. Scaling 20 people is a different problem than scaling 100, 1,000, or 10,000. But don't be too shy or too conservative — a delay of a few months becomes six months, then twelve. It compounds." This produces an interesting contrast with Brian Scanlan (Intercom) on his 1,400-person organization's adoption — Brian holds the counter-position that "even a medium / large org can scale this if the best people are placed on it full time" — a different answer to the same question.
Editorial reading — PFF's case study on the MEMEX map
Three angles for taking this talk into MEMEX.
(1) The earliest proof of an organizational structure paradigm shift. Most companies are introducing AI tools but keeping the process (Scrum / sprint / standup). PFF has dropped the process itself. That this functioned within two months is an early data point in the industry debate of "will Agile survive into the AI era." Over the next 12 months, whether other companies copy the PFF model is a metric worth watching.
(2) A reskilling signal that "the definition of the engineer's role" is changing. Mike's split between "curious" and "prescriptive" engineers could fundamentally change the criteria for engineer recruiting, promotion, and education going forward. It connects to the "future role of the engineer" discussion in Karpathy's Software 3.0 and Sholto Douglas (Anthropic) on running vibe coding in production. The end of the era in which universities, bootcamps, and corporate training mass-produce engineers who operate on prescriptive instructions.
(3) The strategic advantage of small companies widens. PFF's case study landed at "200 people, 20 engineers." For the Y Combinator / startup world, it reinforces the thesis that "the large-enterprise moat erodes with AI." The Intercom case sits as a counterargument: "a mature large enterprise with permissions / audit / control can also adopt this if it concentrates the best people." Together, these two cases become a starting point for redefining AI competitive dynamics between enterprise and startup.
Video outline
- (00:00) PFF introduction — sports data, 200 employees, 20 engineers, distributed org
- (01:00) Falling behind competitors, personal experiments with Claude Opus from November 2025
- (02:00) Questioning the premise of "engineers as bottleneck"
- (02:30) Case study results — 25x deploys, 10x output, 8.6/10 customer satisfaction
- (04:54) Declaring that Scrum did not survive
- (05:30) The abolished-ceremonies list, and the remaining huddle
- (07:00) The new workflow — Spec → LDD → automated tickets → PR → QA agent
- (09:00) The curious vs prescriptive engineer split
- (10:00) Three areas where engineers remain — security, product feel, scale
- (12:00) Factory metaphor — decomposition into composable skills
- (13:00) The next stage — self-healing previewed
- (14:00) Recommendations — how to begin
- (16:00) Small-company advantage compared to big enterprise
- (17:00) "Don't be too shy or too conservative," closing