The reality of being a CTO

Estimated reading time: 10 minutes

Key takeaways

• There’s no single CTO job. The title stretches from a founder still writing code to a board-facing executive who hasn’t opened an editor in years.
• Executive first, technologist second. You own the link between technology and commercial outcomes. The work is mostly outward and sideways, not down into the code.
• In 2026 the bar rises both ways. More strategic and more hands-on.

---

In almost every engineering role, your peers are other engineers. Whether you’re a junior, a staff engineer, or an engineering manager, you sit among people who do a version of what you do, and you lean on them constantly to check your thinking and share the load. The first thing that surprised me about being a CTO is that this stops being true.

My team isn’t the engineering team. My team is the other functional leaders, the CEO, the CFO, the people running sales and product and marketing, and together we operate the company. That group looks nothing like a team of engineers, and learning to belong to it is most of the job.

So when someone asks what I do all day, the answer is that it varies enormously. One hour I’m in an architectural review doing a deep dive on a project, the next I’m with finance on budget projections, and later I’m down in our hosting costs or pulled into an incident. It’s the whole breadth of a company, viewed from the technology side, and little of it looks like the job I had on the way up.

There is no single version of the CTO role

The reason the CTO role is so badly understood from the outside is that it isn’t one role. At a twelve-person startup, the CTO is usually the founder who still writes most of the code. At a large enterprise, they may be a board-facing technology executive who hasn’t shipped a commit in years.

Both are doing the job correctly, because the job is to be the technical leader the company needs at its particular stage, and stages differ wildly.

The larger the company, the more the role tilts to board management, capital allocation, and leading through other leaders rather than touching the code. Nearer the startup end it tilts back the other way. Yet, wherever you are on that line, the accountability is the same.

So what is my own role like? Well, Nordhealth is a public company, but in size and trajectory we’re closer to a scale-up. I run my role like a founder CTO who stays deep in the product and the technical decisions rather than watching from above.

As CTO, you own the relationship between the company’s technology and its commercial future, and you answer for it to the CEO and the board. Camille Fournier’s shorthand for this is that a CTO is an executive first and a technologist second, and it’s the part people sometimes miss when they picture the role as the best engineer in the building at the top of a technical ladder. It isn’t like that at all.

However, what that accountability does to me is the opposite of what most people expect. Being answerable for everything makes me want to be closer to the work, not further from it, and I’ve built the role so that I can be. I want a truth-seeking organization, and the truest thing in a technology company is the code we are actually writing, so I stay near it.

That’s what our Wednesday reviews are for, and it’s why I sit in every project’s Slack channel and use AI to interrogate our own codebase and logs, asking why something is slow or how it could be structured better. Staying technical is how I know the quality bar is holding and that we’re taking the right approach, and it keeps a direct line open between me and every engineer, which I think is extremely healthy.

Most of the week is other people

As the job is executive, most of it happens in conversation with people who aren’t engineers. I report to the CEO, so I talk to him constantly, and I speak to our VP of product every day, often every few hours. C-suite peers in sales, marketing, and onboarding take up real time, as do customers, both resolving their issues and understanding where they’re heading next. My own engineering leadership group is just one meeting in that week, not the center of it.

I try to give every week a deliberate shape, because left alone it would fill entirely with meetings. We run two no-meeting days for R&D, Tuesday and Thursday, which protect two days of deep focus for the team and for me.

Monday holds my one-to-ones and our senior leadership meeting, which reliably generates a long list of things to do. Wednesday is project reviews, where the CEO, the VP of product, and I sit down with the people running our projects, go through the latest build, give design critique, and unblock the decisions that are stuck.

On Friday I write to the whole department, because at this scale writing is how you reach more people than you can speak to.

This structure helps me greatly in dealing with context switching and the high workload, as I always know I have two focus days to get my work done, so I don’t stress too much if I am continually interrupted on the others.

The skill nobody trained me for

Your technical skills are assumed, which is why you likely end up a CTO in the first place. However, the skill I had to learn, and the one I’d most encourage anyone eyeing the role to take seriously, is reading a company’s finances.

What it teaches you is to see the true cost of a decision rather than its sticker price. The uncomfortable part is that the best engineering answer and the best financial answer often point in different directions. A large part of the job is being the person responsible for finding the right tradeoff between them and for explaining that call to a room that might have leaned the other way.

Understanding what things cost, or what they could cost in the future, is highly underrated in engineering, partly because organizations are often structured so that engineers don’t always see the real dollar cost of their decisions.

Take a decision of ours that looks purely technical on the surface, and one we got wrong the first time. We put our monitoring onto hosted Grafana Cloud on an early estimate of our usage, and the desirable situation of not needing to self-host.

As we grew and got a clearer picture of how much we actually wanted to store, that pricing model stopped scaling for us and the cost of staying on it was heading somewhere we couldn’t justify. So we’re now moving onto a version we host and run ourselves, building it out to switch over when the contract ends.

The engineer’s instinct is to keep paying the vendor and leave the implementing team on product work, but the finance question is what a choice like that really costs on the trajectory you are actually on, not the one you modeled at the start.

Running it ourselves carries a real cost too, in engineering time to build and operate, so the job is to weigh the two honestly with a long-term mindset rather than reach for whichever is less work this quarter, and kick the rest into the long grass. What made the decision for us was complete financial control and no surprises, because self-hosting lets us decide how much we keep in fast recent storage versus cheap long-term archive, so the cost curve is ours to shape as we continually grow.

This anecdote frames nicely what the role asks of you: to stop being the person with the best technical answer and become a company operator who happens to own the technology. You can practice this at any layer of an organization. Long before anyone hands you budget authority, the way you win a technical argument is increasingly to make it in the language of cost and commitment to the company rather than technical elegance. It’s worth getting ahead with that thinking.

How AI is changing the CTO job

AI has changed the mandate more than anything else in the last few years. I’ve pushed the whole department to use it every day, and most of our code is now generated rather than written by hand. We’re currently mostly a Claude Code shop, followed by Cursor and Codex respectively.

However, the bigger shift has been across the whole company, where we’re teaching everyone, not just the engineers, to automate the work around their work, and I’ve had a big input into that.

Although the industry is still struggling to measure the gains of AI accurately, what matters to me is the consequence, which is already concrete. We no longer know the upper bound of what a single engineer can produce, and we are on an exploratory journey to see how much we can do to a high level of quality with the tools that we have available to us.

The same finance lens changes how I think about hiring. A new engineer is never just a salary line. Once you count everything around the role it is a commitment several times that figure, slow to reverse, and you are making it against last year’s assumptions about how much one person can produce, exactly when AI is rewriting those assumptions.

So this year I agreed to a different default with our executive team and our engineering leads. We fixed the number of seats at an unmoving figure and set out to discover how productive and efficient we can be with the people we already have. If someone leaves, we sit with the empty seat for around three months before we will even open the conversation about a backfill, and we only hire when it genuinely hurts.

The point was never the money it saves; a hard limit is the only thing I’ve found that reliably forces the better behavior which is to work out whether to cut the scope or find a smarter way to solve a problem rather than reaching for more people by default.

Where an unconstrained company would hire to chase everything at once, we have to keep a deliberate lid on how many new features and how many new markets we take on, and say no to good ideas we would otherwise build. The constraint makes the organization think harder rather than just spend more, and I think it is very good practice to do so.

The part that’s harder than it looks

The hardest thing about the job is the thing I started with. You are the top of the engineering tree, which means you no longer have a natural team of engineers around you to lean on.

The decisions that weigh the most, the ones about people and money, are exactly the ones you cannot always talk through with the people they affect, and no peer in the building is in your exact seat with your exact problems.

The only way I’ve found to handle it is to build a web of professional people you trust, a few inside the company and most well outside it, so the hardest calls get tested somewhere before you make them alone.

Getting into a CTO role is hard unless you start your own company, and it’s about far more than being an excellent technologist. You have to want to be a company operator. If that’s the path you want, be as curious about business and your industry as you ever were about technology, because that’s the half of the job nobody advertises.

I’ve written separately about the winding route I took to get here, what I didn’t expect is how much it would change what motivates me. These days I care more about growing a great company than about only building a great product.