Promote engineer or hire a fractional CTO for your team

What problem are you trying to fix

If you're deciding whether to promote your strongest engineer or bring in a fractional CTO, start with the work, not the title. A new title can feel like progress while the same problems keep eating time every week.

Name the problem in plain language. "Engineering feels slow" is too vague to help. "No one owns technical priorities," "senior candidates sit in limbo," or "the founder still makes every hard call" points to a real gap.

In most teams, the pressure shows up in a few obvious places: releases slip because nobody decides scope fast enough, hiring stalls because no one can judge senior engineers well, the founder becomes the fallback for architecture and incidents, or the team ships code without a clear direction for the next stage.

Those are different problems. One company needs tighter day-to-day control. Another needs someone to build a hiring process and coach the team. A third needs broader technical judgment because the product changed, the customer base changed, or the company suddenly has more moving parts.

Look back six months. That usually tells you more than the org chart. Maybe the team grew from four engineers to ten. Maybe larger customers now ask for security reviews, uptime targets, and a clearer roadmap. Maybe the founder got pulled into sales and can no longer act as the unofficial CTO between meetings.

That context matters. If the work became broader and more cross-functional, your strongest engineer may not be the missing piece. They may be excellent at shipping and still have no interest in hiring, planning, or making business calls with incomplete information.

A promotion makes sense when the person already does much of the job, wants the rest of it, and the team accepts them in that role. A fractional CTO makes sense when you need senior judgment now but do not need a full-time executive yet. If you cannot say which problem you need solved first, wait before you change titles.

What changes when a strong engineer becomes CTO

A great engineer solves hard problems with code. A CTO spends far less time coding and far more time making decisions that affect everyone else.

That shift is bigger than many founders expect. The person who used to ship the hardest feature may now spend the day deciding what not to build, which hire to make first, or whether the team can afford another month of cleanup before launch.

The work changes in a few important ways. The CTO has to make tradeoffs across product, hiring, budget, and delivery. They set technical standards for the whole team. They settle conflicts when different groups want different things. And when a decision hurts speed, quality, or cost, they own that outcome.

A strong engineer often looks for the best technical answer. A CTO often has to pick the least bad business answer. Sometimes that means shipping with known flaws because sales needs a date. Sometimes it means saying no to a feature the founder loves because the team will spend six weeks supporting it.

Standards become their job too. Code review depth, testing rules, release checks, incident response, and architecture discipline stop being personal habits. They become team habits. If the new CTO stays vague, every engineer fills the gap with their own version of "good enough." That gets messy fast.

Conflict handling changes as well. Product wants speed. Engineering wants time. Sales wants promises. Support wants fewer fires. The CTO has to hear all of it, make a call, and explain the call without dragging the company into endless debate.

Picture a startup with seven engineers. The strongest engineer used to unblock everyone by jumping into the hardest ticket. After the promotion, that same person may spend the morning in roadmap meetings, the afternoon interviewing candidates, and the evening deciding whether to cut cloud costs or keep extra capacity for a shaky release. If they keep acting like the top individual contributor, nobody owns those calls.

That is why this choice is rarely about tenure or raw coding skill. It is about judgment, clarity, and whether the person can carry decision load every week.

Check the decision load first

Teams rarely get stuck because nobody can code. They get stuck because too many decisions wait on one person, or because nobody owns them at all.

Before you promote anyone, track the decisions that slow work down across product, engineering, design, support, and operations. Do it for a week or two. Write down every decision that blocked progress for more than a day.

You will probably see the same patterns. Product changes wait for the founder. Incidents drag on because nobody knows who has authority. Vendor choices bounce between people for weeks. Hiring decisions stall because no one feels confident making the final call. Architecture changes sit open because they affect more than one team and no one wants the risk.

This exercise tells you where the real load lives. If the founder still makes the final call most of the time, you do not just have a leadership gap. You have founder dependence. That matters because a new CTO title will not help much if the founder still owns the actual authority.

Roadmap changes, production incidents, and vendor decisions usually reveal the problem fastest. If the roadmap shifts every week because sales, product, and engineering pull in different directions, someone needs to own tradeoffs. If incidents drag on because engineers wait for approval, someone needs clear authority. If vendor choices stay open for months, nobody owns cost, risk, or timing.

The most useful finding is often the awkward one: a cluster of decisions that nobody clearly owns. That gap might sit between engineering and product, between infrastructure and security, or between the founder and the team. A promoted engineer might grow into that space. Or the company may need a fractional CTO who has already handled hiring, architecture, operations, and founder communication.

Once you map the real decision load, the choice gets simpler. You stop guessing based on loyalty or seniority and start looking at the work that needs an owner.

Look at hiring gaps, not just coding skill

A strong engineer can ship fast and still be the wrong answer for your biggest problem. If the team keeps missing hires, the issue often is not code quality. Nobody owns recruiting, leveling, coaching, and team design.

Start with the roles you should have filled by now. Maybe you needed a senior backend engineer three months ago. Maybe QA, platform work, or mobile keeps falling back to the founder or one tired engineer. That is a hiring gap, not a coding gap.

Then ask who can actually hire for those roles. Good interviews need more than technical questions. Someone has to define what good looks like, spot weak answers, sell the role to strong candidates, and make a clear yes or no decision. Many strong engineers can judge code. Fewer can run a full hiring loop and close a candidate who has other offers.

Coaching matters just as much. The person leading engineering needs to raise the floor of the team, not just be the smartest person in the room. If your top engineer writes clean systems but avoids feedback, skips mentoring, or gets impatient with weaker teammates, promotion will not fix the team.

A few questions cut through the noise. Which roles stay open because nobody shaped them clearly? Who can run interviews without the founder joining every call? Who can coach a mid-level engineer into a solid senior over six months? Who can plan the team you will need next year, not just the next sprint?

If nobody inside has done this before, outside help can make sense. This is the kind of work Oleg Sotnikov does at oleg.is as a fractional CTO and startup advisor, especially for small teams that need better hiring structure, clearer role design, and less founder pull on every technical decision.

Measure founder dependence honestly

A lot of teams think they have a leadership gap when they really have a founder bottleneck. The founder still approves the risky calls, explains tradeoffs to customers, and settles internal debates. If that stays true after a promotion, the new title will not change much.

Start with a simple review of the last month. Which decisions stopped work until the founder replied? Scope changes for large customers, hiring decisions for senior engineers, deadline tradeoffs when quality slipped, pricing promises tied to product work, and production incidents that needed a business call usually end up on the list.

That list tells you more than the org chart. If the founder owns most of those calls, the company depends on one person for both business judgment and technical direction.

Also watch who explains tradeoffs outside the engineering team. When a client asks, "Can you ship this by next week if we drop X?" who answers with confidence? When an investor asks why the roadmap moved, who connects product, hiring, and delivery in plain language? Strong engineers often know the technical side, but they may not want to carry those conversations yet.

Then test the team without the founder in the room. Use a real week, not a thought experiment. If the founder steps away, do projects keep moving, or do the same questions go back upstairs? "Can we promise this?" "Should we hire now?" "Do we accept this shortcut?" Those repeated escalations show where authority still lives.

A small example makes the issue obvious. A founder promotes the most trusted engineer to CTO, but sales calls still need the founder, enterprise prospects still ask the founder for architecture answers, and hiring decisions still wait for founder approval. That is not a handoff. It is founder dependence with a new title.

If your real goal is to reduce founder dependence quickly, a fractional CTO may solve the problem better than an internal promotion.

Use a simple decision process

This choice gets easier when you shrink the time frame. Focus on the next 12 months, not the next five years. You are not choosing a title for life. You are choosing who can handle the work your company is about to create.

A simple scoring process helps:

1. List what the company must ship, fix, hire for, and stabilize over the next year. Include product deadlines, team growth, architecture changes, major customer asks, and problem areas like security, reliability, or delivery speed.
2. Rate your internal candidate on people management, planning, and judgment. Use a simple scale from 1 to 5. Coding skill matters, but it should not carry the whole decision.
3. Write down the gaps you cannot leave open for another year. Be direct. Maybe nobody can hire senior engineers well. Maybe no one owns architecture tradeoffs. Maybe the founder still makes every hard technical call.
4. Compare real options, not fantasy ones. Look at a full-time executive hire and a fractional CTO side by side. Compare cost, time to start, scope, and how much founder time each option actually frees up.
5. Set a review date before you decide. Ninety days works for a trial promotion. Six months works for outside support or a bigger org change.

This process gets sharper when you add names and numbers. If your internal candidate scores high on judgment but weak on hiring and planning, the answer may be a supported promotion rather than a clean yes or no. They can lead engineering while outside help covers the missing parts.

That is often the practical case for a fractional CTO. You get senior coverage in architecture, hiring, and infrastructure without rushing into a full-time executive hire. For a small team, that can lower founder dependence and buy time for a better long-term choice.

The review date matters more than most founders think. It turns vague hope into a test. Did planning improve? Did the founder step out of daily technical decisions? Did the team close the gaps you named at the start? If not, change course early.

A simple startup example

Picture a 12-person SaaS team with one standout engineer. She writes the hardest parts of the product, other engineers trust her judgment, and she usually spots problems before anyone else. On paper, promoting her looks obvious.

But the founder still drives priorities, joins every hard customer call, and steps into every messy technical choice. When a release slips, the founder decides what gets cut. When the team needs a new backend hire, the founder runs the interview. When product and engineering disagree, everyone waits for the founder.

A promotion helps some of this. The new CTO can raise code quality, tighten reviews, and give the team a clearer technical direction. That part is real. But the weak spots often stay in place.

Hiring stays thin because the new CTO has never built a hiring loop. Planning stays reactive because the founder still owns the roadmap. Cross-team decisions stay slow because nobody has set clear rules for who decides what. The company gets a stronger engineering lead, but not always the executive coverage it thought it was buying.

Now change one part of the story. The company brings in a fractional CTO for a few days each month. That person sets a planning rhythm, fixes the hiring process, and takes some tradeoff decisions off the founder's plate. The standout engineer keeps leading the codebase and grows into management step by step instead of getting dropped into a job that mixes architecture, hiring, budgeting, and team design.

That setup usually fits a team in transition. It covers the gaps while the company grows, and it lowers founder dependence without burning out the strongest engineer. Coding strength and executive range are not the same job.

Mistakes founders make in this choice

One common mistake is treating loyalty as proof of executive fit. The first engineer, the longest-serving engineer, or the calm person during outages often earns a lot of trust. That matters, but it does not tell you whether they can set direction, make hiring calls, handle conflict, and push back on the founder when needed.

Founders often do this because they want to reward someone without having a harder conversation about role fit. The result is awkward. The company gets a new CTO title, but nobody can say what actually changed except the org chart.

Another mistake is leaving the same coding load in place after the title change. A strong engineer can write code all day or lead the team well. Doing both for long usually fails. Meetings multiply. Hiring takes time. Product tradeoffs pile up. Incidents still happen. Soon the new CTO works nights to keep up, and the team still lacks clear direction.

Founders also tend to bundle several separate problems into one role. They say they need a CTO, but what they really need is a hiring plan, better technical planning, or less founder dependence. If you hand all of that to one newly promoted engineer, you set them up to disappoint you.

Waiting too long is another expensive mistake. Teams often delay this call until someone looks exhausted, deadlines slip, and the founder has joined every major technical decision. By then, the problem is bigger than a title change. Burnout has already shaped team behavior. Good engineers stop taking ownership because they expect the founder to step in anyway.

A simple example shows how this goes wrong. A founder promotes their best backend engineer after a rough release cycle. Three months later, that engineer still owns the hardest services, still reviews half the pull requests, and now also runs hiring and planning. Nothing gets proper attention. The founder decides the promotion "didn't work," when the real issue was role design.

The safer approach is more honest. Define the job that needs doing right now. If the company needs day-to-day technical judgment, team structure, and founder relief, spell those tasks out first. Then decide whether your current engineer should grow into them or whether a fractional CTO should carry that load for a while.

A quick check before you decide

Before you choose, look at the next quarter, not the org chart. If every product choice, hiring call, or architecture change still needs the founder's approval, the problem is leadership load. A title change will not fix that on its own.

A short gut check helps:

• Will this decision reduce founder approvals within 90 days?
• Can this person hire well, coach others, and make hard calls when someone is underperforming?
• Do you need help for a short stretch, or do you need a long-term executive?
• If this goes wrong, can the company afford the delay and the cost?
• While someone moves into leadership, who keeps delivery on track every week?

Founders often overrate tenure. The engineer who knows the codebase best is not always the person who should set priorities, push back on bad ideas, or handle a weak hire. CTO work is full of tradeoffs, people issues, and repeated decisions under pressure. Some engineers grow into that well. Some do not. That is normal.

Time horizon matters too. If you need outside leadership for six months to fix delivery, hire better engineers, and reduce founder dependence, a fractional CTO is often the safer move. If you expect one person to own technical direction for years, build a team, and stay through several stages of growth, then a permanent executive may make more sense.

One last check is easy to miss: protect delivery during the switch. If you promote your strongest engineer and nobody takes over their current work, you can lose two things at once - hands-on output and clear leadership.

What to do next

Do not change anyone's title until you write a 90-day brief. If you are deciding between a promotion and a fractional CTO, that brief forces the choice into plain terms: what must improve, who will decide, and what success should look like after three months.

Keep it simple. Write down the delivery problems you need to fix, the hiring decisions this person will own, and the founder tasks that should leave your plate. If you cannot name those clearly, you are not ready to make the role change.

A test period is often better than a permanent title on day one. Give the person clear decision areas for a few weeks, then review the results every week. Watch whether they can make tradeoffs, keep projects moving, and handle disagreement without pulling the founder back into every call.

Your 90-day brief should answer a few basic questions. Which decisions belong to this role now? Which meetings should the founder stop leading? Which hiring gaps need attention first? Which delivery risks need active oversight? Which metrics will you review each week?

If your strongest engineer has never owned hiring plans, org design, or team priorities across functions, do not assume they will grow into executive work fast enough. Great engineers often need support, and some do not want that job at all.

A fractional CTO makes sense when the team lacks executive experience, the founder still carries too much product and delivery risk, or hiring has stalled for months. A full-time executive makes sense when the role is already broad, permanent, and clearly defined.

Make the decision based on the work in front of you, not on who has been around the longest. One careful call now can save months of confusion, missed hires, and founder overload.