Playbook
Sail, Don't Row
By Brian Weisberg · June 2026
A playbook for running an AI hackathon with your finance team
There are two ways to approach the AI moment in finance. The first is to row harder: one-off solutions, manual handoffs, each person finding their own tool at their own pace. Exhausting. Doesn't scale. The second is to sail: build the infrastructure deliberately, rig it carefully, and let the conditions do the work. The difference isn't capability. It's intention.
A hackathon is how a finance team learns to sail. It creates protected time and a low-stakes space to learn something hard together—as a team, where nobody has to already know the answer. The builds you ship at the end are real, but they're a byproduct. The point is the skill that stays when everyone goes home.
I've run one of these with my own finance and ops team, and this is the format distilled—what worked, why it worked, and how to run it yourself.
- Is this worth doing?
- And am I sailing or rowing?
Rowing isn't inherently bad. The point is being intentional about when you go manual and when you build something repeatable. Ad-hoc has a way of becoming permanent ad-hoc.
Why a hackathon—and why now
AI adoption in finance doesn't happen on its own. It gets crowded out by the close, the board deck, the forecast update. There's always something more urgent. Left to find the time on their own, most teams never do.
A hackathon fixes that by force. It carves out protected time and makes exploring together the actual assignment. The format works for three reasons:
- Psychological safety. When everyone is learning at the same time, in the same room, there's no expert to defer to and no reason to hide. Half-formed ideas get air.
- Time-boxing as a feature. The constraint—ninety minutes to build something shippable—focuses effort better than a two-week sprint with no end in sight. Done is better than perfect.
- Compounding returns. A team that has learned something together learns faster next time. The first hackathon is the hardest. Run it annually and it becomes a flywheel.
The goal isn't to automate the whole finance function. It's to close the gap between your team's potential and its current velocity—on purpose, together, in a way that compounds.
The method behind it: design thinking
Before the mechanics, the philosophy. The prioritization format I use: post-its, dot stickers, a 2×2. It isn't a team-building exercise. It's the application of a specific method: design thinking.
Design thinking is a problem-solving approach that starts with the people experiencing the problem, not with the solution. It works in two modes:
- Diverge first. Everyone generates ideas independently, without talking.
- Then converge.
The separation matters—if you skip the silent step and just go around the room, the first voice anchors every other answer.
The other half is the ground rule going in: no bad ideas. No judgment, no evaluating while generating. The only requirement is a clear persona and use case: a real person with a real problem, not a vague wish. That's what makes people comfortable putting the half-formed thing on the wall—which is exactly where the good ones tend to start.
This method started in product design but works anywhere you need a group to surface and prioritize ideas without the usual political drag. A few examples of what it looks like at scale:
Three resources worth sending as pre-reading before you run this:
Covers the six phases and why this isn't just a brainstorming session with a fancier name.
Why you split ideation from prioritization, and what goes wrong when you don't.
How many dots to give, when to rerun a vote, and the failure modes to watch for—especially the person who campaigns out loud before the stickers go up.
The original source—where the method came from, with toolkits and examples across industries.
Before you arrive: the setup
The single biggest mistake in running a hackathon is walking into the room cold. If the first thing you do is ask "so what should we build?"—you'll spend half your time generating half-baked ideas and the other half convincing people to try something. Do the intake work before you're in a room together.
- Set up a simple intake form (Notion works well) with these fields: problem statement (one sentence), who it hurts, type (automation / visibility / missing skill / analysis), impact and feasibility (a first guess), and definition of done.
- Ask specific questions. "What do you do every week that feels like copy-paste?" gets better answers than "What problems do you have?"
- Make it frictionless. Let people dump free text if that's easier—you or an AI agent can structure it afterward. The goal is honest input, not a polished pitch.
- Optional: use AI to auto-fill the structured fields from each submission, then have people review and correct. That task itself is a small AI adoption moment.
Also before the event: get your integrations connected. If you're building with Claude or another AI assistant, make sure it's linked to the systems you actually use—NetSuite, Notion, Google Drive, Slack. Spending build time on setup is demoralizing. Arrive ready to build.
Consider sending the design thinking pre-reads (linked above) a few days out. Not required, but teams that arrive with the method in their heads move faster once they're in the room.
Day zero: from problems to priorities
This is the framing session—the day (or half-day) before the build. Its job is to turn a backlog of submitted problems into a ranked shortlist of sprint candidates. Here's the full sequence:
Transcribe to post-its
During a break, the facilitator writes each submitted problem onto a physical sticky note—one problem per note. This forces a human edit pass. You spot duplicates, catch problems that are really the same thing framed twice, and produce something the whole room can see simultaneously. Keep laptops closed for the rest of this session.
⏱ 15–20 min · facilitator only · done during a breakLive additions + clustering
Give the room a few minutes to add anything not submitted async. Then cluster: pull duplicate or overlapping stickies together before voting. Facilitator-led, fast—group what's obviously similar and move on. Don't debate the clusters. Debate costs time and anchors thinking before the vote.
⏱ 10–15 min · whole teamSilent dot voting
Everyone gets five dot stickers. You can stack all five on one idea or spread them across five. No talking while voting. Silence prevents the loudest voice from anchoring the group—the most common failure mode in group prioritization. Once votes are tallied, log totals back into your intake database so the prioritization is permanent.
⏱ 5–10 min · whole team · silence requiredThe 2×2: value vs. effort
With vote tallies as a guide, place stickies on a 2×2 grid together as a team. Value on the vertical axis. Effort on the horizontal—and effort means all-in effort: time, skill required, data access, dependencies. Facilitator guides, team places. The conversation happens around placement, not around lobbying for ideas.
Things that "fall off the list" have a way of coming back. Things you've explicitly decided to skip don't. For every idea below the line: name it, say it out loud, agree to leave it alone. "Intentionally skipping" and "fell off the list" are not the same thing.
Two final cuts: when, and whether it's ready
Sort the upper-right survivors two ways. First, timing: Build (do it at the hackathon), Later (worth doing, not this week), Even Later (needs scoping first). Second, readiness: can you touch this right now, or does it have a dependency, a data question, an unknown to resolve? A high-value idea that isn't ready to build isn't a sprint candidate—it's a scoping task. Naming that distinction keeps you honest.
⏱ 10–15 min · whole teamAssign pairs
Match people to Build-ready ideas. Pairs, not solo work—two people per build keeps momentum up when one gets stuck. Assign 1–2 floaters (ideally including yourself if you're the leader) who stay unattached and circulate to unblock teams during the sprint.
⏱ 5 min · facilitator-ledProtect the gap: inspire, sleep, build
Here's the sequencing decision that separates a good hackathon from a great one: don't build on the framing day.
The framing session is dense with new thinking—a full backlog processed, clustered, voted on, and prioritized. Ending there, inspired rather than rushed, gives that thinking time to settle. People go home with a problem in their head. They think about it in the shower. They wake up with the approach half-formed. That overnight processing is doing real work.
That's the sequence. The gap between the framing day and the build day isn't scheduling slack. It's part of the method.
Add one more step on the morning of the build day before anyone opens a laptop: 15–20 minutes of inspiration. Show examples of what other finance teams have actually built with AI. Real demos, not slides. Actual workflows someone is using. Then, and this is the move worth stealing, clear the votes and run a second idea-generation round from scratch. The second round is almost always better than the first. People arrive with new angles, sharper problem statements, and sometimes a completely different sense of what they want to build.
The build day
The build sprint is simple by design. Complexity is the enemy of shipping.
- Morning reboot (15–20 min): Inspiration videos, second idea-generation round, confirm pairs and targets.
- Sprint #1 (90 min): Pairs build. Floaters circulate. No whole-group check-ins until time's called—mid-sprint interruptions break flow.
- Optional midpoint (45 min in): 5-minute pulse check per team. Not a demo—just calibration. Are you stuck? Do you need to scope down?
- Demos + verdicts: Regroup as a full team. Each pair demos what they built or learned. 10 minutes per team, 2 minutes for the verdict decision. Every demo gets a verdict and a named owner before the next team starts.
The constraint (90 minutes) is the point. It forces scope decisions early. A team that's trying to build the perfect reconciliation engine will fail. A team that's trying to build a working prototype of one slice of that engine will ship something. "Done enough to demo" is the bar.
What floaters actually do: when a pair is stuck on a tool behavior, a data question, or scope creep, the floater doesn't solve the problem for them. They ask one question: "What's the smallest thing you could build that would prove this works?" That's usually enough to unblock.
Closing with verdicts and owners
The close is where most hackathons fail. Teams demo, everyone claps, and then... nothing. The builds sit in a Notion database for three months and quietly become shelf-ware. What prevents that is a discipline: every demo gets a verdict and a named owner before the room empties.
Push it to production now. It's working, it's useful, it's ready. Assign an owner whose job is to not let it die.
Another pass before it's ready. Assign an owner and a target date. Iterate without a date is just Park with extra steps.
Not the right moment—but documented for later. This is a legitimate verdict. Honor it by writing down why.
The Park verdict deserves more credit than it gets. It's not failure—it's intellectual honesty. Naming why something isn't ready (wrong timing, missing data, dependency on something else) is more useful than letting it die quietly. A well-documented Park can become a Ship six months later when the conditions change.
The goal is at least one thing in production before anyone gets on a plane. Aim for that. It changes the energy of the room and sets the bar for everything that follows.
The operating system: a Notion setup that compounds
The post-its get the attention. They're not what makes this work. What makes it work is the underlying system—one intake database, one page per idea, a structured record that outlives the event.
Submission name
A 3–6 word label. Forces clarity before anyone has read the full submission.
Problem statement
One sentence. The constraint is the discipline—a problem that needs "and" is really two problems. Split it.
Who it hurts
A specific person or role. "The team" is not a persona. "The controller on every close" is.
Type
Automation / visibility / missing skill / analysis / ops plumbing. Useful for spotting patterns—if half the submissions are "I can't see X," that's a signal.
Impact + feasibility
A first guess, not a commitment. You'll refine it during the 2×2.
Definition of done
Describe the two-minute demo. What does success look like when someone watches it work? This field does more work than any other.
The move worth stealing: one page per idea. Not just a row in a table—an actual page that becomes the full record. What the team submitted, live notes from the build, what they learned, what broke, what to do next. The page carries the idea through the event and becomes searchable institutional knowledge.
Without this, the hackathon produces prototypes. With it, it produces compounding assets. The next person who picks up a similar problem starts from the answer, not from scratch.
Two database views worth setting up: an effort × value matrix (the digital twin of your sticky-note 2×2, auto-sorted by vote count) and a groups board by theme. The groups view is useful for spotting when one area—say, month-end close—quietly dominates the shortlist, which is usually a signal worth paying attention to.
After: building the AI Lab
The hackathon is a beginning, not a destination. What makes it compound over time is institutionalizing what you learned: a shared space—call it the AI Lab, call it whatever fits your culture—where builds live and can be forked.
The operating model is simple:
- Build something useful → document it → drop it in the Lab.
- Find something someone else built → fork it → adapt it to your context.
- Review the Lab quarterly. What's still in use? What needs updating? What opened up new possibilities?
Run the hackathon again next year. The format gets easier the second time—the setup is faster, people know what to expect, and the ideas are sharper because everyone has spent a year noticing problems worth solving. The first one is the hardest. The flywheel needs one good push.
- 3–4 working prototypes, each with a verdict and a named owner
- A prioritized backlog in Notion for everything that didn't get built—with owners on anything that moves forward
- At least one thing in production before anyone leaves
- A shared Lab space where builds live and can be forked
- A date on the calendar for the next one
The teams that get the most out of AI aren't the ones with the best tools. They're the ones that got good at using them—together, on purpose, through deliberate practice. A hackathon is how you start that. Sail, don't row.
Brian Weisberg is a tech CFO writing about finance leadership, AI adoption, and building finance teams that compound. More writing →
⛵ Made it this far? Sail, Don’t Row is also a game.