How AI will disrupt organizations

The rise of the "Full stack builders" and why 1k+ employee companies should be worried.

At a recent Lenny’s podcast, LinkedIn CPO Tomer Cohen said something that really stuck with me:

The way organizations are built is flawed. We are transitioning towards the concept of “Full stack builders”.

That has sent me into a rabbit hole of reflection.

In my experience, the larger the organization gets, the less the share of people working on real value. From a large unicorn perspective, out of 1k people, only 100 might be doing meaningful work. The rest are either administrating or supporting the teams creating the value.

AI significantly changes that equation.

A single software engineer can create an x10 output, negating the need to hire 10 additional people. Without those extra 10 people, the need to build supportive processes goes away. Not only do you avoid this process tax, but you also don’t hire the people who will facilitate it.

If you extrapolate this line of thinking, you might end up with one of the biggest economic shifts of recent years. I’d argue that large 1k+ orgs will slowly but surely get disrupted by fast-moving AI-native teams.

This article is a guide on how to build or become one, with practical examples from real experience.

There’s a catch, though: you’ll have to either start from scratch OR significantly shed your workforce. There are no half-measures.

---

🧬 Today’s Free Article

1. The Org Bloat. The root-causes behind org inefficiency.

2. The AI Leverage. How AI can amplify the output. Why you cannot “impose” AI onto bloated organizations.

3. The New Org Playbook. How roles blur and each leader becomes an agent orchestrator. A practical playbook you can start using today.

How AI can disrupt organizations through the eyes of NanoBanana v2, loosely inspired by the art of Alex Katz

---

🐘 The Org Bloat

According to Gary Hamel, the number of managerial roles grew at a pace of over 190%+ from 1983 to 2014, while the workforce grew by less than 50%. The trend continues.

In the US alone, for every 4.7 workers there is at least ~1 administrative role above them and ~2 support roles.

This bloat follows a predictable cycle. Say you start a company. First, you hire an outsourced team and spend six months building an MVP (at least that’s what I did back in 2013). Once you reach product-market fit, you hire people in-house, starting with a cross-functional team of 10-12 people.

As clients request features, you add more teams, creating layers of reporting. Eventually, information flow stagnates. On top of this, each new employee comes with certain needs. They want vision, strategic clarity, performance evaluation, and regular salary indexing.

To manage this, companies hire support functions: HRBPs, performance managers, and agile coaches—hired ostensibly to “speed up teams.”

As the org stacks layers of reporting, decision-making becomes spread across many teams. In order to safeguard it, you start introducing committees and stage-gates. Moreover, you hire people to facilitate those committees. As you hire those people, the work allotted to them tends to expand. As the Parkinson’s Law says, “work fills the allocated time, even if the actual workload is lower.”

Specific examples of this dysfunction include companies completely detaching from value creation for a month to run performance evaluations, or teams focusing entirely on writing quarterly report documents to prove their value to management.

At the peak of this, you end up with a tech bureaucracy that is designed to protect rather than create. In such a context, a feature rollout can take between 3 to 9 months, and scaling a new process can easily take a year (with all the change management required).

At such a scale, the ratio between the core team (the one that delivers value) and total headcount drops dramatically. At scale of 10 people, all of them are focused on solving customer problems. At a scale of 10000 ~4-5% of the entire org is building the actual product. The other 95% support them and support the supporting teams, creating a vicious cycle.

What’s worse, this core team becomes more and more dissatisfied with the work they are doing. Simply because they are the ones who own the most information → more people want to collaborate with them. This “collaborative overload” leads to lowest engagement and satisfaction scores across the entire org.

From the article “Collaborative Overload” by Rob Cross

The paradox is that while trying to do a good thing and increase the efficiency, those intentions suffocate the actual builders.

🦾 The AI Leverage

AI meaningfully changes the equation by amplifying work. A single senior engineer can now write functional code at the level of 10 junior-to-mid-level engineers, negating the need to hire those additional people.

If one engineer can perform as 10, a team of 50 can execute the workload of 500. This allows a small organization to reach the revenue potential of a $1 billion company. Without the extra headcount, the “process tax” disappears.

In this flat structure, support functions become unnecessary. Information flow is immediate because everyone is in the same room. Feedback is direct, removing the need for formal performance evaluations or “scrum mastery,” which is effectively a patch for bloated organizations. These builders become the CEOs of their technological scope.

This is a complete mind shift. A small team of 10 people can pivot instantly; if a product doesn’t deliver value, it can be rebuilt in a day using agentic frameworks. You don’t need to sustain layers of engineering teams when a single “full stack builder” can rewrite the stack.

By delegating grunt work to AI agents, humans focus on value creation. Product managers build synthetic customers for accurate discovery rather than writing PRDs or selling ideas to management. The team is moving at lightning speed with time to market measured in hours, not months.

Consequently, 90% of traditional corporate tasks - managerial complexities, 1:1s, annual specs, and quarterly budget docs - will disappear.

This is already happening. Tiny teams, generating a 1b+ in revenue, is already a live phenomenon.

This also means that large archaic 1-10k corporations are going to have a hard time (I’d expect massive headcount shedding).

There’s a reason why ~95% of AI integration efforts show low to negative ROI. You cannot induce AI into a large org. This will always be a side-quest pet project.

That’s why in most cases roles like Chief AI Officer or AI Ops are just glorified titles. They are created for PR purposes for investors and the board. “Hey, we’re AI-first, look, we even have the titles”.

In order to become AI-native, the org needs to be designed around agents from the ground up.

Here’s how.

📖 The New Org Playbook

Leadership shifts from managing people to managing agents and stochastic systems. The functional owner is responsible for two core pillars:

1. Context Engineering: This acts as the constraint for agents. A Head of Design specifies the design system and code that agents cannot override. An Engineering Lead defines the environment - e.g., “built on React, Next.js or Nuxt” - and specific library dependencies. A Product Manager defines the core user and it’s attributes (e.g. price sensitivity).

2. Evals: Functional leads must evaluate the agentic framework’s output line-by-line. The effectiveness of these chains becomes the primary KPI.

The future model is a network of small, “two-pizza” teams. You only need one human expert per function (1 PM, 1 Fullstack Engineering Lead, 1 Product designer, 1 Q&A, 1 DevOps, 1 Data Analyst, 1 Agentic Platform Manager, 1 HR, 1 Marketing Lead, 1 Finance/legal).

Roles shift dramatically. For example, the Data Lead won’t build dashboards or do manual research but will orchestrate the data lake for agentic retrieval. Proper databases and event logging will become critical.

The CEO is then responsible for the entire agentic platform and its outputs. If evals in a certain function are below expectations, the CEO intervenes. Additionally, enabling seamless cooperation and data transfer between multiple agents becomes one of the core priorities (call this “Agentic Engagement Studies”).

What’s more interesting is that the boundaries between roles will shift. If a PM can user-test (with synthetic users), design, and code a feature, why set up a grooming session, manage a backlog, and create Jira tasks for engineers?

Just fire up a prompt using the context provided by the Engineering Lead and eval the outputs really quickly.

Real case example

We’ve gotten a taste of this at BirMarket.

An engineering chapter lead has provided the environment specifications and deployment requirements (as a context).

Designer has provided basic design system specifications.

Supportability manager wrote an *.md spec and used the requirements for the context.

Claude code fully coded and designed the feature.

Manager has uploaded the feature directly to the companies github.

The chapter lead has included it into the release.

It is all possible in less than a day.