The Org Chart Decides How It Feels

In the map essay I put two chapters side by side and never connected them. One was about org charts: two-slice teams, pirates and architects, Block’s three roles. The other was about how the year felt from the inside, which for a lot of engineers was bad. I filed them as two topics. Reading them again, I think they’re one.

Here’s the claim. Whether you feel this change as grief or as the most fun you’ve ever had depends on your org chart, not your character. The tools are roughly the same everywhere. What differs is whether anyone moved the role boundaries when code got cheap. Where they moved, the job got bigger. Where they didn’t, the job got smaller and faster, and people were asked why they weren’t enjoying it.

That’s a strong claim, and the evidence is posts, a few essays, and one survey that partly cuts against me. I’ll lay it out, give the skeptics real space, and say what would change my mind.

The pizza paid for typing

Amazon’s two-pizza rule has an origin story that Dan Shipper retells in The Two-slice Team. At a 2002 retreat, managers asked for more communication, and Jeff Bezos answered that “communication is terrible!” A few weeks later Amazon reorganized around small, autonomous teams. More than ten people, more than two pizzas could feed, was too big.

Read it as a price. Coordination was expensive, so teams had to be small. Typing was slow, so teams couldn’t be too small. The two-pizza team was the size at which those two costs crossed. It was paying for typing.

Agents moved one of those curves. Dan’s answer is a team you feed with two slices: one person. At Every, by Dan’s account, there are four software products, each run by a single person, and 99 percent of the code is written by agents. Monologue, the company’s dictation app, has 143,000 lines of code that Naveen Naidu wrote almost entirely alone with Codex and Opus. Design, growth, and marketing act as internal agencies that move people in and out of products as needed.¹/01field noteEvery’s numbers come from Every’s own essay, which is also the launch post for one of its products. Every sells AI apps to readers and AI training and adoption work to companies, so it has a stake in this story.Dan Shipper, “The Two-slice Team”

About a month later Dan posted the version that spread. Two people only: a pirate and an architect.²/02the postsSeeing so much success with 2-6 person teams, especially when deep subject matter expertise … is needed. Allie K. Miller, Mar 23gabe, Mar 22

The idea got picked up, including by Coinbase, which ran pirate-and-architect pods from May.³/03field noteDan had been pushing the pair since April. Coinbase’s version, as Chintan Turakhia described it, adds a part-time designer, makes the pirate the DRI early on, and has the architect drive the “scale-out through spec for agents.”Dan Shipper, Apr 13 · Chintan Turakhia, Oct 10 But the reply I keep coming back to is the one with 165 likes: the architect job “sounds like the worst job ever. Slop clean up crew.”

That reply is the whole essay in miniature. Same two-person team, same agents. One person gets to explore, own a product end to end, and talk to customers. The other gets the mess. Which of those jobs you’re handed is an org decision, and it decides how your year feels.

It also decides whether the mess gets cleaned at all. The map’s second thread is that context is contagious: agents copy whatever they find in a codebase, good or bad, so sloppy code teaches the next change to be sloppy too. The cure is a human with enough attention to reshape it. The architect is that human. If nobody is given that time, the pirate’s prototype becomes everyone’s template.⁴/04field noteBoris Cherny’s map of the Claude Code team has a name for this job, the Sweeper, who “cleans up the UI, simplifies the code and system, unships.” Ben Holmes explained why it can’t be skipped: agents, like humans, “copy bad patterns like a virus.”Boris Cherny, Jun 28 · Ben Holmes, Nov 9

Titles were routing

Jack Dorsey and Roelof Botha make the deeper version of this argument in From Hierarchy to Intelligence. Their claim is that hierarchy has always been “an information routing protocol.” The Roman army nested eight soldiers in a tent under one leader, eighty under a centurion, and so on up, because a leader can manage somewhere between three and eight people. Railroads, then corporations, copied the shape.⁵/05field noteThe essay also covers the Prussian General Staff (“middle management before the term existed”), Daniel McCallum’s first org chart for the New York and Erie Railroad in the 1850s, and the flat experiments at Spotify, Zappos, and Valve, each of which, in Block’s telling, ran into limits as it grew.Jack Dorsey and Roelof Botha, “From Hierarchy to Intelligence” If a model of the company can carry that information instead, you don’t need the layers. Block’s answer is three roles and “no need for a permanent middle management layer.” The map has the three roles; I won’t repeat them.

The part I find more useful is what titles did for the people inside the hierarchy. A title routed work to you, and it also told everyone else how to treat you. signüll put it better than I can, with a story about walking into meetings with VPs who couldn’t place them on a ladder.

“Member of technical staff” is the flattest title there is. It says you build things here and nothing else. If you believe titles were routing work, it’s what you’d expect to spread once agents do the routine part of the work. Some companies stopped trying to name the role at all.⁶/06field noteDia’s hiring post ran through “Slop cannon. Vibecoder. Prototyper. Product Eng. PM.” before admitting “We don’t know what to call this role exactly.”Nick Dobos, Aug 28

I’d like to tell you it is spreading fast, and there’s a number going around that says so. I can’t check it. It comes from a post by Alex Bouaziz about Deel’s own platform, so treat it as a vendor talking about its customers, not as a measurement.⁷/07the posts19x! That's how much "Member of Technical Staff" has grown on Deel's platform since Jan 2024 Alex Bouaziz, Jul 17maybe the single AI builder title that combines all functions isn't really happening, even at the best labs Peter Yang, Sep 2

Peter Yang’s counterpoint is the honest one. Even at the best labs, the title comes split by function: member of product staff, member of design staff, member of technical staff. People still have specialties. What flattened was the ladder, not the function. That’s a smaller change than the hype, and I think it’s the real one. Fewer levels means fewer people whose job is to decide what you’re allowed to touch.

It’s still management

Now the skeptics, and they deserve more than a paragraph. The strongest is Kenton Varda, who in July pointed out that building software by prompting agents without reading the code isn’t new. It’s called being an engineering manager.⁸/08the postsThat's what managers have been doing all along, with their human reports. You are just a manager now. Kenton Varda, Jul 24a manager for a group of sycophantic prodigious savant contractors who can't really form long-term memories Devin Plumb, Jul 24

Addy Osmani made the same point at article length in November, under the title “Your coding agents made you a manager,” and the preview says it plainly: “If you’re spending all day with a coding agent, you are managing.” Uncle Bob Martin went further, in a reply to the most-liked post about engineering misery in my bookmarks: nothing has changed at all.⁹/09field noteUncle Bob was replying to v0xium’s post, which the map covers: a new job at a big company where everything is made by Claude Code and people work 12 to 13 hours a day “just to press enter.”voxium, Sep 20¹⁰/10the postsOnce the software gets beyond a certain level of importance businesses will not want to be dependent on one person. John Crickett, Oct 2

John Crickett’s objection is about a different claim, that teams are going away entirely. Businesses don’t want to depend on one person, and enterprises hire a law firm, not a lawyer.¹¹/11field noteCrickett was replying to Cory House’s theory that development teams are going away and developers will work alone, the way doctors see patients alone inside a practice.Cory House, Oct 2 I think that’s right, and it’s a good check on the two-slice story. Bus factor didn’t stop mattering because the bus got faster.

So the skeptics say it’s just management with new branding. They’re half right.

They’re right that the skills are old. Delegating, writing a clear brief, checking work you didn’t do, building loops so mistakes get caught: managers have done all of that for decades, and engineers who sneer at it are about to learn it the hard way.

They’re wrong that nothing changed, because management used to be a separate job, on a separate ladder, for a few people. Now everyone who touches an agent does some of it, and the replies under Kenton’s post found the difference fast: you still hold the pager.¹²/12field noteThe replies found the differences: you’re “still holding the pager,” an IC and an engineering manager are “responsible in different ways for shipped code,” and, less charitably, “I’ve yet to meet a happy middle manager. Agent prompting just scales the misery.”Phillip Carter, Jul 24 · Ben Weiner, Jul 24 · Alex Taco, Jul 26 A manager of agents is also the person on call for what the agents wrote. That’s a new shape of job. And if the work really is management now, then the org chart matters more, not less, because the org chart is what decides who gets to manage what.

A team, not a factory

The other objection is to the metaphor. A lot of people this year started calling the new setup a software factory. Quinn Slack, who builds Amp with Thorsten Ball, rejected it for Amp itself.¹³/13the postsAt Amp, someone tries it first and asks “should we ship this?” If the answer is “no”, it was just a prompt Amp, Oct 28Amp is not and could never be built by a factory. Quinn Slack, Nov 3

That second post is the clearest picture I found of what a role boundary costs. Every arrow in the old pipeline is a handoff, and every handoff is a wait.

When building something takes a prompt instead of two weeks, the pipeline is the slow part. You don’t fix that with faster engineers. You fix it by letting the person with the idea try it. Amp’s follow-up episode lists the consequences in its chapter titles: “You’re only 21 people” is the point, “Culture stops slop,” and “No PMs in the middle.”¹⁴/14field noteQuinn and Thorsten build Amp, which sells a coding agent, so this is a company describing itself. I’ve read the episode’s show notes on X, not watched it. Quinn also joked that Amp might need a bigger database before it hires any managers.Amp, Oct 20 · Quinn Slack, Oct 23¹⁵/15the posts“How do you not ship slop if everybody can just push to main?” Amp, Oct 30imagine if you founded a startup and you're the only one working on it. nothing would be out of scope. lauren, Aug 28

Lauren (poteto) gives the warning that goes with it. Owning the whole experience was always the job, and AI doesn’t change that. If anything it makes ownership rarer, because it’s easy to become a meat proxy, the human who passes text between two agents.¹⁶/16field noteWill Larson named “meat proxy review” in a post about code review, and the map follows how the phrase spread. “Send Me Your Prompt” has more on what it does to writing.Will Larson, “Speeding up code review with small-change” · What We Had to Unlearn: Writing it yourself A factory is happy to have meat proxies. A team isn’t.

The best argument for keeping teams came from the person who coined the two-slice team. In November, Dan Shipper described giving everyone at Every the same customer survey and the same models. Each person found something different: a sales opportunity, a churn problem from sending too much email, readers who felt lonely in their excitement about AI.¹⁷/17the postsgenerating possibilities is cheap. Knowing which ones matter is hard. Dan Shipper, Nov 11

I read that as Dan arguing against Dan’s own February framing, and winning.¹⁸/18field noteDan’s evidence, as Dan reports it: in an experiment by @hammer_mt, Claude given 400 attempts produced an answer like Dan’s 93% of the time, but ranked Dan’s answer in its own top 10% only about 60% of the time. Generating is the easy half.Dan Shipper, Nov 11 One person with agents can generate the possibilities. Deciding which ones matter takes several people who are each responsible for a different part of the world. A team isn’t a factory because a factory doesn’t decide what to make.¹⁹/19field noteKyle Mathews made the same objection: factories run one process to make identical parts, while knowledge work is “more like an R&D lab or a Michelin kitchen.”Kyle Mathews, Oct 4

Same tools, opposite days

Back to the feelings, which is the part I actually went looking for. In July, Dillon Mulroy, an experienced engineer and not a newcomer, posted the most honest version of the bad day.

The replies split. A lot of them said “me too,” some from people you’d expect to be fine.²⁰/20field note“for real,” from ThePrimeagen; “me too man,” from Ken Wheeler; and the specifics: “I feel like I learn a fraction of what I did before,” and “context switching and that everyone wants everything instantly slowly burns us out.”ThePrimeagen, Jul 5 · patagucci perf papi, Jul 6 · Dreams of Code, Jul 6 · Andras Bacsai, Jul 6 A lot said the opposite, including one person who’d been writing software since the 1970s.²¹/21field notePerry Metzger: “I’ve never been more pumped, and I’ve been writing software since the 1970s.” Another: “in 30 years of doing this, i’ve never felt more alive.” Ben Dicken named the condition: satisfaction “depends significantly on what’s being built.”Perry E. Metzger, Jul 6 · Hot Aisle, Jul 6 · Ben Dicken, Jul 5 What caught me is how the second group explained themselves. The ones I found most convincing didn’t claim a better temperament. They described what they owned.²²/22the postsFor me this comes from not being immersed in the problem. Noah, Jul 5I always liked building the thing, not necessarily writing the code. Whole Mars Catalog, Jul 5Dmytro Krasun, Jul 6

“Software Engineer Me” is frustrated; “Founder Me” is “the happiest I have ever been.” Same person, same tools, two roles. Noah got the joy back by getting a say in the architecture. Those are org changes, not mood changes.

Two weeks later, a developer named Ram described the other side from inside a job, and it reads like a job description with everything interesting removed.²³/23the postsIt feels like someone is just telling you to do the work. There is no enjoyment anymore. Ram, Jul 23

Nothing in that routine is the tool’s fault. The PRD arrives from someone else. The decision space is X, Y, and Z. The deadline is lunch. Ram found the fun again in an app built on the side, where none of those boundaries existed.

In November, Thorsten Ball relayed a conversation with his Amp colleague Lewis Metcalf that put both sides in one paragraph.²⁴/24the postsyour engineers won't become 10x more effective if your org doesn't allow them to Thorsten Ball, Nov 12

Lewis’s point, in full, is that if you were hired only to do engineering and you’re only allowed to do engineering, things might suck. At Amp, Lewis can do marketing, think of product ideas, ship them, talk to users, and record videos. Both of them work at a company that sells a coding agent, so weigh that.²⁵/25field noteA reply under Thorsten’s post put the condition in one line: “the most fun time to be an engineer if ur org lets u off the leash.”Skadoosh, Nov 12 But the mechanism doesn’t depend on Amp. Agents made the engineering part smaller. If engineering is all your role allows, your role got smaller too.

the short version

Your engineers won’t get 10x better if your org forbids them from owning anything.

There’s one piece of evidence that cuts against me, and it’s the biggest sample here. Lenny Rachitsky’s 2026 survey found tech splitting into two halves, one amplified by AI and one shaken, and said which half you’re in predicts how you feel about your career more than your role, seniority, or company size.²⁶/26field noteThe survey also found significant burnout up from 44.7% to 55.7% in a year, and only 22% worried about “losing my job to AI.” I’ve read Lenny’s summary, not the full report.Lenny Rachitsky, Jul 7 If org design were the whole story, you’d expect role and company size to show up. They didn’t. My best answer is that “role” on a survey is a job title, and I’m arguing about what the title is allowed to do, which nobody measured. But that’s a hope, not a finding. The same survey’s biggest fear points my way, though: not losing your job, but being expected to do more for the same pay. That’s a decision someone above you makes.

That most-liked post about engineering misery, the one Uncle Bob answered, ends the same way. Its author, v0xium, wasn’t against the tools: “I would not mind it, to be honest, if we were at least given the time to check out the code and see what is going where.” That’s the contagion thread again. The scarce cure for bad context is human attention, and attention is scheduled by the org. Nobody cleans code on a team that’s measured only on how much it ships.²⁷/27field noteThis is the map’s second thread: agents copy what they find, so the code is also the context. “Make Bad Code Impossible” is about the structural fix. This essay is about who gets the time.What We Had to Unlearn: What stayed

A layoff in a hoodie

There’s a less flattering reading of all of this, and I’d be dishonest to skip it. A lot of “AI transformation” is a layoff wearing a hoodie.

Block is the clearest case, because the sequence is public. In February, Jack Dorsey told the company it was cutting nearly half its people. Then came the essay about hierarchy as a routing protocol.²⁸/28the postsXBOX CEO announces they are shrinking the team by ~3,200 … matches the proposition in Jack Dorsey’s manifesto Joel A. Adejola, Jul 6

To be fair to Jack, the note is unusually direct, and it spells out the severance before anything else.²⁹/29field noteThe note lists 20 weeks of salary plus a week per year of tenure, equity vested through the end of May, six months of health care, and $5,000, and it admits “we may have gotten some of them wrong.”jack, Feb 26 The essay is honest too, in one sentence most readers skip: if your company doesn’t understand something hard, “AI is just a cost optimization story. You cut headcount, improve margins for a few quarters, and eventually get absorbed by something smarter.” That’s Block’s own test, and not every company copying the vocabulary passes it. By July, one reader was mapping Xbox’s restructuring memo, as the post quotes it, line by line onto Block’s three roles.³⁰/30field noteOthers drew the same line from layoff to manifesto. One post set Coinbase’s 14% cut next to Block’s: “Both got there through layoffs. @jack got there through a manifesto.” Another described senior work growing tenfold while managers “Hide in meetings,” and concluded “layoff is in order.”Marmik Pandya, May 15 · Art of Biz, Sep 21

Here’s where my thesis gets uncomfortable. “The org decides how it feels” has nothing to say to someone who no longer has an org. I read replies from people in exactly that spot, and I’m not going to quote them. Their situation isn’t an illustration.

What the thesis can do is put the responsibility in the right place. If loss versus expansion is an org-design outcome, then companies own it. An org that cuts the boxes and leaves the remaining ones the same shape didn’t redesign anything. It just has fewer people doing the same narrow job faster. Xiaoyin Qu named the incentive problem: real AI gains require rebuilding the org chart, and most executives have no reason to do it.³¹/31field noteXiaoyin’s post is about forward-deployed engineers, who, in Xiaoyin’s view, automate “the status quo, because that’s what’s easy to sell.”³²/32the postsask how folks should grow their business by leveraging AI, not how to “right size” their work force Son Luong, Nov 12

My test is simple. If the new org chart only removes boxes, it’s a layoff. If it widens the boxes that are left, it’s a redesign. Most announcements I read this year were the first kind using the language of the second.

Who redraws the boundary

Thorsten’s post ends with an instruction: “If you haven’t done this four times this year already, it’s high time to rethink all of your org boundaries and roles.” The argument is that work that stays fixed, like infrastructure, needs fewer people now, while product teams can and should do more, if the org allows it. The replies pushed back on almost every detail.³³/33the poststhis is completely backwards. You'll find that you get the least acceleration on the infrastructure side. Trent Zock-Robbins, Nov 12creating "one person feature teams", but that means missing out on a lot of creativity Rafael Mendiola, Nov 12Souvik Sarkar, Nov 12

An infrastructure engineer said infra gets the least acceleration, not the most, because it was already automated. Others pointed out that on-call doesn’t shrink with the code.³⁴/34field note“writing infra got cheaper. being paged at 3am didn’t. a humane on-call rotation still needs 5 or 6 people.” And: “The infra team still has to cover the same number of nights and weekends.”Vatsalpandya333, Nov 12 · Zo, Nov 12 A product person said users and sales can only absorb so many changes a quarter. And Rafael Mendiola made Dan’s argument from the other side: size a team for how creative you want it to be, not for the work it has to deliver. All of these are good objections to Thorsten’s examples. None of them is an objection to redrawing the boundaries. They’re arguments about where to draw them.

Marc Brooker wrote the version of this for senior engineers in March. Principal engineers think of themselves like John Candy’s retired bobsled champion in Cool Runnings: still useful because they know the sport. “But we’re not bobsledding anymore.” Brooker calls it “an extinction-level event for rules of thumb,” and the remedy is to get back on the ice: build, own, and update your constants. Then, without irony: “It’s as fun as hell.”³⁵/35field noteBrooker’s list of heuristics that may no longer hold includes what it means for a system to be maintainable, where service boundaries should be, and what’s easy versus hard.Marc Brooker, “My heuristics are wrong. What now?”

Five days later Brooker wrote about juniors, and the answer was the same move made earlier in a career. A new engineer builds and, “much earlier in their career than you might have been comfortable with before,” owns: a project, a customer conversation, a deadline. The people with the least clear path are the ones who want “a low-ambiguity job taking tasks off a backlog.”³⁶/36field noteBrooker’s advice to juniors goes back to a 2019 post of his: join a team that owns something big, and carry a pager. “Reality cannot be fooled.”Marc Brooker, “What about juniors?”

Read those two posts next to Ram’s routine and the pattern is hard to miss. The fun comes from ownership, and so does the career. The grief comes from a backlog that someone else fills. Whether you get the first or the second is mostly not up to you. It’s up to whoever draws the boxes.

What would change my mind is evidence I don’t have yet: engineers whose roles really did widen, with real ownership and time to clean what they own, reporting the same loss as everyone else. If that shows up, the problem is the work itself, and no org chart fixes it. Until then, I think the people drawing the boxes owe their engineers a better one.