First day as CTO at growth-stage startup not all you think
Voxgig is preparing for growth. By the summer we'll be in full public release, onboarding lots of new users and customers. As things progress, we'll move onto the next round of funding, and filling out the 'C-Level' team. That means we'll be bringing experienced people into the company to build out teams and structures. In the last two articles, I wrote about our need for a CTO. In this article I'll continue that discussion - in later articles in this series I'll talk about the other roles we need to hire. Some of them will only come into place much later, but it's good to think ahead. As ever, next year you'll be able to look back and have a good chuckle at my mistakes and wrong-headedness. Of course, so will I - and that's the reason I write this startup diary.
What does day one look like for a new CTO joining a growth-stage startup? Excitement and enthusiasm based on the great results so far? Are you looking forward to building out some great technology and jumping into some great scaling and team-building challenges? If so, I'm afraid you'll be better off at an established tech company.
If an early-stage startup has got to growth stage, then by definition they've done so with minimal resources and a tiny team. The corners of the corners have been cut. Any problem that isn't immediately fatal has been pushed into the future. Take a look at our website voxgig.com - notice how the page header is not consistent and changes on different pages. How embarrassing. Different people build different pages at different times for different purposes. There's now a job to consolidate all that work. It's just been pushed down the priority list - when you have a trial client running your system in production, they win every time. And rightly so. And this is just the tip of the iceberg.
Day one for a new CTO means a growing sense of dread and rapidly escalating sense of panic. "What have I got myself into?" The software is usually in such bad shape that a complete rewrite is often felt to be necessary - by everyone. That would be a fatal mistake, so don't succumb to temptation. Netscape's big rewrite in the mid-90s famously allowed Microsoft to come in with the Internet Explorer browser and take over the market.
There is a term for this situation - technical debt. It is the deliberate accumulated of bad design and short cuts in the technical system in order to achieve immediate business goals. In an established company, your choices are not so extreme and you can afford to get the engineering right. But in a startup you have no choice - good engineering will kill you.
The job of the new CTO is to pay down the technical debt. Not only in the software code itself, but also in the team structure and working practices. This is the reason they have been hired. It is also the reason that this is a particular role needing a very special set of skills. Just being a good architect or technical manager is not enough. You also need to be skilled at organisation and system design, because that is how you deliver the most value.
If you're just starting out, you might be wondering how you can mitigate this chaos. Even if you acknowledge the need to 'move fast and break things', you still want to keep damage to a minimum. In Voxgig we kept things reasonably under control with a few key tactics: first, choosing microservices as our architecture. This technical design keeps every part of the system separate, and prevents bad code from spreading. Parts of the system can fail, or become out of date, and things still keep working. Our minimum viable product, the search engine, which is our home page, is the same code from this time last year - the rest of system has moved on, but that old code is not impacted. It is only now that we are looking at upgrading it. Second, choose popular and established tools that you can hire for. Don't use very new or experimental tools. This is a common startup mistake. People look for leverage in new tools that promise greater productivity, precisely because resources are so limited. This bet never pays off. You'll spend more time fixing the tool than building your product. Startups founded by developers often fall victim to this, and it's something I have to watch for in myself. Third, build in partnership with real users. If your system has to go into production, there are basic things you can't avoid, a level of quality you have to reach, so that you can keep your customers happy. In return, they will keep you honest.
Despite all this, we have still incurred technical debt. This takes two forms: process debt and system debt. We have no well-defined software development processes. This is deliberate. Startups are so small and so wholly dependent on individual contributors that process adds nothing. You have to have coders on the team that can actually get stuff done independently. If you find that you have to manage them in the usual way, you're not going to make. There's a reason project management is a full time job, and it's a job as founder that you will never have time to do. Your early technical team should be able to work independently and develop an understanding of the business requirements on their own. That's why technical co-founders are such a strong plus for investors.
As a new CTO, your job is to design the software development process from scratch. That means not only defining the process from a blank slate, but also working with the existing team to bring them on-board. This will not be easy as developers who choose startups often do so because they have lots of freedom. Nonetheless, to scale, you have to have process and structure. This means setting up a new regular meeting schedule, introducing quality measurement, taking away full access, introducing reviews, pager duty, and all the necessary elements of a larger software development process. Of course, you still don't have the resources to this from day one, so you still have to prioritise and take on more process debt.
There's a story from the early days of Amazon that illustrates this well. Amazon allowed you to return your books for a full refund. But they had no system for tracking returns - they literally could not tell if the books had been bought from Amazon itself. Jeff Bezos decided to run the returns process on an honour system. It was more important to provide returns than to police them.
Soon enough someone discovered they could get refunded for anything they sent in. They started buying up second-hand books cheap and mailing them back to Amazon for refunds. It was good money.
Deciding not build one is exactly the type of decision a CTO needs to be able to take, especially when there are much cheaper non-technical solutions. Designing non-technical solutions that sort of scale is the hidden job of the startup CTO.
The system debt is the corners cut in the software itself. This is a technical challenge, and a key measure of the competence of the CTO, but is a little outside the scope of these articles. If you are non-technical how do you know the CTO is doing a good job? There is one key metric: technical debt is directly correlated with the speed that new features can be introduced. Large, complicated, messy systems can't be modified quickly, so features take a long time to build. That's what startups can move faster in the early days. A good CTO minimises this problem.
Search engine statistics: in our database of technology conferences we have 2,217 conferences, 6,141 speakers, 4,945 exhibitors, and 961 venues.
Marketing update: speakers newsletter: 5,809 subscribers, open rate 12pc; EventProfs newsletter: 487 subscribers, open rate of 37pc, and the podcast is at 49 downloads. One the feature requests we getting in from our early users is more automation for the social media activities that have to happen before, during, and after and event. Since we run our own events, the Dublin (last week's was a great one if you missed it) and London (this week) Eventprofs meetups, we have this need ourselves. It's a perfect case of 'eat your own dog food'. As we build out these features, I will, of course discuss them, and you'll be able to judge the impact for yourself.
- Richard Rodger is the founder of Voxgig. He is a former co-founder of Nearform, a technology consultancy firm based in Waterford