A question comes up that affects several people. Someone reaches for a poll, because a poll is quick and it feels participatory. Forty responses come back, split 55 to 45, and now the organisation has a number, a divided team, and no decision.
This is the most common format error in organisations that are trying to be participatory, and it is expensive. The wrong format does not merely fail to produce a decision. It commits you to something you did not intend, and taking that commitment back costs more trust than never asking would have done.
The short version
Poll | Proposal | Async decision-making session | |
|---|---|---|---|
Best for | Gauging preference on something low-stakes or reversible | A specific change you are ready to make unless someone objects | A genuine question with several viable answers and real consequences |
What you commit to | Considering the result | Making the change unless a reasoned objection lands | Reaching a decision through the process, whatever it produces |
Who decides | You, informed by the numbers | The proposer, if no objection stands | The group, through the process |
Time to close | Hours | Days | Days to a week |
Fails when | The question is contested or the answer is close | The change is not yet specific enough to object to | It is used for something trivial |
When to use a poll
Polls are for preference, not for decisions. They work when the options are genuinely equivalent in consequence and you simply want to know what people would prefer.
Which of these three dates suits most people. Which name do you like better. Would you rather have the offsite in March or June. These are questions where the majority preference is a reasonable basis for choosing, because no minority is materially harmed by the outcome.
Polls fail badly in two situations. The first is when the question is contested, because a close result gives you a mandate for nothing and leaves 45% of the organisation feeling outvoted on something they cared about. The second is when the poll is not really a poll, and you have already decided but wanted the appearance of consultation. People detect this quickly and it is more damaging than not asking.
The test before you run a poll. Ask yourself what you will do if the result comes back 51 to 49 against your own view. If the honest answer is that you will do it anyway, do not run the poll. Write a proposal instead and let people object properly.
When to use a proposal
A proposal is the right format when you have a specific change in mind, you are reasonably confident it is a good idea, and you want to give the people affected a genuine chance to stop it.
The mechanics matter. A proposal states exactly what will change, gives the reasoning, names a closing date, and proceeds unless someone raises a reasoned objection. Not a preference, not a dislike, but an argument that the change would cause harm or prevent the group from doing its work. This is the consent standard rather than the consensus standard, and the difference is what makes proposals fast.
Proposals are the workhorse format and most organisations underuse them dramatically. They are faster than a meeting, they produce a genuine decision, they give people a real veto on things that would harm them, and they generate a record almost automatically.
They fail when the proposal is too vague to object to. "We propose to improve our expenses process" is not a proposal, it is an intention, and nobody can raise a reasoned objection to an intention. Specificity is what makes the format work.
When to use an async decision-making session
An async decision-making session is for the questions that genuinely have not been answered. Several viable options, real trade-offs, consequences that matter, and no single person who obviously ought to decide alone.
Should we take on this large client who would represent 40% of revenue. How do we restructure the team now we have grown past sixty. Do we change our pricing model. These are not poll questions and they are not proposals, because there is no proposal to make yet. The work of an async decision-making session is to produce one.
An async decision-making session runs over a defined window rather than in a meeting. The question and its context are published, participants contribute considerations and options in their own time, the options are narrowed, and the group works towards a decision with a defined close. The output is a decision plus the reasoning that produced it.
The reason to run this asynchronously rather than as a meeting is not merely convenience, though the convenience is real for distributed and shift-based teams. It is that a meeting systematically over-weights whoever is most fluent in real time, and an async process gives the same weight to the person who thinks carefully for an hour and comes back with the point everyone missed.
An async decision-making session fails when it is used for something that did not need it. A session for a question with an obvious answer is expensive theatre, and running two or three of those will exhaust people's willingness to participate in the ones that matter.
The routing rule
If you want one heuristic that gets it right most of the time:
Ask whether the decision is already made in your head. If yes, and you are confident, write a proposal and let people object. If yes, and you genuinely do not mind either way, run a poll. If no, and the answer matters, run an async decision-making session.
The failure mode to watch for is the first case disguised as the second: a decision already made, dressed as a poll, to manufacture legitimacy. That is the single fastest way to teach an organisation that participation is not real, and its effects last years.
What happens after, in all three cases
Whatever the format, the output should end up in the same place: a decision record carrying what was decided, the reasoning, who held the authority, and the trigger that would bring it back.
This matters more than the format choice, because a well-run session that leaves no record has to be re-run in eighteen months when the context is gone. The format determines how you reach the decision. The record determines whether the decision holds.
It is also the thing that makes participation feel worthwhile. Someone who raised an objection in a proposal, or contributed a consideration in a session, can see it in the record. Their input is not merely acknowledged, it is part of the reasoning the organisation now runs on.
Where the tooling gets in the way
Most organisations have all three formats available in some form and use them badly, because in the tools they have, the three look almost identical. A poll, a proposal and an open question are all just messages, distinguished only by the words in them, so people reach for whichever is easiest to send. Easiest is nearly always the poll, which is why polls get used for things they cannot carry.
In Autono's Feed, the three are genuinely different objects with different mechanics. A poll collects preference. A proposal has a closing date, an objection route and a defined outcome. An async session runs a structured process towards a decision, for the times when sync would have meant a meeting. Choosing the format is a real choice, which makes it much harder to reach for the wrong one by accident, and everything lands in the decision log when it closes, with who decided, what was decided and why.
If your organisation is trying to make participation genuine rather than decorative, the formats have to mean something. Get started with Autono, or request a demo if you would rather be shown how it works.
If your announcements are going unread, the format choice is usually the cause: see why nobody reads our internal announcements. And if the volume of open items is itself the problem, how much transparency is too much covers the structuring side.
