Hackathon Pilot: Facilitator Guide

Your job

Keep teams moving, keep it inclusive, and ensure each group leaves with:

• A demo/prototype
• A clear housing outcome
• Assumptions + risks/guardrails + optional next steps written down

Non-negotiables to set early

• Tenant respect: ensure lived experience is heard and not tokenised.
• Data safety: no personal data or case notes in AI tools; use synthetic/anonymised examples.
• Small PoC mindset: one thin user journey that works beats a big idea that doesn’t.
• Show your working: assumptions, risks, and next steps must be captured in a short README/doc.

Suggested running order

Time	Activity
09:00–09:20	Welcome, rules, problem statement, example PoC bar (“small and demo-able”).
09:20–09:45	Team formation + idea selection (impact/effort filter). Ensure tenants are distributed across teams.
09:45–12:00	Build sprint. Roam, unblock, keep scope tight.
12:00–12:30	Prepare demo + ensure 1-page README exists (assumptions, data needed, risks, next step).
12:30–13:15	Working lunch.
13:15–14:00	Demos (2–3 mins each), wrap, contacts, capture follow-ups (who wants to continue collaborating).

Parallelise aggressively

If you see lots of people around one screen, intervene: “Split into parallel roles for 15–20 minutes, then reconverge.”

Recommended roles (fast + inclusive)

• Driver: owns the laptop and implements.
• Navigator: decides next step, keeps scope tight, reviews AI output.
• Tenant advocate: checks the workflow matches real needs and avoids unintended harm.
• Prompt lead: runs structured prompts (plan → small diffs → tests → risk checks).
• Scribe: writes README live (assumptions, risks, decisions, next steps).
• Pitch lead: crafts the 2–3 minute story and demo flow.

How to split work in practice (what you say to teams)

• “One person: prompts for the plan + acceptance criteria.”
• “One person: prompts for UI copy + the user journey.”
• “One person: prompts for risks/guardrails (privacy, bias, safeguarding).”
• “Driver: builds the thinnest working slice.” (Potentially have two of these.)
• “Scribe: captures decisions continuously.”

Unblocking patterns (what to do when teams stall)

1. They’re stuck in “idea soup”. Say: “What is the user doing in minute 1?” Then force a one-screen PoC: input → transform → output.
2. AI outputs are wandering or low quality. Make them add:
   • Output format: “Return JSON/table/checklist/only code diff.”
   • Constraints: “Max 2 screens; works without real data; 90-minute build.”
   • Examples: provide 1–3 synthetic records and desired outputs.
3. They’re generating big opaque code dumps. Say: “Smallest working version first. Then add one feature. Output only the changes each step.”
4. Tenant voices aren’t being used. Pause for 5 minutes and ask tenants:
   • “What would make this useless?”
   • “What would make this unsafe?”
   Capture answers in the README and adjust scope accordingly.

Facilitator prompt cheat sheet (give these to teams)

PoC definition
“Define a PoC we can demo in 90 minutes. Include: target user, steps, synthetic data, outputs, and what we are not doing.”

Acceptance criteria
“Write 6 acceptance criteria + 3 edge cases + what failure looks like.”

Risk/guardrails
“List top 10 risks (privacy, bias, hallucination, safeguarding, misuse). Provide mitigations and what to disclose to users.”

Demo script
“Write a 2-minute demo script: problem → user story → demo steps → impact → next step.”

Licence

This page is licensed under CC BY-SA 4.0. You may share and adapt it with attribution and under the same licence.