In Part 1, I talked about who comes to our offsites, when we run them, and why a good pickleball court is almost as important as a good agenda. Now let’s get into what actually happens once everyone is in the room (or in the pool).

This is the part I had to learn the hard way. Running strategy sessions is a bit like cooking spaghetti… looks simple, but if you don’t time it right, everything gets mushy. After years of trial and error, I’ve found a rhythm that makes these sessions productive without turning into corporate torture. This is in no way an exhaustive guide, and I still intend to get better at this, but hopefully someone will find this useful.

The Agenda Book

When everyone arrives, they get an agenda book, printed out on beautiful standard office paper, and lovingly stapled in the top corner. It also comes in a fancy digital version. In fact, they usually see it a few days before the offsite so they know what’s coming. But this isn’t like getting assigned homework. I don’t ask anyone to prepare long presentations or status updates. We’re not here to listen to two hours of “how marketing is doing.”

An example of one of my agendas

Instead, the agenda is designed to focus us on the big questions. It always includes a warm-up to get people thinking, breaks every two hours (because no one does good strategy work with a full bladder), and a quick refresher on what we actually mean by “strategy.”

I’ve uploaded a template version of my Agenda Book for you in case you find it useful.

So… What Is Strategy

Here’s how I break it down in plain English (when I say “I” I mean mainly what I learned from Richard Rumelt’s excellent book “Good Strategy/Bad Strategy“:

  1. Diagnosis. What’s the challenge we’re really facing?
  2. Guiding Policy. What’s our overall approach to deal with it?
  3. Coherent Actions. What are the specific things we’ll do to carry out that policy?

Or, to put it more simply: what game do we want to play, and how do we make sure it’s one we can win? If you haven’t heard this before, watch Robert Martin’s video on “A Plan is Not a Strategy“.

I also always remind my team of our company’s purpose, who we serve, our long-term goals, and our value proposition. Without those reminders, it’s too easy to drift into a “wouldn’t it be cool if…” brainstorm that has nothing to do with what we actually do.

Lessons and Successes

Every offsite starts with a “lessons and successes” session. Everyone writes down what went really well last quarter and what didn’t. But we don’t call them failures. We call them lessons or opportunities. It’s a small linguistic trick that makes people a lot more open about sharing. Somehow, no one wants to talk about failures, but everyone is happy to share a lesson. Go figure.

The Art of Session Timing

The timing of your sessions matters just as much as what you’re talking about. Here are a few rules of thumb I’ve learned:

  • Avoid the first week of January. People are still mentally on the beach.
  • Do the most creative sessions at 10 a.m. That’s the sweet spot between being awake and not yet hungry. Your team’s biological systems may differ.
  • After lunch = process-driven work. Digestion is the enemy of innovation. You can still work while eating, but keep those conversations more about softer subjects (how to handle one on ones, time off policies, annual parties, etc.)
  • End around 4:30 p.m. It gives people time to wind down before dinner and leaves wiggle room if you run over.
  • Plan for things to go off schedule. There will be times when the group is on to something, and you (or hopefully your facilitator) can give them that space to breathe. So you need to plan this time into your agenda.
  • Always define your terms. Even the obvious ones. Trust me, “everyone knows what that means” usually translates to “everyone has a slightly different definition.” Maybe have a little glossary where you say “OKRs: Objectives and Key Results” or something, and you can have it grow.
  • Never plan your agenda in Word or Google Docs. Use a tool like Miro. Moving around digital Post-its is a lot easier than trying to force an agenda into table. You probably have groups of ideas that either need to be spread out through the offsite, or logically follow other sessions. Having this be fluid is much easier.

Exercises That Actually Work

Here are a few of the exercises we’ve used over the years that can spark insight (and sometimes recurring jokes that last for years about moths… ask me sometime).

  • Wins and Lessons from the last quarter.
  • The $500,000 Startup Challenge: “You’ve got half a million to launch a new version of our business. What do you build?”
  • Forward and Backward Visioning: Picture three years in the future, then reverse-engineer how we got there.
  • Personal Three-Year Visions: Where do you want to be, professionally and personally?
  • OKR Realignment: Are our objectives actually aligned to strategy, or just busywork in disguise?
  • Values and Behavior Mapping: How do our values show up in real life, and where do they fall short?
  • Cultural Story Mapping: What stories define us, and what new ones should we be telling?
  • Weird Rules Creation: The sillier, the better. Think: “No big decisions without snacks.” These often end up reinforcing culture more than you’d expect. (Stolen from What You Do Is Who You Are: How to Create Your Business Culture by the brilliant, but increasingly strange Ben Horowitz).

Sometimes things do get very tactical, like “how do we estimate better” or “what should the customer experience feel like at every touchpoint.” The point is to mix the big-picture, the personal, and the practical.

Facilitator or DIY?

For our big three-day Q4 offsite, I work with a professional facilitator. About six weeks before, we start planning the sessions. He drafts exercises, I give feedback, we go back and forth a couple of times, and by the time he arrives, everything is mapped out. During the offsite, he runs most of the sessions, and I step in to lead a few. If you’re going to do this properly, you have to get a professional facilitator. There is no way you can participate and facilitate at the same time. If you want the contact information of our fantastic facilitator, just contact me and I’ll introduce you.

For the one-day offsites, I handle it myself. It’s leaner, but the same principles apply. I still use Miro boards and agenda docs with links so no one has to ask, “Where’s the link again?”

Wrapping It All Up

At the end of each day, we set aside time to reflect and capture action items. On Sunday at the Q4 offsite, we do a quick survey for the facilitator, then finish with a wrap-up where we turn the best ideas into concrete action items or OKRs.

After that, it’s back to the pool, pickleball, or Mario Kart, and whiskey. Sometimes all combined.

Final Thoughts

The trick to a great offsite is balancing focus with fun. If it’s all play, you come back with nothing but a hangover and embarrassing photos of some executive who should not have eaten that gummy (or one that accidentally ate a moth!) If it’s all work, you come back exhausted and not wanting to go back to work. The sweet spot is somewhere in the middle: a weekend of clear strategy, honest reflection, and bragging rights to the late-night Nintendo battles. But the true indicator that you’ve pulled it off is that your team are excited to get back to work on Monday.

That balance is what keeps our team aligned, resilient, and ready for whatever the next quarter throws at us.

Previous ArticleNext Article
I help companies turn their technical ideas into reality.

CEO @Sourcetoad and @OnDeck

Founder of Thankscrate and Data and Sons

Author of Herding Cats and Coders

Fan of judo, squash, whiskey, aggressive inline, and temperamental British sports cars.

Leave a Reply

The Million-Line MVP

A founder told me last week that his chatbot understands him better than most people he works with, and he wasn’t joking.

He had been alone in his house for the better part of a year building an app on one of the popular AI coding platforms, and he wanted me to take a look. Almost a million lines of code, one developer (him), no engineering co-founder, no senior reviewer, no nobody. The app had an ERP module, a CRM module, a custom AI agent with a name and a voice, built in mini-games (yes, really), dozens of character personas, a few landing pages, and a small army of social media accounts in multiple languages. He had not yet had a paying user, or even a free one.

He was, by the way, very excited.

(I’ve changed some details, since the pattern is what I want to talk about and not the founder. I see something close to this on roughly one out of every three sales calls now.)

What used to slow you down was the point

Building software used to be annoying for mostly good reasons. You had to hire developers, or learn to code yourself, or convince a co-founder to come along for the ride. Then, you would grind out every line, which would come at a cost (time, money, conversations, arguments, etc.)… basically friction. And that friction was not a bug, but it was like this ting that you are forced you to deal with, before adding any feature, whether the feature actually needed to exist.

Startup advice has been more or less the same for twenty years, maybe more:

  • Build something small
  • Show it to real people
  • Find out what they actually want
  • Don’t build a million things at once.

The Lean Startup came out in 2011 and we have all been quoting it at each other ever since (poorly, mostly).

This is what we talk about when we discuss “startup discipline”. It’s really not very complicated, but it can be really hard. It used to be hard because building was hard, and now it’s hard for a completely different reason.

How does one person build almost a million lines of code in a few months?

The honest answer is they don’t, the AI does, and the AI has no opinion on whether any of the code should exist.

This is the part I want to sit with for a minute, because I think it’s the heart of the problem. Imagine you’re building a startup that lets local news anchors rent out their unused toupees by the hour (try not to overthink this). You sit down with one of the AI coding tools and you say “build me a marketplace where toupees can be listed by the hour,” and the AI builds it. Then you say “actually, add a loyalty rewards program,” and the AI builds that too. Then you say “and also, add a Pokemon-style mini-game where users battle each other’s toupees,” and the AI starts coding.

It doesn’t pause or ask why, and it doesn’t say “dude, I love your enthusiasm but I am genuinely worried we are losing the plot here,” it just builds the toupee-battle-feature.

This removes the single most useful thing about a good engineering team, which is that engineers PUSH BACK. A senior developer, or a seasoned product manger, asked to add a toupee-battle mini-game to a B2B rental marketplace would slowly take off their glasses, set them on the desk, and ask one of those long quiet questions that means “we are not doing this.” The AI this is a sycophantic drone that has the eagerness of an underfed puppy to please you, and it has no glasses to take off. It also has unlimited keystrokes and believes that every single idea you’ve ever come up with is absolutely genius. At least it tells me that everything I’ve ever written or thought about is pretty clever.

A few months ago I ran into the perfect name for this, which is Slurm Coding. I used to call it AI crack coding, because the dopamine loop is very real, and I have really needed another hit of that good AI crack just one more time before I went to bed on more than one occasion. But Slurm is both more insidious in its combination of addictiveness and corporate outreach.

The MVP don’t change

Here’s what hasn’t moved in twenty years of startup thinking:

  1. Build the smallest thing that solves one specific problem for one specific person.
  2. Show it to that person (a real person, probably not your spouse, definitely not your mom, and DEFINITELY not my mom, and 100% not your chatbot).
  3. Find out what they actually do with it (which is probably not what you thought).
  4. Kill features, pivot, or double down based on what you learned.
  5. Repeat.

What’s new is that step one is basically free, and while not perfect, free is very alluring. You can build the smallest thing in an afternoon, or the largest thing if there’s no one around to tell you not to. Steps two through five still require getting out of your house, talking to humans, accepting that most of your assumptions are wrong, and throwing real work away. None of that is faster than it was in 2005, none of it is fun, and none of it scratches the “I NEED MORE SLURM” build-a-thing itch the way an AI tool does.

So a certain kind of founder just skips it, staying in the build phase indefinitely, because the build phase now feels like winning at a casino while getting unlimited free martinis. The feature ship (how to get them onto a server is someone else’s problem) the codebase grows, the agent agrees with everything. Meanwhile the only thing that actually matters, which is whether anyone wants this, goes unanswered.

It’s the founder version of Wilson the volleyball. In your unwashed isolation, you’ve made a friend, you’ve named the friend, and the friend agrees with everything you say. The problem is that the friend is also the boat, the island, and the ocean, and you haven’t actually left the house yet.

To be fair, I am not above this myself, by the way. I have, in my time, built things that nobody asked for and gotten weirdly emotional about them, but the difference is that mine were three hundred lines of code over a weekend, not almost a million lines of code over the better part of a year, which is sort of the whole point. No one asked for my William S. Burroughs poetry writing twitter bot, but I loved it anyway.

Codebases don’t love you back

Code you wrote yourself CAN hard to let go of, and code you wrote with an AI, when you are not a trad-coder, seems to be way harder. Experienced engineers seem to be more than happy to throw away AI code or rebuild it in a heartbeat. But I can see how even if you didn’t actually write the lines, but the shape of the thing is yours (you named the characters, you picked the voice, you spent months in a chair with this thing as your only collaborator), and you have feelings about it.

But one day, if you’re lucky, and it does have SOME product market fit, a real engineering team is going to need to look at your masterpiece. And they are not going to share those feelings. They’re going to tell you, as gently as they can manage, that most of it has to go. Not because they’re mean (they might actually be mean), but because almost a million lines of AI-generated code, written by one person, in one tool, with no architectural review, is never maintainable, almost guaranteed to not be secure, and almost never going to scale past the “prototype” it currently is.

So what should you actually do?

I mean, I already told you… Build the smallest thing you can, then show it to ten strangers and actually listen to them. Throw away half of what you built and build a slightly different smallest thing, and repeat until one of those things is real. Keep your runway reserved for the moment you realize you were WAY off about something important, because, like, you will be, and that moment is what your runway is for.

Use AI tools, because they are legit amazing. But treat them like a coffee machine (fast, useful, no opinions of their own), not like a co-founder or worse, a slot machine. Co-founders are supposed to tell you no, slot machines whisper “just one more hit baby!”