Self-organizing Team

For a long time the default was separating the people who plan from the people who do the work. A manager breaks the work into a list, decides who does what by when, and passes it down. Whoever receives it follows what's written.

There is a mismatch built into that arrangement: the person who knows the work best isn't the one deciding. Only somebody who has actually been inside that screen's code knows this task is two weeks rather than three days, and that same person knows two tasks need their order swapped. Yet the decision arrives from someone who has never touched it.

Pagedeck had exactly that scene early on. A task list came down and Theo said that building invitations first would mean reworking the permission structure twice. He was right, but the schedule built on that order had already gone to customers. It got reworked twice.

So the decision moves toward the people who know. What gets built and why still gets decided outside; how it gets built moves to the people building it. A self-organizing team is the structure with that boundary drawn. Drawing it badly is the usual reason attempts fail, in either direction.

The point is drawing the boundary of autonomy clearly. Mix up what the team decides with what it doesn't and the structure collapses quickly.

Four things the team decides.

1. Who takes what. No assignments handed down; they sort it among themselves.
2. What order to work in. Whoever understands the technical dependencies builds the sequence.
3. What approach to use. Technology choices, design, and how far to automate belong here.
4. How much to take into this cycle. The volume isn't set from outside.

Four things the team doesn't decide.

1. What gets built and why. Product goals arrive from outside. The product owner is the role that sets priority, and the team doesn't substitute its own judgment for that.
2. When it's needed by. Dates set by a market or a contract arrive as constraints.
3. The quality bar. What counts as finished is an organizational agreement.
4. Who is on the team. Adding and removing people is decided outside it, by whoever owns headcount.

Four conditions have to hold for that boundary to work. Goals must arrive as outcomes rather than task lists, and every discipline needed to ship has to sit inside the team. That composition is called a cross-functional team, and if design or deployment has to be requested from another team, deciding your own sequence stops being possible. Decision authority has to genuinely exist, and the team carries responsibility for the result.

Three places show whether it's actually running. In sprint planning the team sets its own volume; day to day they align progress among themselves and move what's blocked; in a retrospective they change the process itself. A retrospective is the session for reviewing how the team works and deciding what to fix. Without authority to change the process, the first two are ceremony — the meetings happen and nothing about the work moves.

Three conditions make it fit: the problem is complex enough that it can't be fully broken down in advance, technical judgment strongly shapes the outcome, and the people involved have enough experience to make that judgment. Software development generally satisfies all three, which is why the agile family treats this structure as a default.

There are places it doesn't fit.

1. Work whose procedure is set externally. With regulatory or certification steps, the order can't be changed, so there is little room for autonomy to operate in.
2. Teams with shallow experience. A team of entirely new hires tends to start with whatever is easiest, pushing the risky work backward until it is too late to absorb.
3. Emergencies. During an outage somebody has to take command. Deciding by consensus costs time you don't have, which is why incident response runs on a named commander instead.

The manager's role doesn't disappear; it shifts from distributing tasks to explaining goals and clearing obstacles outside the team. Scrum naming a separate scrum master is a way of making that role explicit.

Two failures recur. One is nobody deciding anything; the other is granting autonomy without supplying a goal. The second is more common. A team that doesn't know what the work is for decides by individual judgment, and a few weeks later the directions have diverged.

"We'll handle the assignment ourselves. Just give us the goal and the deadline."

A request to make the decision boundary explicit before work starts.

"This isn't ours to decide — it's a priority question. The owner needs to call it."

What gets built sits outside the team's autonomy.

"You said autonomy, and we're getting approval for every decision."

The authority exists in words but not in practice.

Pagedeck got this wrong on the first attempt. Grace said the team should handle it and stopped sending down task lists — and the goals disappeared along with them. Three weeks later, collecting what everyone had changed, two people had modified the same screen in different directions.

So the order changed. Mia brings what the cycle is meant to achieve as two outcome sentences, and how to divide that work gets settled by the team in the meeting. The team sets its own volume too, and when that volume differs sharply from recent output Mia asks why. Autonomy didn't increase; a boundary got drawn. Divergence between people's work stopped being a monthly discovery after that.

The most common reading is that managers become unnecessary. If the team decides for itself, it sounds like nobody above needs to decide anything. But what goes away is only breaking work into assignments. Setting goals, conveying context, and clearing obstacles outside the team all remain, and in fact the latter grows. Deciding for yourself requires knowing in much more detail what the work is for, and supplying that is the outside's job. A manager who stops assigning and also stops explaining leaves the team spinning without direction.

Believing the team also decides what to build is also frequent. The word autonomy arrives without a scope attached, so it reads that way. But in this structure the team decides the method and the goal comes from outside. Once a team starts setting priority, there is nobody to resolve a clash between a customer request and an internal judgment, and it tilts toward whoever argues loudest. Keeping the role that decides what to build separate from the role that decides how is a precondition here, not an optional refinement of it.