The Company-Wide AI Build Week
Stop all project work for a week; every employee builds what they think matters most.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 7
- Confidence
- 85%
This is a one-week, whole-company forcing function that converts abstract AI enthusiasm into shipped internal tools and, more importantly, into evidence about who in your organisation can build. All project work stops. Every employee, regardless of role, picks the thing they personally believe would most improve the company and builds it. Two rules only: you must use AI, and you must demo to the whole company at the end. The demo requirement supplies the accountability that would otherwise come from management filtering, without the filtering suppressing the surprising ideas. The week length is load bearing, because most people's first-order idea is wrong and the value comes from having enough time to see that, react and iterate. Expect the distribution of results to invert your prediction: the ratio of serious projects to toys tends to come out far better than leadership assumes.
Origin
Extracted from Naval, where Blake Scholl describes running exactly this experiment across Boom Supersonic and being surprised by the ratio of needle movers to silly projects.
Core principles
- 01Everyone has an idea of what would make the company better; almost nobody can build it.
- 02First-order ideas are usually wrong, and only building reveals that.
- 03A demo to the whole company is better accountability than a manager's filter.
- 04Non-technical staff are the underrated source of needle movers.
- 05A week is the minimum time to fail, react and iterate.
How to run it
- 1
Clear the week
Announce that all normal project work stops for five days. Half measures fail, because anyone who keeps their day job will default to it.
Pro tip Pick a week with no launch or audit deadline so nobody has an excuse to opt out.
Watch out If leadership quietly exempts a team, the whole signal about who can build is lost.
- 2
Set the brief and the two rules
Everyone builds whatever they think is the single most important thing to build. The only requirements are that they use AI and that they demo it to the whole company when they are done.
Pro tip Say explicitly that nobody will approve or reject the idea in advance.
Watch out Adding a third rule reintroduces the filter you are trying to remove.
- 3
Include every role deliberately
Reception, shipping and receiving, finance, sales and engineering all participate on the same terms. The point is that people closest to the manual work know where the automation belongs.
Pro tip Pair non-technical staff loosely with a technical buddy for environment setup only, not for the build itself.
- 4
Remove the setup friction
Before day one, make sure everyone has model access, credentials and somewhere to deploy. The barrier you are testing is imagination, not procurement.
Watch out Every hour spent on access requests is an hour of iteration lost from a five-day loop.
- 5
Let bad first ideas die in public
Do not rescue people whose initial concept is not working. The mechanism of the week is that they discover it themselves and iterate into something that makes sense by Friday.
Pro tip Mid-week, ask people what they have changed their mind about rather than what they have finished.
- 6
Demo to the whole company
Everyone presents. This is where the accountability lives and where the org sees, collectively, what is now possible.
Pro tip Record the demos; they are the best internal AI training material you will ever produce.
- 7
Adopt the survivors
Within two weeks, assign owners and put the genuinely useful builds into real use, with the architecture and review standards your normal software carries.
Watch out Tools built in a week without an owner rot fast and poison the next build week.
In the wild
The most surprising output of Boom's build week did not come from engineering. The shipping and receiving associate, whose job was to take packages off a truck and email people when their items arrived in inventory, built an automation for that workflow during the week. It was not a demo toy: the company kept using it afterwards.
→ A non-technical employee shipped an internal automation the company adopted into daily operations.
Leadership went in expecting a large number of silly projects and a small number of genuinely useful ones. The result inverted: a large number of needle movers and very few toys, with two or three projects judged capable of changing the direction of the company.
→ Two to three trajectory-changing projects surfaced from a single week of stopped project work.
Common mistakes
Screening ideas before the week starts
Pre-approval filters out exactly the unglamorous operational ideas that turn out to be needle movers, because they do not sound impressive in a proposal.
Restricting it to engineers
If only technical staff take part you learn nothing new, since the people nearest the repetitive manual work are the ones who know where the automation should go.
Cutting it to a single day
A one-day hackathon only surfaces first-order ideas. The value comes from having enough runway to discover the first idea was stupid and iterate past it.
Is it for you?
Best for
Company leaders who want a fast, honest read on where AI actually helps their operation and who in the org can build.
Not ideal for
Teams in a hard delivery crunch where a week of stopped project work carries a contractual or safety cost.
From the transcript
“the only requirements you have to use AI and you have to demo it for the whole company when you're done.”
“I expected we would get a large number of silly projects and a small number of needle movers. And what we got was a large…”
“if they have the ability to go from idea to an actual thing, if it's not working, they can react. They can iterate.”
From the episode
Full Episode: The AI Industrial Revolution