A teammate leaves the hackathon: hand over work and revise the plan
What to do when a teammate leaves a hackathon: clarify availability, collect materials, check team membership rules and reduce the remaining work.
·4 min read·
A teammate says they can no longer work. The reason may be personal, technical or related to the event. The team needs to find out which project materials it can access, check their current state and change its plan. Trying to keep the same scope with fewer people often leaves the very parts the project was built for untested.
First clarify the facts without pressure: are they leaving permanently or unavailable for a while, can they hand over their current materials, and does any work need to be saved urgently? You do not need details of a personal reason to reassign tasks.
Check the rules for team membership changes
Find the event conditions and notify the organizer if the rules require an updated team list. Clarify whether a replacement is allowed, how the work already contributed is treated and what information must remain in the application. Do not invent an answer based on another hackathon’s rules.
Keep the clarification you receive. If the team uses materials created earlier, it must describe authorship and assistance according to the actual work and event conditions. Someone leaving does not erase their contribution from the project’s history.
Include general questions in the hackathon rules beforehand. When membership changes, teams need a short, specific answer rather than another debate about an unclear clause.
Find your event page through the Stavleak catalog and check its current team membership conditions. Discuss exceptions with the organizer before replacing a participant.
Accept the work in its current state
Ask the departing teammate to save materials in a shared location using the team’s agreed methods. This might be a repository branch, a design source file, a research document or an experiment record. Unfinished work is useful too when it is clear what has been checked.
A short handover card is enough:
Where the latest version is stored.
What already works and how to check it.
What remains unfinished.
Which dependencies or decisions prevent further work.
Who takes the next task.
Check access immediately. “I sent everything” does not confirm that others can see the file. If materials are in a personal service account, use its supported export or agree an access transfer; do not ask for the password to a personal account.
Separate knowledge from personal access
The team needs instructions for using the service rather than a way to sign in as the departing teammate. Check whether there is a shared project and a named owner. Add others through the service’s roles and invitations when the owner permits it.
If a critical part exists only on that person’s laptop and cannot be handed over now, acknowledge the dependency. Do not promise to include it in the final demo without checking it. Sometimes simplifying the scenario is faster than urgently reproducing an unknown setup.
GitHub’s README documentation lists getting started and getting help among the file’s purposes. A short, current set of instructions is especially useful during handover. The guide to a hackathon project README provides a detailed structure.
Recalculate the remaining work
Open the task list and identify the parts that no longer have an owner. Then select what is needed for one complete scenario. If the team cannot do everything at once, prioritize running, checking and submitting the project over extra screens, integrations and visual polish.
Do not divide tasks by count alone. One integration may require more context than several visual changes. The new owner needs time to understand the work, and the team needs a clear point at which to check progress.
Illustrative example: instead of automatically handling several formats, the team keeps one prepared format it can test from start to finish. It states this limitation in the description and presentation. Reducing scope this way is acceptable only within the challenge and must not hide an unmet mandatory requirement.
Update the demo and contribution details
Rewrite the presentation plan to match the actual state of the project. Remove promises of features dropped after the teammate left. Check who will now answer questions about that part of the project.
Keep accurate information about authors and their actual contributions in the work description. If there are disagreements, do not settle them through public accusations while preparing for the final. Use the process provided by the organizers and keep the relevant work materials.
After the event, discuss which dependency became a single point of failure. The fix may be simple: a second person runs the project, materials are saved more often or decisions are recorded. This is a useful topic for a team retrospective, whatever the reason for leaving.
