Stop, redirect, learn
I spent last week’s hackathon learning things I didn’t expect to learn, which is probably the point of hackathons.
The first thing came early. We had a list of things we could vibe code – quick fixes we could demonstrate in the room. I’d added a couple of items to that list myself, and I knew, even as I typed them, that they didn’t really belong there. Conversation design isn’t something you vibe code. The dialogue flows I wanted to create were something I was planning to do. They’re for an agent we’re building. I wrongly thought this was a way of getting it done and getting ahead on my to-dos.
So I carried on. I pulled strings of copy straight from the code. I turned them into a flow diagram with AI. I built a toggle to switch between a clean conversation and the same conversation with each string’s ID overlaid. It worked. It was satisfying to watch a tangle of responses turn into something you could read as a conversation. Also, to see that once you did, the strategy behind some of those responses wasn’t quite there. Not a criticism of the team – they’d been focused on other things. Just a gap worth naming.
Then I hit a wall I already knew existed, and had forgotten about. A couple of weeks ago I had asked the team if we could edit the assistant’s responses, and the answer? “No.” I don’t fully believe that’s true, but true or not, I’d forgotten it was a constraint at all. The sensible thing was to stop and pick up something else, which I did. I set up a follow-up call with the team to walk through what I was trying to do and why. To talk about the strategy rather than the wording. But the lesson sits with me. When you’re juggling several threads at once, constraints you heard about weeks ago don’t stay front of mind. You have to write them down.
The second thing came later, and it stung more at the time. We do audit our product content regularly. As a team of two covering eleven delivery teams, we squeeze audits into whatever spare hour we can find. Rarely is it the data itself pointing us to where to look first. So I set out to fix that properly. I wrote a problem statement, pulled the traffic and revenue data, and immediately drowned in it. Too much information, too fast, with no real plan for cutting it down to size. I picked a user journey, poked at it in the code, and watched the whole thing turn to spaghetti.
At the time it felt like failure. Looking back, it wasn’t the size of the task that beat me – it was the decision to go it alone rather than join a team. I simplified what I was working on, and I found a small fix: some jargon I could improve in minutes. After the session, I fixed it, created a quick prototype and recorded a demo.
Next time I’ll aim lower on purpose. A small, certain win, with room to do more if there’s time, beats a big idea that collapses under its own ambition. And if in doubt, collaborate before I default to my own list.
Leave a comment