After building a successful open source project I then started a company and made many mistakes.
Some folks on this path foolishly ask for my advice. This article encodes some of that advice.
It is intended for technical founders who have no experience building companies.
Most Advice is Wrong#
Many people will offer you advice:
Fractional CTO/CMO/COO/CRO folks
Other founders (like me)
We’re all mostly wrong. That’s not because we’re dumb (we’re mostly not dumb) but our experiences were valid for our situations, and they probably don’t transfer over to yours.
Early stage companies are all pretty unique, and it may be that there isn’t a lot of transferability of knowledge. Unfortunately, the wisest person for your situation is probably yourself. You’re going to feel pretty lost (that’s ok, you are) but you should probably just follow your gut most of the time and see where that takes you. Trying to integrate advice from lots of generic advisors invariably leads to mediocrity, which is death in early stage.
Given that, I encourage you to read and then discount my advice below.
Hire Experienced Folks#
You should certainly employ folks though, and you should listen to them. They should all be smart; ideally smarter than you.
You don’t want any interns or junior folks. No one on your team has time to grow them. You’d be doing them a disservice; early stage startups are a horrible place to start a career. Junior folks need structure. You want people who are smarter than you.
You’ve succeeded in finding someone when you can say “Oh, so-and-so has that problem, I don’t need to think about it anymore.”
Hire Nimble Folks#
So hire experienced people, hire people with opinions, but avoid people who have a plan. Your first ten plans will fail. You need people who can acknowledge failure quickly and move on.
Some experienced people make a living by going into early companies and running a well-known playbook. This will be great for a month and then it will be wrong, but these people won’t want to deviate from their playbook that frequently. These playbooks will sound enticing; they allow you to offload responsibility for a time to an expert. This is a lie though, you’re still on the hook.
You want people who are intellectually excited about pivoting once a month.
Hire Independent Folks#
Some people want to be told what to do. They’ll ask questions like “OK, what are my goals for the quarter”. These people are used to much more structure than you’ll be ready to give to them.
You want to hire people who can look at the entire situation and can come up with and change their own goals after chatting casually with you. You can’t be guiding them the entire time.
A team of five gets along well together. A team of thirty has a variety of issues:
differences in culture
they can’t all fit in a room
they need management structure (and will then start to care about titles and hierarchy and such)
Before long you’ll find that instead of solving important problems you’re spending all of your time managing a group of people.
Given that you’re going to fail ten times before you find the right path, it’s best to keep the team pretty small. They won’t go as far, but it’ll be way easier to bring everyone along as you explore the space.
It’s like walking down the street with friends. Two people can walk pretty quickly even around obstacles, but thirty people walk really slowly and get bogged down when unexpected obstructions occur. It’s just hard to redirect the group of thirty without a lot of emotional work.
Stay small until you have actual revenue that you think you can scale. Staying small will also enable you to pay for really good people. One really good person is worth more than five ok people, which are worth infinitely more than fifty junior people.
You individually are probably faster than fifty junior people.
Hire Consistent Culture#
Do you care mostly about …
Changing the world?
Building the best working culture?
Then make sure that everyone with hiring authority on the early team picks the same one. Otherwise you’ll have to fire a bunch of people down the road.
This is a hard lesson to learn, but you’ll know that you’ll need to fire someone, and then you’ll try for a few more months to make it work. This will be bad for everyone and so very bad for the company.
Fire early. It’ll suck, but everyone (including the firee) will be better afterwards.
Take the Money#
Investors may be offering you more money than you need. That’s ok. Take the money. Money is useful. It can be turned into good people, time to relax and regroup, experimentation, offloading dumb problems onto contractors, firing troublesome customers, etc.. Don’t worry about being overvalued. Don’t worry about overly high expectations. Just take the money.
VCs primary value is money#
VCs are smart, but they’re also diffuse and thinking about many companies at once. They’re good to talk to and to make introductions, but that’s mostly it. Their experts are smart, but they don’t know your business well and so you shouldn’t depend on them to solve your problems. You’ll outgrow them in a few months.
Choose people who understand your space#
Even though they won’t be able to help you, it’s really nice to have people who understand what you’re doing so that you don’t have to explain everything to them.
Authenticity and Mental Health#
There’s no recipe to being a CEO#
Often folks feel stressed because they feel like they often need to behave in a certain way:
You must have a clear and inspiring vision several years into the future
You must know exactly how to execute on that vision
You must present optimism to the team and to the world of your irrefutable success
Screw that. No sane person has that much foresight/confidence. Most startups fail, including probably yours. This is the sort of unreasonably high expectations that lead to burnout for you and corrosive behavior to the team.
You’re a human, and you’ve been a pretty successful human up until this point. You should probably keep doing whatever it was were doing before. There’s no reason to completely change your behavior. Instead, change the company to suit you.
Optimize for yourself#
If you’re successful then you’re going to be the bottleneck of your company. It’s ok if you optimize for yourself.
Hate Slack? Push the company to mailing lists and Github.
Hate regularly scheduled meetings? Push for asynchronous communication and ad-hoc meetings.
Want to take some time off? Define a vacation policy that suits your needs.
Want to go to the beach? Schedule the next offsite near the water.
You’re being selfish and that’s ok. It’s also probably what’s best for the company.
Hire a group for this. Your investors will have contacts. Pay those contractors well.
Do this yourself. You can find people to do this for you, but you’ll spend a bunch of your time and energy explaining things to them, having them translate your words poorly to a lower common denominator, and then spend a bunch more time and energy struggling to make those words right.
It’s easier and better if you do this yourself for a while, and learn whatever you need along the way.
You are your biggest competitor. You’re likely to slow yourself down far more than any other entity.
Early competitors pivot quickly#
Early stage companies shift a lot. It’s likely that who you perceive to be your biggest competitor will shift considerably every few months. This is because both you and they will be pivoting rapidly.
Given this, you shouldn’t optimize around them too much.
You’re a small slice of a growing pie#
Activity in a space is good. Conversation is good. It’s sometimes harder to convince people to care about a problem than it is to convince them that your solution solves this problem well. Competition helps here.
A common refrain we hear is “but this won’t scale”. This applies to early sales contracts, product ideas, technology choices, and so on. It’s ok. Your first job is to build something, not to build something scalable. Eventually the thing will need to scale, but you don’t need to do that yet.
Example: Tesla started with the Roadster, a fully electric sports car that cost $250,000. About 2,500 were ever made. This product didn’t scale. The market of people willing to pay that much for a car is small, and the manufacturing process wasn’t smooth. It didn’t matter though, it allowed the company to experiment and iterate quickly so that they could then produce the Model 3 and think about scaling issues.
It’s ok to start out by just building the Roadster. First build a thing, then build a thing that scales. Building a thing that scales right from the start reduces your chance of eventual success.