hackathon-team-formation

Hackathon Team Formation

You decide how people at a hackathon end up building with each other: the team-size rule the brief publishes, the mechanic that runs on the day, what happens to whoever it fails, when membership stops moving, and how all four fit around the opening.

This is the participant-to-participant problem. It is not the participant-to-expert problem, and the two get confused constantly.

What you own, and what is already decided

You own:

• the team-size number and its solo answer
• the matchmaking mechanic
• the unteamed-participant protocol
• the mid-event change policy
• any track-conditioned composition rule

Four things arrive from, or leave for, siblings - hand them over rather than re-deciding them:

• The published rules text belongs to samber/dev-event-organizer-skills@hackathon-brief-design. Its interview asks this skill for the team-size rule by name, and its pre-publication threshold counts that rule as one of seven items that must exist. You decide the number and the wording intent; that skill prints it.
• Matching a stuck team to expertise belongs to samber/dev-event-organizer-skills@hackathon-mentoring. Draw the boundary this way: a participant who cannot find a team is this skill's problem, a team that cannot find help with a technology is that skill's. Never build a mentor request channel here.
• The run-of-show slot - where the pitch round or mixer actually sits in the day and what it displaces - belongs to samber/dev-event-organizer-skills@event-run-of-show. You supply the duration and the ordering constraint; it schedules against them.
• Prize eligibility and who may receive a payout belong to samber/dev-event-organizer-skills@hackathon-cash-prize. A team-size cap changes how a non-cash prize divides; say what the roster is, never what it is worth.

Every menu below, with its rungs and its axis orderings, is this skill's own construction: reasoned from mechanism, not measured against event data. Each ranking is a default, not a law. Re-rank every one after the interview against what you already know about this edition:

• last year's registration data
• a returning cohort that arrives in formed teams
• an organizing team who has run a mixer before
• a venue with one room and no second space

Interview

Ask one question at a time, multiple-choice where possible. Questions 2 to 9 each key a rung, a delete condition or a promotion condition; no default below can be picked without those answers.

1. Is the event themed with organizer-supplied problems, open with participants bringing their own, or both?
2. How long is the hacking window, and do the opening ceremony and the start of hacking sit in the same block or on different days?
3. Of the people registered so far, how many registered as an existing team, and how many registered alone? An estimate is a real answer; "we do not collect it" is the most useful answer of all.
4. What share of the cohort is at their first hackathon, and does registration ask anything about skills, role or what someone wants to work on?
5. Is a demographic or skill-level track required - a beginners track, a first-timers quota, a student-only category - and does anything in it depend on a fraction of the team rather than the individual?
6. How many rooms does the event occupy, and is there a second space available for a facilitated session?
7. Are prizes awarded against a submitted project, and may minors participate?
8. Is this a one-off edition or a recurring one whose mechanic should still work next year, and when must the rules be published?
9. What is the effort ceiling: organizer hours before the event, and how many named people are actually free during the hacking window rather than nominally on the schedule?

Q8 and Q9 each move a named rung. Say which as you re-rank.

• Q8, near publication date: promotes the adopted size rule over anything drafted, and demotes pre-event matching, whose whole cost is reading registrations that have not arrived yet.
• Q8, recurring edition: promotes the rungs written once and reused, the size rule with its carve-out and a pitch-round script, because their cost amortises where a one-off pays it in full.
• Q9, effort ceiling in organizer hours: does not touch the safety net.
• Q9, effort ceiling in people free during the window: removes the floor sweep and the escalation outright, because both are somebody's attention and nothing else. Say that rather than pretending a rota exists.

Workflow

1. Run the interview. Read last edition's registration data first if one exists; Q3 and Q4 are the answers it settles.
2. Fix the team-size rule before the mechanic. The mechanic has to produce teams the rule allows, and a mixer that forms sixes under a cap of four wastes the room. Hand the rule to samber/dev-event-organizer-skills@hackathon-brief-design as soon as it is decided.
3. Pick the matchmaking mechanic and state its duration and its ordering constraint. Load references/matchmaking-mechanics-and-run-sheets.md.
4. Decide the unteamed-participant protocol before the day, not during it. Load references/unteamed-participant-protocol.md.
5. Set the change policy and its cut-off, and check it against step 4 - a freeze that lands before the safety net runs cancels the safety net.
6. Stock the project backlog if the mechanic or the safety net depends on one, and size it against Q1. Load references/team-size-and-composition-rules.md.
7. Hand the slot, its duration and its position to samber/dev-event-organizer-skills@event-run-of-show, and the rule text to the brief.
8. Publish before registration closes. A team-size rule added after people have already agreed to hack together disqualifies teams that already exist.

Present the decision set section by section for validation - size rule, mechanic, safety net, change policy - never as one block. Get explicit approval before the rule goes into the brief; publication is the point of no return.

If your harness has persistent memory, record:

• the size rule and whether solo entry was allowed
• the mechanic and its measured duration
• how many people were still unteamed when the sweep ran
• what each of them ended up doing

The last one is the only number that tells you whether any of this worked, and no other event's figure substitutes for it.

Team-size policy

Four rungs: no stated rule, a stated cap only, a stated range that includes solo, and a range plus a track-conditioned composition rule.

• value (disputes prevented at submission, a solo entrant knowing before arriving that they may enter, and a carve-out that is actually enforceable): range plus composition rule > stated range including solo > stated cap only > no stated rule
• effort (deciding the number, wording it, and checking it against every track): range plus composition rule > stated range including solo == stated cap only > no stated rule
• compliance cost, as the review each rung triggers and the reversibility it costs: range plus composition rule > no stated rule > stated cap only > stated range including solo
• efficiency: stated range including solo > stated cap only > no stated rule > range plus composition rule

Dominance structure: 6 pairs, exactly one strict-dominance relation. The stated range including solo beats the cap alone on value, ties it on effort, and beats it on compliance cost, so it dominates. The efficiency line honours this by ranking the range first.

None of the other three rungs dominates:

• the composition rule (top of every cost axis)
• no stated rule (dominates nothing)
• the cap (dominates nothing)

A wrong ordering here would have failed the check, so this pass carries information.

The == on effort is argued, not a dodge. A cap and a range are the same sentence: deciding a maximum already forces the question of whether one person counts, so the cap does not save the decision; it just declines to write it down. Both land under an hour, and the cap only looks cheaper because its deferral is invisible until someone registers alone.

• Stated range including solo - the default, and the strongest single recommendation this skill makes.
  • Copy-paste text from a published organizer guide: "Teams can be 1-4 people".
  • The same guide's own reason for the cap: "We see hackers have the most success with teams of a maximum size of 4", offered as one organizer network's practitioner observation, with no study cited behind it.
  • Take the shape; decide the number for your own event.
• Stated cap only - real value for the same minutes, and it leaves the question the source poses explicitly, "Can hackers participate solo?", unanswered until somebody asks at the registration desk.
• No stated rule - delete it, from this menu and from the axis lines above, as soon as a brief is published at all (Q8). samber/dev-event-organizer-skills@hackathon-brief-design's own pre-publication threshold counts the team-size rule as one of seven items that must exist with zero blanks; shipping without it leaves that check at six. It also ranks second on compliance because it triggers no review beforehand and defers the whole adjudication to the least reversible moment there is - a prize decision, in public, with a team standing there.
• Range plus composition rule - the starved option: top of value, top of effort, top of compliance cost.
  • Promotion condition, keyed to Q5 and Q7: a track whose eligibility depends on a fraction of the team rather than on each individual.
  • Published example: "Beginners track where at least half the team must have this be their first hackathon".
  • The same source's procedural rule: "Make sure to state how many of the team members must fit the category in your rules before the event."
  • Treat the fraction as the thing to decide and "half" as one event's number.

Why the composition rule tops the compliance axis. A fraction keyed to "first hackathon" is a skill-level proxy and reviews cheaply. A fraction keyed to age, student status, gender or disability is a carve-out on a protected characteristic: it needs review before publication by whoever owns that exposure for the organizing entity, and it cannot be withdrawn mid-event without re-scoring a whole track. Decide which kind yours is before writing it, and route the second kind rather than wording it yourself.

Matchmaking mechanic

Five rungs: no formal matchmaking at all, a pitch-and-join round, a persistent project board, a facilitated mixer, and pre-event matching from registration data. Two value axes, because they genuinely disagree.

• value, coverage (share of participants who end the mechanic in a team of their choosing): pre-event matching > facilitated mixer > pitch-and-join round > persistent project board > no formal matchmaking
• value, project fit (the team that forms has a buildable thing to build and the skills to build it): pitch-and-join round > pre-event matching > persistent project board > facilitated mixer > no formal matchmaking
• effort (organizer setup, run-of-show minutes, and coordination during the window): pre-event matching > facilitated mixer > persistent project board > pitch-and-join round > no formal matchmaking
• efficiency: pitch-and-join round > persistent project board > no formal matchmaking > facilitated mixer > pre-event matching

Dominance structure: 10 pairs, exactly one strict-dominance relation. The pitch-and-join round beats the persistent board on coverage, on project fit, and on effort simultaneously, so it dominates. The board reaches only whoever walks past it, carries a project statement with nobody standing next to it to answer questions, and still costs a surface plus somebody maintaining it all day. The efficiency line honours that by ranking the round above the board.

None of the other three rungs dominates:

• pre-event matching (top of the effort axis)
• the mixer (loses project fit to both the round and the board)
• no formal matchmaking (bottom of both value axes)

The other nine pairs each trade one axis against another. The check verifies nothing about them, so their ordering rests on the arguments below.

Why the two value axes split. A pitch round forms teams around a project somebody has already articulated and committed to building. A mixer forms social groups that then have to invent a project, which is the slowest possible route to a first commit. Coverage and fit are not the same quantity, and a mechanic that maximises one can starve the other.

• Pitch-and-join round - the default, and the only mechanic with a published run sheet behind it.
  • "Hacking begins with project introductions. Participants that bring projects to the event have an opportunity to briefly (1 minute max) explain what they are working on at the very start of the event so that other participants can join that project".
  • The same source names the anti-pattern that ruins it: "Do not allow anyone to pitch an idea that they will not be working on at the event, unless there really are not enough ideas to go around."
  • Groups formed this way are described as "about 2-5 individuals", a range observed at that author's civic-tech events, not a target to enforce; it sits alongside rather than inside the 1-4 cap above.
  • Two aids scale the round past a small room. Both are this skill's own suggestions, not published practice:
    • a marker per pitcher, readable across the space and tied to their spot, so a crowd finds a project without queuing
    • a skill-coded wristband issued at check-in, so the room self-balances by discipline
• Persistent project board - the rung the dominance check rules out, kept on the page because it is what an organizer reaches for when the pitch round runs late and gets cut. Naming it is how you notice that happened.
• No formal matchmaking at all - a real rung, and correct at an event where the cohort registers as formed teams: its coverage equals any other mechanic's for zero cost, because everyone already has a team. Delete it, from this menu and from the axis lines above, as soon as Q3 shows anyone registering without a team. From that moment silence is not a light-touch choice; it is a decision to leave those people to the room.
• Facilitated mixer - a starved option: second on coverage, second on effort, and fourth on project fit. Promotion condition, keyed to Q4 and Q6: a cohort mostly at its first hackathon, where too few people brought projects for a pitch round to absorb the room, and a second space exists to run it in. Never promote it on the first condition alone - a mixer in the hacking room displaces the hacking.
• Pre-event matching from registration data - the other starved option: top of coverage, top of effort, and t

...