From Developer to CTO: What Nobody Tells You

The jump from developer to CTO is the most misunderstood career transition in tech. People assume it is about becoming a better engineer. It is not. It is about becoming a different kind of professional entirely.

I have made this transition myself, first as CTO at OneRagtime and then through various leadership roles. I now teach a module called "Developer to CTO" at Harbour.Space University in Barcelona. Every cohort, I watch students confront the same realizations I had years ago.

Here is what nobody tells you about this transition.

Your Best Skill Becomes Your Biggest Liability

As a developer, you got promoted because you wrote great code. You solved hard problems. You shipped features. Your value was directly tied to your output.

As a CTO, writing code is usually the wrong use of your time. Not because coding is beneath you, but because your job has changed. You are no longer responsible for writing the best code. You are responsible for making sure the best code gets written.

I struggled with this at OneRagtime. In the early days, I was the one building everything: the Platform, the Core, the Deepdive. I was deep in the Django codebase, writing Python, deploying to Docker Swarm. And it felt good because it was familiar. I knew I was being productive because I could measure it in commits and features.

But as the team grew, every hour I spent coding was an hour I was not spending on the things only I could do: defining technical direction, aligning the engineering work with the business strategy, or unblocking people who were stuck.

The hardest day in my career was the day I realized I needed to close my IDE and start spending most of my time in meetings, documents, and one-on-ones. It felt like a demotion. It took me months to accept that this was the actual job.

The Identity Crisis Is Real

Developers have a clear identity. You write code. You solve technical problems. You have a craft, and you improve at it over time. There is a satisfaction to it that is hard to replicate.

When you become a CTO, that identity dissolves. Your days are filled with activities that do not feel like "real work." You are in meetings about hiring. You are reviewing budgets. You are explaining technical constraints to investors. You are mediating disagreements between team members. You are writing documents that nobody will read.

At the end of a typical day as CTO at OneRagtime, I often could not point to a single concrete thing I had "built." No code, no architecture, no deployed feature. Just conversations, decisions, and plans. It took time to understand that those conversations and decisions were the product of my work.

I tell my students at Harbour.Space: if you measure your productivity by what you build with your hands, leadership will feel deeply unsatisfying. You need to learn to measure it by what your team builds instead.

What to Stop Doing

Here is a concrete list of things I had to stop doing when I moved from developer to CTO. This list would have saved me a year of mistakes.

Stop being the first to answer technical questions. When someone on your team asks how to solve a problem, your instinct is to answer immediately. Resist it. Ask them what they think first. If you always have the answer, your team never develops the ability to find answers themselves.

Stop reviewing every pull request. You do not need to approve every line of code. Define coding standards, set up automated checks, and trust your senior developers to review each other's work. Your review should be reserved for architectural decisions, not implementation details.

Stop optimizing for the best technical solution. The best technical solution is not always the right one. Sometimes the "good enough" solution that ships this week is better than the perfect one that ships next month. Your job is to make that call, and it requires understanding the business context, not just the technical one.

Stop working alone. As a developer, you could put on headphones and disappear into a problem for hours. As a CTO, isolation is dangerous. The decisions you make affect the entire team. If you make them without input, you will make mistakes that could have been easily avoided.

What to Start Doing

Start delegating the work you are best at. This is counterintuitive. You want to delegate the work you dislike and keep the interesting stuff. Do the opposite. Delegate the interesting technical work to your team. Keep the organizational, strategic, and people work for yourself. That is where you add the most value now.

Start communicating technical decisions in business terms. When I proposed architectural changes at OneRagtime, I stopped framing them as technical improvements. Instead: "This change will let us ship the investor dashboard two weeks faster" or "This migration will reduce our infrastructure costs by 30%." Business stakeholders do not care about clean architecture. They care about speed and cost.

Start having one-on-ones. Regular, scheduled conversations with every person on your team. Not status updates. Actual conversations about how they are doing, what is frustrating them, and what they want to learn. At Consentio, my one-on-ones with each of my ten engineers are the most important meetings on my calendar. This is where I learn what is really happening, not from Jira boards or standups.

Start saying "I do not know." As a developer, admitting you do not know something feels like incompetence. As a CTO, it is essential. You cannot be an expert in everything your team does. Saying "I do not know, but let me find out" or "I do not know, what do you think?" builds more trust than pretending you have all the answers.

The Skills Nobody Teaches

There are skills you need as a CTO that no engineering program covers.

Hiring. Reading resumes, conducting interviews, evaluating cultural fit, selling your company to candidates. I was terrible at this initially. I hired people who were technically strong but could not collaborate. It took me several painful experiences to learn that a great developer who cannot work with others is worse than a good developer who can.

Conflict resolution. Technical teams disagree. About architecture, about priorities, about code style. Your job is to resolve these disagreements in a way that maintains respect and keeps the team moving. This is harder than any technical problem I have faced.

Budget management. Understanding infrastructure costs, planning headcount, forecasting engineering expenses. At OneRagtime, I had to justify every engineering hire to investors. At Consentio, I manage budgets that directly affect the company's profitability. Nobody taught me this. I learned it by making mistakes.

Stakeholder management. Translating between engineering reality and business expectations. When a product manager asks for a feature "by Friday," your job is to explain what is realistic without being dismissive. When the CEO asks why something is taking so long, you need to translate technical complexity into terms they can understand and act on.

The Transition Takes Longer Than You Think

At Harbour.Space, I give students a timeline: expect the transition from developer to CTO to take two to three years before you feel fully comfortable. Not two to three months. Years.

During that time, you will feel like an impostor. You will miss coding. You will question whether you made the right choice. You will have days where you want to throw away the management books and just open your laptop and write code.

That is normal. Every CTO I respect has gone through it. The ones who made it to the other side did so by accepting that the discomfort is part of the process, not a sign that something is wrong.

Is It Worth It?

I get asked this by students every cohort. My answer is always the same: it depends on what drives you.

If you are driven by the craft of writing code, by the elegance of a well-designed function, by the satisfaction of solving a hard technical problem with your own hands, then stay an individual contributor. There is nothing wrong with that. Senior and staff engineers have an enormous impact.

If you are driven by building things that matter, by seeing a product succeed in the market, by watching a team grow and improve, then the CTO path is worth the discomfort. The leverage is different. You are no longer building the thing. You are building the team that builds the thing. And when it works, the satisfaction is profound.

That is what I try to convey at Harbour.Space. Not that everyone should become a CTO. But that those who choose to should know what they are actually signing up for.