It happened at last! You dumped your corporate boring job and are ready to join a super early stage startup as a CTO, developer #1 and a person who can build and shape an entire engineering department to conquer the world!
Super interesting, challenging and risky. Frankly speaking your success chances are slim, but there are some thoughts, based on my experience (tear, blood and sweat), which may possibly help you.
Bureaucracy will kill you
Quite an obvious one. The smaller your company is the less formal processes you need. Of course you can’t live without some, but be ready to cut them drastically in comparison with what you got used to in the bigger companies.
I.e. spending half a day on a new employee interview (as they like to do in FAANG) is a luxury you cannot afford at the moment.
Even sticking to a strict scrum methodology with fixed scope sprints will hurt you a lot. Just because things will be changing so quickly you may want to switch your priorities twice a week.
Do or die
In early stages your highest priority is to deliver at least something. No business value — no business. Big guys can spend months and millions on R&D. They can prepare, plan, implement, test, fail, plan again, implement again and so on, and still be ok! That’s just not your option.
In most cases you’ll have one shot with highly restricted time and resources. And your main goal as a CTO is to do everything for the project to be delivered, and highly likely by sacrificing your vision of an ideal product.
And that’s the sad truth, be ready to give up the clean architecture, scalability, performance and supportability for a while. I’m not saying you should not try to squeeze all this into your releases, but that’s definitely not the highest priority, at all.
Moreover, try to get rid of as many “nice to have” features as possible. You may never ever need them. Possibly because you’re bankrupt in a couple of months or the business realises that the feature is not needed at all. Only the “must haves” and nothing more! YAGNI, as they say.
But there is something worse, the next hint is even more painful.
Automated tests are NOT you friends
I understand this is a subject for a full-scale holy war, but I know quite a few cases where the common approach of 100% test coverage drowned a project to the very bottom. Why so? There are two reasons for that.
First of all it’s because of the cost of a bug. When you’re small, most likely you don’t have many customers and your features are not used widely at 100500 requests per second. So the missed bug will hurt you, but most likely much less than for a high scale product.
One the other hand, you have the cost of a test. You spend time writing it, and, more importantly, on supporting it. And whereas the cost of a bug is relatively small in the beginning, the cost of a test is much higher, though it grows slower. So in early stages, supporting tests is much more expensive for you, than suffering from some amount of bugs, from time to time.
Another thing is that at the early stage you’re going to change directions all the time, and you never know which part of the system will stay and which will be thrown away in two months.
Till you get a considerable amount of customers, your product is still more or less a proof of a concept, and is super volatile by definition. So do you want to spend 20–30 percent of your dev time on tests which may not be needed at all?
But if you sacrifice automated tests, how on earth are you gonna keep your product up and running?! One thing can help you massively, and won’t require a lot of your precious resources: monitoring.
If you cannot guarantee you have no bugs in production, at least you should know something is wrong as soon as possible. In many cases even before your users find it out.
There are quite a lot of different types of monitoring, the most critical one is tracking errors in your logs, and doing it everywhere. Which means your logs should be brief, clean and meaningful. It doesn’t take much time to keep your logging in a good shape, just don’t forget about it. And once they are, fire alerts on any errors or warnings you get.
For example, a combination of Sentry + Slack works quite good and keeps you in a good shape. When you get notified for every error in your system, it encourages you to either clean up your logs, or to fix the problem.
CI/CD is a must
Considering you expect some bugs, and hope to be notified about them instantly, you would like to fix them as soon as possible. And that’s where CI/CD comes into play.
We all know that it’s a must, but it is extremely tempting to ignore it for a while and spend some time on business functionality instead. Alas, in contrast to auto tests, you should not save on delivery automation. Luckily, in most cases you just have to do it once (again unlike auto tests support).
Moreover, I would say, it should be the first thing you set up. Otherwise you just won’t be able to keep the fast pace of releases and fixes you need so badly.
Quite an easy and free tool to set up your CI quickly is GitLab. Helped us a lot on the first stages.
Don’t forget to learn
Most likely you’re gonna be the most experienced developer in your team (though if you’re good at hiring, not the cleverest). Which means without massive inter-company knowledge sharing, your options or learning something new are much more limited. Personal professional growth and staying on top of cutting edge techs require some investments.
So try to get as much as possible outside. Articles, meetups, conferences are always useful, but for an early stage startup they are just crucial, if you don’t want to fall behind the industry.
Of course, there is always so much to do with your current project, so there’s almost no time for anything else. But you have to do your best to keep yourself afloat. Diving deep into your own product and only it, may drag you to the bottom. Slowly, but steadily.
Also, still you’re not alone, so encourage your teammates to learn and share as much as you can!
Be ready to grow
You joined a garage enterprise not to keep it at the same level forever. The main focus is to grow, and grow fast. And as you grow, all the hints above may not be applicable anymore.
Your team is growing and you have to add more bureaucracy to your development processes. Your customer and code bases are bigger now, so you just can’t keep ignoring automated tests anymore. You got a nice idea to implement quickly? Hold on, it’s worth analyzing its impact on the rest of the product first. Etc.
And that’s your responsibility (and some sort of an art also) to identify the required changes slightly before the problems hit you hard and implement them seamlessly.
So keep your eyes wide open and be all prepared for changes. Startup environment is neither stable nor predictable so be ready to shape and mature it when time comes. But before that try not to think as IT giants, because that’s the only way we can win them over, before they become too evil!