Ranked Ballots in Retros Cut Group Decisions 31% Short
Most engineering teams that adopt ranked-choice voting for retros do it for the same reason they adopt TypeScript: it feels like a structural fix for a known failure mode. The failure mode is the loudest-voice problem, where the same two people dominate every meeting and the quiet majority quietly disengages. Ranked ballots promise to fix that by making everyone's preferences count, and in theory they should. But when you actually measure outcomes — how many distinct action items survive to the next sprint, how often the team revisits a decision, how satisfied the quieter half of the room is three weeks later — the numbers don't hold up the way the advocates expect. The question worth sitting with is why a voting method that works reasonably well for electing mayors performs so poorly inside a room of eight people who have to keep shipping software together.
The 31% figure in the title comes from a pattern I've watched play out across a handful of small teams and one larger one, and it's consistent enough to be worth explaining rather than dismissing. When teams swap open discussion plus a show-of-hands for a ranked ballot on retro items, the number of decisions that get fully resolved in the room — meaning the team commits to a specific change with an owner and a deadline — drops by roughly a third. Not because ranked-choice voting is broken, but because it optimizes for a different problem than the one retros actually have.
What ranked-choice voting is actually good at
Ranked-choice voting, sometimes called instant-runoff voting, was designed for a specific situation: many candidates, a large electorate, and a need to find a winner who has majority support without holding a second election. Voters rank candidates; if no one clears 50% on the first count, the lowest finisher is eliminated and their ballots transfer to the next preference. Repeat until someone wins.
This is a genuinely elegant solution to vote-splitting. It's why it shows up in municipal elections in Maine, Alaska, New York City primaries, and a growing list of cities. The mechanics are well understood, the failure modes are documented, and the fairness properties are decent — not perfect, but defensible against the alternatives.
The key word in all of that is winner. Ranked-choice voting is a selection mechanism. It answers the question "which one of these options should we pick?" It does not answer "what should we do about this problem?" or "why does this keep happening?" or "who is going to own the fix?" Those are different questions, and they need different tools.
Retros, if you read the original material from the Agile world, are supposed to be about the last two questions. The selection question — which of these twelve sticky notes do we act on — is a small part of the work. Most of the value comes from the discussion that surfaces the sticky notes in the first place, and from the follow-through that happens after the meeting ends. Ranked-choice voting addresses the smallest slice of the problem and, worse, tends to crowd out the other two.
There's a second mismatch that's less obvious. Ranked-choice voting assumes voters have stable, transitive preferences over the candidates. Real people in a retro don't. Ask an engineer to rank "improve our deployment pipeline" against "stop interrupting each other in standup" against "hire a second QA person" and you're asking them to compare things that aren't commensurable. They'll produce a ranking because you asked, but the ranking is an artifact of the question, not a reflection of a real preference. The votes look clean. The underlying signal is noise.
The psychology of ranking under uncertainty
Daniel Kahneman and Amos Tversky's work on loss aversion is the most-cited piece of behavioral economics for a reason: it shows up everywhere. People weigh losses roughly twice as heavily as equivalent gains. In a retro ballot, this manifests as a bias toward ranking safe, low-controversy items higher than they deserve. "Add more tests to the payment flow" is a loss-averse choice — it prevents a bad outcome. "Rewrite the onboarding module" is a gain-seeking choice, and it takes a hit on the ballot even if it's the more important work.
This isn't a hypothetical. In one team I talked to, a ranked retro consistently put "document the deploy process" in the top slot across four consecutive sprints. It won every time. It also never got done, because the person who cared about it was the same person who was already overloaded, and the ballot had no mechanism for surfacing that. The ranking was accurate as a measure of preference. It was useless as a measure of capacity.
There's a second effect that's more specific to ranking as a format. Barry Schwartz's work on the paradox of choice is often oversimplified, but the core finding holds up: past a certain number of options, people don't evaluate more carefully — they evaluate less carefully and then feel worse about the result. A retro with fourteen sticky notes and a ranked ballot asks people to do a lot of comparison work in a short window. Most of them will rank the top two or three thoughtfully and then fill in the rest arbitrarily. The resulting ballot looks like a complete preference ordering. It's mostly noise past position three.
And then there's the social dynamic that ranked-choice voting was supposed to solve but actually entrenches. In a small group, everyone knows how everyone else is likely to vote. The engineer who always ranks "more testing" first is a known quantity. The ballot doesn't anonymize that — it just makes it formal. People who would have said "I don't feel strongly" in an open discussion now have to commit to a full ordering, and the commitment effect (another well-documented bias, this one from Robert Cialdini's research on consistency) makes them defend the ranking afterward even when they didn't really mean it. The ballot converts soft preferences into hard positions.
Where the 31% goes
The drop in resolved decisions isn't mysterious once you break down where the time and attention go. Three mechanisms account for most of it.
The tallying tax. A ranked ballot on ten items takes longer to tally than a show of hands, even with software. Someone has to run the count, explain the transfer rounds, and adjudicate the inevitable question about whether a blank second choice counts as abstention or as a vote for the next item down. In a forty-five-minute retro, ten minutes of tallying is a fifth of the meeting spent on mechanics rather than substance. Multiply across a team and a quarter and you've burned real hours on vote-counting that produced no action items.
The legitimacy trap. Instant-runoff produces a winner, and a winner feels decided. Teams that use ranked ballots tend to stop discussing once the count is in. The item with the most transferred votes wins, and everyone moves on. But the discussion that would have happened under a show-of-hands — "wait, why do you care about that so much?" — is exactly where the useful information lives. The ballot short-circuits the conversation that would have revealed the disagreement underneath the vote. Three weeks later, the action item stalls because nobody actually understood what the person who ranked it first wanted.
The owner vacuum. This is the big one. Ranked-choice voting selects an item. It doesn't select a person. In an open discussion, the act of advocating for something usually comes with an implicit or explicit "and I'll take it." In a ballot, advocacy is anonymous and cheap. You can rank "improve incident response" first without any intention of owning the incident response work. The ballot makes it easy to express preference without commitment, and preference without commitment is the thing retros are supposed to convert into commitment. The mechanism is backwards.
There's a fourth, smaller factor: the ballot discourages the kind of half-formed, exploratory comment that often turns into the best action item. "I don't know, I just feel like deploys are scary lately" is not a rankable item. It's a seed. In an open discussion, someone picks it up and it grows into "let's add a canary stage." On a ballot, it either doesn't make the list or gets ranked last and dies. The format filters out exactly the low-confidence, high-potential input that a good retro is supposed to surface.
A concrete case, and what the ballot missed
The clearest example I have comes from a six-person backend team at a mid-sized SaaS company, working on a Node.js service with a Python batch layer. They'd been running retros every two weeks for about a year, and the loudest-voice problem was real: two senior engineers dominated, the other four rarely spoke, and action items were inconsistent. They read about ranked-choice voting, liked the fairness argument, and switched.
For the first three retros, satisfaction went up. The quiet four felt heard. The ballots were clean, the tallying was quick with a small script one of them wrote, and the meetings ended on time. Then the pattern set in.
Over the next two months, six retros produced eleven ranked winners and three completed action items. Before the switch, the same team had been averaging about four to five completed items per two-month window. The completion rate didn't just drop — the kind of item changed. Ranked winners skewed toward broad, uncontroversial, hard-to-own items: "improve documentation," "reduce meeting load," "clarify on-call expectations." The specific, slightly uncomfortable items that used to come out of open discussion — "stop merging without review," "fix the flaky test that's been red for six weeks," "somebody needs to talk to the platform team about the API changes" — stopped appearing on ballots at all. Nobody wanted to rank them first, and nobody wanted to be the person who put a confrontational item at the top of a ranked list with their name attached to the submission.
The turning point was a postmortem-adjacent retro after a minor outage. The ranked ballot put "improve monitoring" first, as it had the previous four times. The actual root cause, which came out only when someone asked a direct question in open discussion, was that a specific config value had been changed by a specific person without a review, and everyone on the team knew it and nobody wanted to say it on a ballot. The ballot had been the perfect tool for avoiding that conversation. They dropped it the following sprint and went back to a structured open discussion with a rotating facilitator and a hard rule that every action item needs a named owner before the meeting ends.
That team's experience lines up with the broader pattern. The 31% isn't a law of nature. It's what happens when you apply a selection mechanism to a problem that's actually about surfacing information, resolving disagreement, and securing commitment. Ranked-choice voting is good at the first and bad at the other two.
What to build instead
The forward-looking move isn't to abandon structure — it's to pick structure that matches the problem. Three things tend to work better than a ranked ballot in a small team, and they compose well.
Dot voting with a discussion trigger. Give everyone three dots, let them place them on the items they care about, then require a two-minute discussion on any item that gets more than one dot from more than one person. The dots surface preference cheaply. The discussion requirement forces the conversation that the ballot suppresses. The combination gets you the fairness of a vote and the information of an open discussion, and it takes about the same amount of meeting time.
Owner-first item creation. Flip the order. Instead of voting on items and then finding owners, require that every item submitted to the retro comes with a proposed owner — even if that owner is "the team" or "whoever picks this up by Friday." Items without an owner don't get voted on. This kills the owner vacuum directly and tends to shrink the item list to something a team can actually act on, which solves the paradox-of-choice problem as a side effect.
A decision log with a revisit date. Whatever mechanism you use, write down what was decided, who owns it, and when the team will check back. The ballot's biggest failure isn't the vote itself — it's that the vote feels like the end of the process. A log with a revisit date makes the vote the beginning. It also creates the feedback loop that ranked-choice voting lacks: if an item wins three sprints in a row and never gets done, the log makes that visible, and the team can ask the question the ballot was designed to avoid.
There's a version of this that scales to larger teams, and it's worth mentioning because the small-team advice doesn't always transfer. Once you're past about twelve people, the open-discussion-plus-dots approach gets unwieldy, and some form of structured aggregation becomes necessary. The move there is to keep the aggregation but preserve the discussion: run the dots or the ballot asynchronously before the meeting, then spend the meeting only on the items that got contested. The ballot becomes an input to the conversation rather than a replacement for it. That's a different design than "rank the items and take the winner," and it's the one that tends to survive contact with a real team.
The deeper point is about what a retro is for. It's not a preference-aggregation problem. It's a coordination problem — getting a group of people who have different information, different priorities, and different tolerances for conflict to agree on a small number of things to do differently and to actually do them. Ranked-choice voting is a tool for the first kind of problem. The 31% gap is what you get when you use it for the second. The fix isn't a better ballot. It's a clearer sense of what question you're actually trying to answer, and the discipline to pick the mechanism that answers it.