How do you fix manager performance in a flat organization?

It's Thursday, and the design lead finds out in the all-hands that the onboarding redesign she spent three weeks on has been cut. Her manager knew on Monday. He has eleven people, two product areas, and a hiring loop running, and the message he meant to send her is still sitting in his drafts. Nobody would call him a bad manager. He just has no slack left, and in a flat org, nobody sits between him and the problem to catch it.

That's what manager performance problems usually look like in a flat organization. Rarely one big failure. A handful of small, ordinary conversations stop happening, and the cost spreads sideways onto peers who have no authority to fix it.

Why the layered-org fixes don't work here

In a layered company, a struggling manager gets help from above. A director notices, an HRBP gets pulled in, the manager goes to a program. Each of those moves assumes someone with time and context is sitting one level up.

A flat org took that person out on purpose. (The delayered org makes the longer case for what went missing when the layer came out.) So the three standard moves break down:

• Another layer brings back the cost and slowness you flattened to get rid of.
• An HRBP sees the problem late and secondhand, usually after it has already turned into a complaint.
• A training program builds willingness for a week or two. It doesn't touch the span, the fuzzy standards, or the decisions nobody owns. (Why leadership workshops don't stick goes deeper.)

The fix has to live inside the team, and it has to work for people who aren't anyone's boss.

Four things that actually break

Before you decide the manager is the problem, check the structure around them. In flat orgs, these four fail far more often than talent does.

Span

The manager has more people than they can hold in their head. The tell: one-on-ones get moved, then shortened, then quietly dropped. The manager knows the work but has lost track of the people doing it.

Clarity

Nobody wrote down what good looks like. Two engineers ship the same kind of feature with completely different ideas of "done," and the manager only finds out at review. When the standard is fuzzy, every hard conversation feels like a personal judgment call, so it doesn't happen.

Decision rights

A peer lead and a manager both think they own the roadmap call, or each thinks the other one does. Work stalls in a thread with nine replies and no decision. This is the most common flat-org failure and the easiest to mistake for a people problem.

Skipped conversations

The feedback that should have been one sentence on a Tuesday in January is a pattern by March. With a wide span, that sentence costs more time and social risk than the manager has to spend that day, so it slides. (Why managers avoid hard conversations breaks down those costs.)

Diagnose before you fix

Start from the symptom you can actually see. Each row points to the likely cause and the smallest first move.

What you're seeing	Likely cause	First move
One-on-ones keep getting cancelled or cut to 15 minutes	Span too wide	Count real working relationships, not headcount. Move two people's day-to-day questions to a peer lead.
People are surprised by their review	Clarity	Write a one-paragraph "what good looks like" for each role and share it before the next cycle.
A decision sits in a Slack thread for days with no owner	Decision rights	Name one owner per recurring decision type. Pin it where the team works.
The same missed handoff happens three sprints in a row	Skipped conversation	Someone says one sentence about it this week.
Peers quietly redo a teammate's work instead of talking to them	Skipped conversation, plus no permission	Say publicly that raising things directly with a teammate is expected.
Everything still routes to the founder	Decision rights and clarity together	List the last ten escalations and sort them by who should have decided.
The manager is strong on the work and silent on the people	Span plus skill	Pick the one conversation they've been putting off and prep it together.

Most teams find two or three rows that fit. Start with the structural ones.

What to fix first

Fix in this order: decision rights, then clarity, then span, then the conversations.

The order matters because the conversations depend on the structure. Asking a manager to hold someone to a standard that was never written down puts them in an unfair spot, and the other person knows it. "You should have known" lands as an ambush. Once the standard exists, the same conversation gets short: here's what we agreed, here's what happened, what's going on?

Decision rights come first because they clear the most noise fastest. When the roadmap call has one named owner, a whole category of tense threads disappears, and the manager gets back the hours that were going into refereeing.

Span comes third because it's the slowest and most expensive to change. You often don't need a reorg. You need to stop routing every small question through one person. The senior engineer who already answers "is this ready to merge?" for three teammates is carrying part of that span. Naming it out loud makes it real, and makes it count.

How peers and ICs raise things without a boss in the middle

In a flat org, the person who notices the problem is usually not the manager. It's the peer who keeps fixing a broken handoff, or the IC whose one-on-one has moved three weeks running. If those people wait for someone above to step in, nobody steps in.

The Accountability Dial™ works in every direction, which is what makes it useful here. It has five stages: Mention, Invitation, Conversation, Boundary, Limit. The history of the pattern decides the stage, not how frustrated you feel. Most situations resolve at the first two.

A Mention is one sentence, said early. From a peer:

"Hey, the API spec landed after the sprint started again. Can we get it to the Friday before next time?"

From someone to their own manager:

"Our last two one-on-ones got moved. I'd rather have 20 minutes that happens than 45 that doesn't. Can we lock in Thursdays?"

Mentions can be praise, and in a flat org they often should be:

"The way you split the migration into three PRs made review so much easier. Thank you."

If the same thing happens again after a Mention, it's time for an Invitation: name the pattern and ask what's going on, without assuming you already know.

"This is the third time the spec has come in late. I don't think it's carelessness, so I'd like to understand what's getting in the way. Can we grab 15 minutes?"

Notice what's missing: no threat, no cc to anyone's manager. A peer doesn't need authority to say that. They need the words, and they need to know saying it is allowed. Leaders can give the second part away in one line at an all-hands: "If something isn't working between you and a teammate, tell them first. That's how we do it here."

The heavier stages (Conversation, Boundary, Limit) usually do need someone with decision rights, and that's fine. The first two stages, where most problems get solved, belong to everyone.

A 30/60/90-day sequence

Days 1 to 30: find out what's actually broken

• Run the diagnostic table with the managers, not about them. Ask each one which rows fit their team.
• List the ten most recent escalations or stalled decisions. Sort them by who should have owned the call.
• Write the decision rights page. One page, specific decisions, named owners.
• Say the peer norm out loud, in the all-hands and in the team channel.

Days 31 to 60: fix the structure

• Write "what good looks like" for each role, starting with the roles where review surprises happened.
• Rebalance span where it's worst. Name peer leads for day-to-day questions, and give the role a name so it stops being invisible work.
• Each manager picks the conversation they've put off longest and has it. Stage it honestly first: if it's never been mentioned, it's a Mention, even if it's been bugging you since spring.

Days 61 to 90: make the conversations routine

• Ask every team: what's one thing you raised directly with a peer this month? If the answer is nothing, the norm hasn't landed yet.
• Re-check the escalation list. Fewer calls should be landing in the wrong place.
• Look at one-on-ones again. If they're still getting cancelled, span is still the problem, and it's worth a real structural change.

At day 90, ask a sharper question than "are our managers better?" Ask whether problems are getting named earlier, and by whom. In a healthy flat org, a lot of those names belong to peers.

Where Ren fits

The hard part of all this is the small moment: noticing the pattern on a Tuesday and saying the sentence before Friday. Ren is an AI app in Slack and Microsoft Teams (plus a web app) built for those moments. It notices conversations that aren't happening, helps you judge how serious a situation is, drafts the first sentence in your voice, and asks why it's hard for you to say. It's built on the Accountability Dial™ and works for every seat, so the IC raising a missed handoff gets the same help as the manager. It can't read direct messages between people, and what you tell Ren is never shared with your manager or HR.

To see where your own team stands, start with the 60-second diagnostic, or try Ren.

---

Related: Why managers avoid hard conversations · What is the Accountability Dial? · How to have a difficult conversation at work · The 60-second diagnostic