« What I’ve learnt as a CTO in the last 6 months

December 21, 2017 • ☕️ 2 min read

A mailing list discussion inspired this ‘end of the year’ personal retrospective, I think a lot of people might be in my same situation and might benefit, I also think it’s always good to look back in a few years, where I was and where I’ll be and track progress.

First of all, the context: I am a hands-on CTO of a pre-seed round, pre-revenue startup.

Avoid Infrastructure (and DevOps!) at this stage: go Serverless or rather PaaS/monolith: the amount of time that it takes to spin off, maintain, evolve a non-serverless infrastructure is the most under-estimated task in IT these days, it doesn’t matter how many good practises, automation, good engineers, good tooling you will use, Serverless or a PaaS will obviously take less time.

Optimise for the right stuff: that implies identifying what is the right stuff, as fast as you can, and the right stuff is a moving target, it might shift on a daily, hourly basis.

Use the tools that you already master: there’s no time to learn, you might want to optimise who you hire depending on tech in order to get better/more candidates but you need to master that tech, inside out, there is absolutely no time to learn something new at this stage or even worse, to waste time troubleshooting some serious issues because you (or your hires) don’t know the tech inside out.

Keep Work In Progress small: as small as possible, focus focus focus on one single thing, achieve that, move on. Keeping WIP small on a ‘standard’ project is a good practice, but in an early startup, with limited resources, and limited funding you will be constrained by something way heavier than just “good lean principles”.

Tech doesn’t matter: Tech is actually the least important thing in the whole chain! Users and Product are way more important. As techies we often see the world from our own techie eye, there’s a whole ecosystem which is way more important, your users won’t care about the quality of your code nor how many tests you wrote, even less which tech stack or latest framework you are using: they care about a good user experience and a product that is useful and potentially solves one of their problems.

Be Pragmatic/Context driven: it’s totally fine to hack something together as far as you know (and share with the biz) that you will pay for it later on if a fast Time To Market gives you some useful insights.

Often not writing any code at all is the best option (WordPress, Typeform, Unbounce, etc…): you won’t have a system to support, but you will gather insights from your users. Google for a solution before building it, it might be already there!

Now you are the boss but you will notice soon that there are constraints that are above you, there will be always something above you, there will be tough decisions, there will be tech/tools/decisions that you hate and you will have to use/make anyway.

Better hire one super-senior ‘full stack’ engineer who can master everything from UX to Infrastructure than two less junior engineers specialised with vertical expertise.

I’m not claiming that I have succeeded at anything of the above, I am mainly learning from my own failures.

A special thanks to the folks who helped me with chats and support in these last six tough months: Luca, Marco, Mike above all.

And that’s the last but most important tip: have some friends who went trough the journey before who can advise and support.