Choosing who gets the one seat

The essay on not being the one who got the seat is written to whoever's still at their desk, wondering what the decision actually weighed. This is the same decision from the other chair — the one with the budget line, the one name to fill it, and two or three colleagues who each have a real case. Most managers inherit this job without ever being taught it, and default to whoever asked first, asked loudest, or asked most recently. All three are worse methods than they feel like in the moment, and all three eventually get noticed.

Weigh the project, not the résumé

The strongest, most defensible reason to send one person over another is rarely seniority or who wants it more — it's whose work is actually at the stage where the room matters right now. Someone with a submission due the week of the conference is a weaker case this cycle regardless of standing; someone whose project just hit the exact question a session is built around is a stronger one, independent of title. This is the same logic a signable business case already runs on from the requester's side — your job is to apply it evenly across every request on your desk, not just vet the one that lands first.

Keep the rotation somewhere other than your memory

A single decision made well can still add up to an unfair pattern over several cycles, because unaided memory quietly overweights whoever asked most recently and underweights whoever quietly didn't ask again after being turned down once. A short, boring log — who went, to what, which cycle — takes five minutes to maintain and answers a question you will eventually be asked directly: why does the same person keep getting the seat. If you can't answer it from a record, you're reconstructing a justification after the fact, which reads exactly like what it is.

What you owe the person who didn't get it

"Maybe next year" is not a reason; it's the absence of one, and the absence is what actually produces the resentment the essay on the other side of this describes. Say plainly what tipped it — timing, project stage, a submission deadline that made travel impossible — and then do the more useful thing: ask what case they'd want to make for next cycle, while the conference year is still being planned and there's time to build around it. A specific, named path to the next seat does more for how the decision lands than any amount of softening the delivery of this one.

When two cases are genuinely equal

Occasionally the arithmetic really does come out even, and the honest tie-breaker is just whose turn it's been longer since they went anywhere. That's a legitimate reason to use once you've checked the log and confirmed it's true — but it's worth exhausting the actual criteria first, including whether a virtual option or a different, better-scoped event could turn one seat into something closer to two. A tie-break should be the last tool used, not the first, or it quietly becomes the only one anyone remembers you using.