Mastermind · April 20, 2026
Two Hackathons in Two Days
I ran two hackathons in two days last week. Cornell on Saturday, Hopkins on Sunday, five hours of driving in between. We had a contract for a six-stop college tour and the next two stops were back to back.
The Cornell event ran well. Good energy, strong teams, solid submissions through the MentorMates agent. But the five-hour drive to Baltimore after was brutal. I pulled into Hopkins at 1 AM, slept four hours, and was setting up registration tables by 7.
Hopkins was messier. Different venue layout, different student culture, different wifi situation. Half the things that worked smoothly at Cornell needed manual overrides. The submission flow broke for three teams because the agent timed out on a slow campus network. I had to debug in real time while also running the opening ceremony.
That contrast is what taught me something.
When you run one event, you optimize for that event. You learn the room, you learn the crowd, you make it work. But when you run two events in 48 hours at two different schools, the thing that breaks is everything that was held together by your personal presence instead of by the system.
The things that survived the sprint were the things we had actually systematized. The MentorMates submission schema worked identically at both stops because it was locked in code, not in my head. The judging rubric was the same because Jeffrey had templated it. The AI interviewer asked the same questions at both schools because the prompt was versioned.
The things that broke were the things that depended on me being in the room. Wifi troubleshooting. Venue-specific audio setup. The moment when a team captain needs to be walked through the submission flow in person because the onboarding doc assumed they were technical.
This is the difference between running a show and building a machine.
A show needs a showrunner. It scales with the showrunner's energy and attention. When the showrunner is exhausted from five hours of driving, the show degrades. A machine needs an operator, but the operator's job is to monitor and intervene, not to be the thing that makes it work.
We are not a machine yet. We are a show with some machine parts. The submission flow is a machine part. The judging rubric is a machine part. The venue setup is still a show. The wifi debugging is still a show. The team onboarding is still a show.
The goal for the remaining four stops is to convert every show-part into a machine-part. That means documentation that assumes non-technical team captains. It means a site-lead protocol so someone local can handle venue-specific problems without calling me. It means a network-fallback mode for the submission agent so it degrades gracefully on bad wifi instead of timing out.
None of this is glamorous. It is the difference between doing this six times and doing this six hundred times.
The two-day sprint was the stress test that showed us exactly where the seams are. Every seam that survived is a real system. Every seam that broke is a thing we built around ourselves instead of into the product.
The next stop is Columbia. If I can run Columbia without being the thing that makes it work, we have a machine. If I still have to be in the room for it to function, we have a really good show that only works when I show up.
I know which one I want to build.