The AI-Native Organization: Smaller Teams, Faster Execution, Fewer Roadmaps

This is a time of the year where every organization is working out the structure that makes sense for them. And this year, every firm clearly has significant changes planned.

A big contributor is AI. Tools have evolved massively since the start of the year (coding tools, org harnesses, best practices), and many of us now run org structures that don’t match what’s possible today. That may be slowing us down.

The fundamentals of creating a great product have not changed.

At the end of the day, all of us need to

understand our consumers,
know our unfair advantage / right to win
Execute cleanly, against your goal - reliably and consistently on things that matter most

But with Coding tools evolving the way they have, a lot of the “how” has collapsed.

Claude already is writing about 90% of Claude Code’s code.

https://x.com/ClaudeDevs/status/2111168901723906176?embedable=true

Traditionally non-technical users like Marketers and Finance have also warmed up to pushing code using org provided and self owned harnesses.

As a part of this study, we have looked at a broad range of technology firms, from the large, like Amazon and Microsoft, to Shopify and Linear, as well as smaller labs like Every - and how they have evolved over the year to adapt to this new reality

Some of the across-the-board changes

A few common patterns across organizations include

Firstly, teams have gotten smaller.

Salesforce is experimenting with one-person and three-person teams. So is Meta, with three- to five-member teams. Every has redesigned the construct into “two-slice” teams: a single person running an entire product.

“We have four software products, each run by a single person.” — Dan Shipper, The Two-slice Team, Feb 13, 2026 (tweet)

Most companies have realized that the shorter the distance between idea and execution, the lower the friction. And with agents, people can have virtual team members rather than actual ones, which avoids the need for a full setup.

The emergence of the builder persona

Companies have also started experimenting with consolidation of roles into common profiles.

For example, LinkedIn has started its builder program, where individuals in very small teams own end-to-end accountability, from customer focus to outcomes.

https://careers.linkedin.com/pathways-programs/entry-level/apb

Anthropic has stopped talking about roles, and talks more about Archetypes. They have also stopped bucketizing the roles of designers, product managers - and meld everyone into a common job title - MTS (member of technical staff), with designers pushing code, developers PM’ing and PM’s developing.

https://x.com/bcherny/status/2071379474277613732?embedable=true

Over time, when designers and PM’s write code, engineers design and plan what to release - the functional hats everyone wears is more and more likely to transform into what each person brings to the table (growth, consumer sense, building and architecting)

Companies with decisive leaders (founders) are adapting the fastest to these new structures

When speed of decision making is key, having committees decide on the right approach is clearly a drag on time. We see firms with founder leaders taking a stronger stance.

For example, Ramp has mentioned that “everyone is a builder” and they expect nothing else from anyone in the organization.

https://x.com/eglyman/status/2070137496399155243?embedable=true

Tobi talks about the expectation from teams on AI adoption, decisive leadership.

https://x.com/HarryStebbings/status/2051302577149800570?embedable=true

AI-forward firms have started building their own harnesses (virtual teams)

Harnesses are the organizational brain and actioning engine, and which practically operate through the equivalent of chat. For example, Ramp’s Inspect and Shopify’s River allows anyone in the companies to be a builder and get what they want done (Create creatives, run a campaign, develop code).

No intermediaries for capabilities that are not consumer facing.

Therefore - teams beyond engineering are coding. Whether it’s marketing or finance, all teams have started pushing code.

So what do teams look like - compositions, roles & responsibilities

The delivery unit is now a pod of one to five builders (accountable for outcomes)

that owns a problem end to end for a fixed stretch. Meta is moving from teams of 10–20 to pods of 3–5. LinkedIn forms engineer, designer and PM trios for about a quarter. Roles are a lot more fluid, sure engineers write more of the code that customers see and ensure scale. But designers, PM’s and other roles also operate on code / so design as a function is not sacrosanct to designers, neither is code sacrosanct to developers. This is a slow pivot towards archetypes - from the existing role-based functions

In this new structure, The pod owner answers for the end metric itself, whether that’s revenue, retention or customer time saved, and everything else, agents included, is just how they get there.

There is a thin - but strong central team - driving the company harness.

A small platform team runs the company harness: Ramp’s 5-person Inspect team, Shopify’s River and Stripe’s Minions. The Harness acts as everyone’s virtual teammate - operatable through slack or any channel of choice. This allows for multiplayer real-time development, as well as non-engineers being able to get work done on code with limited human intervention or gatekeeping.

Quality and security, reviewed by risk level

With teams incentivised to ship fast, that works well, until a major stability, security or compliance issue kicks in. Non-negotiable functions are gatekept (to the essential degree), and reviewed by agents (and humans) above a certain risk level. Even at Shopify, a human still reviews every production PR.

Shared specialists, who codify what can be codified

Design, growth and marketing move between pods instead of sitting inside them. They codify everything they can, and check it into the codebase for all engineers to use. But they still get involved in the most important phases of each project.

Define a frontier team, which keeps everyone current

With all teams now focused significantly on outcomes and speed of delivery, it’s impossible for everybody to keep track of the latest developments in the market. That’s why there is typically also a frontier team. Its members may not be allocated full-time, but they are responsible for synthesizing what’s going on in the world and systematically bringing it into the organization. Examples are Every’s frontier team, Meta’s Agent Transformation Accelerator and Ramp’s Glass, built so the company “learns things once”.

What does planning look like

Naturally, the next key question is how planning takes place. Are roadmaps still relevant? Are they quarterly or weekly? Are they built around goals?

The long feature roadmap is mostly gone.

Microsoft’s Copilot chief Jacob Andreou put it bluntly: “the reality is a six to twelve month roadmap doesn’t really exist.” Notion’s 2026 roadmap lists no features at all, only a principle about responding quickly to major changes. “Ditch fixed roadmap” was a callout from Slack CPO Rob Seaman.

https://x.com/Devlabs_AH/status/2056918329521017217?embedable=true

Direction still exists, but it’s three to six months and set by a leader.

On Claude Code, Boris Cherny sets a three-to-six-month vision and the PM works back from it. Linear keeps roughly a six-month direction but reprioritises weekly, because when building is cheap it’s easier to build the wrong thing.

https://x.com/joonaslindholmm/status/2117137003556823229?embedable=true

Execution cycles have collapsed from quarters to weeks.

Meta’s pods moved to four-week sprints instead of six-month planning cycles. HubSpot went from annual planning to six-week sprints. Tobi Lütke now calls Shopify’s own six-week review cycle “way too limiting”.

https://x.com/lennysan/status/2047669259380383955?embedable=true

Plans are tested by shipping, not by review meetings. Most Claude Code features launch as research previews. Ramp lets teams ship to an early-access tier whenever they want, and reviews only before general release.

https://x.com/eglyman/status/1996604079930331253?s=20&embedable=true

What does it mean for you

Clearly, every organization is different. Sometimes commercial teams and tech teams are separate. But a few things hold:

Rationalize into cross-functional teams wherever possible.
Keep teams small, focused on end-to-end accountability.
Codify best practices, whether it’s design, analytics or engineering, and run shared services for the specialists who aren’t broad-based generalists.
Invest in your company harness if you want non-technical people on board. Giving them the right tools really matters: every individual running their own Claude Code does not create shared knowledge and capability.
Lead decisively. When you don’t have a roadmap, it’s still important for someone to make sure the direction isn’t constantly reset. Decisive leadership and a single line of control are super important.
Make token spend visible, not restricted. Everybody understands ROI once the token budget crosses the people budget. Make sure everyone knows what they are spending on, without restricting them.

In the end, it’s clear that org structures will keep changing, and likely more often than once a year. What’s most important is for the organization to stay agile to changing needs. It’s going to be a wild ride.

References

Introduction

Anthropic (@ClaudeDevs): Claude writes about 90% of Claude Code’s code

Teams have gotten smaller

The emergence of the builder persona

Decisive leaders (founders)

What this means for each team

Quality and security

Shared specialists

The frontier team

Graphic only (numbers not cited in the text)