Episode 1: Thrown into the deep-end; where to start as a CTO
Two weeks in: learning that being CTO means leading, not coding
This article is episode 1 of a new series I call ‘Diary of a CTO’, where I document my new role as CTO in a Dutch EdTech/AI startup.
I have a new job. My first stint as CTO. At least that is how I see it. I have joined BeSmart Campus, a Dutch EdTech startup building AI-powered personal tutors for Dutch high school students. They have product market fit, some ambitious traction with Google and some media outlets, and a good first version of their platform. More importantly, they have ambitious visions on how to embed AI in high school education. It feels exciting. And somewhat surprisingly, to me at least, they asked me to lift their platform to the next level.
After a weird non-linear career as a product manager, hardware engineer, software developer, consultant, strategist, team lead, tech lead and a lot more, I feel I have now landed on the role I aimed for all those years. Combining a weird mix of skills in tech, strategy, product, sales, design and coding. And that is a skillset that has served me well. But never with any true accountability. Never in a role where I could combine all of them.
Accountability. As CTO. Terrifying. Exciting? Yes, also exciting. But the feeling of being totally under-prepared, overwhelmed, is definitely a bit intimidating.
I’m now not building advice. Or writing a bit of code. I’m responsible for everything. Platform, uptime, bugs, cloud infrastructure, devops, engineering vision, product vision, hiring, team building, feature roadmap. Server issues at 2AM, on me. Security and privacy guarantees, on me. Students waiting 2 minutes for a chat window that has frozen, on me.
And I would like to document the journey and chaos I have stepped into. Scary as fuck. But I have always so appreciated when people did this (Alex Blumberg for example, in podcast “Startup”, particularly season 1, but also the brilliant team behind Muse documenting their reflections in their startup “Metamuse”). A series I call “Diary of a CTO”. This is episode 1; where do you even start?
Where do you even start?
Day one. I’m proudly introduced by the founders as the new “head of platform”. They have been waiting for me, I can tell. A small team of 5 gives me a warm welcome. “Are you going to code?”, “We really need someone around here”. Cool intro. Yet I also immediately sense some confusion. Nobody has any idea of what my role will be. Some think I’m a developer, others a team lead. Yet there is no team. A manager with nothing to manage.
BeSmart Campus is an EdTech startup. They used to be an Ed-startup, the “Tech” came a bit later. They have successfully ‘digitised’ their teaching program they have used for years, into an AI assisted platform for high school students. The platform was built by an external agency. That means I’m the first ‘techie’ to come on board. This is a startup that is only just starting to form a team. We’re now with 5. And this startup is still very much finding its way. The platform has been built, and is now in use by a couple hundred users. Yet the platform is basically still the prototype.
Actual software engineering is new. I get the impression that everything around software engineering is new. And building and managing a dev and devops team in-house is very different from commissioning an agency to build a pre-designed prototype platform. It hits me that this team is in ‘startup’-mode. Their reflex is to think in new features, new functionality to build. Trying to find product-market fit. But to be honest, they have product-market fit. And ambitious sales targets. In a couple months we will be hosting many thousands of high school users, and their data. Is the platform ready for that?
The mindset needs to shift. This is turning from an experiment into a company. And it seems to have traction. Promises are being made to the students and schools, whether explicit or not. And promises have been made to investors. As if that is not enough, we’re caught in an AI hype bubble; a race to be the first product of its kind. A race to grab headlines. And I start to feel the pressure of all that. But most of all the pressure of what we (implicitly) promise to our customers and users. The promises about availability, uptime, loading times, new feature development, privacy assurances, security concerns. All the cool stuff, but also all the non-sexy stuff that everybody seems to forget when you think of software development.
It’s a trap
The first week has immediate pressure, we need to build this new feature, a big feature, in a month. Can’t be done. Two months maybe, but it’ll be rough. My reflex is to dive deep. Spend all my time designing and prototyping the feature. Act like an architect and analyst, iron out all the details, hand it over ready to develop. Classic consultant move.
By sunday I realise; this is exactly the wrong move. If I prototype the feature and hand the engineers the code, I’m not leading. I’m micromanaging. I’m telling them what to do, instead of making them shine. My job isn’t to be the smartest person in the room doing all the work. It’s to give the team the tools to do their thing.
So what did I actually do that first week? I introduced structure. The absolute bare minimum. Not the tools I’d want (Notion, Linear, proper project management). Just Slack and Github Projects. A kanban board. A way to communicate that isn’t email or WhatsApp. That’s it. That’s what I could get in place. Because I’m not here to build the perfect system on day one. I’m here to build the framework that lets us build the system. Start somewhere. Move forward.
The weight of it
That first weekend, sitting at home, the full weight of it hits me. Cloud issues are happening. Loading times are bad. And I have zero visibility into how severe it actually is. No idea about development velocity. No idea about the tech debt. No analytics. No insight into what users are doing or experiencing. But we’ve made promises. To hundreds of users already. With thousands more coming if sales delivers. Yet I also feel I have no tools to resolve this. Budget is reserved for feature dev, not cloud engineering. What to do?
And I’m sitting there with a budget. It’s expensive for the company. But for what needs to happen? It’s not enough. Not nearly. How do you make promises about features and stability when you have zero information about the problem? You don’t. You can’t.
Monday, I get sucked into ‘operations’. Response times for some reason can take up to 2 minutes, some issue with how rapidly a new container spins up in Google Cloud. I spend time setting up alerts, trying to diagnose the issue, carefully tweak some settings and hope for the best. The load times improve, the alerts quiet down. Two days are now ‘gone’. By wednesday I start pushing back with the founders. We need to map this. Systematically. We need a roadmap. Not just features. Engineering. Infrastructure. Debt. Stability. The unsexy stuff. Know where we stand, otherwise we can’t manage.
I call a friend, a good engineer, who happens to be available for a small projects mapping the platform issues. I feel relief. This is starting to become a manageable problem. It feels like things start to turn.
Mapping it out
We’re halfway through week 2 and things start to ramp up even more. Designs for the feature come in. The engineer spent a weekend building the API design. We’re moving faster than I expected. We’re starting to understand the architecture.
And I realise something. Let the team do what they’ve been doing. Though it is not yet an in-house team, and though development capacity is impossibly low, this is the team that has built the platform. They built this platform. They know the codebase. Let them build the feature. My job? Map the engineering roadmap. Figure out systematically what we don’t know. What the real problems are. What the debt looks like. What needs fixing now versus later. And do the strategic work. Recruitment. Team building. Vision setting.
Not fixing every bug. Not optimizing every query. Not diving into every config file. Building the framework for what needs to happen. That’s where I add value. Not as the best developer or the best cloud engineer. But as the person navigating the ship of compromise through rough waters. Technology is compromise. Every choice a trade-off. Speed versus stability. Features versus robustness. Building for today versus building for tomorrow. My job is to chart that course. To mark the territory. To help everyone understand the waters we’re in and where we’re heading. That’s what I’m good at. Placing technology in context. Strategy, business, users, constraints. Naming the trade-offs clearly. Helping everyone understand what we’re choosing and what we’re giving up.
Six weeks
End of week two. Founders call. They have decided to launch the new feature in 6 weeks, with a large stunt. Thousands of expected users. Massive scale jump up from the few hundred. My reaction? A bit of panic, but immediately also excitement. Opportunity.
The team builds the feature. They’re already doing it. I map the engineering debt, start fixing critical issues. We setup recruitment in parallel. By launch, hopefully it comes together. Hopefully the platform handles it. And the momentum? The headlines? That could help us recruit. That helps us raise money. That helps us leap ahead. Sprint to early March. If we pull it off, it changes everything.
What’s the actual job
Here’s what I have to remind myself. I was hired as CTO. Head of Platform. Not as a developer. Not as a DevOps engineer. Not as the person who fixes everything. My value is translation. Context. Strategic frameworks. Helping brilliant people understand the landscape and make good decisions. That’s what I’m good at. That’s what they need.
So yes, I’ll dive into cloud configs when necessary. I’ll fix loading times when users are suffering. I’ll prototype when it unblocks the team. But the actual job? Building the vision. Making sure we’re moving in the right direction. Setting up structures that let everyone do their best work. That’s it. Now let’s see if I can actually do it.