Cold Email to a CTO: Three Templates That Read Like an Engineer Wrote Them

A cold email to a CTO is read, if it is read at all, by someone whose real inbox is Slack, GitHub, and the incident channel, and who treats email as the place vendors live. That framing decides everything about how you write a cold email to a CTO. Marketing gloss is a tell. A calendar link is a tell. Any sentence that describes what your product does without saying how it works is a tell, and three tells is a delete. What survives is a note that reads like an engineer wrote it: it references something the team shipped, an engineering blog post, a public repo, a postmortem, a job posting for a specific stack, states one technical claim plainly, and links to documentation the CTO can read without talking to anyone. The three templates below are built that way. Each is short, specific, and asks for a forward to the right engineer rather than a meeting. The prompt after them does the technical reading first.

What a CTO is measured on, and what they delete

A CTO is measured on uptime, shipping velocity, security posture, infrastructure cost, and whether they can hire and keep engineers, and none of those show up in a typical sales email. They read email on a laptop, late in the day, after Slack and GitHub, and at larger companies an executive assistant handles the inbox while the CTO handles the engineering channels. Their filter is precision: a claim without a mechanism is marketing, and marketing is deleted. They also delete anything with a marketing adjective where a mechanism should be, any email whose tracking pixel their client flags, and any note that clearly went to a hundred CTOs. They reply, or more often forward to a staff engineer, when the email cites something their team published and points at docs they can evaluate alone.

Cold email to a CTO: three templates

Pick by what you actually read: a post or postmortem you can cite, an internal-tool pain their job postings hint at, or a peer engineering team on the same stack. Confirm the stack from job postings before you name it; a wrong language or cloud ends the email.

Subject: your post on {{blog post topic}}

{{first name}}, read your team's post on {{blog post topic}}. The part about {{specific detail, e.g. moving the ingestion path off the cron job}} is the problem we spent two years on.

We handle {{one-line technical mechanism}} so the team does not maintain it. Acme Observe's platform team replaced {{n}} internal services with it and got {{result}} back in on-call load.

Docs are here, no signup: {{docs URL}}. If it is worth a look, who on the team should I send it to?

Subject: the internal tool nobody wants to own

{{first name}}, every engineering org past {{n}} people has the internal {{category, e.g. data pipeline / auth / notification}} service that one engineer built, then left.

The cost is the on-call rotation and the senior engineer patching it at 2am instead of shipping the roadmap.

We run that service as a product, {{one-line mechanism}}, with the API and SLA documented. Northwind Freight retired {{n}} internal services on it in {{timeframe}}.

Docs, no gate: {{docs URL}}. Happy to answer questions from whoever owns that rotation.

Subject: how Harlow Logistics cut {{metric}} {{result}}

{{first name}}, Harlow Logistics runs {{stack detail, e.g. Go services on Kubernetes with Postgres}}, which your job postings suggest {{company}} does too.

Their platform team put {{product}} in front of {{n}} services and {{metric}} dropped {{result}} over {{timeframe}}. Their staff engineer wrote up the integration, including the two things that broke in staging.

That write-up is here: {{URL}}. Worth forwarding to whoever owns {{area}}?

your post on {{blog post topic}}
the internal tool nobody wants to own
how Harlow Logistics cut {{metric}} {{result}}
{{stack detail}} at {{company}}
re: the {{incident}} postmortem
docs, no signup

Plain text, no tracking pixel, no calendar link, and a docs URL that works without a signup form; a CTO who has to enter an email address to read your documentation will not, and will remember that you asked.

Personalize these to the account, not just the persona

A CTO reads the first line for evidence you looked at the engineering, and a template with the blog post name left blank is evidence you did not. The version that gets forwarded to a staff engineer cites something the team actually published and gets the stack right from their job postings. Paste the template with the prompt and let Claude read the engineering blog before you write.

You are writing a cold email to the CTO of {{company}} ({{company URL}}) for {{my company}}, which sells {{one-line technical description}}. Documentation is at {{docs URL}}.

First, read what their engineering team has published: the engineering blog, public repos, any postmortem or status page incident, conference talks, and job postings for the stack (languages, cloud, databases, orchestration). Identify one specific post, repo, or incident I can reference, and the stack details that are confirmed rather than guessed.

Then rewrite the template below. Line one must cite that specific thing by name. State the technical mechanism in one sentence, with no marketing adjectives. Link to the docs, not a deck, and ask who on the team should see it rather than for a meeting. Body under 90 words, plain text. Use {{customer proof}} exactly as stated.

Mark anything inferred, especially stack details. Then give me three subject lines that would look normal in an engineer's inbox.

TEMPLATE:
{{paste the template}}

Write cold email at scale with Claude

• B2B cold email templates skill →The Claude skill that writes cold email in your brand voice with the banned-word list and the one-idea rule baked in.
• Cold email from a value prop prompt →The copy-paste prompt version: one value prop in, one specific email out.
• Personalize cold email with Clay and Claude →The use case that runs these templates across a whole list with real enrichment data.

Frequently asked questions