CTO Operating Doc — Template for the Next Chapter
A doc to hand to the next CEO on day one. The premise: operating models with a CEO are dependent on conditions, not just trust. Conditions change. The doc is the mechanism that makes renegotiation explicit, scheduled, and CTO-initiated rather than CEO-initiated through performance feedback.
Refreshed quarterly. Anchored to the lessons in sitemate-farewell-learnings.md.
1. Purpose
This doc exists so that the CEO and CTO never have to infer what the operating model is. It states explicitly:
- How we work together day-to-day.
- What I will produce, on what cadence, observable to you without you asking.
- What I am committing to be, not just do.
- The conditions under which we renegotiate this doc — proactively, before drift forces the conversation.
- The pace expectation we are jointly signed up to.
It is a working document. We update it quarterly. We escalate to update it sooner whenever a trigger condition fires.
2. The operating model
Cadence
| Forum | Frequency | Purpose | Owner |
|---|---|---|---|
| 1:1 | Weekly | Critical strategic items, risks, calls that need joint sign-off | Joint agenda, CTO drafts |
| Mid-quarter review | Quarterly | Pattern-level conversation: am I being the CTO this company needs now? | CEO writes, CTO responds |
| Operating-doc refresh | Quarterly | Renegotiate this doc against current conditions | CTO drafts, CEO approves |
| Async written update | Weekly | Status, deltas, signals — observable without ask | CTO writes, CEO consumes |
Decision-rights map
Stated explicitly so neither party has to guess:
- CTO calls, no consult required: [list — e.g., team structure within PDE budget, individual hiring within band, technical architecture choices within agreed direction]
- Joint calls: [list — e.g., PDE budget, senior hires above band X, strategic technology bets, public-facing engineering narrative]
- CEO calls, CTO informs: [list — e.g., role-level reporting changes that cross PDE/GTM, executive comp]
This map gets revisited at every quarterly refresh. The most common failure mode is drift — calls migrating between buckets without the doc updating.
Observable signals — what the CEO sees without asking
The boss should be able to read state without becoming the auditor. Default artefact set:
- Weekly written update. Single page. State / deltas / risks / asks. Same shape every week. Sent before the 1:1, not in it.
- Decision log. Live doc. Every consequential CTO call: decision, reasoning, alternatives, who was consulted, expected outcome. Reviewable async, no narration required.
- Operating dashboard. Three-to-five metrics, refreshed weekly. Named at quarterly refresh, fixed for the quarter. Resist the urge to add metrics mid-quarter.
- PGM rollup. One paragraph per direct report per fortnight: what they are owning, where the bar is being met or not, what intervention I am making.
The principle: the boss never has to follow up to know where we are. If they have to ask, the artefact set is failing.
3. The proximity contract
This is the piece that was missing in the previous chapter. State it explicitly:
“Under current conditions [name them], I will operate at [distance X] from PDE, with you engaged at [distance Y]. If conditions change in any of [listed ways], we will trigger a renegotiation of this contract within two weeks of the change being recognised.”
Sample distances to choose from:
- Trust at distance — CEO not regularly in PDE forums. CTO operates independently. Works only when (a) CEO has higher-leverage problems elsewhere, (b) PDE is on-pattern, (c) macro conditions are stable.
- Engaged partner — CEO in PDE forums monthly, opining on architecture and team decisions, not driving them. The default healthy state in stable conditions.
- In-the-kitchen — CEO in PDE forums weekly, driving specific initiatives directly, intervening in standards. Appropriate when (a) PDE off-pattern, (b) macro pressure compresses runway, (c) strategic reinvention required.
The proximity is a property of the conditions, not of the relationship. Naming it makes shifts negotiable rather than emotional.
The CTO commitment when proximity shifts
When conditions push proximity toward “in-the-kitchen,” the CTO drafts the new operating model first, before the CEO has to define it through intervention. The pattern from last chapter — CEO arriving and CTO continuing the old mode — is the failure to avoid.
4. Trigger conditions for renegotiation
Any of these fires → proactive renegotiation within two weeks:
- Macro shift. Funding squeeze, miss on a top-3 company KPI for two consecutive periods, competitive landscape inflection, regulatory event.
- CEO scope shift. CEO publicly declares a return to PDE/product (or any other shift in their leverage focus). Operating doc is rewritten before the shift lands, not after.
- Pattern language. A recurring sentence from the CEO that names a gap, repeated in two or more written records across two or more weeks. Treat as load-bearing input — the diagnosis is forming.
- Standards drift. CEO begins authoring frameworks, comms, or interventions inside PDE territory. The level of intervention is the signal — it means the CTO’s output isn’t landing the way they need it to.
- CTO time-allocation feedback. Any explicit feedback on how I spend time, no matter how mildly framed. “Consider your time allocation” is never a soft note.
- 1:1 agenda redirection. CEO redirecting the agenda of the 1:1 itself = the previous form of the meeting wasn’t producing the value they need. Redesign the 1:1 within one cycle.
- Tonal break. Clipped responses, register shift, withdrawal of investment-mode behaviour. Subjective, but real.
The principle: any of these is a renegotiation trigger, not a performance-fix trigger. The fix is structural — change the operating model — not behavioural alone.
5. Who I am being — personal commitments
Process is necessary but not sufficient. The other half is character commitments, named in observable terms so the CEO can read them off behaviour, not infer them.
- Decisiveness. In any forum where data is on the table, I commit to a clear call within the meeting itself, with reasoning, even when the call disappoints someone. If I find myself optimising for fairness or comfort over the right call for the business, I will name it out loud and proceed anyway.
- Direct leverage. A minimum proportion of my week — stated, currently 40% — goes to direct work on the highest-leverage technical/architectural unblockers. Not coordination, not admin, not comms. Tracked in the weekly written update.
- Bar-setting through demonstration. I will be visibly in at least two team forums per week doing the work, not observing the work. “Follow what I do, not what I say.” Documented in the weekly update.
- Performance management upward. I will hold the PGMs to the same standard I am held to. Direct, in writing, with explicit expectation-of-correction. No softening for relationship.
- Boss-facing scaffolding. Every artefact in section 2 is on me to produce on its cadence without prompting. If I miss one, that is itself a signal worth surfacing — it usually means I am off-pattern elsewhere.
These are signed up to. They get audited at the quarterly refresh.
6. The pace check
The most important explicit alignment, and the one that was missing last time. Stated bluntly at every quarterly refresh:
“Given current company conditions, what is the pace at which the PDE org needs to transition to its next operating mode? What is the pace at which I am driving that transition? Are those two numbers the same?”
If they are not the same, the doc gets rewritten before the meeting ends. The lesson from last chapter is that a CEO can be patient with a gap until the company’s runway can no longer afford the gap. The runway is the variable that turns persistent gaps into terminal ones. Naming the runway pace explicitly, every quarter, removes that variable from the relationship.
7. The “what’s not in this doc” check
At every refresh, the question:
“What would I be uncomfortable writing down in this doc? Why?”
The answer is usually where the next gap is forming. Last chapter’s answer would have been: “That my structural reframe of priorities is correct under the old conditions but not the new ones.” If that had been written down in November, the diagnosis lands months earlier and the conversation is different.
Capture the discomfort in writing. Then choose: change the doc to reflect it, or change the behaviour the doc would have to acknowledge.
8. Renegotiation, not surprise
The deepest principle, written for the CTO-future-self:
Operating-model renegotiation is the CTO’s job when conditions shift. It is not the CEO’s job to feel their way into a new model and then communicate it through performance feedback. If the CEO is the one redrawing the operating standard, the CTO has already missed the moment to do it from the outside.
Last chapter, the redraw came through a Q-review document, then a follow-on review, then a coach-led 360. Each is more expensive than a CTO-initiated quarterly refresh, in time, in capital, and in relationship. This doc is the cheaper mechanism. Use it.
9. First-90-days application
When joining a new company, this doc gets drafted in week 2 and signed in week 3. Day-one priorities:
- Surface conditions current as of arrival (financial, competitive, technical).
- State the proximity contract on day one — don’t wait to discover it.
- Name the pace expectation explicitly. “How fast does PDE need to transition to its next operating mode? What’s the runway constraint behind that?” — the answer drives everything else.
- Schedule the quarterly refresh into the calendar before any other recurring meeting.
- Within the first 30 days, produce the weekly written update, decision log, and PGM rollup at full quality. Build the muscle before it’s needed.
The forward question for next chapter, kept visible: “What would I write in this doc that I wouldn’t have written in the Sitemate version?” That is where the growth from this chapter actually lives.