This post is just a place for me to write down a list of lessons I've learned about startups to date. No doubt I'd read about one or two of them before joining the various startups I've worked in, but they're the sorts of lessons I had to live before the lightbulb moment of "oh yeah, I get it now, let's not do that again".

Some cherry-picked lessons:

A startup's priority is to sell, not build. Sometimes we get confused and build in order to sell - but this is backwards. If you can find someone who'll pay you after seeing a Figma mockup, you've found a hair on fire problem. If you can't, find a different problem or look harder. The worst thing you can do is hire engineers to help build a better prototype or demo, because now your time is split between looking harder and managing them (to do what exactly?).

Hiring begets hiring and often costs critical amounts of money in the form of dastardly pernicious opportunity costs. Employees require managing, which takes founders away from finding something to sell.

Finally, the product can't be speculative or based on aspirational customers. It needs to be real and validated. Somewhere around Series B, depending on how persuasive the founders are, the music abruptly stops for startups living in aspirational land.

If you hire before finding a customer you create an echo chamber - where you and that engineer subconsciously start to build what you think the market wants.

This can result in ideas begetting tickets and tickets begetting capacity issues so you hire another engineer - and so the spiral continues.

For every hire, you should know the approximate dollar value of what that employee can bring. If you don't - then do the difficult thing and don't make the hire. It's worth noting that a low valuation in early stages can be an exceptionally good thing, because it leaves the possible exit strategy of being acqui-hired open to the founders. The more people you hire, the less attractive this becomes to prospective acquirers.

If you sell something that saves a company money, you're in the save money camp. This is boring and often difficult to sell.

If however, the customer can make money using your product, you'll sell more easily.

If the customer can do both, you're in a very good position indeed.

Early on in my career I was fuelled by the idea that a group of clever people can build a great company and I still believe this to be true, but with the subtle addition of "but there will be some degree of chaos".

It's a mistake to allow frustrations to creep in if things aren't going ideally. If things are going in a generally correct direction then you're already outperforming a large proportion of startups.

This said, the point of this paragraph is not that you shouldn't aspire to be an elite execution unit, but that it's ok if there's work to do to get there. A company is just a group of people; what's important is that they're aligned on what an elite unit looks like.

I mentioned earlier that hiring begets hiring and the other axiom appears to be that mediocrity begets mediocrity. Unless there's an ironclad rule that you can't hire someone unless they're better than you in some or multiple facets, you'll end up with bloat. Many leading opinions will admit that a certain level of bloat is unavoidable, but I like to err on the side of caution. Keep it lean and sharp.

If you're scaling for legitimate capacity issues and making revenue hand over fist, remember that the people you're hiring will likely be hiring managers one day. If you compromise, so will they. Death by a thousand cuts until your engineering team grinds to a halt.

Nobody else is going to be louder about your work than you can be, and if you're a team lead, be loud about your team's work. Always have a written record of what you or your team has achieved.

Consider being unable to answer the following question - "I know you have presented an argument for how skilled you are and that you deserve a salary increase to be in line with the market, but what exactly have you really done"? Ouch. Come prepared.

About 1 minute into writing this I realised it should be a standalone post... coming soon!

TL;DR - measure twice, cut once; iterating on a requirements document is cheap while iterating on code is expensive (the cost only growing with team size).