Five Reasons Why I left Startup Life

Ever since I left the startup life, I’ve been quiet about why.  There are some things I shouldn’t talk about (since I still heart everyone at that startup), but there are some things I can talk about; and I’d like to focus on these, because they aren’t specific to any one startup, and they’re issues you’ll need to face sooner than later if you join as an early stage startup employee.

This critique is focused on early stage startups where you are or will be joining as the first or as employee 1-5.  It’s especially focused on startups that are either still going through their seed round or just finished the seed round.

Startups have no administrative support. Startups are new businesses, and the lack of administration that goes with that.  There are several things you take for-granted in a business, things like insurance, clockwork payroll, T&E systems, and an administrative support system that enables you to focus on doing your job.

None of that exists in a startup. If you’re lucky (and if the startup has the funding), you’ll get some sort of group insurance; but if not, you may be buying it on the individual market (or your company will pay your COBRA, as happened in my case).  If you’re employee #1, they’ll likely just be setting up payroll, and that is fraught with the same problems that any new system has: a lack of use means a lack of habits, which means mistakes. You’ll also probably be the first person to use T&E for your business, which means receipts and spreadsheets.  There are programs that seek to make this easier (ZenPayroll, Gusto, Expensify) but they aren’t free, and they still have the same issues each new system has: integration cost, time, and money. Every time a founder is setting up those systems or working with those systems, they aren’t working on anything else.

Every business person becomes a single point of failure because if they’re out, there aren’t yet processes in place to make sure someone else can handle it.

Being Employee #1 means being the squeaky wheel. If you’re Employee #1 in the company, you are the one that will encounter any cultural, process, or feedback issues, and you’ll encounter them first. Founders have a fight? You’ll know about it (it’s too small not to). Fundraising is hard? You’ll know. What’s the company’s process for paying for your home internet or cellphone that you’ve been using for work? Oh, they said one thing but didn’t follow through? You get to be the one to bring it up. Memorial Day is coming up: Do we have those days off or not? What days do we have off? Do we actually have vacation? How many days? Is your boss missing something fundamental? Are they doing something you wish they’d stop or change?  I hope you can tell them because there isn’t anyone else to, and there’s no one else to talk to about it.   Are they presuming you’ll pay for your trips and then get reimbursed? (Have they forgotten you work for a startup, and by definition make under market value?)

It’s really easy to be micromanaged because everything you do is visible.  In a startup, you have an outsized impact on the outcome. As a software developer, the business impact of what we do is invisible. Set up unit tests? Invisible. Create script to deploy a site? Invisible. However, that time you spent is very much visible. Since you’re obstensibly there to ship the product, those things that make future you’s life easier (like setting up a deploy process or documentation) is de-prioritized.

When I was starting the firmware work, my initial approach was to develop it using TDD. It’s methodical, helps me keep bugs from encroaching, and would enable the architecture to handle our desire to allow user code (by decoupling the architecture).  So I brought up that I was going to spend some time setting up the TDD environment and porting the existing demo code (that I didn’t really understand, to be honest) over to that.

I received a lot of flack from that, including from unexpected places.  Keep in mind, there were only 4 of us total, so to have one person complain about it starts off the second person complaining about it (Yes, GroupThink even hits small groups), and they put the kibosh on that.

As a direct result of that conversation, I was instructed to ‘not worry about setting up the project for TDD’. I spent far more time (easily 3x) fixing bugs incurred by not using TDD than I would have if I had set the project up to be TDD-able from the start.

I need to be clear; this came directly from a combination of the two issues I mentioned above: It’s really easy for a Founder to micromanage one person; and it’s really hard to push back (and yes, I should have pushed back. Not pushing back ended up adversely affecting the project in other ways).

Startups lack reliable funding, especially startups in unproven industries. I won’t say much on this except to say that there was never a moment when we had a year of runway left when I was at the startup; and the number was often much lower than that. This was due to a combination of factors, but the two most prevalent were: 1) we were doing something new and 2) hardware startups are… different. Personally, if Hardware startups have “never been easier” (according to Ben’s closing quote), then I’d hate to have see them before now.

Your life will be filled with constant stress and there’s no one support structure inside your startup to combat that. About two weeks after I left the startup, I visited relatives, and they remarked immediately how less ragged I looked.  I hadn’t noticed, but thinking back to that time; my days were like so:

1. Get up at 6am. check email, make sure site isn’t down. Get the kids out the door.
2. Take a shower. Check email.
3. Get in front of computer around 7am.
4. Work on development (Firmware, app, website, whatever).
5. Encounter bug. No one to bounce ideas off of.
6. Thrash. Sometimes for minutes, sometimes for hours.
7. Have standup at 10. Explain there’s a bug and I don’t know how long it will take to fix.
8. Endure sighs from teammates (none of whom either have the time to help, or could really help on this)
9. go back to figuring out the bug.
10. Ask Hardware Lead to sit on a hangout to figure out the bug (with no other developers, this was as good as it got)
11. Figure out bug by 3 or so. Eat lunch.
12. Work until around 6pm. Eat dinner.
13. Work again from 8-10, or until bug was fixed / measurable progress was made.
14. Go to bed.
15. Rinse, lather, repeat.

Being the only software developer at a company where most of the visible pieces are software is difficult; but even more difficult is not having another developer to work with to solve problems. The Hardware lead was amazing and helped out a lot (I don’t think we would have shipped had he not been my rubber duck); but it’s hard to replace a classically trained software developer, and there was definitely time and money lost due to that.

I burned out three times when working at a startup, and the first time was after I worked through my vacation. (see those dark commits during the two week period at the end of July/Beginning of August, that was my vacation).

Due to issues like developer health and burnout, I firmly believe there should never be a software developer working alone, and this experience only solidified that. Software Development necessarily means building something new, and the cost lost to thrashing and burnout is far more than the cost of hiring a second software developer. This is especially true if you’re asking the developer to build something in a stack they’ve never touched before (for me, Embedded C).

But, I couldn’t very well complain to my teammates, could I? After all, they had their own full time issues; fundraising, building hardware, growth; what could I say to them? Ultimately, I was sacrificing my life and health in a situation where I was just an employee. There was a mismatch of devotion and position. If you work 12+ hour days for a year and a half, but at the end of the day you’re just an employee with the option to buy stock, you’re not going to feel valued.

If I had to do it all over again, I would have adjusted my performance and expectations to be just an employee and put my family and my health first.  I would still do it; but I would not have sacrificed what I did to do it.  We talk a lot about self-care in this industry (though far less than we probably should), but startups and investors still value the worker be that sacrifices their life and health for the “good of the startup”.

I am fully responsible for all the actions I took. I chose to put myself through this because I fully believed in what I was building and I had a mismatch of expectations, thinking that I was more than just an employee of a company.

So you’ve read all this and you are thinking you want to join a startup, great!  Here are some tips I have:

1. Clear expectations first. This means getting everything in writing and being explicit about your role in the company.
2. Set boundaries. These could be personal boundaries, it could be professional boundaries. In my case, I should have (nicely) told the other party to pound sand when they told me not to architect the firmware a certain way. I was ultimately responsible for the time and cost overrun due to that; so I should have taken a firmer stand.
3. Remember, this is a marathon, not a sprint. You are in control of whether you burn out, so make sure to see the warning signs and act before it’s too late.
4. Negotiate for a package that makes you feel valued, and stick to what you negotiated. If they promise $X raise after Y milestone, bring it up. These were the expectations you were hired with, and it’s no one else’s responsibility but yours to ensure you’re treated according to your expectations.
5. Unless you’re a founder, you are just an employee. Your devotion and your passion will be used against you, sometimes by you. If you really believe in a project, that’s a warning sign that you should take a step back and rationally think through it. Ask a friend who isn’t emotionally invested.  There’s a reason why car dealers ask how you feel about a car after you test drive it. If you fall in love with the car, you’re more likely to make a worse deal than if you were dispassionate about it. At the end of the day, no matter how passionate you are about your mission, you’re still an employee. You are at least third in line for priorities; sometimes fourth. (Investors, Company, Customers, and then you). If something causes an upset in the balance, you are fourth on the list of people to worry about for the founders.

Joining a startup can be the most rewarding thing you ever do, just make sure you jump into it with eyes wide open.

Update #2:  Four days after I wrote this, I wrote about Five Reasons Why You Should Join a Startup. It’s the other side of the coin, as it were.
Update #1: Removed the name of the startup. Yes, it’s easy to find; but these lessons aren’t specific to any one startup.