Every organisation that has tried to give its teams more autonomy has met the same moment, usually about six weeks in. Someone asks a question nobody can answer: who actually decides this?
The instinct is to conclude that autonomy was a nice idea badly suited to real work, and to quietly reinstate the approval chain. That reading is almost always wrong. What failed was not the freedom. It was the absence of anywhere for the freedom to live. Self-management tools exist to solve exactly that, and the good ones are far less about removing structure than their marketing suggests.
What are self-management tools?
Self-management tools are software that lets a team distribute authority without losing track of it. They make roles, decision rights, open decisions and settled outcomes explicit and visible, so people can act independently while the organisation keeps a coherent picture of who is doing what and what has already been decided.
That is the category in one sentence. What separates the products is which part of that job each one takes seriously.
Autonomy fails from too little structure, not too much freedom
Ethan Bernstein and colleagues studied the wave of organisations adopting Holacracy for Harvard Business Review in 2016, and their finding cuts against the popular framing. Self-managed teams are not less structured than hierarchies. They redistribute structure away from individuals and onto roles, and they need more explicit process rather than less, because the informal shortcuts a manager provides have been removed.
Zappos is the case everyone cites, and it is worth citing accurately. After the March 2015 memo announcing full Holacracy adoption, 18% of the workforce, 260 people, had left within ten months across two buyout offers. By 2017 the company had moved away from Holacracy's meeting machinery.
What is rarely mentioned is what Zappos kept: the circular structure and the role-based organisation. They dropped the ceremony, not the scaffolding. The scaffolding survived because it was doing real work.
That is the lesson to carry into any choice of self-management tools. The value is in making structure explicit and queryable. It is not in the meetings.
The six-week test. If a newly autonomous team cannot, six weeks in, point at one place that answers "who decides this, and what have we already decided", the autonomy is notional. They will route around it by asking a manager, which is the old system wearing new language.
The four jobs self-management tools have to do
Most organisations assemble a self-managing platform out of several products without quite meaning to. It helps to see the four distinct jobs, because almost every failure happens at a seam between two of them.
Making roles visible
Who holds what, and what does holding it entitle you to do. Most self-management tools start here, and it is the job the market serves best. Peerdom and GlassFrog both do it well. A visual map of roles, circles and accountabilities answers the question a new joiner asks on day three.
Making decisions decidable
A role that says you can decide something is useless without a process for deciding it. Proposals, consent rounds, objections and votes live here. Loomio built a business on this layer, and most Holacracy software and every credible sociocracy tool includes some version of it.
Turning decisions into work
The decision is not the outcome. Someone has to do the thing. This is ordinary task management, except that with no manager to perform the assignment it becomes a harder problem than it looks.
Keeping the record
What was decided, when, on what reasoning, under whose authority. Six months later this is the only one of the four anyone cares about, and it is the job most self-management tools treat as an afterthought.
Where Holacracy software and sociocracy tools fit
Underneath tool choice sits a live question: whether to adopt a named method at all.
Holacracy software encodes a specific constitution, with tactical and governance meetings, tensions, and a defined process for changing roles. The rigour is the point, and it asks a great deal, which is why Bernstein's recommendation was selective adoption rather than wholesale conversion.
A sociocracy tool typically encodes consent-based decision making and nested circles with a lighter touch on meeting format, and travels better into organisations not ready to rewrite their constitution.
A cooperative governance tool is different again, because co-ops carry obligations a startup does not: one member one vote, quorum, formal resolutions, an auditable record for the regulator. Democratic governance software in that setting has to satisfy a rulebook, not a preference.
Our own view, having looked at a lot of these deployments, is that the method matters less than whether the four jobs are connected. Teams succeed with sociocracy and teams fail with it. What separates them is usually whether their decisions ever reach their work.
If your bottleneck is | Look first at |
|---|---|
Nobody knows who holds what | Role and org mapping |
Decisions take three weeks | |
Decisions get made and then evaporate | |
Work has no owner without a manager | |
Members cannot participate in governance |
Task management without hierarchy is a routing problem
This is where most self-management attempts visibly wobble, so it is worth separating out.
Conventional project tools assume a person who assigns. Remove them and the tool does not break, it goes quiet. Tasks sit unowned and the team reinvents a manager to clear them, which gets read as proof they needed hierarchy after all.
They do not. They need routing. Task management without hierarchy works when three things are true. Work attaches to a role rather than being handed to a person, so "whose is this?" has a structural answer. Anyone can propose work into a queue, but claiming it is an explicit act with a visible owner. And unclaimed work surfaces as a signal rather than rotting quietly, because unclaimed work usually means a missing role, which is governance information.
None of that requires a boss. All of it requires the tool to know what roles exist, which is why this job cannot be cleanly separated from the first. More on who should assign the work, and on the difference between a task, a responsibility and a role.
The integration gap that breaks most self-managing platforms
Self-management tools rarely fail on features. They fail on seams. Here is the pattern we see most often: role mapping in one product, discussion in Slack, decisions in a poll tool, work in Asana, documentation in Notion. Every individual choice is sensible. The combination fails anyway.
It fails because the connective tissue is human memory. The decision lives in the poll tool. The work it implies lives in Asana, entered by hand by whoever remembered. The reasoning sits in a Slack thread that will be unsearchable by spring. Nothing links them, so six months later you can find that a decision was made but not why, or find the work but not the authority behind it.
That is the real argument for a single self-managing platform rather than a stack. Not that one login is nicer, but that a decision should carry its own consequences: the record written at the moment of closing, the tasks generated from the decision itself, the role that held the authority attached to both.
Autono is built around that link. Decisions happen in Sessions, close into the decision log as a by-product rather than a chore, and become owned work in Tasks without anyone retyping anything. The Repo holds the governance handbook the roles are defined in, and the Hub is where members can actually see all of it.
How to choose self-management tools
Three questions, in this order. They are more diagnostic than any feature list.
Start with your bottleneck, not your org chart
Almost everyone begins by drawing the org chart, because it is satisfying and visible. It is rarely the constraint. The constraint is usually that decisions are slow, or that they do not stick. Buy self-management tools for that.
Ask what happens after the vote closes
Push any demo of self-managing teams software to the moment a decision settles, then keep watching. If the answer involves a human copying an outcome into a different system, you have found the seam where your process will leak.
Ask whether the record is a by-product or a task
If documenting a decision is a separate act of discipline performed afterwards, it will happen for three months and then stop. This is the single most reliable predictor of whether you will still have a usable decision log in a year.
Where to start
You do not need to convert to a named method to get most of the value, and the self-management tools matter less than the habit. The teams that make autonomy work do the unglamorous thing first. They write down who decides what, they pick one place for decisions to happen, and they make the record automatic.
That is a fortnight of work, not a transformation programme. If you want somewhere to put it, get started with Autono, or request a demo and we will show you how a decision travels from open question to owned work in one place.
For the vocabulary, see the governance glossary. For the authority question underneath all of this, start with the decision rights framework.
Sources. Ethan Bernstein, John Bunch, Niko Canner and Michael Lee, "Beyond the Holacracy Hype", Harvard Business Review, July 2016. Fortune, "Zappos' Holacracy Experiment Has Cost It 18% of Its Workforce", 14 January 2016. Quartz at Work, "Zappos has quietly backed away from holacracy", January 2020.
