Meta Tried to Shrink Engineering Teams Around AI  🔗 **Source:** [Meta Tried to Shrink Engineering Teams Around AI](https://leaddev.com/ai/meta-tried-to-shrink-engineering-teams-around-ai) > [!note]+ Document Notes > tags: [ai-coding-agents, developer-experience, engineering-metrics, team-structure, platform-engineering] > author: leaddev.com > source: LeadDev > reference: https://leaddev.com/ai/meta-tried-to-shrink-engineering-teams-around-ai > date created: 2026-09-07 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Meta tried to shrink engineering teams around AI > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] - [[#🔄 Refactor Appendix — Meta tried to shrink engineering teams around AI]] ## 🔗 References - Source: LeadDev, "Meta tried to shrink engineering teams around AI" — https://leaddev.com/ai/meta-tried-to-shrink-engineering-teams-around-ai - The 220% code-change figure links out to a Reuters investigation: https://www.reuters.com/investigations/mark-zuckerberg-had-bold-plan-replace-meta-staff-with-ai-here — checked via link extraction before writing this section; the figure is sourced, not asserted bare by LeadDev. - "previously reported" (on metrics not telling the full story) links to LeadDev's own prior piece on Microsoft's engThrive framework and Goodhart's Law: https://leaddev.com/reporting/is-microsofts-engthrive-framework-immune-to-goodharts-law - DX's cross-organization research is described but not linked to a report or methodology page in the captured text. - Peter Bell's forthcoming book, *Scaling AI Adoption in Engineering* (O'Reilly): https://www.oreilly.com/library/view/scaling-ai-adoption/0642572246563/ - Related LeadDev pieces linked in the piece: best AI coding assistants, how to prepare for AI agents, why everyone's suddenly talking about AI agents, designing human-agent engineering teams, the 8 software engineering metrics AI broke, who's catching the bugs as AI helps write more code, the 2026 Engineering Leadership Report, and code maintainability in the AI coding era. - A Gartner press release is cited for the general claim about organizations shrinking teams: https://www.gartner.com/en/newsroom/press-releases/2026-07-07-gartner-predicts-60-percent-of-organiz ## 📝 Summary - **What happened:** Meta restructured engineering into small AI-augmented "pods" of three to five people. Code-change volume rose 220% year-on-year, but the share of changes that actually shipped new or improved features to users rose only 36%. Major technical and security incidents rose 40%, and time spent firefighting them rose 70%. - **Why it matters:** It's a concrete, named-company case of the output/outcome gap that DX's cross-organization data also shows — pull request throughput up 37% while a composite Developer Experience Index fell from 67 to 65. - **Key stakeholders:** Meta engineering leadership, DX (developer intelligence vendor) and its research subjects (500+ organizations), Peter Bell (Gather.dev, author of a forthcoming O'Reilly book on scaling AI adoption). - **Risks and tradeoffs:** shrinking teams before building review/evaluation infrastructure concentrates a torrent of AI-generated changes onto too few reviewers, which the piece ties directly to the incident and firefighting increases. - **Bottom line:** more code isn't more product, and sequencing matters — Meta redesigned the org first and hoped the tooling would catch up; the piece frames that ordering as the likely cause of the backfire. ## 📖 Main Content **The headline metric and the real one diverge.** Meta's pod restructuring produced a 220% year-on-year rise in code changes to internal platforms and infrastructure — sourced to a Reuters investigation, not an unlinked claim. But the metric that should matter, the share of changes reaching users as new or improved features, rose only 36%. Incidents (+40%) and firefighting time (+70%) both grew faster than useful output. > [!quote] ID:rw_01m1y15f3nrhahwysp335h8fky > "The results looked positive – at least according to one metric. Code changes to Meta's internal software platforms and infrastructure reportedly increased 220% year-on-year." **The pattern generalizes beyond Meta.** DX's research across 500+ organizations found the same directional split at a smaller scale: PR throughput up 37% over four quarters, but its Developer Experience Index (a composite friction measure) fell from 67 to 65, and time spent building new capabilities stayed roughly flat. > [!quote] ID:rw_01m1y15f3nrhahwysp335h8fky > "We are often falling in love with our output numbers and not paying enough attention to our outcome metrics" **AI doesn't remove the review bottleneck — it relocates it.** Houck's framing is that AI "exacerbates what were previously minor issues into major ones": a senior developer who used to review everything now faces a volume of AI-generated changes no single reviewer can keep up with. **The proposed fix is role change, not headcount change.** Bell argues product engineers (who understand the customer and domain) and platform/DX engineers (who build harnesses, evaluations, pre-commit hooks, and merge queues) both become more important, not less, as AI writes more code. > [!quote] ID:rw_01m1y15f3nrhahwysp335h8fky > "Their job is to build the harnesses, build the evaluations, build the pre-commit hooks, and build the merge queues" **Team-size and sequencing recommendations.** Bell puts the ideal team at five to eight people, partly for coordination reasons (agent-aided engineers can generate an unmanageable volume of simultaneous changes) and partly for a stated human reason — cohesion. He recommends any team-shrinking happen near the *end* of an AI transformation, via small low-risk experiments that identify which tasks can safely be handed to agents before human review is phased out. Meta, in the piece's framing, tried the reverse: redesign the org first and hope the technology carries the load. ## 🗒️ Notes - Meta's restructuring target: pods of 3-5, replacing 10-20 person product groups. - Metric divergence at Meta: +220% code changes vs. +36% shipped features vs. +40% major incidents vs. +70% firefighting time. - DX cross-org data (500+ orgs, four quarters): +37% median weekly PR throughput; Developer Experience Index 67 → 65; % of time on new capabilities roughly flat. - Houck's diagnosis: teams over-index on output metrics and under-index on outcome metrics; AI amplifies existing weak points (e.g., review capacity) rather than removing them. - Bell's two more-important-not-less roles: product engineers (customer/domain fluency) and platform/DX engineers (harnesses, evaluations, pre-commit hooks, merge queues). - Bell's team-size number: 5-8, for both technical (change-volume) and human (cohesion) reasons; not everyone on the team need work the same repo. - Bell's sequencing rule: shrink teams at the *end* of an AI transformation, not the start, via small incremental experiments that establish which tasks are safe to hand off before phasing out human review. - The piece frames Meta's approach as the inverse of Bell's rule — org redesign first, technology expected to catch up — and states it "appeared to backfire badly." - Bell, on the difficulty: "It is a sign that it is very hard to do this right, and more people than not will fail to do so initially." ## 📚 References - Reuters investigation (source of the 220% figure): https://www.reuters.com/investigations/mark-zuckerberg-had-bold-plan-replace-meta-staff-with-ai-here - LeadDev, "Is Microsoft's EngThrive framework immune to Goodhart's Law?": https://leaddev.com/reporting/is-microsofts-engthrive-framework-immune-to-goodharts-law - LeadDev, "The 8 software engineering metrics AI broke": https://leaddev.com/ai/the-8-software-engineering-metrics-ai-broke - LeadDev, "As AI helps us write more code, who's catching the bugs?": https://leaddev.com/ai/as-ai-helps-us-write-more-code-whos-catching-the-bugs - Peter Bell, *Scaling AI Adoption in Engineering* (O'Reilly, forthcoming): https://www.oreilly.com/library/view/scaling-ai-adoption/0642572246563/ - Gartner press release on organizations shrinking teams: https://www.gartner.com/en/newsroom/press-releases/2026-07-07-gartner-predicts-60-percent-of-organiz - DX's own research (500+ organizations, four quarters of PR/DX Index data) is described in the text but no report URL is captured — treat the numbers as vendor-reported, not independently verified here. ## 🗣️ Paraphrase Meta tried collapsing big engineering teams into tiny AI-supported pods and got a lot more code out of it — 220% more, by one measure. Almost none of that translated into things users actually got: shipped feature-relevant changes rose only 36%, while incidents and firefighting time grew faster than the code did. The same shape shows up across the industry at smaller scale: more pull requests, a slightly worse developer-experience score. The read from both DX and Peter Bell is that AI increases the *volume* engineers can produce without automatically increasing the volume of useful, safe work an organization can absorb — because the bottleneck was never typing speed, it was review, evaluation, and integration capacity. The fix isn't more or fewer engineers in the abstract; it's building the review and safety machinery first, keeping teams around five to eight for cohesion and coordination reasons, and only shrinking headcount once experiments show which tasks agents can safely own without a human in the loop. Meta apparently reordered that sequence — restructure first, let the tooling catch up — and the piece treats that as the likely reason it backfired. ## 📰 Newsletter **Meta's AI pods produced 220% more code and 36% more shipped value — same gap, smaller scale, everywhere else.** Meta reorganized engineering into pods of three to five people leaning on AI tools and agents. Code changes to internal platforms jumped 220% year-on-year (per a Reuters investigation). The metric that should matter — changes that actually became new or improved features for users — rose a much smaller 36%. Major incidents were up 40%, firefighting time up 70%. That's not a Meta-specific glitch. DX's research across 500+ organizations shows the same shape: PR throughput up 37% in four quarters while its composite Developer Experience Index slipped from 67 to 65. "We are often falling in love with our output numbers and not paying enough attention to our outcome metrics," says DX's Brian Houck. Peter Bell's read (forthcoming O'Reilly book, *Scaling AI Adoption in Engineering*): the roles that get *more* important as AI writes more code are the ones nobody's automating — product engineers who know the domain, and platform/DX engineers who build the harnesses, evaluations, pre-commit hooks, and merge queues that keep AI-generated work safe. His team-size number is 5-8, and his sequencing rule is blunt: shrink teams near the *end* of an AI transformation, once small experiments show what's safe to hand off — not at the start, hoping the tooling will catch up. Meta, on this account, did it backwards. ## ✅ Action Items #### DevRel - Not applicable to this source. It's a case study in engineering-org design and metrics, with no developer-advocacy, education, or community dimension. #### OSPO - Not applicable to this source. No license, governance, or open-source-supply-chain content. #### Community - Not applicable to this source. #### WordPress - Not applicable to this source. No WordPress-specific content; the review-bottleneck and merge-queue points are generically applicable to any codebase reviewing AI-generated PRs, WordPress plugins included, but the source itself makes no WordPress claim. #### The WPOCC - Not applicable to this source. ### FAIR - Not applicable to this source. ## 🧪 Hypotheses 1. Organizations that build review/evaluation infrastructure (harnesses, pre-commit hooks, merge queues) before shrinking teams show a smaller incident-rate increase per unit of AI-driven code-change growth than organizations that shrink first. 2. The ratio of shipped-feature changes to total code changes falls as AI-assisted code volume rises, unless review capacity scales proportionally. 3. Team cohesion (self-reported) degrades below roughly five members and plateaus above roughly eight, independent of AI tooling — Bell's number is a coordination claim as much as an AI one. 4. DX's Developer Experience Index and PR throughput are negatively correlated across the 500+ organizations in its dataset once AI-assisted coding tools cross some adoption threshold. 5. Small, staged experiments in task hand-off to agents (Bell's recommended sequencing) produce fewer incidents than wholesale org-redesign-first approaches, holding final team size constant. ## 📊 Methodology Two named but differently verified data sources: (1) Meta's internal metrics, reported via Reuters' investigation and repeated by LeadDev — no methodology, sample window beyond "year-on-year," or independent audit is described in the captured text; (2) DX's cross-organization research (500+ organizations, four quarters), also undocumented here beyond the topline numbers — no sampling method, industry mix, or definition of "Developer Experience Index" components is given. Both are vendor- or press-mediated figures, not primary research this analysis can independently verify. Bell's recommendations (5-8 person teams, shrink-at-the-end sequencing) are presented as expert judgment, not the output of a study. ## ❓ Questions - What is Meta's actual definition of a "code change" in the 220% figure — commits, PRs, diffs? The undercounted denominator problem is exactly what "The 8 software engineering metrics AI broke" (linked in-piece) seems built to address. - Does DX's Developer Experience Index weight incident/firefighting time, or is the 40%/70% Meta-specific increase a separate, unmeasured cost sitting outside that index? - Is Bell's 5-8 person number derived from any study, or is it a practitioner heuristic like the well-known "two-pizza team" rule repackaged for the AI era? - What specifically did Meta change in team structure beyond headcount — did review requirements, on-call rotation, or approval gates change too, or only pod size? - Has Meta reversed or adjusted the pod model since these results, and is that documented anywhere post-dating this piece? ## 🔮 Future Research - A controlled or quasi-experimental comparison of "shrink-first" vs. "infrastructure-first" AI adoption sequencing on incident rate and shipped-feature ratio, holding company size and AI tool constant. - Longitudinal DX Index and PR-throughput data broken out by team size, to test whether Bell's 5-8 person range is the actual inflection point or an anecdotal midpoint. - A public breakdown of Meta's incident data by severity and root cause, to establish whether "major technical and security incidents" is driven by AI-authored code specifically or by review-capacity strain generally. ## 💡 Implications - **Practice:** review, evaluation, and merge-gating infrastructure is a prerequisite for team-shrinking, not a parallel project — the piece's clearest actionable claim. - **Cost:** output metrics (PRs, commits, LOC) are cheap and visible; outcome metrics (shipped value, incident rate) are the ones that actually track return on AI tooling spend, and they're the ones organizations under-track per Houck. - **Security:** the 40% rise in major technical and security incidents at Meta is the sharpest data point in the piece and gets comparatively little elaboration relative to the throughput numbers — a review-capacity failure mode with security consequences. - **Reliability:** firefighting time rising faster (70%) than incidents (40%) suggests each incident is also taking longer to resolve, which the piece doesn't explain but which would follow from thinner review/on-call staffing per pod. - **Org design:** "minimum viable engineering team" reframes headcount planning around review and coordination capacity rather than raw output capacity once AI is in the loop. ## 🧠 Learning Styles Assessment - Reading level: approximately grade 11-12 (Flesch-Kincaid estimate) — trade-press business writing, moderate sentence length, domain jargon (PR throughput, Developer Experience Index) used without definition. #### 👀 Visual learners - Present: none — no charts, diagrams, or tables for the several percentage figures cited. - Improve: a simple before/after bar chart of the four Meta metrics (220%, 36%, 40%, 70%) would make the divergence immediately legible. #### 🔊 Aural learners - Present: none. - Improve: a short audio pull-quote of the Houck line on output vs. outcome metrics. #### 🗣️ Verbal learners - Present: well served — Houck's and Bell's quotes carry the argument in plain, quotable language. - Improve: define "Developer Experience Index" and "pod" on first use rather than assuming familiarity. #### 🧩 Kinesthetic learners - Present: none — no checklist or exercise for applying the sequencing rule. - Improve: a short self-assessment ("do you have harnesses/evaluations/merge queues before you shrink?") would operationalize Bell's advice. #### 🧠 Logical learners - Present: the output/outcome contrast is a clean logical structure repeated at two scales (Meta, then DX's broader dataset). - Improve: a simple causal diagram (team shrink → change volume ↑ → review capacity strain → incidents ↑) would make the implied mechanism explicit instead of left implicit. #### 🧑‍🤝‍🧑 Social learners - Present: multiple named voices (Houck, Bell) in conversation with the reporting. - Improve: none needed; already interview-driven. #### 🧘‍♀️ Solitary learners - Present: well served — a self-contained short read. - Improve: none needed. #### 🌿 Naturalistic learners - Not applicable to this source. ## 📊 Accessibility Assessment #### Screen reader semantics - Present: standard article structure with headings and paragraphs (not directly inspectable from captured text, but no evidence of structural obstacles). - Improve: cannot assess without the live page; no images or embedded charts in the captured content to require alt text. #### Keyboard navigation - Present: not assessable from captured text. - Improve: not assessable. #### Contrast and readability - Present: not assessable from captured text (host-determined). - Improve: not assessable. #### Text resizing and reflow - Not applicable to this source — no layout information captured. #### Media and captions - Not applicable — no audio/video in this piece. #### Forms and interactions - Not applicable — no interactive elements in the captured content. #### Standards reference - Not assessable against WCAG 2.2 AA from the captured plain-text content; a live-page audit would be required. ## 🌍 DEIB Assessment #### Cultural breadth - Narrow by design — a single named company (Meta) and one vendor's (DX's) client base, both large-tech-adjacent contexts. No non-US or non-big-tech examples. #### Inclusive language - Neutral throughout; no gendered or exclusionary phrasing. Both named sources (Houck, Bell) are referred to by name and title without assumption about identity. #### Neurodiversity support - Moderate — short paragraphs and one idea per section, but percentage figures are presented in prose rather than a table, which raises the parsing cost for readers who benefit from tabular data. #### Representation - Two named male sources quoted (Houck, Bell); no other perspectives (e.g., an engineer on one of the affected Meta pods) are represented. #### Psychological safety - Neutral-to-cautionary tone; frames Meta's outcome as a lesson rather than a failure to be blamed on named individuals. Bell's "more people than not will fail to do so initially" softens the framing without minimizing the incident/firefighting cost data. #### Economic access - The tooling and consulting referenced (DX as a paid developer-intelligence vendor, Bell's forthcoming paid book) assumes budget for both AI coding tools and measurement infrastructure — a real barrier for smaller or resource-constrained engineering orgs that the piece doesn't address. ## ✅ Logical Validity #### Strong reasoning - The output/outcome contrast is drawn from two independent-ish data sources (Meta's internal numbers via Reuters, DX's cross-org research) that point the same direction, which is stronger than either alone. - Houck's causal claim — AI "exacerbates what were previously minor issues into major ones" — is stated as a mechanism (review capacity was already a constraint; AI raises the volume hitting that constraint) rather than asserted as a bare correlation. #### Fallacies - **Unsupported precision.** Four precise Meta percentages (220%, 36%, 40%, 70%) are reported with no stated measurement window details, denominator definitions, or confidence range, borrowing the authority of hard data without the methodology to back it. Fix: cite Meta's or Reuters' underlying methodology, or flag the figures as approximate. `#fallacy/unsupported-precision` - **Appeal to authority (mild).** Bell's 5-8 person team-size recommendation is presented with his job title and forthcoming book as the credentialing, not with any cited study. Fix: label it explicitly as expert judgment, which the piece does do reasonably well via attribution, but the number itself risks being treated as evidence-based by a skimming reader. `#fallacy/appeal-to-authority` - **Single-case generalization (mitigated).** The piece uses one company's (Meta's) results as the hook, then pivots to DX's broader dataset to generalize the pattern — this largely avoids the fallacy, but the specific 5-8 person number is never validated at the DX-dataset scale, only asserted by Bell. #### Tone of voice Even, trade-press-analytical. Cautionary about Meta specifically ("appeared to backfire badly") without being punitive toward named individuals; framing consistently routes blame toward sequencing and infrastructure choices rather than people. ## 🛡️ DARVO Analysis Not applicable to this source. There is no accusation, denial, or victim/offender dynamic — it's a reported analysis of an organizational metrics outcome, with named experts offering diagnosis and recommendations rather than defending against a charge. ## 🎯 Conclusion Meta's pod experiment is a clean, named-company illustration of a pattern DX's broader dataset also shows: AI raises how much code gets written faster than it raises how much of that code becomes useful, safely-shipped product. The 220% figure is properly sourced to a Reuters investigation, not an unlinked claim, and the piece's real news is the divergence from it — 36% feature-relevant, 40% more incidents, 70% more firefighting. Bell's practical answer is sequencing: build the review and evaluation machinery (harnesses, pre-commit hooks, merge queues) before shrinking a team, keep pods around 5-8 for both coordination and human reasons, and treat any headcount reduction as the last step of an AI transformation rather than the first. Meta, on this account, ran that order backwards. For any team is adopting AI coding tools, the actionable move is auditing whether output metrics (PRs, commits) or outcome metrics (shipped features, incident rate) are actually driving decisions — Houck's line is the piece's sharpest single claim. ## 🔄 Refactor Appendix — Meta tried to shrink engineering teams around AI ### 📚 Literature Atoms (H3) #### [H1] Meta's 220% code-change increase produced only 36% more shipped features > [!quote] ID:rw_01m1y15f3nrhahwysp335h8fky > "The results looked positive – at least according to one metric. Code changes to Meta's internal software platforms and infrastructure reportedly increased 220% year-on-year." Verified against the link check: this figure is sourced to a Reuters investigation, not an unlinked assertion. The gap between it and the 36% feature-shipping figure is the article's central data point; major incidents (+40%) and firefighting time (+70%) grew faster still. Tags: `#atom/literature/h1` #### [H2] Organizations chase output metrics and under-track outcome metrics > [!quote] ID:rw_01m1y15f3nrhahwysp335h8fky > "We are often falling in love with our output numbers and not paying enough attention to our outcome metrics" DX's Houck names the general failure mode Meta's case illustrates: PRs and code changes are visible and easy to count; shipped value and incident rate are the metrics that actually matter and are harder to track. Backed by DX's cross-org data (37% PR throughput increase against a Developer Experience Index that fell from 67 to 65). Tags: `#atom/literature/h2` #### [H3] Team-shrinking should follow AI-safety infrastructure, not precede it > [!quote] ID:rw_01m1y15f3nrhahwysp335h8fky > "Their job is to build the harnesses, build the evaluations, build the pre-commit hooks, and build the merge queues" Bell's sequencing argument: platform/DX engineers who build review-and-safety infrastructure become more important, not less, as AI writes more code — and any headcount shrink should come after that infrastructure exists, near the end of an AI transformation rather than the start. Tags: `#atom/literature/h3` ### 🧠 Permanent Candidates (H4) #### [P1] A capacity constraint doesn't disappear when its upstream volume grows — it gets stressed When a system's bottleneck sits downstream of a process (review capacity downstream of code production, moderation capacity downstream of content production), increasing the upstream volume without proportionally increasing the bottleneck's capacity doesn't remove the constraint — it just makes the constraint bind harder, showing up as backlog, incidents, or firefighting rather than as throughput. AI coding tools are a specific instance: they increase code-production volume while leaving review, evaluation, and merge-gating capacity fixed unless that capacity is deliberately scaled first. The general design rule: before scaling any input to a pipeline, identify and scale its downstream constraint, or measure the constraint's failure mode directly rather than the input's growth. *Candidate; the Meta and DX data both instantiate the same shape, which is a reasonable generalization signal, though neither source names the mechanism as a queueing/bottleneck problem explicitly — that framing is this analysis's addition.* Links: [[3. Resources/MOCs/Evidence & Claims Literacy MOC]] · [[3. Resources/Permanent Notes/A Quality Label Without a Quantity Is Not a Claim You Can Check]] — because applies-in the same "specific number borrows authority it hasn't earned" pattern the linked note identifies, here for the 220% figure specifically. Tags: `#atom/zettel/z1` ### ✏️ Fleeting Queue - The piece never states what counts as a "code change" in the 220% figure — commit, PR, or diff — which is exactly the kind of metric-definition gap the linked "8 software engineering metrics AI broke" piece seems built to address. Worth reading that companion piece directly. `#atom/fleeting/f1` - Bell's 5-8 person team-size number reads like a repackaged "two-pizza team" heuristic for the AI era — worth checking whether he cites any study or if it's pure practitioner judgment, since the piece gives no citation. `#atom/fleeting/f1` ### → Things 3 (max 2 actions) - [ ] Compare Bell's "harnesses, evaluations, pre-commit hooks, merge queues" checklist against current WordPress-plugin-adjacent AI-assisted workflows to see which pieces already exist and which are missing. `#action/h1` - [ ] Read the linked "8 software engineering metrics AI broke" piece to get the fuller metric-definition critique this article only gestures at. `#action/h2` <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Meta Tried to Shrink Engineering Teams Around AI.md|Meta Tried to Shrink Engineering Teams Around AI by leaddev.com]] ## Highlights - The results looked positive – at least according to one metric. Code changes to Meta’s internal software platforms and infrastructure reportedly increased 220% year-on-year. ([View Highlight](https://read.readwise.io/read/01m1y1hd4d035yxhbt7sygn2ne)) - Note: H1 — the sourced 220% figure whose gap against 36% shipped-feature growth is the article's central data point. #atom/literature/h1 - Tags: atom/literature/h1 - “We are often falling in love with our output numbers and not paying enough attention to our outcome metrics,” says Brian Houck, distinguished scientist at developer intelligence company DX. ([View Highlight](https://read.readwise.io/read/01m1y1hfwjh84q49z0aa1m02c1)) - Note: H2 — names the general failure mode: output metrics are visible and easy to count, outcome metrics are what actually matter. #atom/literature/h2 - Tags: atom/literature/h2 - Bell reckons that an ideal-sized team is around five to eight people, even if only one or two are working directly on the same repository. Part of that is down to technical pragmatism: several engineers aided by agents can easily generate an unmanageable number of simultaneous changes. ([View Highlight](https://read.readwise.io/read/01m1y1hjaw9ydsq5fg3hym5ebw)) - Note: H3 — Bell's team-size recommendation, presented as expert judgment rather than a cited study. #atom/literature/h3 - Tags: atom/literature/h3