I’ve been CTO at TIBU Health for over five years now. When I started, I thought the transition from Senior Web and Mobile Developer to CTO would be mostly about technical leadership - making architecture decisions, reviewing code, mentoring engineers. I was wrong about that, and wrong in ways that were harder to correct than any technical mistake I’d made.

The hardest shifts weren’t technical. They were mental, emotional, and strategic. These are the ones no one prepared me for.

1. From “I build” to “We build”

The first version of my day as a new CTO was trying to stay deeply involved in everything being built. I wanted to be the one writing the hard code, making the tricky architecture calls, fixing the production fires. I told myself I was setting an example.

What I was actually doing was creating a bottleneck and signalling to the team that I didn’t trust them.

The shift that eventually happened: I started measuring my output differently. Not features shipped or bugs fixed personally, but team velocity. How many things got unblocked because of a decision I made? How much faster did we move after a hire I made? When I reframed it that way, conversations and decisions became real work - not interruptions to real work.

2. From solving problems to deciding which problems to solve

As a developer I was given a problem and expected to solve it. My job was execution, and good execution was the whole game.

As CTO, the harder skill is deciding which problems are worth solving at all. Early on I said yes to almost every feature request that came my way - from clinics, from the business team, from investors who had seen something at a conference. I thought saying yes was being helpful.

What I actually needed to do was develop a ruthless filter: Does this improve patient care or clinic operations directly? Can we ship a useful version in two weeks? Is this “must have” or “nice to have”? I probably say no now four times as often as I did in the first year. That has made the things I say yes to much more likely to actually ship and get used.

3. Technical depth to strategic breadth

I used to know our stack inside out. Now I lead a platform with more moving pieces than any one person can hold in their head, and I’ve had to accept that I’m not the deepest expert in everything anymore.

The adjustment was getting comfortable saying “I don’t know, but I know who to ask.” I stopped trying to win every technical argument and started building a network of people who could inform decisions I couldn’t make alone - advisors, peers at other companies, people who’d solved the same problems in different contexts.

What I’ve kept: enough technical literacy to call out bad assumptions, ask the right questions, and know when an estimate is off by a factor of three.

4. Maker’s schedule to manager’s schedule

I used to hate meeting-heavy days. I’d feel like I hadn’t done any real work. Some of that instinct is still correct - context switching is genuinely expensive and unfocused calendars kill output.

But somewhere along the way I realised that enabling eight engineers to work effectively is worth more than me coding alone. A 30-minute conversation that unblocks a senior engineer’s week is 30 minutes of the highest-leverage work I can do. I protect Tuesday mornings for focused work, and I accept that some days I won’t write a single line of code - and that’s a good day if the team shipped something important.

5. Technical excellence to business alignment

This one took the longest. I grew up as a developer who believed that doing things the right way technically was always worth the cost. Technical debt was failure. Shortcuts were professional embarrassment.

CTO-brain is different: the best solution is the one that delivers value at the right time. Technical debt is a tool, not a confession. Shipping a “good enough” feature that helps patients today has beaten waiting for a perfect version six months from now more times than I can count. The key is being intentional about what debt you’re taking on and keeping a register so it doesn’t quietly accumulate into something unmanageable.

6. From peer to leader

When you move from being part of the engineering team to leading it, some things shift that no one explicitly tells you about. You can’t vent about the business to your team the way you could when you were peers. You can’t show uncertainty in the same way. Some decisions you have to make without being able to fully explain the reasoning - personnel decisions especially.

Leadership is lonelier than I expected. The thing that helped most was finding other CTOs to talk to - people at similar-stage companies who were working through the same questions. That peer group has been more valuable than any management course.

7. Recruiting as a core skill

I spent about 5% of my time on hiring in year one. Now it’s closer to 25%. That shift happened because I finally understood the leverage: a great hire who’s still here in three years will compound in ways that are hard to fully account for. A bad hire - or a gap in the team that goes unfilled too long - costs far more than it looks like on paper.

I now treat hiring like product development. There are intake criteria, there’s a process, and there are retrospectives when things don’t work out. The goal is to get better at it systematically, not just to fill roles when they become urgent.

8. From executing the roadmap to setting the vision

As a developer, someone gave me a roadmap and my job was to execute it well and on time. The roadmap was an input.

Now the roadmap is an output. My job is to have a clear enough view of where the company needs to go - technically, organisationally, in terms of platform capability - that the team can make good decisions without needing to escalate everything. What does our infrastructure look like when we’re at 500k patients? What does the team composition look like? What technical capabilities do we need to build now so we’re not scrambling in two years?

Getting comfortable thinking 18-24 months out, while still being useful to the team working on this quarter, is probably the hardest ongoing balancing act in the role.

The hardest truth

The transition from developer to CTO isn’t a promotion - it’s a career change. You’re giving up a craft you were good at for a different craft that takes years to develop and where the feedback loops are much slower.

Some days I miss writing code. The immediate feedback of a thing that didn’t work and then does - there’s nothing quite like it. But when I see our platform serving 60,000+ patients, or watch an engineer I hired ship something that genuinely changes how a clinic works, that’s become the new version of that feeling. Different, not lesser.