Being a start-up CTO (or ‘how I fired myself enough times to finally become CTO’)

A little over 5 years ago, we started SuperAwesome. With just a few people in a small office in central London, we didn’t realise the scale of the challenge. To us, it was still a product problem and we didn’t truly grasp it was going to need an infrastructure solution (which ultimately led to the creation of the ‘kidtech’ sector). For context, today our kidtech is used by hundreds of companies (and thousands of apps) all over the world to enable safe engagement with over half a billion kids every month. This is 100x bigger than what we were thinking in the beginning.

It’s one challenge to be CTO in a ‘normal’ startup, it’s quite a separate challenge to also be at the forefront of a new category. I’ll post separately about the category challenges, but first, here’s my functional CTO story;

Stage 1 (2013) — Keep systems alive

My main responsibilities could be summarized easily in 2 priorities:

  1. Keep systems alive
  2. Refactor to make the first point easier

Normally the start your company is the only time you get to play with a nice and clean codebase (although that never lasts more than a few weeks anyways). However (very) early on we acquired a UK company which was basically an eBay for kids, allowing them to safely swap items. My main day-to-day activities were related to cleaning-up servers, moving to another hosting provider (our acquisition was actually running on physical hardware still) and trying to convince friends to help me rewrite part of the mess.

What did my day-to-day look like?

  1. System goes down
  2. Bring system back up
  3. Figure out how systems work
  4. Back to step 1

Stage 2 (still mostly 2013) — Hire all of the friends

Whenever I was able to get my focus away from keeping our systems alive, the next challenge was finding people to help me deal with everything. Today we have a fairly refined recruitment process (in fact, we hired a Head of Talent Acquisition recently), but at the time our recruitment process for developers was as simple as running through my LinkedIn and Facebook contact lists and calling up anyone I trusted enough to help. Instead of interviewing people, I was very much the one being interviewed. I needed to sell this new company idea to people who then needed to take a career gamble and join us. It was hard enough convincing my friends to join our (very) small team, I can only imagine how much harder that would have been if the people I was interviewing didn’t even know me.

Note: it was around this time I reached out to my wider network and find a mentor that could help me think through everything that was going on. This is when Barry Cranford (who ran “meet a mentor” events in London with his firm RecWorks) introduced me to Martijn Verburg — one of the most influential introductions I have ever had. Martijn has (and continues to) helped me think through so many challenges, some of which I am writing about today.

What did my day-to-day look like?

  1. System goes down
  2. Bring system back up
  3. Call all of the friends
  4. Back to step 1

Stage 3 (2014) — Early Product Management

When we had a few more people helping out, we started being able to actually build stuff. With building (versus maintaining), the questions of “what” and “why” became more and more important. Although everyone has opinions on those questions, actually getting people to agree on them and provide a clear rationale to your decision logic is a different ball game all together — and it meant learning a whole bunch of new skills I had never thought about: product management.

This is where I was introduced to Janna Bastow, a co-founder of ProdPad and one of the leaders of the main product manager meetup in London: ProductTank. Janna is a total badass at product management and she walked me through a list of about a million things I didn’t know about — enough to keep me learning for a very long time! One of the most helpful people I have ever met and most rewarding experience I have gone through as a professional.

What did my day-to-day look like?

  1. Refactor / extend systems to fix obvious flaws
  2. Call all of the friends
  3. Roam the meetup space in London to hear people talk about
    a. Product management
    b. Scaling early (very) stage companies
  4. Buy as many coffees or lunches for Martijn and Janna as they would let me

Stage 4 — Actual Product Management (2015)

Even though my own product management skills were nowhere near where they could/should be, the organisation was growing so fast that we needed more help keeping everything (& everyone) aligned so we hired some more product managers. At this point, we were lucky enough to be joined by some experienced people in other parts of the company (e.g. Max Bleyleben, then COO, now Managing Director). This is also when we hired our first full-time product manager. Suddenly I had Chris, who knew a lot more about product management than I did, reporting into me — another one of those massive learning experiences that forced me to double-down on scaling myself and figure out how to be helpful as he tried to teach us how to work differently.

Soon, one product manager became two, which became three, etc. and slowly but surely, we built-up the product organisation within SuperAwesome. Again, there were a lot of unique product development challenges because of the completely new space everyone was operating in. More on that in next post.

What did my day-to-day look like?

  1. Prioritize product development
  2. Help make key technical decisions
  3. Stakeholder management and company-wide communication around product development
  4. Roam the meetup space in London to hear people talk about
    a. Product management
    b. Building scalable companies

Stage 5 — Adding a Chief Architect (2016)

I was never the best developer in the company, but for a time was very aware of how applications should be built and what best practise looked like. Unfortunately (albeit for good reasons), that situation didn’t last very long either. As we hired more and more engineers and I personally spent more time scaling up on product management, I quickly lost touch with how we should be building our products from a technology perspective. This is where we created our first Chief Architect role, taking yet another one of the things I used to do off my plate. In reality, our new Chief Architect had been the de-facto expert on any technology we had worked with across the team for a long time before he took the title. I knew it was the right move as soon as we made the change as I immediately felt like an idiot for not having done it much sooner.

Note — it was around this time that another interesting thing happened: there were fewer meetups in London relevant to our stage of the business. Although many companies go through the very early stages, less and less make it through their first hurdles and so fewer meetups focussed on the particular challenges of scaling companies from 50 to 100 or 150 people. This meant I had to start looking for other avenues that would help me scale faster.

What did my day-to-day look like?

  1. Create & communicate company product vision & alignment
  2. Spend time with clients to inform product development
  3. Scale our hiring process across product & engineering
  4. Buy even more coffee for Martijn to help think through stuff

Stage 6 — Adding a Head of Engineering (2017)

My number one priority for a long time was to build out the team behind our products, which obviously meant spending a lot of time with people. However it’s hard to combine that with the demands of a rapidly growing company which also requires you to be on planes and in different countries much of the time. For this reason, last year we hired our first Head of Engineering. Once again, the moment they joined I scratched my head as to why we hadn’t hired this role much earlier (clearly a recurring theme). He quickly scaled up our processes, re-connected with the team (who, at this point, I was no longer able to sit down with as much as was really required) and showed me all that was wrong with the way we used to operate (and why it wouldn’t scale).

What did my day-to-day look like?

  1. Fly around the world (mostly the US) to spend time with clients
  2. Fly around some more to spend time with people in our various US offices
  3. Trying to maintain a clear product vision and direction across the team
  4. Coordinate large (mostly technical) strategic projects across the company

Stage 7 — Adding a Chief Product Officer (2018)

At the start of 2018 it was becoming pretty clear that I needed to make another transition. Five years in and we now have a comprehensive suite of products powering over 270 customers (pretty much every kids brand you’ve heard of) with teams dedicated to the ongoing development of each. Every product is almost a mini-company in its own right and the management and strategy of this existing stack needs complete focus. At the same time, much of my bandwidth was (and still is!) being taken up with high-level customer discussions, customer success planning and other strategic activities. So we decided to split out the roles of Chief Product Officer and CTO. After five years I finally get to be the CTO!

What did my day-to-day look like?

  1. Fly around the world (mostly the US) to spend time with clients
  2. Fly around some more to spend time with people in our various US offices
  3. Miserably failing at maintaining clear product vision and direction (bandwidth issues)
  4. Getting involved in the operations of way too many projects (because it was basically all product)

Stage 8 — Actually being a CTO (today)

At this point, all of my previous responsibilities are being handled by people way better placed to take those areas to new heights. Being a start-up CTO is not a defined role. If the company is scaling, your role is constantly changing and that means something entirely different every 6–12 months. This can be a real roller-coaster and is hard to take sometimes. Different people will have different reactions to each stage, as they have to relinquish ownership and control of various parts of the business in order to allow it to grow. If you’re going through anything similar to what I’ve been going through, I hope the above provides you at least some comfort that it’s normal and that there is always a next challenge to look at.

What does my day-to-day look like today?

  1. Fly around the world to spend time with strategic partners and clients
  2. Fly around some more to spend time with people in our various offices
  3. Spend time figuring out what the next set of core scaling challenges are for our product & engineering teams and pre-empt them wherever possible
  4. Interviewing & hiring key roles to scale the company

P.S. We are only at the start of our journey to make the internet a safer and better place for kids and have a long way to go. If you want to help us go faster, we’re hiring! (https://www.superawesome.tv/careers)

This story is published in Noteworthy, where thousands come every day to learn about the people & ideas shaping the products we love.

Follow our publication to see more product & design stories featured by the Journal team.

Helping people learn faster, remember more and get things done as CEO @MindstoneHQ. Previously CTO/CPO @GoSuperAwesome, acquired by Epic Games.