AI Made Individuals 10x Faster. Teams Are Still Stuck.
One-sentence summary: Giving individuals AI can accelerate them 3 to 10 times, but the team's overall output cycle barely changes—the problem isn't the "people" nodes, but the "collaboration dependencies" edges between them. This article uses three old laws of distributed systems to explain why, and then provides a set of concrete actions that both leaders and individual developers can take.
Friday afternoon, 5 PM. A product manager sends a message in the group: "Can we get this copy done today?"
The designer replies: "I can't fit it in today, earliest is next Monday."
This message hung there, uncaught, until the following Monday. This scene is probably one that every team using AI has witnessed over the past year—except its frequency hasn't decreased as expected with the rise in individual efficiency.
This isn't an isolated case. Over the past six months, I've asked several AI-native startups and internal teams at large companies, and the answer is highly consistent: Individual workflows have been accelerated 3 to 10 times by AI, but the team's overall output cycle has barely changed. Some teams have even seen longer delivery cycles because of an added "review AI output" step.
This reminds me of a few old laws I learned over a decade ago from reading The Mythical Man-Month and distributed systems papers.
Back then, I thought they were about "software project management." Now I realize,
- Replace "team" with "distributed system";
- "Person" with "node";
- "Departmental wall" with "network latency";
These laws can be applied almost verbatim to today's problem of AI organizational efficiency.
This article aims to clarify two things: Why a 10x increase per person doesn't translate to a 2x increase for the organization, and what to do about it.
1. The Bottleneck Isn't the Nodes, It's the Edges
Imagine an organization of thousands of people as a directed graph: each person is a node, and every review, alignment meeting, and approval is an edge connecting nodes. Giving everyone AI does one thing: it increases the processing speed of the nodes by 10 times, but it does absolutely nothing to the edges. The overall throughput of an organization is determined precisely by the edges, not the nodes. This judgment can be precisely quantified using three classic laws.
1. Amdahl's Law: Speedup is Strictly Capped by the Non-Parallelizable Portion
The conclusion first: Even if individuals are accelerated to infinite speed, the organization's overall speedup has a mathematical ceiling. This ceiling is determined by the proportion of work that "cannot be done independently by one person and must be done through collaboration."
Expand this section if you want to see the derivation; skip to the next law if you just want the conclusion.
Amdahl's Law gives the speedup formula as:
$S(n) = \frac{1}{(1-p) + \dfrac{p}{n}}$
Where $p$ is the portion of the task that can be independently completed and parallelized, and $n$ is the factor by which this portion is accelerated by AI. The key is the limit:
$\lim_{n\to\infty} S(n) = \frac{1}{1-p}$
For example: If reviews, alignment meetings, and cross-departmental approvals account for 40% of total work time (i.e., $p=0.6$), then no matter how much individuals are accelerated by AI, the organization's overall speedup is capped at 2.5x—and this is the ideal scenario. In reality, the non-parallelizable portion for many teams far exceeds 40%.
There's an easily overlooked angle here worth thinking about more deeply: $p$ is not a fixed constant.
The truly powerful thing about AI might be its ability to turn tasks that originally required cross-departmental discussion into something one person can independently judge and complete—that is, to increase $p$ itself, not just accelerate $n$. This is why the second half of this article, which discusses "building skills for upstream and downstream teams," is essentially doing the harder but more effective work of increasing $p$, rather than continuing to pile onto $n$.
2. Brooks's Law: Collaboration Costs Grow Combinatorially, Not Linearly with Headcount
Fred Brooks, in The Mythical Man-Month, made a counter-intuitive conclusion: Adding people to a delayed project only makes it later.
The reason is that the number of communication paths that need to be maintained among $n$ people is $\dfrac{n(n-1)}{2}$, which grows quadratically.
This law explains why "giving individuals AI" doesn't touch the root of the problem—AI only makes a single node compute faster. The $n(n-1)/2$ communication edges between nodes remain, not a single one fewer.
3. Theory of Constraints: System Throughput Equals the Throughput of the Bottleneck
Eliyahu M. Goldratt's core conclusion in The Goal is: Optimizing a non-bottleneck resource only piles up more work-in-progress in front of the bottleneck and does not increase overall system throughput. If a certain review node is the bottleneck, giving AI to people upstream of the bottleneck only makes the "pending review queue" longer—upstream output speed increases, downstream processing speed remains unchanged, the queue builds up, and the overall delivery cycle not only doesn't shorten, but sometimes gets longer.
How to find that real bottleneck? The simplest but most effective method is to spend a week recording one thing for every cross-team collaboration link in your team: after sending this thing out, how long did you wait to receive the first response? Not the processing time, but the waiting time. Lay these numbers out together, and the longest ones are almost invariably the real bottlenecks—and they are often not the link you thought they were.
The three laws point to the same conclusion:
| Law | Conclusion | Corresponding Phenomenon |
|---|---|---|
| Amdahl's Law | Speedup is capped by the non-parallelizable portion | Reviews/alignments are inherently serial; individual AI can't touch this part |
| Brooks's Law | Collaboration cost grows by $n(n-1)/2$ | Equipping with AI hasn't eliminated a single collaboration edge |
| Theory of Constraints | Throughput = Bottleneck throughput | Accelerating non-bottlenecks only piles up queues in front of the bottleneck |
For AI to truly improve organizational efficiency, it must act on the edges—the dependencies between people—rather than continuing to pile onto the nodes.
If you're in a small team of a few people, without cross-departmental approvals, this framework still holds—it's just that the "edges" change from "collaboration dependencies between departments" to "the cost of switching between the roles of development, design, and operations in your own head." When one person wears multiple hats, what really slows you down is often not any single task becoming slower, but the gaps when switching roles or waiting for external feedback (customer replies, client confirmations). The principle is the same.
2. Turning "Waiting for a Reply" into "Doing It Yourself": A Service-Oriented Transformation
"Building skills for upstream and downstream teams" is, at its core, a very specific transformation: turning a wait without agreed-upon rules into a self-service interface with clear inputs and outputs.
"Design team receives request → schedules → delivers"
This chain essentially means the marketing team sends a request and then waits in place—the response time depends entirely on the other party's schedule and priority, which is completely uncontrollable. This is the most common pattern in efficiency problems: the requester has no choice but to wait. The way to break it has a mature path in the industry—service-enable the capability, allowing the requester to do it themselves instead of queuing for the other party to do it.
The examples in the original text, when broken down, are all different instances of the same thing:
- The design team gives the marketing team a skill to self-serve materials, which is equivalent to turning "design capability" into a self-service interface.
- The R&D team gives the design team a skill to create high-fidelity prototypes, which is equivalent to turning "front-end rendering capability" into a self-service interface.
- The data team gives the business side a skill to self-serve queries and build dashboards, which is equivalent to turning "data query capability" into a self-service interface.
This isn't about weakening the professional value of the upstream team; it's about interfacing the upstream capability.
Twenty years ago, Amazon did almost the exact same thing via executive order—in 2002, Jeff Bezos sent an internal memo to the entire company (later known in the industry as the "Bezos API Mandate"), requiring all teams to expose their functions through standard interfaces and forbidding teams from communicating by bypassing these interfaces privately; violators would be fired. This transformation later evolved into AWS.
The difference today is: a service-oriented transformation that once required a CEO's mandate to push forward now has a marginal cost so low for writing a skill that many teams can do it spontaneously, without waiting for an executive order.
It's hard for a large organization to transform overnight into a structure organized by "loops," but there is a more realistic path: Don't overturn the organizational structure first. First, let local teams produce service-oriented interfaces between each other. Collaboration paths will first become self-service in local areas. The organizational structure will be slowly "dragged" and rearranged by these actually running paths. There's no need to wait for a top-down reorganization; just send out the interface, and the rearrangement has already begun.
This line of thinking is in the same vein as the "loop" concept proposed by Shrivu Shankar in The Transposed Organization—he defines this organizational form as "one person owning the complete decision chain from problem to deployed solution," with the expert's role shifting from direct execution to encoding judgment into specifications usable by agents. This and the article's point that "upstream shifts from ticket processor to specification owner" are essentially two ways of saying the same thing.
3. "Will Teaching Colleagues Replace Me?"
This is the biggest psychological barrier to implementing this, and it's worth explaining the mechanism separately, rather than just offering a "don't worry."
Traditional collaboration is a ticketing model: the downstream sends a ticket, the upstream processes it in a queue, and closes it when done. In this model, the upstream's value is equivalent to "how many tickets were processed"—the scarcer the manpower, the more visible the value, but also the more likely it is to be the first to be replaced by automation once the process is standardized.
A Skill swaps this model for a PR model: the downstream directly calls the skill, getting things to 70% on their own first. The upstream is no longer the "executor processing requests from scratch," but the owner of the specification—defining guidelines, reviewing key changes, and deciding whether to merge new judgment rules into the main branch. Clontent, built by Anthropic's content design team (an internal agent specifically assisting in generating product content copy), walks exactly this path: team members vote weekly on whether to write new rules into the agent's long-term memory. When the agent encounters tasks like "naming things" that fall outside the content team's responsibilities, it proactively calls a human to judge—this isn't something an executor does; it's something a specification owner does.
| Dimension | Ticketing Model (Old) | PR Model (New) |
|---|---|---|
| Upstream Role | Request Processor | Owner of the Specification/Interface |
| Value Manifestation | How many tickets processed | How many rules defined and reused by downstream |
| Source of Scarcity | Limited manpower | Scarce judgment |
| Resistance to Automation | Weak | Strong |
This is also why Chelsea Larsson (a member of Anthropic's content design team and one of the main drivers of the Clontent project) says that because of Clontent, far more people inside the company now understand the "content design" function—she didn't turn herself into an executor swallowed by tickets, but upgraded herself into the person behind the content specifications. The more the downstream uses it, the stronger the presence and influence of the specification setter, not weaker.
There's an easily overlooked prerequisite here: the PR model works because it doesn't require perfection every time.
A 70% draft, plus a sufficiently cheap manual merge mechanism, will have much higher throughput than a processing method that pursues perfection but requires queuing. This is also why the statement "an agent has value as long as it reaches 70%" isn't about lowering standards, but about switching to a more efficient quality control method.
4. When Not to Skill-ify
The previous sections covered the benefits of this approach. To be fair, it also has clear boundaries; not every link is worth the investment.
Don't rush to skill-ify links that involve judgment, not execution. For example, decisions involving value judgments and accountability (whether to release a controversial feature, whether to make an exception for a client). The core difficulty of these links isn't "slow processing speed," but "who takes responsibility for this judgment." A skill can't help much here; forcing it only creates an illusion of "it looks automated, but responsibility is actually more blurred."
Links with very low collaboration frequency have a poor return on investment. If a collaboration node only occurs two or three times a month, the effort to build a skill and maintain its edge cases might cost more time than it saves. This advice seems simple, but it's precisely the step many teams most easily overlook when promoting skill-ification—check the frequency first, then decide if it's worth doing.
An unmaintained skill is worse than no skill. A skill isn't something that works well forever after it's built. Business rules change, edge cases accumulate. If no one continuously updates it, after a few months, the answers it gives will start to be subtly wrong. And because everyone is used to self-service calls without manual review, this kind of error is even harder to detect. This is a risk common to all "self-service" transformations, and it's worth thinking about from the start: who will maintain it, and how often will it be reviewed.
5. How to Implement Specifically
This framework allows anyone, regardless of their role, to find actions they can take immediately. It's broken down into two checklists by role.
If you are a leader / have organizational decision-making power
- Measure waiting times first, then decide which skill to build. Spend a week recording the waiting time for each cross-team collaboration link. The longest ones are the ones truly worth prioritizing.
- The goal of a skill is 70%, not 100%. Covering the most common, most standardized scenarios is enough. For the remaining parts requiring professional judgment, keep a mechanism to "proactively call a human."
- Make this a clear work output, not invisible labor. Building skills for upstream and downstream teams is likely not in anyone's KPIs and is easily procrastinated. Pushing it from the top down yourself, or setting up a dedicated role to do it, is far more reliable than expecting individuals to do it spontaneously.
- Set a maintenance cadence. Even if it's just checking once a month whether the skill's output has started to drift, this action determines whether it's useful long-term or becomes a black box that no one dares to turn off but no one trusts after three months.
If you are an individual contributor / small team without organizational decision-making power
- Start with "yourself" first; don't wait for the company to push it. Identify the one thing where you are repeatedly blocked by the same person or the same link every week (e.g., always waiting for a designer to adjust copy layout, or always having to manually export a data sheet). First, build a minimal skill that only serves you—a script, a prompt template, a fill-in-the-blank document all count.
- Once you've done it once, turn it into "something reusable." Even if only you and two or three colleagues around you are using it, as long as it turns "waiting for the other party to reply" into "doing it yourself," the nature of this thing has already changed from a "personal trick" to a prototype interface—this is exactly the smallest unit of an "edge" being dismantled, as described in this article.
- Don't pursue perfection; solve your own problem first. There's no need to think about "building a standardized tool for the whole company" from the start. If it can reliably save you several hours of waiting time each week, this thing is already worth doing. People will naturally come and ask you later, "Can I use that thing too?"
Conclusion
A 10x increase per person didn't bring a 10x increase for the organization, not because AI isn't powerful enough, but because we applied AI to the wrong place—on the nodes, while the organization's real bottleneck has always been on the edges.
Equipping yourself with AI optimizes a node;
Building a skill for upstream and downstream teams dismantles an edge.
This doesn't require waiting for a top-down organizational restructuring to begin—whether you're a team leader or an individual developer, you can start right now by turning a part of your own capability into an interface that others can use themselves.
That message no longer needs to hang in the group chat until next Monday. This is the real beginning.
6. References
- Fred Brooks, The Mythical Man-Month, 1975
- Gene Amdahl, "Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities", 1967
- Eliyahu M. Goldratt, The Goal, source of the Theory of Constraints
- Shrivu Shankar, The Transposed Organization, Shrivu's Substack, 2026.03 — Conceptual source for the "organizing by loops" section in part two of this article
- Anthropic Clontent / Chelsea Larsson related case study source