“In that alpha user onboarding, literally nothing worked” - Stella (CEO of Hoop)
This is not the first message you hope to see when you sit down at your desk in the morning as a founding engineer at a seed-stage startup. A shock wave of mild panic ricocheted through my heart, gut, and mind as I read those words in our team chat.
Stella had just gotten off a video call where she was walking a new Hoop alpha user through the process of onboarding into our app. Clearly, she had run into some technical difficulties getting the new user set up. This message arrested my attention because I had just shipped the MVP of our new Slack integration a few days earlier. I assumed the “literally nothing” included my brand-new SaaS baby. I frantically scrolled up in our team chat hoping to understand what in the world was going on.
*scroll, scroll, scroll* 💡
Ahhh… there it is!
As I surveyed the gory details of the catastrophic call, I took a soothing sip of warm coffee from my “The Best Dad in the Galaxy” mug and settled in for another day at a seed stage start-up.
The first engineer
For the past two months, I’ve been working as the first founding engineer at Hoop. We are building software to help people make better decisions, faster without meetings. Hoop is my first time as the first engineering hire at a seed-stage startup. I want to share some of my experiences so far.
I get asked almost daily “How is the new job?” My response has been a consistent and transparent:
“It’s exactly all the things I had hoped it would be including the messy challenging stuff.”
I could just as easily translate that sentence to an honest “Great! I’m loving it!” but I want to be clear that a seed-stage startup isn’t for the faint of heart. Even when you have 4-day work weeks, incredibly empathetic co-founders, helpful investors, and a problem domain that makes your heart sing, some days, “literally nothing works.”
Let’s play a game! I’m going to share a bit about what my first 10 weeks at Hoop have been like in the form of “Two truths and a lie.”
Which of the following is a lie?
- “Startups move faster.”
- “Startups are messy.”
- “Startups mean working day and night.”
Startups move faster
At a seed-stage startup, speed is life. You are racing to find product market fit, growth, and probably, hopefully, eventually revenue. You are trying to outrun your burn rate, your competitors, and the blistering pace of a constantly evolving industry. Generative AI, anyone?
The most important area you want to focus on being fast is the speed of your learning. Learning about your customer, their problems, and how your brilliant product idea does, or more often does not, solve those problems. The ideal seed stage company is like Miss Frizzle and the Magic School Bus set in a Fast & Furious movie. Fast. Learning.
When it comes to building software, shipping small changes more frequently is almost always a better way to build software anyway. It creates a virtuous feedback loop where the changes you make to the system are easier to reason about, test, and detect defects in.
The best way to learn fast in software is to ship something to customers and watch them use it.
The good news is that when it comes to building software, shipping small changes more frequently is almost always a better way to build software anyway. It creates a virtuous feedback loop where the changes you make to the system are easier to reason about, test, and detect defects in.
Early on in my time at Hoop, I told my co-founders that I was setting a personal goal of shipping daily. That doesn’t mean I will ship every single day but it means on average the cadence of shipping will be at least once a day if not more frequently.
I make myself accountable to this cadence by posting a chat message at the end of each day title “What I shipped today 📦”.
Here’s a real example of what that looks like:
My favorite part of being an engineer is putting little bits of delightful value in the hands of real people with real problems. Shipping is the pulse of a startup. It also feels really darn good. I mean, look at those little “heart eyes” reactions on my “What I shipped today” post!
Delivering incremental changes to customers is the most critical place to be fast in a startup, but it’s not the only place you want to take advantage of being small and nimble. At Hoop we are also focused on our pace of recruiting, the pace of research, and the pace of publishing content among many other things.
Verdict: (Good) Startups move faster -> Truth
Startups are messy
Let me pick up my “literally nothing worked” story from above. Here’s the rest of that conversation from our team chat:
So what happened?!
The first version of the Hoop Web app is built on a fairly flexible and powerful “no code” platform called Bubble. Overall, we’ve been very happy and successful with Bubble. However, on the day of “onboard-ageddon”, Bubble had an outage and it took down both our web app and our Slack app just before a customer onboarding call.
A 3rd party platform outage isn’t something you only experience at a startup. Big companies have outages all the time. The difference is when you are at an early-stage startup and are optimizing for speed of learning and building systems that might get tossed in the trash tomorrow, you don’t have all of the mature processes, tooling, and systems in place. You can’t afford to invest in the same level of reliability and graceful recovery in the case of exceptional events like 3rd party outages. Things get messy.
Things feel especially messy when you are the only engineer at a startup scrambling to diagnose and fix an issue in real-time.
Aside: This is one of the many reasons I’m so excited about our second engineering hire starting at Hoop as well as finding engineer number 3 to round out our founding engineer trio.
In the end, we recovered from the incident and all was well. I patched some code on our side that failed during the outage, I made our app health monitoring a bit more robust and we made a process change to pivot or reschedule any onboardings if there is a platform dependency outage.
Verdict: Startups are messy -> Truth
Startups mean working day and night
If you’re keeping score then you know this is the “lie.”
I want to take a moment to unpack why it’s important to me personally to “debunk” the startup “hustle culture” myth.
The reality is that startups are a LOT of hard work. There is no way around it. Creating something from nothing is a tremendous achievement on its own. Creating something that a lot of people genuinely love and want to pay money for is an improbable superhuman feat. More startups go bust than not for good reason.
One lever you can pull to try and optimize for success at a startup is to pour every last ounce of time, energy, and focus you have into building your business. There are a certain number of essential tasks at a startup where investing more hours does move you along farther faster. I believe it is a valid position to argue that if you can pour more time and attention into your startup without burning out, you are likely increasing the probability of a “successful” outcome.
The problem is, if “maximum hustle” is a pre-requisite to building a successful startup then many of the most ambitious, intelligent, talented people are ruled out of building startups from the jump. This is because they, like me, have decided that as wonderful, beautiful, and fun as building a startup is, there are some things in life that are more important. Things like healthy rich relationships with family, partners, kids, and friends.
I consider it a core part of my life’s mission to make delightful software that solves real problems for people. In doing so I hope to make the world a better place. At the same time, I refuse to sacrifice being present and involved with my wife, kids, and community for the sake of startup hustle.
At Hoop, we are making a big bet on this “anti-hustle” position by working 4-day work weeks. We believe that by constraining our working hours to 4 work days, focusing those hours on the most critical work, and being as efficient as we can with those hours, we can build a meaningful successful startup AND ALSO leave a lot of room for the rest of our lives outside of work.
The 4-day workweek has a very “focusing” effect on my work hours which makes me more efficient and productive with those hours. I’ve found myself falling into an enjoyable weekly rhythm of work, rest & think -> work, rest & think.
My personal experience in my 10 weeks of the 4-day workweek experiment is that it’s both wonderful and challenging. The extra time flexibility it adds to my work week has created some wonderful opportunities for me as a dad to spend quality time with my kids. It also has a very “focusing” effect on my work hours which makes me more efficient and productive with those hours. I’ve found myself falling into an enjoyable weekly rhythm of work, rest & think -> work, rest & think.
In roles at previous companies, a weekend could feel like a crash landing into a busy two-day desperate attempt to catch my breath after sprinting at work. With a 4-day workweek, weekends feel more like a smooth transition where I have the space to prioritize my personal life as well as spend a lot of time “thinking” about what we learned the prior week at Hoop. It also gives me extra mental bandwidth to mentally prepare for the week ahead.
Bottom line: I’m more convinced after my first 10 weeks that it’s not only possible but in many cases optimal to build a startup with a shorter work week. I believe 4-day work weeks will continue to catch on, not out of lazy entitlement, but rather out of a data-backed acknowledgment that in many cases raw work hours != output != outcomes. In some contexts, you actually get better outcomes with fewer raw work hours.
Verdict: Startups mean working day and night -> Lie
The next two months
I could not be more excited about the future at Hoop. We’re exploring a promising new product direction to make decisions even better and faster. The way we work as a team continues to get tighter and faster. We have an incredible 2nd engineer starting this week. We’ll be meeting up for our next team offsite in late May. Want to meet us there?
If you are a senior front-end or full-stack engineer that believes in helping people make better decisions and wants to join a proven successful and empathetic team, we would love to hear from you. (Update: This position has been filled and we don’t currently have any open positions. However, if you’re interested in what we’re building and want to be considered for a future role, email us at firstname.lastname@example.org)