The largest change is not the title. It is the unit of work.
As an engineer, the unit is usually a system: a service, a flow, a decision that can be reviewed in a pull request. As a CTO, the unit is the organisation that has to keep making those decisions after you have left the room.
That sounds abstract. It becomes concrete the first time a correct architecture fails because the team that owns it cannot see the state it needs, or because two teams have different definitions of “done.”
Architecture becomes an organisational decision
Every serious technical choice allocates ownership. Who can change the ledger? Who can add a payment method? Who is allowed to be uncertain about a transaction, and for how long?
If those questions are left implicit, they will be answered by whoever is fastest, or by whoever is closest to the incident. That is a decision too. It is just an accidental one.
I now spend more time on the interfaces between teams than on the interfaces between services. The two are related. A clean service boundary that nobody owns is not a clean boundary.
You still need to be able to read the work
Moving away from day-to-day implementation does not mean becoming vague. The opposite is more useful. You need to stay close enough to the system that you can tell the difference between a real constraint and a habit.
The risk is not that a CTO writes too little code. The risk is that they lose the ability to see when a proposal is solving the wrong problem. In a payments company, that often looks like adding another layer of abstraction over a rail that is still poorly understood. In an AI product, it looks like adding another prompt instead of deciding what the system is allowed to do when it is unsure.
The job is to keep those distinctions visible.
Research and execution pull in different directions
I work in both. Research rewards precision about a narrow question. A company rewards shipping something that is good enough to operate.
The useful overlap is not “apply research to the product” as a slogan. It is a habit of stating what you believe, what would change your mind, and what the system should do if you are wrong. That habit is as valuable in a training run as it is in a payment incident.
The other overlap is more personal. I do not think of research as a departure from building. I think of it as another place where reliability is the actual subject, rather than a quality attribute added at the end.
What I try to keep
The temptation, once you are responsible for a technology organisation, is to speak only in themes: scale, culture, velocity. Those words can be true and still hide the work.
I try to keep the description closer to the ground. What are we building? What is uncertain? Who owns the uncertain part? What will we do when the third party fails, or the model is wrong, or the market we just entered does not behave like the last one?
Those are engineering questions. They remain the job, even when you are no longer the person writing the function.