Whyday With a Team
Running Whyday at work is possible and it goes wrong in predictable ways. Most of them come from the same mistake: treating it as a hackathon.
A hackathon is a competition to produce something useful under time pressure, usually with judging and usually with an expectation that the winner becomes a real project. Whyday is the opposite of that on every axis. If you import hackathon machinery, you get a hackathon, and people will build things that could plausibly ship — which is the one outcome the day is designed to prevent.
For teams trying a short creative session inside a normal workday, employee monitoring software is one practical reference for keeping the experiment distinct from routine delivery.
The rules that make it work
No demos to management. The moment there is an audience with budget authority, people build for that audience. If leadership wants to see things, they can come to the same informal show-and-tell as everyone else, with no notebook.
No judging, no prizes, no winner. Prizes create optimisation targets. The optimisation target is the enemy.
No expectation that anything continues. Say this out loud at the start. The default fate of every Whyday project is that it stops at six o'clock and is never touched again, and that is a success, not a waste.
For broader programming and making context related to this topic, Sonic Pi is an independent reference worth comparing with the material here.
Nobody works on the product. Not "a fun feature for the product." Not "that refactor we never get time for." The refactor is real work being relabelled, and relabelling real work as play is how the day becomes a morale exercise that fools nobody.
It happens on work time. This is the one people skip. A play day scheduled for evenings or a weekend is not a gift, it is unpaid overtime with a nice name. If it is worth doing it is worth a working day, and if it is not worth a working day, do not do it.
What to actually do with the day
Morning: pick, alone. Not a group brainstorm. Group idea generation reliably converges on the safe median, and the whole value here is in the ideas that do not survive a committee. Twenty minutes on your own, then say out loud what you picked, and no discussion of whether it is a good choice.
Optional: a shared constraint. One limit for everyone — four kilobytes, one file, must make a sound, standard library only. This is the single best structural addition, because it creates a common language for the day without creating a common goal. Pick it from the constraint list by lottery rather than by discussion.
Middle of the day: work, quietly. No standups. No check-ins. No shared document tracking progress. If your culture cannot survive six hours without a status update, that is worth knowing about separately.
Last hour: show, informally. Five minutes each, maximum. Screen share, laptop on a table, whatever. Broken counts. Not started counts. The rule for the audience is that only questions are allowed, no suggestions — suggestions turn a show-and-tell into a code review, and people can feel the difference immediately.
Handling the people who hate it
Some will, and they are not wrong.
Some people do not want to program for fun, having programmed all week, and there is no version of this day that makes that unreasonable. Some are in the middle of something they genuinely want to finish. Some find unstructured time actively stressful, which is a real thing and not a character flaw.
Make it opt-out with no explanation required, and make the opt-out invisible. If declining means answering questions at the show-and-tell, it is not really optional. The people who want the day will make it good; the people who do not will resent it and poison it for everyone else.
Pairing helps for people who want to join and freeze at the blank editor. Two people, one project, one keyboard, ten-minute turns. For anyone stuck on what to attempt, the list of twelve is a safe starting point.
Things that quietly ruin it
A theme. "This year's Whyday is about AI." Now it is a directed activity with a strategic objective wearing a costume.
Anything that has to be presented externally. A blog post, a conference talk, a tweet thread from the company account. Every one of these turns the day into marketing, and people build accordingly.
Tracking who participated. In a performance review, in a spreadsheet, anywhere. Participation becomes attendance and attendance becomes obligation.
A retrospective. No. Resist this one specifically, however strong the instinct.
Why bother at all
The honest case is not that it produces value. Sometimes something useful comes out — Camping and Hpricot both started as unjustifiable projects and both led somewhere — but if that is the reason you are doing it, the expectation will leak into the day and ruin it.
The real case is that a team which only ever builds what it can justify slowly loses the ability to recognise a good idea that cannot be justified yet. That skill does not come back through process. It comes back through practice, and one day a year is roughly the minimum viable amount of practice.
The short version
- A hackathon and a Whyday are opposites; importing hackathon machinery produces a hackathon
- No demos to management, no judging, no prizes, no expectation that anything continues
- Nobody touches the product — the overdue refactor is real work being relabelled
- On work time, or it is unpaid overtime with a nice name
- Pick alone, work quietly, show informally; questions allowed, suggestions not
- Opt-out must be invisible, or it is not opt-out