The Flat Org Hype Is Loud

There is a narrative running through CEO forums, board meetings and investor calls right now that goes something like this: flat is fast. Remove the layers, trust the teams, let AI do the rest. It sounds compelling, especially when you are staring at a company that is slowing down precisely as it adds people and process.

I am not going to tell you that is wrong. What I will tell you is that most companies that try to make that leap do it backwards. They restructure first and then discover, expensively, that the problem was never the org chart. It was the system underneath it.

If your company is feeling slow and layered, the most useful thing you can do right now is not redraw the reporting lines. It is run one contained autonomous team experiment, read what it tells you, and let that signal guide what comes next. This is how you do that.

First, align on what you are actually testing

An autonomous team is not the same thing as a flat org, but at the core of any flat organization is greater autonomy, and this is a smart way to test whether your operating system can actually support it before you commit to the structural change. Most companies that flatten without running this test first find out too late that the problem was never the hierarchy. It was the operating system underneath it.

What matters is whether the team has clarity on what they are trying to achieve, who is accountable for it, what they can decide without asking for permission, and whether the conditions are in place for them to actually do the work without depending on the rest of the organization to function. That last one is where most experiments break before they even get started.

You are testing two things simultaneously: whether this team can move a business metric, and whether your organization can actually operate with more autonomy. The first question is obvious. The second is the one most forget to look for, and it is the more important of the two.

Step 1: Choose the right slice

Pick one high-leverage slice of the business and design a cross-functional team around a single outcome. Think: improving conversion at one stage of the funnel, reactivating dormant customers, or driving expansion revenue for a specific product line. The slice should be measurable, revenue-adjacent, and something a small team can materially move within the established timeframe.

The criteria are simple: is there one measurable, high-impact outcome this team can materially influence, and can they do it without being constantly blocked by another function? If the answer is yes, you have found your slice. If no, you have an operating system issue to solve first. Specifically: you do not have clear enough priorities to know which slice matters most, or you do not have the shared rules in place to let a team work without constant cross-functional permission-seeking.

Step 2: Define the outcome, not the projects

When this goes wrong, the team gets handed a work-stream instead of an outcome, and within a few weeks, they are executing tasks with no real clarity on whether any of it is working.

Define one primary metric for a X-day window. Not "improve conversion" but "increase the number of qualified mid-market prospects who book a second sales conversation from 20 to 35 per month." The difference between those two sentences is a team that knows when they have won and a team that is always partly winning. One or two supporting metrics at most. No more than that, the constraint is the point. When a team has one thing to move, they make decisions differently than when they have a list of objectives that all feel equally important.

When a team has clear outcomes that ladder up to a clear priority rather than a list of projects, the signal is clean and decision-making is faster. The important shift here is that the team owns which experiments they run to hit the outcome, rather than waiting for functional leaders to assign projects. AI can accelerate that loop significantly: helping the team generate and test ideas, analyze data faster, and ship more iterations without adding headcount. It is an amplifier for a team that already has clear ownership. It is not a substitute for it.

Step 3: Build a true cross-functional pod

You cannot fake autonomy with a functional structure. If the team still has to wait on another function for daily progress, they are not autonomous. Form a small, named pod with the minimum skills required to move the lever end-to-end. Note: skills, not necessarily people. Before you assume you need to add someone, ask yourself whether anyone in the organization can cover more than one of the required skills. A minimum viable GTM pod needs someone who understands the product, how to close or advance revenue, can translate the offer into messaging and positioning, can read the data, and can build or ship on the technical side without waiting on a central engineering queue. Those are five capabilities. They do not have to be five people.

Be deliberate about who goes into this team. People who need a lot of structure, clear direction, and regular check-ins will struggle in this environment, and it will not be a fair test of the model. You want people who are comfortable with ambiguity, can prioritize without being told, and will push decisions forward rather than upward. Where someone has the right mindset but a skill gap, AI can genuinely help bridge it, particularly for data analysis, content production, or rapid experimentation. But autonomy readiness is not something AI can compensate for.

The team also needs one Initiative Owner. The team is collectively accountable for the result, but when the team cannot reach a decision, someone needs to be able to call it without escalating outside the pod. That is the Initiative Owner: not a manager above the team, but a named person inside it who has the authority to break the tie and keep things moving. Without that, unresolved disagreements quietly become the thing that kills the experiment. And they need to be fully committed to the team. Someone running this as a side responsibility alongside their existing role will not give you a clean read on what is actually possible.

The critical infrastructure test: can this team make meaningful progress on any given day without waiting for someone outside the pod? If a single engineer from a central platform team is the bottleneck, the autonomy has already collapsed. If a platform dependency is genuinely unavoidable, name it, assign one person to manage that relationship formally, and make it a defined role rather than an ongoing coordination cost.

Step 4: Write down the decision rights

This is the step almost every company skips. It looks like bureaucracy but is one of the things that actually creates speed. If people do not know what they can decide without approval, they will escalate. Not because they are not capable, but because escalation is the rational choice when the boundaries are unclear. Nobody gets in trouble for asking. People do get in trouble for making a call they were not supposed to make.

Document it explicitly and keep it simple. Something like: "This team can test, build, and spend without asking permission. The only things that need a conversation upward are hiring and anything over $10k." That clarity, in writing, changes how people work. Vague encouragement to move faster does not.

Shared rules and language let teams operate without friction. When they are in place, people do not need to ask what they can do. They already know. When they are not, the experiment fails not because the team lacked capability but because the boundaries were never clear enough for anyone to act on them.

Your role as CEO, or through one named leader, is to remove blockers, not micromanage tactics. One leader, one set of expectations.

Step 5: Give the team a cadence

Autonomy without rhythm becomes drift. The team needs a consistent structure for reviewing their own progress and surfacing blockers without waiting for someone external to notice. A weekly execution review, a bi-weekly metrics check, and a monthly outcome checkpoint with one shared dashboard visible to leadership is the minimum.

The cadence should match the nature of the work. A team in early exploration mode needs lighter check-ins as they test hypotheses quickly. A team in execution mode needs a rhythm that tracks progress against a known outcome without adding overhead. The rhythm each team runs on is set deliberately rather than inherited from the company calendar. An AI-assisted dashboard can remove the need for most check-ins, but only if the team has the capability to set it up. If the capability is not there yet, track it manually. The data matters more than the tool.

There should be one person whose job is to remove blockers, not to direct tactics. The instinct when something is not moving is to get involved in the work. The right move is to identify what is in the team's way and clear it. Those are different jobs, and the experiment depends on keeping them separate. This cadence also keeps the work visible enough for you to see whether more autonomy plus AI is giving you more speed, or just more noise.

Step 6: Instrument the learning

You are testing an operating model, not just a GTM play. That means you need to track both the business outcome and the operating model indicators side by side throughout the pilot, not just at the end.

On the business side: did the metric move?

On the operating model side: how long did it take from issue to decision? How often did the team escalate? How many cross-team dependencies created friction? Did ownership and psychological safety improve or erode?

These signals are what turn a story about a pod into real evidence you can use internally, and they are the basis for deciding what happens next. Most of this can be tracked without adding overhead: a simple Slack integration captures decision latency and escalation patterns, a meeting capture tool handles qualitative signal, and shipping velocity is visible in whatever the team is already using to manage work, Linear, Jira, or a shared log if the process is easier. The infrastructure is lighter than it may sound.

The invisible work: what you have to do in parallel

The pilot team is the visible experiment. What happens in the background determines whether you can ever scale it.

Talent readiness. Before or alongside the pilot, honestly assess whether your broader people are ready for autonomy. In most teams you will find roughly 20 to 30 percent who thrive in this mode naturally, 40 to 50 percent who can grow into it with the right support, and some who genuinely prefer a more structured environment. This is not a judgment. It is a diagnostic that tells you how much up-skilling or reshuffling the model actually requires before you scale it.

Manager to coach shift. If the people currently managing these teams keep directing rather than coaching, the experiment will not hold. Coaching rather than solving, asking outcome-based questions, tolerating productive friction, allowing reversible mistakes: these are real behavior changes that require deliberate investment, not just a new operating model announcement.

Planning and platforms. Autonomy raises the bar on how you set and track priorities, manage dependencies, and maintain visibility into what is actually moving. If your planning and systems are weak now, more autonomy will expose and amplify that weakness, not fix it.

Career and compensation. Autonomous systems often break down when growth paths and pay logic are unclear. You need a view of how people progress and get rewarded without simply climbing a management ladder, because if that path does not exist, your best people will eventually leave to find one that does.

How to read the results

Evaluate on two axes.

The first is business outcome. Did the metric move meaningfully? If yes, you have commercial signal. If no, understand why before drawing conclusions. Was the goal unclear? Was the team under-resourced? Was there a dependency that undermined them before they got started? The answer changes what you do next.

The second is operating friction. Did decisions speed up? Did escalations drop? Did the team actually own the outcome, or were they still looking upward for signals about what to prioritize? This is the axis that tells you whether autonomy is taking hold or whether you have a team that talks about ownership but still functions like a traditional function.

If business performance is up and operating friction is down, you have something real. Scale the pattern to a second team. If business is up but friction is still high, the model has commercial merit but your coordination system is not working yet. Fix that before you expand. If both are flat or going the wrong direction, do not scale. That result is still valuable information.

Only at this point should you revisit the question of whether to flatten the org. You will be answering from evidence, not ideology. You may decide to expand the autonomous team model and redesign layers, roles, performance, and compensation step by step, thoughtfully but not slowly. Or you might find that targeted autonomy plus better planning and updated leadership behavior gives you most of the speed you wanted, without a full structural overhaul. Either outcome is a good one. The experiment is how you find out which it is.

What this experiment is really testing is whether the system underneath your company can support a different way of working. If it cannot, no amount of restructuring will fix that. But if it can, you will have evidence to build from rather than a theory to bet on.