The Full-Time CTO Job Description We Talked Three Founders Out Of: A Line-by-Line Duty Audit

Why three founders drafted a full-time CTO posting, and what was actually wrong with it

In each case the posting was a symptom list, not a role. The founders had written down every technical decision that had recently frightened them and turned it into a bullet. The result read like a job for one person, but the underlying work split into three unrelated buckets: episodic judgement, continuous execution, and people management.

The pattern was identical across all three. A founder at a health-tech company, a founder at a London fitness community operation, and a founder at a Croatian activity marketplace each arrived with a document titled something like 'Head of Engineering' or 'CTO'. The bullets included architecture ownership, hiring and interviewing, vendor selection, security and compliance sign-off, investor technical diligence, roadmap sequencing, code review, and on-call. Read as a list, it looks like a full plate. Read as a calendar, most of it does not recur weekly.

The useful question is not 'do we need a CTO'. It is 'how many hours per month does each of these bullets actually consume, and does that work need someone present or someone reachable'. Presence and judgement are different products and they price very differently. We have sat in the fractional seat across several companies at once, which is the only way to know that a compliance sign-off cycle takes a concentrated week and then nothing for four months.

The scoring method: hours per month, continuity, and delegability

We scored every bullet on three axes. First, real hours consumed per month in our engagements. Second, whether the duty needs continuity, meaning someone who is present when it happens unpredictably, or whether it needs judgement, meaning someone who can be scheduled. Third, whether an existing senior backend or mobile engineer on the team could absorb it with a documented process instead of a new hire.

The continuity axis is the one founders get wrong. Architecture ownership sounds continuous because the architecture exists continuously. But the decisions that constitute ownership are discrete: a data model choice, a service boundary, a decision to move a workload off Firestore into Postgres. Those cluster into a handful of hours in a specific week and then go quiet. On-call is the opposite. It looks episodic because incidents are rare, but it requires a person to be awake and reachable on a schedule, which is a continuity cost regardless of how few pages fire.

Delegability is where most of the savings come from. Many bullets do not need a new person at all. They need a named owner, a written standard, and a review cadence. We have used the same pattern for AI features: rather than hiring an ML engineer, split the responsibility into named roles and hand them to existing staff. The same logic applies to code review, dependency upgrades, and release management.

• • Hours per month: measured from our own time logs across engagements, not estimated from the job description
• • Continuity vs judgement: does it require presence on an unpredictable schedule, or can it be scheduled into blocks
• • Delegability: can an existing senior engineer own it with a checklist and a monthly review
• • Blast radius: what breaks if it is handled two days late rather than immediately

The decision table: which bullets justify a full-time hire

Three categories of duty genuinely require a full-time person: daily people management of four or more engineers, permanent on-call rotation ownership, and in-person team building or culture work. Everything else on the three postings was either episodic, delegable to an existing lead, or a fixed monthly commitment measured in single-digit hours.

Daily people management is the clearest case. One-on-ones, performance conversations, unblocking, career progression, and hiring pipeline management scale linearly with headcount and cannot be batched into a scheduled block. Below roughly four engineers a founder can carry it. Above that, it becomes a job. None of the three founders had more than three engineers at the time they drafted the posting, which is precisely why the posting was premature.

Permanent on-call ownership is the second. Not the incident response itself, which is rare, but the accountability for the rotation, the escalation path, and the postmortem discipline. A fractional arrangement can own the runbook and the architecture that reduces pages. It should not own the pager as the single point of escalation, because a fractional person is by definition splitting attention across companies. In-person culture work is the third, and it is the one founders dismiss as soft until their first two engineers quit in the same quarter.

• • Full-time justified: daily people management above ~4 engineers, permanent on-call accountability, in-person team building and culture, full-time recruiting pipeline ownership during an active hiring push
• • Fractional-suited: architecture calls, vendor and tool selection, security and compliance sign-off cycles, investor technical diligence, roadmap sequencing reviews, technical hiring interviews as an interviewer rather than a pipeline owner
• • Delegable to an existing senior engineer: routine code review, dependency and framework upgrades, release management, CI pipeline maintenance, documentation upkeep

Line by line: what each duty actually consumed

Across our engagements, the episodic duties clustered into predictable shapes. Investor technical diligence is a concentrated burst, typically one to two weeks of heavy involvement around a raise and then nothing for a year. Vendor selection is a bounded exercise per decision. Compliance sign-off follows the audit calendar. Architecture ownership is roughly a few hours a month in steady state and spikes when a new system is added.

Investor technical diligence is the bullet that scares founders most and consumes the least calendar time overall. Diligence questions cluster: architecture diagram, security posture, data handling and GDPR, key person risk, technical debt inventory, and roadmap credibility. If those artifacts already exist and are maintained, the work is preparing a data room and sitting in two or three calls. If they do not exist, the work is three weeks. The correct fix is maintaining the artifacts continuously, not hiring a person to produce them under deadline.

Vendor selection behaves the same way. Picking a model provider, a payments processor, or an analytics stack is a genuine judgement call with a long tail of consequences, but the decision itself is a scoped exercise: define constraints, shortlist, run a spike, decide. We ran exactly this for model provider selection across three client features. It is a week of work per decision, a handful of times a year. Code review is different again. It recurs constantly, which makes it look like a full-time duty, but the recurring part is mechanical and belongs in a checklist and a linter. What actually needs senior judgement is the small subset of PRs that cross a service boundary or change a data contract.

The two roles we told a founder to hire full-time instead

We told one founder to skip the CTO posting entirely and hire two other people full-time: a senior product engineer who would be the permanent owner of the codebase, and an operations lead who understood the domain well enough to own the internal tooling requirements. Neither role was on the original posting. Both were the actual bottleneck.

The reasoning was continuity of context, not seniority. A fractional arrangement is good at decisions and bad at being the only person who knows why a table has a particular shape. A senior product engineer sitting inside the company every day accumulates that context, and they are the person who makes the fractional relationship efficient, because architecture calls become thirty minutes instead of two hours when someone in the room already holds the state. Key person risk also drops, which is the thing diligence actually probes.

The operations lead was less obvious. In two of the three companies, the loudest technical complaints were not technical. They were requirements problems: nobody inside the business could specify what the internal system needed to do, so engineering built approximations and then rebuilt them. Hiring a CTO would not have fixed that. Hiring someone who knew the operational reality, and who could write down the rules that lived in a spreadsheet, did. We have run that migration pattern more than once, and the failure mode is always the same: undocumented business logic hiding in formulas.

How to run this audit on your own draft posting

Take your draft posting, put every responsibility bullet in a spreadsheet, and add four columns: estimated hours per month, continuity or judgement, current owner if any, and what breaks if it is two days late. Fill it in honestly with your last six months of actual events, not with hypotheticals. Then total the continuity column. If it clears roughly twenty hours a week, hire full-time.

Two rules make the audit honest. First, count events that actually happened rather than events you fear. If you have not had a security incident, an audit, or a diligence process in the last year, do not budget for one monthly. Second, separate the bullet from the artifact. 'Own the architecture' is a bullet. 'A current architecture diagram, a data contract inventory, and a documented decision log' are artifacts. Artifacts can be produced on a cadence by anyone competent. Bullets create the illusion of a full-time job.

Whichever way the audit lands, the artifacts are worth producing first. When founders come to us before signing anything, we hand over an entity and event model, an integration inventory, a must-ship-first list, non-goals, and an assumptions register. Those five documents answer most of what the CTO posting was trying to buy, and they make the eventual full-time hire, whenever it happens, dramatically cheaper to onboard.

If you want the artifacts a CTO posting is usually trying to buy, start with the five discovery artifacts we hand over before a contract is signed, which cover the entity and event model, integration inventory, must-ship-first list, non-goals, and assumptions register.