Early Stage Company Offsites
this post was mostly dictated off the top of my head with Wispr AI
A basic rule I made for myself when going ahead with running a remote company is that we would spend the money we’d’ve spent on office rental in traveling to meet in person at least once to three times a quarter. We have just come out of the first full company (aka 3 people off-site/onsite) in St. Louis. It was just 2.5 days, but it felt relatively productive, and I wanted to jot down some thoughts on things that I felt we wanted to repeat and that I would recommend to others.
Give Every Hour A Job
The first thing I did on a whiteboard was to mark out every single hour of the retreat and list everything we wanted to accomplish during the offsite (basically time block planning, but just on a group basis). We also made sure that everyone had input on what they wanted to cover on the offsite so that they could walk away feeling like they had gotten what they wanted out of the offsite.
The classic problem with this is underestimation errors compound. A discussion that supposedly takes one hour might take three, and that is entirely natural. You can mitigate this by leaving room at the end of the day for unplanned extensions (aka question marks). Because we are so early, we did not do prior planning to each of these sessions that we are about to go into next. At larger off-sites, I have seen that people take a day or two prior to the off-site to make sure that enough context is being set for the session that is being discussed.
the Finance Review
Between us, we had been part of 4-5 remote companies that did off-sites, but very rarely do companies do full finance reviews during them. I suspect this is out of some mix of conservatism around not exposing all the economics (including everyone’s salaries) and also the difficulty of accounting when you have a lot of different customers and SKUs. This is not a problem for us because our salaries are transparent as of right now, and funding sources and customer/revenue sources are pretty straightforward.
The basic goal of this meeting is for everyone in the company to walk away knowing where the money is, where it comes from/where it goes, and where we are likely to make more in the future. This gives people, especially employees, some security in terms of runway and the fundamental viability of the business.
For us, this took 15 minutes because it was so simple and could be drawn off the top of my head.
the Customer Review
Our products and engineering priorities gain more clarity the better we understand the customers we are building for. I admit this is something we are still figuring out, and I am not sure what advice to give here apart from the fact that I do strongly believe that customer centricity and obsession are the right way to grow a company - or at the very least keep a company honest - as opposed to other things like technology or research centricity or “vibes” centricity.
the Architecture Walkthrough
Take the entire codebase and throw it into ChatGPT, asking it to make a Mermaid diagram showing all the major sections with boxes and arrows pointing to different parts. Put that onto Excalidraw, tweak to taste, and color to taste, making it all roughly make sense. Then walk the entire company through it.
The basic principle: everyone is entitled to have an opinion on what to do next, but we must all share the basic ground facts about what exists today.
I was challenged on why this exercise was important. Hypothetically in a larger company, the CEO should be able to treat the tech team as a black box and no longer be so concerned with implementation details. Discounting the size of the team, I still think it is relevant for people not directly on the engineering team to understand the architecture so as to appreciate technical bets that have been made and not make ridiculous/insane feature requests. And if possible, proactively surface designs of the system that can be productized as features.
Of course, as a technical founder, I also use this opportunity to insert some opinions that I had that I wanted to see which leads into next discussion…
the Principles Meeting
Offsites are handy as an intentional break from routine to work on the business instead of work in the business. This is a concept I picked up from the E-Myth Revisited book by Richard Gerber, which I have not read, but I’ve heard enough people talk about that I feel like I have read it. So this is explicitly a meeting about HOW we work and how we want to continue working going forward.
As a first-time founder, I found it very refreshing that this was the highest leverage meeting for creating the kind of company that I always wanted to work at and to express principles that I believe most strongly in a public fashion so as to be held accountable for it to build compounding success habits. In other words, I could just speak into existence the kind of work culture I believed in, and we could either voice our disagreements or mostly go along with it.
The two primary influences of the principles meeting are probably the Amazon Leadership Principles Ray Dalio’s book on principles. Ray’s top principle is that “pain + reflection = progress”. At Amazon, there are 14 leadership principles that define various strong opinions developed by Jeff Bezos. I think there is a value to parsimony of principles - so we need to make every word in the principles count because then they carry weight. If there are too many principles, we cannot remember them and it is too easy to excuse not following them. We ended up coming up with 5 principles, which is probably one or two too many because that is more people than exist in the company. The hardest thing is saying no to reasonable additions, of course.
A core, unsettled principles debate
Currently, the strongest principle I believe in AI is that ”product leads process leads platform”. In other words, we will reason from first principles on what the best product for our customer is and do whatever it takes to make the best product possible - whether it is a mix of software or human labor. We’ll then systematize the human labor into a process and as far as possible, finally, we’ll try to express/encode/generalize those processes into software.
This is in direct contrast to some other startups I have seen that put platform first. For example, building an open source product that can do everything or cloud products that can do everything and then going out to search for customers and use cases.
My general sense is that the most successful leaders in AI have built a product that encapsulates a magical or frontier experience, and people don’t actually really care about having access to the API under the hood. They just want to care about the end result.
If in the future you then put out open source products or API platforms that power your experience, the users will then be swayed by the product’s branding to also adopt your platform in a similar fashion that Amazon.com was able to give its imprimatur on Amazon Web Services when it was launched later. There will be exceptions to this rule, of course. Both in the sense that people who prioritize products like Character AI, even if they are leading products, don’t necessarily win and don’t manage to successfully monetize either their products or their platform. As well as platforms that become relatively successful with no strongly opnionated product leading it- aka Together AI, Braintrust, and Fireworks.
I do worry that putting products first instead of customer first gives us an out to be product-centric instead of customer-centric. And that is a flaw of the current principle that I have identified for the company.
A simpler principle
The easier principle that I proposed that encountered some debates but was eventually accepted was that we would ship code every day. This is a behavioral principle rather than a theoretical/business strategy one, but I like it in terms of having momentum.
The motivating story here is how Nat Friedman took over as GitHub CEO because most new CEOs embark on a 3-6 month listening tour with their senior management before making moves. Instead, Nat said “We will ship 100 things in the next 100 days and discover the roadblocks” - or learn how the company functions by doing that.
Obviously, at a small company, that is a less controversial statement, but I think it is that commitment to being close to code also being close to products helped us move quickly. In startups, being a startup means moving quickly and responding rapidly to new technologies and customer demands.
This principle directly expressed itself in our time block planning, which we mentioned at the start of this post. We left space to code every day of the offsite, addressing a concern that we had that work would stop when we were doing this meta work.
the Bus Factor Onboarding
Again, this is a meeting that is probably most useful in a smol company. The goal of this meeting is to have the most knowledgeable person walk everyone else through running the entire system, getting permissions and admin logins, and familiarity with the system administration. This way, should one of us be on holiday, anyone can pick up where we left off. If someone else was unavailable, someone else would be able to bring systems back up even if it took more time.
I do recommend starting a Zoom and sharing the screen and recording so that you end with a nice recording of the process that you’re to fall back on. There are some AI products that will generate a runbook just from this kind of recording, but I can recommend any because I haven’t tried any of them out yet.
Brainstorming
In the course of regular work, there are a lot of ideas thrown around as to what to do and what can be done - both from a core product point of view as well as product extensions or other experiments that we want to do. This meeting offers space for people to brainstorm and bring creative juices together, but unfortunately it is very difficult to switch from diverging to converging.
I recommend setting a separate meeting for prioritization, which we did at the end of the offsite where we converged.
Prioritization
ultimately, the task of prioritization is the job of the founders/CEOs/product managers, so it’s not entirely a democratic exercise. It is useful to think about and to lay out everything to do that we want to do on a board and acknowledge that there will never be enough time to do all of them, therefore, some tough decisions must be made.
The challenge I find in many prioritization schemas, including linear and JIRA-style ratings, is that they don’t account for the fact that priorities can change over time. Rating systems or Eisenhower matrix style rating systems do not include the value of experimentation and the fog of war when it comes to gaining information with small easy steps. I requested that we have a 2-number rating system based on ease of the idea and potential of the idea, rating from 1 to 10. We would then try to create boundaries on the ranges of the rating (i.e., level sets on what 1 means and what 10 means on the easy scale) and what 1 means and what 10 means on the potential scale.
We’d then use this to multiply or add the scores for a point system ranking of the ideas that we wanted to pursue. We are not used to the easy scale…
Everyone struggled the most with the easy scale because we interpreted the ‘E’ as effort, but we wanted higher numbers to represent better things while at the same time acknowledging the fact that we do not only pick low-hanging fruits. We want to pick a mix of low-hanging fruits that are expected to pay off well and harder things that are also expected to pay off longer term.
Socials
Most people are tired of cringe team building activities. To be honest, we didn’t do much in the way of social activities apart from getting meals together and visiting Blueberry Hill, which I highly recommend everyone visits if they are in St. Louis. I think that’s okay, but I’m definitely open to ideas for better socials for small teams like ours.