I have organized successful hackathons at multiple companies, and the part I value most often becomes visible after the event.
Engineers who previously knew one another through tickets and meetings have now worked through an uncertain problem together. They have seen how someone explains an idea, responds when an approach fails, or helps another person get unstuck. The next cross-team conversation starts with a little more shared experience.
The prototypes matter. So does the opportunity to discover something technically useful. But if the event ends with a polished demo and everyone returning to the same isolated groups, we have left much of its potential unused.
A hackathon gives leaders a temporary opportunity to change how people work together. Making good use of that opportunity takes deliberate planning. Relationships do not automatically form because you provide a room, a problem, and a deadline.
Decide what the event should make possible
Before inviting anyone, write down the purpose in plain language.
For a team spread across several workstreams, a useful purpose might be to help engineers understand one another's constraints while exploring a small improvement to their shared workflow. That points toward mixed teams, a bounded problem, and time for explanation.
A different purpose, such as exploring an unfamiliar technical approach, may need more specialist support or a common environment. Be honest about which outcome matters most. An event cannot reasonably promise production features, deep research, team formation, and universal participation in a single afternoon.
I would make relationship-building explicit. Explain that helping another team, documenting a failed approach, or making the problem easier to understand will count as useful work. Otherwise, participants will reasonably assume that the only valued contribution is the most impressive thing running at demo time.
Keep the football connection practical: training gives players opportunities to understand how teammates move and communicate. A hackathon can provide that kind of shared practice for engineers, without the stakes and constraints of a live release.
Form mixed teams with care
If everyone chooses only the people they already work with, the event is likely to reproduce existing boundaries.
Invite preferences, then help form small teams that bring together different workstreams and useful skills. Consider experience with the problem, implementation, testing, operations, and explaining the result. Let people say where they want to learn, rather than assigning them only the role they already perform every day.
Mixing teams should not mean treating individuals as representatives of a demographic group or making one person carry all the teaching, note-taking, or presentation work. A junior engineer should have a real contribution to make and enough support to attempt it. An experienced engineer should not automatically become the unquestioned decision-maker.
Give teams a short working agreement: how they will choose an idea, divide the work, check in, and handle disagreement. Rotate visible responsibilities where useful. Make it clear that someone may contribute through design, investigation, tests, documentation, or facilitation as well as code.
Provide a way to flag an uncomfortable team arrangement privately. Deliberately mixing people is useful only when the organizer remains responsible for how that experience works.
Make participation possible during real working hours
A hackathon should fit inside paid working time, with managers protecting that time and adjusting normal commitments accordingly. An invitation is hollow if participants still have a full day's delivery work waiting for the evening.
Publish the schedule early. Use reasonable start and finish times, include proper breaks, and avoid an expectation of overnight work. Caring responsibilities, travel constraints, health needs, and personal commitments should not determine who can produce a competitive entry.
For distributed teams, choose an overlap that is genuinely workable. If time zones make a single live event unreasonable, use shorter shared sessions with planned asynchronous work inside each person's working day. Give remote participants the same access to mentors, decisions, and presentation opportunities.
Check accessibility in the venue, materials, collaboration tools, and demo format. Offer written participation and a quiet workspace where feasible. Ask privately about accommodations without requiring public explanations.
Most importantly, do not turn participation into an informal loyalty test. Provide a useful alternative or an opt-out, and make sure managers understand it carries no penalty.
Choose problems small enough to learn from
A good brief gives the team a real question and enough room to make choices.
For example, an illustrative challenge might ask: can we make a handoff between two engineering workstreams easier to understand using a synthetic request and a simple status view?
The brief can describe who would use it, the existing difficulty, what is out of scope, and what evidence would make the exploration useful. A paper flow or a tested assumption may be as valuable as a working interface.
Prepare approved tools, sandbox environments, and synthetic or explicitly approved non-sensitive data. Do not make participants improvise access to production systems, copy private information into unfamiliar services, or create unreviewed integrations to keep up with the clock.
Resolve access and dependency problems before the event. Provide a fallback challenge that can be completed with the prepared materials if a service becomes unavailable. The interesting uncertainty should come from the problem being explored, rather than whether someone can get permission to open a repository.
Give organizers a manageable timeline
For a one-day event, I would use a preparation sequence like this:
- Two weeks before: Agree on the purpose, sponsor, working-time commitment, accessibility arrangements, and follow-up owner. Invite problem ideas and participant preferences.
- One week before: Publish a small set of bounded briefs, the evaluation criteria, and draft team arrangements. Confirm facilitators and technical support.
- Two days before: Test the tools and access with someone who did not prepare them. Confirm the timetable, data boundaries, presentation options, and escalation route for problems.
- The day before: Ask managers to clear conflicting work. Send one concise participant guide containing everything people need to begin.
The exact intervals can change with the size of the event. The important point is that somebody owns the preparation. Leaving access, team formation, and judging to the morning consumes the time people came to spend working together.
Facilitate the day rather than announcing it
Here is a suggested agenda for a team sharing the same working day:
- 09:30: Welcome, purpose, boundaries, and examples of useful outcomes.
- 10:00: Team introductions, problem selection, and a short working agreement.
- 10:30: First exploration session, with facilitators available to help teams narrow their questions.
- 12:00: Brief check-in on learning and obstacles, followed by a proper lunch break.
- 13:00: Build, test, investigate, and document. Mentors circulate without taking over.
- 14:45: Stop expanding scope. Prepare a short account of the question, approach, evidence, and remaining uncertainty.
- 15:30: Demonstrations or written walkthroughs, with equal time and a consistent question format.
- 16:30: Recognition, team reflection, and a clear explanation of what happens next.
Keep ordinary breaks available throughout. Facilitators should notice who is struggling to enter a discussion, who has become overloaded, and whether a team needs help reducing scope. They should offer support without turning the event into continuous supervision.
Ted Lasso catches himself dismissing an idea with the line:
I shouldn’t bring an umbrella to a brainstorm.
That is a useful reminder for the opening phase. Let people explain an unfamiliar idea before the most experienced voice decides what it cannot do. Then help the team test it within the event's boundaries.
Judge the work people were actually invited to do
Publish the criteria before the event and apply them consistently. For a learning-and-collaboration hackathon, I would ask evaluators to consider:
- Is the problem understandable and appropriately scoped?
- What did the team try, and what evidence did it collect?
- Can the team explain limitations and useful next steps?
- How did members share work, knowledge, and responsibility?
Use several perspectives in the review and disclose conflicts of interest. Judge the work presented, rather than rewarding seniority, theatrical confidence, or time spent outside the agreed hours. A written walkthrough should receive serious consideration alongside a live demo.
If there are awards, recognize several kinds of contribution. An insightful experiment that rules out an approach deserves acknowledgement. So does work that helps other teams participate. Avoid making collaboration a competition to claim that somebody else was helpful.
Keep the commitment after the demos
Within the following week, gather the artifacts and the lessons, credit the contributors, and ask participants what made collaboration easier or harder.
Give each idea a clear disposition: pursue a specific next step, retain the learning, or close it. Any further development needs an owner and allocated working time. A prototype should not silently become a support obligation, and participants should not have to finish it at night to prove the event succeeded.
A few weeks later, ask whether people have used their new connections and whether anything still makes cross-team work difficult. Concrete examples can guide improvement. They are not proof that one event caused faster delivery, and there is no need to invent a productivity percentage.
Some of the most useful outcomes will never ship. A disproved assumption, a clearer handoff, or an engineer who now knows whom to ask can all justify the time. Plan for those outcomes, recognize them, and give the relationships room to continue.
Quotation source
Ted Lasso is the fictional character played by Jason Sudeikis. The excerpt appears in season 2, episode 1, “Goodbye Earl”, released 23 July 2021. Wording is corroborated by a public episode transcript; Apple’s episode page confirms the episode and date.