CTO or lead developer: who decides when business and technology collide?

Who, in your company, decides when a technical requirement collides with a commercial deadline? If you hesitate before answering, you have found the question this article addresses, and it has almost nothing to do with how good your developers are.

A classic case: the founder has just promoted his best developer. New title: CTO. Nothing else has changed. Priorities, budget and hiring are still decided in the founder’s office. The new CTO codes as much as before, with the added vague expectation that he will “step back and see the big picture”. In a year, one of the two will be disappointed. Often both.

A lead developer helps the team deliver within agreed priorities and constraints. A CTO helps set those priorities and constraints with you, and answers for their consequences. Naming a CTO without giving them a mandate does not create a role, it renames a lead developer. I made that move at Ipedis, and that is where you see what the title does not say.

A table, because it replaces a page.

Responsibility	Lead developer	CTO
Architecture	Evolves the team’s code within established choices	Settles the overall architecture and its trade-offs with budget, deadlines and risk
Roadmap	Breaks down, estimates and organises the planned work	Builds the technical roadmap with leadership and product
Hiring	Takes part in technical interviews and onboarding	Defines roles, the hiring plan and the team’s structure
Leadership	Reports progress and flags blockers	Takes part in decisions and translates technology into cost, time and risk
Code	A large share of their time	A share that shrinks as the team grows

Read the right-hand column. None of those decisions is a code decision. A lead developer decides how to deliver a feature. A CTO decides, with you, whether to deliver it now, with which team and at the cost of which risk. If nobody in your company makes those decisions, you do not have a CTO, whatever the org chart says.

First, the founder who wants to approve everything. He named a CTO because investors or clients ask for one, then kept product, budget and hiring for himself. Not out of malice: he built the company, and every technical decision still feels like his. His CTO is a lead developer with an expensive title and a growing frustration.

Next, the CTO measured in tickets. The larger the team, the more of their time goes into decisions, hiring and conversations with you; blaming them for coding less is blaming them for doing their job.

Finally, the mirror of the first case: the lead developer who is handed the roadmap, hiring and leadership, without the power to decide. They carry choices they cannot settle, and it is the surest way to lose a good lead developer.

Titles, for their part, prove nothing. At Gridky, I was Head of Engineering. During the feature freeze, the calendar belonged to the CTO and the CEO, the work belonged to the team. Nobody looked at titles. Everyone knew who decided what.

At Ipedis, I was lead developer of a team of five. I had built the V1 of PubliSpeak from nothing, and that was precisely the problem: everything went through me. When the team began to grow, I had to choose between staying its best developer and becoming the person who decides where it goes. At twenty-five, you cannot be both.

That move shifted my impact. It no longer came from code, but from understanding the business. The day I started talking about revenue, risk and growth with leadership, technology stopped being an end in itself and became a lever. Meanwhile, PubliSpeak became a platform of ten microservices without service interruption, and the team went from 5 to 25 people. How we hired and organised is in Growing an engineering team.

Two conditions made that move real for me. A mandate, first: taking part in leadership decisions, not being informed afterwards. Letting go, second: accepting that others now make code decisions that used to be mine, and sometimes make them differently from how I would have. The second is the harder one. A lead developer who becomes CTO without letting go of the code does not change role, they take on more than they can carry.

If you are preparing this move for someone, write down what they decide with you, what they settle with product, and what the developers decide without them. Then hand part of their code to someone else. Success shows in one place only: the team decides and ships without waiting for them.

A lead developer is enough when the decisions that commit the company already have an owner. A technical co-founder who owns architecture and the roadmap, a stable product, a single team, little hiring planned: do not hire a CTO. Give your lead developer the name of the person who decides when a technical requirement collides with a commercial deadline. Without that name, they will decide by default, or let it rot.

They are no longer enough when technical decisions commit the company beyond one team and nobody owns them: several teams on one architecture, a hiring plan to build, clients asking for commitments, security constraints to enforce. The signal is not the missing title, it is the queue of pending trade-offs. A founder who decides the architecture may well be filling that role. Look at how decisions actually get made before concluding that someone is missing.

The “Do you need a CTO?” assessment distinguishes autonomy, internal action and several forms of support. And if your question is whether or not to open a position, the article Should you hire a CTO deals with it.

Between a lead developer on their own and a full-time CTO there is a third form, and it is the one I practise. A fractional CTO takes the leadership decisions agreed for the engagement, overall architecture, roadmap, hiring plan, while the lead developer keeps the team and delivery. My rate is €550 a day excluding VAT, from a few days a month to a weekly presence; what that adds up to as a budget is in the article on outsourced CTO rates.

The format prepares what comes next. The lead developer sees how decisions get made and gradually takes back what they can carry. They may become your CTO, or help define the role before you hire. A lasting split between a lead developer and a fractional CTO may also fit: creating a full-time role is not the goal in itself. How this kind of collaboration is organised is in the article on the freelance CTO.

Choosing between a CTO and a lead developer is not a question of level, it is a question of decisions waiting for an owner. If you cannot name them, do not name anyone CTO: all you would have changed is a line on the org chart. The page on engineering team organisation takes the question further on the structure side.