“Everyone always seems to get the easy ones” is a complaint about a process, not about the tasks. It persists because the process is invisible: nobody can see why a particular colleague was chosen, so the absence of a reason gets filled in with suspicion.
A random draw does not make the distribution equal. It makes the reason visible, which is the part people were actually objecting to.
What Random Assignment Does
It removes you from the decision. Not your judgement — your selection. You still decide which tasks exist and roughly how long each takes. What you stop doing is choosing who gets what, which is the step people read as favouritism whether or not it is.
It gives everyone an equal chance. Uniform, not equal. Over a short period someone will draw the short straw twice. This is worth saying out loud to your team, because the alternative is that they conclude the process is broken.
It gives you a record. A screenshot showing the list and the result is a better defence than an assertion that you were fair, which is unfalsifiable.
What It Does Not Do
It does not balance workload. Random assignment gives equal probability, not equal effort. Rotating a ten-minute task next to a two-hour task produces an unequal week that is mathematically fair, and your team will correctly call that unfair.
Fix it before you draw, not after: either split the large task or accept the imbalance out loud. What does not work is drawing anyway and hoping nobody notices.
It does not account for skill. If a task requires a qualification, randomising guarantees sometimes that the wrong person has it. Assign those deliberately, and randomise the rest.
It does not handle dependencies. If one task must happen before another, sequence them instead of pairing them.
It is not a rota. Over four weeks, four random draws will not give everyone the same workload. If that is the requirement, you need a published rotation, and you can use the draw only for the parts that genuinely need it.
Setting Up a Rotation That Holds
List the people. Full names where two people share a first name, or the result will be disputed on a technicality.
List the tasks as comparable units. Not “kitchen” and “accounts” — those are different amounts of work. If one is three times the other, either split it into three or group them by weight before rotating.
Save both lists. Re-typing them every week is what kills a rotation. Saved lists keeps up to five, works in your browser without an account, and syncs across devices if you sign in.
Fix a day. A draw tied to a trigger — Monday standup, month end, the start of a shift pattern — is a rotation. An ad-hoc one is a gesture.
Review after a month. Look at who actually got what, not at what the draws said. This is the step most teams skip, and it is where you find out that one task takes twice as long as you thought.
When to Draw in Front of People
If the process will be questioned, run it where it can be seen. Screen-record the draw with the participant list in frame, or run it in front of the team.
This is not about theatre. It is that a random process nobody witnessed is indistinguishable from a biased one, so the witness is what makes the difference real rather than asserted.
One-Time Assignments
A different pattern. For a single task, draw one person from a list of volunteers, or draw from everyone if the task is genuinely shared.
Do not draw a name to assign a task someone has volunteered for — it wastes the volunteer and creates a strange obligation.
Task Matcher handles the pairing case: people on one side, tasks on the other, matched in one action. It reports unassigned tasks rather than quietly dropping them, which matters when the count does not divide evenly.
What the Underlying Method Is
Draws use the browser’s cryptographic random source rather than Math.random(), which is predictable — its output can, in principle, be anticipated by reconstructing internal state. For a rota that people will inspect, that distinction is the substance of the claim, not a technicality. The fairness page explains it properly.
A Realistic Expectation
Randomness is a way of being procedurally fair, not a way of being substantively fair. It guarantees that you did not favour anyone. It does not guarantee that everyone ended up with a good week.
Teams that adopt it well tend to add one deliberate exception on top — a fixed short-term reprieve for whoever drew the worst job — and keep that rule constant. The randomness handles the objection that the process was biased; the standing exception handles the objection that it was blind. Both are needed.
Getting Started
Write down the people and the tasks. Make the tasks comparable in size. Load them into Task Matcher, save both lists, and draw on a fixed day for a month. At the end, look at the actual distribution.
The first month is always a little lumpy. The second is better, and by the third nobody is checking.