From Boss to Coach to Conductor: The 50-Year Evolution of Software Management

Here’s a question I get asked a lot by people transitioning into engineering leadership: “Why does everyone say I should manage 6 to 8 people? And why do I need to do a weekly 1:1 with each of them?”

It sounds like bureaucracy — a scheduling burden invented by HR. But the answer is bigger than a single number. Software management has evolved along several dimensions at once: the SDLC (how we build), the team structure (who builds), and the manager’s role (who coordinates the builders). Those three things aren’t independent — they lock together. Change the way software is built, and you change what a manager does. Change what a manager does, and you change what the team looks like.

Over the last 50 years, the span of control has tracked a clear arc — wide, then narrow, then widening again. But so has everything else: the lifecycle, the team, and the job description. Here’s how we got here, and where I think we’re going.

Era 1: The Boss (1960s–1990s)

If you go back far enough, managing software teams looked a lot like managing a factory floor — because that’s exactly where the discipline came from.

The factory inheritance

Frederick Taylor published The Principles of Scientific Management in 1911, and his ideas cast a long shadow over every industry that followed. The core assumption was radical for its time: management’s job was to think, and workers’ job was to execute. Taylor wanted managers to analyze work, find the “one best method,” break it into measured tasks, and then watch workers do them in the best and cheapest way.

Software imported this model wholesale. Managers decomposed projects into tasks, estimated them, and assigned them down. Programmers were treated as interchangeable units — which is exactly what the famous productivity unit of that era, the man-month, implied. You didn’t count people, you counted person-months.

The psychology matched the structure. Douglas McGregor’s Theory X (1960) described managers who assume workers “have little ambition, avoid responsibility, and need close supervision.” Command-and-control software organizations ran on de-facto Theory X: individual traceability (so you knew exactly who to blame), top-down tasking, and multiple layers of supervision.

The waterfall machinery

The management technology of the era was the waterfall model — even though its creator, Winston Royce, explicitly warned in his 1970 paper that the single-pass version he diagrammed “is risky and invites failure.” The DoD formalized it in 1985 with DOD-STD-2167: requirements first, then design, then coding, then integration, then testing, with a review gate at every phase.

This machinery required a specific kind of manager:

• Change control boards ruled on any deviation from the baselined requirements
• Phase-gate reviews stopped the project cold until gatekeepers signed off
• Status flowed up, instructions flowed down

The manager was a planner, tasker, tracker, and gatekeeper. The human beings underneath were cogs in a scheduling machine.

The SDLC and the manager’s place in it

The waterfall SDLC was a five-phase serial pipeline, with the manager positioned as the gatekeeper at each handoff:

• Requirements — specs were frozen up front in a document the customer signed. The manager’s job: prevent scope creep, control the Change Control Board.
• Design — architects produced module diagrams and interface contracts. The manager’s job: sign off on design reviews, track compliance against the spec.
• Implementation — programmers coded in isolation, one module per person. The manager’s job: monitor progress, escalate schedule slips.
• Testing — QA ran test scripts against the frozen spec, as a separate late phase. The manager’s job: decide what qualified as a bug vs. a new requirement.
• Deployment — a big-bang release at the end. The manager’s job: coordinate the final phase-gate sign-off.

That’s the link between SDLC and role: when the lifecycle is a serial pipeline, the manager becomes a pipeline controller. The role wasn’t about the work — it was about governing the handoffs between phases.

Span of control: the classic numbers

Management theory actually gave managers a reason to keep spans small in theory — Vilfredo Graicunas showed back in 1933 that the number of relationships a manager must handle explodes combinatorially as the team grows. But the manufacturing mindset pushed spans large in practice: first-line supervisors of routinized work could manage up to 30 people. Pre-modern organizations averaged around 1:4, and even after the 1980s “flattening” it drifted toward 1:10.

And there was Fred Brooks, fresh off IBM’s OS/360 — a project with roughly 1,000 programmers — writing The Mythical Man-Month (1975). He gave us the two laws that should have ended the era:

“Adding manpower to a late software project makes it later.”

And the communication math: for n people, there are n(n−1)/2 communication channels. Fifty developers means 1,225 channels. That’s why the man-month was a myth — the man, once you add more of them, spends his time talking instead of working.

How the era failed

The 1968 NATO conference coined the term “software crisis” — projects running over budget, over time, delivering software that didn’t meet requirements. The Standish Group’s CHAOS Report (1994) quantified it brutally: only 16.2% of projects succeeded, 52.7% were late or over budget, and 31.1% failed outright. Average cost overrun: 189%. Average time overrun: 222%.

The failures weren’t minor. The London Stock Exchange’s TAURUS system burned £75m and was scrapped. The FAA’s Advanced Automation System cost billions and never shipped. Therac-25, a medical radiation device, killed people because of a race condition that the process-heavy, big-bang review system never caught.

“The major problems of our work are not so much technological as sociological in nature.” — DeMarco & Lister, Peopleware (1987)

The waterfall model assumed requirements could be frozen up front. They can’t. It assumed integration and testing were a late phase you could schedule. They aren’t. And when the big-bang release inevitably slipped, Theory X’s individual traceability meant the blame landed on the people at the bottom — the same people Taylorism had taught to “soldier.”

The boss era didn’t fail because the managers were bad. It failed because the model of work was wrong: software is not a factory floor, and requirements are not specs you hand to a machine.

Era 2: The Coach (2001–present)

The manifesto and the self-organizing team

In February 2001, seventeen software practitioners met at a ski resort in Utah and signed the Agile Manifesto. Buried in its four values is a revolution in who does the thinking:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

But the real managerial content is in the Principles. Principle 11 says the best designs “emerge from self-organizing teams.” Principle 5 tells management to “give them the environment and support they need, and trust them to get the job done.” Principle 12 demands the team regularly “reflects on how to become more effective, then tunes and adjusts.”

This is McGregor’s Theory Y winning: workers are internally motivated, and the manager’s job is to facilitate, not control. The unit of organization flipped from individual-and-boss to self-organizing team. Which meant the manager’s job description had to be rewritten.

The new SDLC: from serial pipeline to iterative loop

Where waterfall was a one-way pipeline, agile replaced it with a feedback loop. The SDLC didn’t disappear — it compressed into repeating cycles where all phases happened concurrently within each sprint:

• Requirements — user stories written as the work goes, not frozen up front. The Product Owner owns priority; the team owns estimation. No contract-style spec exists.
• Design — emergent, not a separate phase. Architecture decisions happen inside the sprint. Principle 11: “The best architectures, requirements, and designs emerge from self-organizing teams.”
• Implementation — pair programming, collective code ownership, continuous integration. No one owns a module alone.
• Testing — automated tests run in the pipeline on every commit. QA is not a separate team; testing is embedded in the development process.
• Deployment — continuous delivery. Every green build is potentially shippable. Releases are not events; they’re a dial you turn.

The manager’s relationship to the SDLC flipped. In waterfall, the manager drove the pipeline and the team fed it. In agile, the team drives the loop — and the manager’s role is to protect it: remove blockers, shield the team from noise, and create the conditions for the loop to spin faster. The rituals (standups, retros, sprint reviews) are the gates analog — but instead of sign-off checkpoints, they’re feedback checkpoints.

Why the span of control shrank to 6–8

Here’s the direct answer to the question I started with. The modern engineering manager manages 6 to 8 people for three compounding reasons:

1. Coaching intensity. The Scrum Guide says a team is “typically 10 or fewer people” (older editions said 5–9; in practice 6–8 is the sweet spot). Andy Grove made the one-on-one meeting the core management ritual in High Output Management (1983) — and Silicon Valley took it to heart. Rands (Michael Lopp) codified the modern rules: same time every week, at least 30 minutes, never cancel. “Each time you bail on a 1:1, they hear, ‘You don’t matter.’” Do the math: 30 minutes × 8 reports = 4 hours of 1:1s a week, before you write a line of your own.

2. Cognitive load. Team Topologies (2019) made the point that teams can only absorb so much complexity before breaking down — “each new tool, responsibility or domain your team is given taxes their mental bandwidth.” The same logic applies to a manager’s reports: each person needs real coaching, real career support, real feedback. Beyond ~8, the relationships degrade into what Rands calls “the guy who grins uncomfortably as he infrequently flies by the office.”

3. The old theory catches up. Graicunas’ 1933 math, which the boss era ignored, came roaring back: interactions among direct reports grow exponentially. Self-organizing teams need small spans because they communicate more, not less.

The manager’s new job

Google’s Project Oxygen (a multi-year study of 10,000+ data points) turned the old career advice on its head. The #1 behavior of highly effective managers? “Be a good coach.“ Not “have deep technical skills” — that made the list but wasn’t the top priority. Managers were no longer the smartest engineer with a promotion; they were a distinct profession whose value is developing people and delivering outcomes.

The rituals replaced the directives:

• Weekly 1:1s — the subordinate’s agenda, about the person, not the status
• Standups, sprints, retros — the team runs the work; the manager protects the process
• OKRs (Grove’s invention, popularized at Google) — align on outcomes, not task lists
• DORA metrics — deployment frequency, lead time, change failure rate, time to recover — shifted management from output (lines, hours, tickets) to outcomes (flow). (I explored DORA in depth in Observability Engineering Part 1)

The manager became a coach, an impediment-remover, a context-setter. The player-coach (a tech lead who also manages) was exposed as a trap you grow out of — hence the dual career tracks (IC vs. manager) that became standard across Google, Microsoft, and Facebook.

The flat-org experiments

The Agile era also tried to answer the question “do we even need managers?” with experiments:

• Zappos went “holacratic” in 2013 — no titles, no managers. By January 2016, 18% of staff had left, and the company quietly reverted after Tony Hsieh’s death.
• Medium adopted holacracy and abandoned it in 2016. The team said explicitly: “the act of codifying responsibilities in explicit detail hindered a proactive attitude and sense of communal ownership.”

The lesson of the experiments is worth stating plainly: you can’t delete managers — you can only relocate their work. “Flat” orgs don’t remove hierarchy; they shove it into meetings, governance, and informal power, and dump the emotional load on individuals. What Agile did wasn’t remove the manager. It changed the manager from boss to coach.

Era 3: The Conductor (2024–?)

Now the interesting part: the AI era is doing to the coach era what the coach era did to the boss era. And the first signs suggest the span-of-control rule is about to flip again — but this time, in the opposite direction.

The unit of management is changing

The most revealing data point I’ve seen is from Anthropic’s June 2026 study of ~400,000 Claude Code sessions (if you’re curious how these agents work under the hood, I wrote a series starting with What Is an Agent Harness?):

“On average, people make about 70% of the planning decisions but only 20% of the execution decisions… People decide what to build, and the agent decides how to build it.”

Put that next to the other big numbers:

Here’s the shift in plain terms: in the boss era, the manager delegated tasks to people. In the coach era, teams owned the work and the manager coached the people. In the conductor era, managers (and individual engineers) delegate implementation to agents, and the remaining human job is specification, context, and review.

That’s literally what Pichai’s phrasing implies — AI generates, humans review and accept. And it’s what Airbnb’s Brian Chesky means when he says AI “makes managers get their hands dirty”: managers get pulled back into the work, because someone has to write the specs and judge the output.

Why hierarchies flatten

If execution is increasingly delegated to agents, the coordination layer that existed between people shrinks. This is the structural argument, and it’s showing up in the headlines:

• Fortune (2025–26): “AI agents are flattening corporate hierarchies.”
• The Guardian (2026): “inside tech’s AI-fueled manager purge.”
• ClickUp laid off 22% of staff and deployed 3,000 AI agents, calling itself a “100x org.”
• Founders report 2 engineers now doing what used to take 30.

The logic is hard to argue with. If one human can direct a swarm of agents that each execute like a diligent junior, you need fewer implementers, and you need fewer coordinators-of-implementers. The flat-org experiments of the 2010s failed because humans can’t self-organize without structure. But agents don’t need emotional safety or career growth — so the reason middle management existed in the coach era starts to erode.

Midjourney runs a service with millions of users on roughly 11 people. Cognition’s “AI software engineer” Devin resolved 13.86% of SWE-bench issues end-to-end on launch — versus a prior state-of-the-art of 1.96%. The examples are anecdotal, but they’re pointing the same direction: output per person is rising, and the number of people needed per unit of output is falling.

The manager’s new job (again)

If every senior engineer will be directing agents — specifying, verifying, iterating — then what’s left for someone with a manager title? Why not just let engineers run everything?

This is the right question. The “conducting” skill — writing crisp specs, reviewing output, steering agents — belongs to anyone who builds software. A staff engineer conducts their own swarm. A tech lead conducts across their domain. Directing agents is the new form of building, and every builder will do it.

But the manager’s job is not just to be one more conductor on the team. The manager title carries responsibilities that a staff engineer — no matter how senior — doesn’t hold. Here’s what’s truly unique to the manager role, and what’s shared:

1. People developer (uniquely manager). 1:1s, performance reviews, compensation, hiring, firing, career growth — nobody else on the team has the formal authority or accountability for these. When every engineer is also a conductor directing agents, the manager’s coaching shifts: you now coach the conductorship itself — how to specify better, how to review more effectively, how to know when the agent is hallucinating.

2. Context architect (uniquely manager, at team scale). Individual engineers curate their own context — their rules files, their prompts. The manager owns the team-wide context system: shared conventions, review standards, architecture decisions, and agent configurations that every conductor on the team draws from. One engineer makes their own agents better. A manager makes everyone’s agents better — and that’s something no individual IC has the scope or authority to enforce.

3. Resource allocator (shared, but manager holds the authority). Senior engineers can (and do) help decide what the team works on. But the manager holds the formal authority to assign conductors to problems, staff projects, and say “no” when scope exceeds capacity. In a world where every engineer has an agent swarm, capacity management becomes the hardest problem — and the manager owns the tradeoffs.

4. Outcome owner and bridge (shared, but manager is the backstop). Let’s be honest: staff engineers own outcomes all the time. Tech leads translate business intent into technical direction every day. In healthy teams, these are shared responsibilities. But the manager is the backstop. When conductors disagree on whose agents’ output is correct, the manager makes the call. When the spec is ambiguous and nobody wants to own the clarification, the manager closes the gap. When the business asks “is this on track?” and the answer is fuzzy, the manager has to know. These aren’t things only a manager can do — but they’re things that fall to the manager when nobody else picks them up. And in the conductor era, with more output flying through the pipeline, they fall more often.

Put together: the manager doesn’t direct agents. The manager builds and runs the human system inside which conductors operate. You develop the people, you architect the shared context, you allocate the capacity, and you’re the backstop for outcomes when things get ambiguous. The individual engineers conduct their swarms. You conduct the conductors.

Anthropic’s study supports this reading: management occupations had the highest verified-success rate with coding agents — slightly above software engineers. “Perhaps acting like a manager confers greater success.” But the nuance that matters: it’s the behaviors of managing — clear specification, context curation, judging output — that transfer. Not the title. The title gives you the scope to do those things at team scale.

The future SDLC: from iterative loop to delegation chain

If agile compressed the waterfall pipeline into a feedback loop, AI compresses the loop into a delegation chain. Here’s the emerging shape of the SDLC in the conductor era:

• Specify — the human defines what needs to be built: intent, constraints, acceptance criteria. This is the critical bottleneck, and it’s now the highest-leverage activity in the entire lifecycle.
• Generate — agents produce implementation: code, tests, configs, docs. Each human prompt triggers ~10 agent actions producing ~2,400 words of output.
• Review — the human verifies correctness, catches edge cases, rejects or redirects output. Judgment happens here. Seniors become the scarce resource.
• Test — agents run the tests they generated. Automated validation layers catch 80%+ of mechanical issues. The human checks what matters: business logic, security implications, UX coherence.
• Deploy — CI/CD pipelines triggered by review approval. The deploy step itself is fully automated.

Notice where the human sits. In waterfall, the human executes each phase sequentially. In agile, the human participates in every loop iteration. In the conductor era, the human sits at exactly two points: entry (specification) and exit (verification). Everything between — implementation, test generation, boilerplate — is increasingly agent-mediated. The human’s value moves from doing the work to defining and judging the work.

The team structure shifts accordingly. Where the boss era needed separate roles for each phase (analyst, architect, coder, tester, ops) and the coach era collapsed them into cross-functional squads, the conductor era shifts toward T-shaped individuals who can specify, review, and own outcomes — supported by a swarm of specialized agents that fill the gaps. The ratio isn’t “how many engineers per manager” anymore. It’s “how many agents does this conductor direct, and how good is their specification and verification judgment.”

The counterweight: why it’s not simply “fewer people”

Before you write the “managers are obsolete” headline, note what the data cuts against:

Domain expertise is now the bottleneck. Anthropic found verified success rates of 15% for novices vs. 28–33% for intermediate and expert users. When sessions hit trouble, novices abandon at 19% — vs. 5–7% for experienced users. The more understanding a worker brings to the agent, the better the agent does. This is the opposite of “anyone can do it with AI.”

Review is the scarce resource. AI-generated code carries more bugs (the Stanford/Ars findings), so the human gate matters more, not less. Seniors don’t get replaced; they become the scarce bottleneck everyone funnels through.

a16z’s blunt answer to “will AI replace software developers?”: “Of course not.” Their reasoning includes Jevons’ paradox — cheaper software development leads to more software, and thus more developers — and the simple fact that “coding still matters as frequently you have to drag the LLM out of a hole it dug itself into.”

DORA’s 2025 finding is the one I’d frame on my wall: AI acts as an amplifier, “but the greatest returns come from focusing on the underlying sociotechnical systems.” Teams with good practices + AI get dramatically better. Teams with bad practices + AI get dramatically worse.

What changes: SDLC, teams, and the manager role

Here’s the concrete shift across the three dimensions this post has been tracking:

The SDLC

The delegation chain — specify → generate → review → test → deploy — replaces the sprint loop as the dominant lifecycle. Review becomes the largest time investment in the pipeline, because it’s now the only human gate between intent and production. Continuous verification (agents testing agents’ output) replaces the phased testing of waterfall and the embedded testing of agile. The lifecycle doesn’t get shorter — it gets front-loaded: the quality of the spec determines everything downstream, and the cost of a bad spec compounds through the chain.

The team

Span of control widens. The 6–8 rule relaxes toward 10–15, because each engineer now carries agent capacity that handles the mechanical work. But “headcount” becomes a misleading metric. The real team measure is effective output — how many conductors, directing how many agents, with what quality of specification and verification.

Team composition shifts from role-based (analyst, coder, QA, ops) to capability-based. Every engineer is a T-shaped conductor who specifies, verifies, and owns outcomes — supported by a swarm of specialized agents that fill whatever gap they don’t cover. The junior role transforms: instead of learning through discovery (reading code, fixing bugs), juniors learn through direction (telling agents what to do, learning from what the agent produces). The catch-22 is real — directing agents requires the judgment that comes from experience — and nobody has solved it yet.

The manager role

The manager’s four core responsibilities — people developer, context architect, resource allocator, outcome backstop — persist and sharpen. But the role that disappears is the pure delegating manager: the person whose only value was coordinating people doing work. Agents do the work now. Coordination without the ability to specify, review, or develop people is automated away.

At the same time, senior ICs who can specify and verify become the most valuable individual contributors the industry has ever seen — because they can direct swarms of agents without the overhead of managing people. The IC/manager track distinction doesn’t disappear, but it evolves: both tracks now require the conductor skill (specification and verification), and the manager track adds the four unique responsibilities on top.

1:1s, coaching, psychological safety, retrospectives — the human layer survives intact. Every study (Project Oxygen, DORA, Anthropic) says the same thing: good management amplifies whatever team it sits on. AI amplifies the manager’s leverage. It doesn’t replace the manager’s function.

Why the role changes: SDLC shapes the manager

Before we land the conclusion, let’s make the cause-and-effect chain explicit — because in all three eras, the same dynamic repeats:

The SDLC determines the coordination problem. The coordination problem determines what a manager does.

In the boss era, the SDLC was a serial pipeline. The coordination problem was handoffs — information moving through frozen gates without distortion. The manager’s role solved that: govern every transition with a sign-off. You didn’t need to coach people; you needed to make sure Phase 2 didn’t start before Phase 1 was signed off.

In the coach era, the SDLC became an iterative loop. The coordination problem was synchronization — the team spinning through plan-build-test-review together without friction. The manager’s role solved that: protect the loop. Shield from noise, remove blockers, coach growth. You didn’t need to gate outputs; you needed to un-gate the team.

In the conductor era, the SDLC is becoming a delegation chain. The coordination problem is direction and verification — does the swarm of agents produce output that matches intent? The manager’s role solves that: develop the people who specify and verify, architect the shared context they work from, allocate capacity across conductors, and own the outcomes when things get ambiguous. You don’t need to un-gate teams or gate handoffs. You need to build and run the human system that conductors operate inside.

This is why the role doesn’t just evolve randomly — it follows the SDLC. Change how software is built, and the manager’s job description rewrites itself.

And the good news? The human skills that survive — judgment, coaching, ownership, the ability to communicate intent — are the ones that compound across eras. A manager who can specify clearly, review with discernment, and develop the people around them is prepared for whatever SDLC comes next.

Conclusion

Look at the pattern across all three eras and it stops looking like a series of fads:

Every era redefined what the manager does — but every era needed the manager. The throughline is this: as work becomes more reliably specifiable, it gets delegated — and the human role moves up the abstraction ladder. In the boss era, humans executed every SDLC phase and managers controlled the gates. In the coach era, teams owned the loop and managers protected it. In the conductor era, agents execute the middle of the chain and the remaining human job is to decide what should exist, why, and whether it’s good enough.

If you’re a manager today, the practical takeaway is straightforward: your 1:1s and your coaching aren’t going anywhere — the human layer is the last place automation compounds. But the technical part of your job just got more technical again. The managers who learn to specify intent precisely, build great context, and review output with judgment are the ones who’ll be in demand. The ones who only knew how to coordinate people doing work will be squeezed.

The rule I opened with — “manage 6 to 8 people, do your 1:1s” — was never a law of nature. It was the right answer for one era. The next era’s right answer is still being written. And for once, managers get to help write it — because, as Anthropic’s data suggests, we might be the ones best at it.

What’s your span looking like today? Are you already seeing the shift — or is the 6–8 rule holding firm? I’d love to hear in the comments.

References

The Boss era:

• Scientific Management (Wikipedia) — Taylor’s principles and history
• Theory X and Theory Y (Wikipedia) — McGregor’s 1960 framework
• The Waterfall Model (Wikipedia) — Royce 1970, DOD-STD-2167, phase-gate reviews
• The Mythical Man-Month (Wikipedia) — Brooks’ law, n(n−1)/2 communication channels
• Span of Control (Wikipedia) — Graicunas 1933, classic span guidance
• Software Crisis (Wikipedia) — the 1968 NATO conference
• List of Failed and Overbudget Custom Software Projects (Wikipedia) — TAURUS, FAA AAS, Therac-25
• Capability Maturity Model (Wikipedia) — SEI, process maturity levels
• Peopleware (Wikipedia) — DeMarco & Lister’s sociological thesis
• CHAOS Report 1994 (Standish Group) — 16.2% / 52.7% / 31.1% figures, widely cited via The Mythical Man-Month and software engineering literature

The Coach era:

• Agile Manifesto and The 12 Principles — 2001, Snowbird
• The 2020 Scrum Guide — team size, roles, events
• Rands, “The Update, The Vent, and The Disaster” — the modern 1:1 rules
• High Output Management (Wikipedia) — Grove’s 1:1 and OKR origins
• Google re:Work — Project Oxygen & Project Aristotle — “Be a good coach” #1
• Team Topologies — Key Concepts — cognitive load, team types
• DORA — Software Delivery Metrics and DORA Research — the four keys, 2025 AI findings
• HBR, “Agile at Scale” — managers shift from controllers to coaches
• Holacracy (Wikipedia) — Zappos and Medium experiments and outcomes
• Atlassian, “Discover the Spotify model” — squads, tribes, Dunbar’s number
• What Matters — OKRs Explained — Doerr, CFRs
• The Manager’s Path (Fournier, 2017) and An Elegant Puzzle (Larson, 2019) — 6–8 direct reports guidance

The Conductor era:

• Anthropic, “Agentic coding and persistent returns to expertise” — 70%/20% planning/execution split; managers’ success rate; novice vs. expert results
• Anthropic, Economic Index: Cadences — junior job-loss anxiety, AI-augmenting pattern
• GitHub, “Quantifying GitHub Copilot’s impact on developer productivity” — the 55% controlled study
• a16z, “The Trillion Dollar AI Software Development Stack” — +20% assistant, 2x best-of-breed, “of course not” on replacement
• Ars Technica, “Google CEO says over 25% of new Google code is generated by AI” — the 25%→30% figures
• Matt Welsh, “The End of Programming” — humans to a supervisory role
• Sam Altman, “The Intelligence Age” — personal AI teams
• Cognition, “Introducing Devin” — SWE-bench 13.86%
• Sequoia, “AI’s $600B Question” — the skeptical macro view
• swyx, “The Rise of the AI Engineer” — the AI engineer role
• Business Insider coverage: Airbnb’s ~60% AI-written code; “2 engineers doing the work of 30” and “10 AI startups with tiny teams” — anecdotal founder claims circulating in 2025–26 coverage of small AI-native teams (e.g. Business Insider’s “The Tiny Team Era Is Here”), exact article URL not independently confirmed
• Fortune: “AI agents are flattening corporate hierarchies. Here’s how companies—and managers—can develop a new playbook” (June 2026)
• The Guardian: “Inside tech’s AI-fueled manager purge” — specific article not independently located; verify before relying on this citation
• McKinsey & Co: “The agentic organization” — contours of the next paradigm for the AI era