Benchmark Learnings: Emailing Technical Buyers

Benchmark Learnings: Emailing Technical Buyers

Уроки бенчмаркинга: письма техническим покупателям

How to Cold Email Technical Buyers (And What Our Benchmarking Data Says You're Getting Wrong)

Как писать холодные письма техническим покупателям (и что, по нашим бенчмарк-данным, вы делаете не так)

Out of 231,818 cold emails in our latest Cold Email Benchmark Report, engineering and product are two of the most prospected technical departments in B2B. The reply rate? 5.2%.

Из 231 818 холодных писем в нашем последнем Cold Email Benchmark Report engineering и product — два самых часто прорабатываемых технических отдела в B2B. Reply rate? 5,2%.

That's actually above average. Technical buyers reply more than HR, marketing, finance, or ops. But there's a catch.

И это даже выше среднего. Технические покупатели отвечают чаще, чем HR, маркетинг, финансы или ops. Но есть нюанс.

Only 11% of those emails earned a Lavender A grade. And when sellers write A-level emails to this group, the reply rate only climbs to 5.5% — a 6% lift. While that may be the smallest quality lift of any department grouping in the dataset, our models have helped an enterprise sdr team prospecting CISOs 10x their total replies.

So why is there such discrepancy?

Только 11% этих писем получили оценку A по Lavender. И когда продавцы пишут A-уровневые письма этой группе, reply rate поднимается лишь до 5,5% — рост 6%. Это, пожалуй, наименьший прирост качества среди всех групп отделов в датасете, но наши модели помогли enterprise-команде SDR, прорабатывающей CISO, увеличить общее число ответов в 10 раз. Так почему такое расхождение?

Here's why that matters: for most departments, writing a "better" email reliably produces more replies. For technical buyers, the relationship between email quality and reply rates is weaker. It suggests that what makes a cold email "good" to a marketer or an HR leader doesn't map cleanly onto how engineers and product leaders evaluate your message.

Вот почему это важно: для большинства отделов написание «лучшего» письма стабильно приносит больше ответов. У технических покупателей связь между качеством письма и reply rate слабее. Это намекает на то, что критерии «хорошего» холодного письма для маркетолога или HR-лидера плохо переносятся на то, как engineering- и product-лидеры оценивают ваше сообщение.

So what does work? And how is it different?

Так что же работает? И чем это отличается?

Let's use some real examples as if we're a seller at Launch Darkly. Engineering uses it for safe deployments and infrastructure control. Product uses it for controlled rollouts, experimentation, and shipping features to specific segments. Both teams have real, distinct reasons to care.

Возьмём реальные примеры, будто мы продавцы в Launch Darkly. Engineering использует его для безопасных деплоев и контроля инфраструктуры. Product — для контролируемых раскатов, экспериментов и отгрузки фич конкретным сегментам. У обеих команд есть реальные, но разные причины интересоваться.

Technical buyers aren't ignoring your email. They're ignoring your credibility.

Технические покупатели не игнорируют ваше письмо. Они игнорируют вашу достоверность.

The biggest pattern in the data is this: engineering and product buyers respond to people who clearly understand the technical world they operate in. Not people who borrow technical language from their marketing team. It’s the people who understand the actual workflows, tradeoffs, and constraints well enough that they can explain it to other non-technical people.

For engineers, you need to be able to get into the weeds. But there's a critical distinction here. Technical jargon turns engineers away. What performs better is speaking to a specific use case or workflow in language that feels authentic. If you can't explain it clearly, they assume you don't understand the technicalities well enough to be worth their time.

Главный паттерн в данных таков: engineering- и product-покупатели отвечают людям, которые явно понимают технический мир, в котором те работают. Не тем, кто позаимствовал технический язык у своего маркетингового отдела. А тем, кто понимает реальные workflow, компромиссы и ограничения настолько хорошо, что может объяснить это даже нетехническим людям. С инженерами нужно уметь спускаться в детали. Но есть важный нюанс. Технический жаргон отталкивает инженеров. Лучше работает разговор о конкретном use case или workflow на языке, который ощущается аутентичным. Если вы не можете объяснить это ясно, они решат, что вы недостаточно понимаете технические тонкости, чтобы тратить на вас время.

Product buyers are different but related. They don't want you to get technical too early. They want you to speak to broader roadmap initiatives and product priorities before any specific technical detail. Technical depth is earned, not led with.

Product-покупатели — другие, но похожие. Они не хотят, чтобы вы слишком рано уходили в технические детали. Они хотят, чтобы вы говорили о более широких roadmap-инициативах и продуктовых приоритетах до любых конкретных технических деталей. Технической глубиной нужно заслужить право, а не начинать с неё.

Here's a summary from what the data shows is working and not working:

Вот сводка того, что по данным работает, а что нет:

What works for engineering: Personalized relevance tied to requests, events, or context. Technical specificity with concrete use cases. Clear next-step CTAs. Brevity and credibility signals.

Что работает для engineering: Персонализированная релевантность, привязанная к запросам, событиям или контексту. Техническая конкретика с реальными use case. Чёткие CTA с понятным следующим шагом. Краткость и сигналы доверия.

What works for product: Context tied to product priorities and roadmap themes. One focused value prop. Specific examples and proof. Low-friction CTAs to validate interest.

Что работает для product: Контекст, привязанный к продуктовым приоритетам и темам roadmap. Один сфокусированный value prop. Конкретные примеры и доказательства. Низкозатратные CTA для проверки интереса.

What doesn't work for either: Generic templates. Overly long emails with too much jargon. Weak CTAs ("learn more"). Broad product claims without context. Overly salesy tone.

Что не работает ни для кого: Общие шаблоны. Слишком длинные письма с избытком жаргона. Слабые CTA («learn more»). Широкие продуктовые заявления без контекста. Чрезмерно sales-овый тон.

The shared thread: authenticity. These are buyers who build things for a living. They respect people who understand what they build and why it's hard. They don't respect people who copy-paste buzzwords from a website.

Общая нить: аутентичность. Это покупатели, которые зарабатывают на жизнь созданием вещей. Они уважают людей, которые понимают, что они строят и почему это сложно. Они не уважают тех, кто копирует баззворды с сайта.

But how you demonstrate that understanding shifts based on seniority. A CTO and a security engineer have very different filters. So let's break it down.

Но то, как вы демонстрируете это понимание, меняется в зависимости от seniority. У CTO и security engineer — совсем разные фильтры. Разложим по полочкам.

Selling to Technical Executives (CTO, VP of Engineering, VP of Product, CISO)

Продажи техническим руководителям (CTO, VP of Engineering, VP of Product, CISO)

Titles you're targeting: CTO, VP of Engineering, VP of Product, VP of Infrastructure, VP of Security, Head of Engineering, Head of Product, Head of Platform, CISO

Должности, на которые вы целитесь: CTO, VP of Engineering, VP of Product, VP of Infrastructure, VP of Security, Head of Engineering, Head of Product, Head of Platform, CISO

What the data says about executives: C-Suite buyers reply at 4.8%, VPs at 3.4%, and Heads at 4.4%. Heads see a 42% lift on A emails — the highest across the executive tier. This is likely because Heads tend to operate in smaller organizations or sit in a more execution-oriented seat inside larger ones. They're less likely to be thinking "should I delegate this to…"

Что говорят данные о руководителях: C-Suite-покупатели отвечают на 4,8%, VP — 3,4%, Head — 4,4%. У Head прирост на A-письмах составляет 42% — самый высокий среди executive-уровня. Вероятно, это потому что Head'ы чаще работают в небольших организациях или занимают более «исполнительские» позиции внутри крупных. Они реже думают «может, делегировать это…»

What this means for technical execs specifically: Technical executives filter everything through two lenses: does this reduce risk, and does this help us ship faster? Revenue matters to them, but for engineering it's usually framed as the cost of not solving a problem: downtime, breaches, slowed velocity. It’s not a direct revenue play. For product, it’s also about solving problems and the opportunity costs associated with not hitting product milestones. That unlocks revenue, but its downstream.

Что это значит конкретно для технических руководителей: Технические руководители фильтруют всё через две линзы: снижает ли это риск и помогает ли ship быстрее? Выручка для них важна, но для engineering обычно подаётся как стоимость нерешённой проблемы: downtime, утечки, замедление скорости. Это не прямая игра на выручку. Для product это тоже про решение проблем и упущенные возможности от непопадания в продуктовые milestones. Это разблокирует выручку, но опосредованно.

The tone needs to be direct and credible. Not warm like HR. Not casual like marketing. Technical execs want to feel like they're talking to someone who understands the engineering org's constraints, not someone reading from a sales playbook trying to get chummy.

Тон должен быть прямым и достоверным. Не тёплым, как с HR. Не неформальным, как с маркетингом. Технические руководители хотят чувствовать, что говорят с тем, кто понимает ограничения engineering-организации, а не с тем, кто читает sales-плейбук и пытается фамильярничать.

Reiterating an important nuance: product execs and engineering execs think differently. A VP of Engineering cares about infrastructure, reliability, and security posture. A VP of Product cares about roadmap priorities and where a solution fits into the product strategy. Adjust accordingly.

Повторим важный нюанс: product-руководители и engineering-руководители думают по-разному. VP of Engineering заботится об инфраструктуре, надёжности и security posture. VP of Product — о приоритетах roadmap и о том, как решение вписывается в продуктовую стратегию. Корректируйте подход соответственно.

What to do

Что делать

Lead with a company-level technical observation — a migration, an architecture decision, a security posture shift, a product launch. Connect it to a risk or velocity challenge that shows up at their stage. Keep proof concrete and technical (deployment time, coverage metrics, reduction in incidents). Frame the CTA as collaborative. Give them a path to delegate to the right technical lead.

Начинайте с технического наблюдения уровня компании — миграция, архитектурное решение, сдвиг в security posture, запуск продукта. Связывайте это с риском или вызовом для скорости разработки, актуальным на их стадии. Доказательства держите конкретными и техническими (время деплоя, метрики покрытия, снижение числа инцидентов). Формулируйте CTA как совместный шаг. Дайте им возможность делегировать нужному техническому лиду.

What not to do

Что НЕ делать

Don't lead with product features. Don't use buzzwords you can't back up. Don't write more than 100 words. Don't use hype language like "world-class," "cutting-edge," and "next-generation". These are instant credibility killers with this audience. And don't make multiple asks. Save the deep technical dive for a lower seniority.

Не начинайте с продуктовых фич. Не используйте баззворды, которые не можете подкрепить. Не пишите более 100 слов. Не используйте хайповый язык вроде «world-class», «cutting-edge» и «next-generation». Это мгновенные «убийцы доверия» для этой аудитории. И не делайте несколько запросов сразу. Глубокое техническое погружение оставьте для уровня пониже.

Example: You're an AE at LaunchDarkly, emailing a VP of Engineering

Пример: вы AE в LaunchDarkly, пишете VP of Engineering

You noticed their company recently shipped a major product update and their engineering blog mentioned moving to weekly release cycles.

Вы заметили, что их компания недавно выкатила крупное обновление продукта, и в их engineering-блоге упомянут переход на еженедельные релизные циклы.

James,

Read the post on moving to weekly releases. Big shift. Guessing team is wrapping every release in feature flags?

Realize you might have an in house fix. But, that’s a lot of new code. This could be an opp to have the team maintaining less if we automatically wrapped every release.

If DevOps is closer to this, happy to connect w/ them directly.

James, прочитал пост о переходе на еженедельные релизы. Большой сдвиг. Полагаю, команда оборачивает каждый релиз в feature flags? Понимаю, что у вас может быть in-house решение. Но это много нового кода. Это могла бы быть возможность сократить нагрузку на поддержку, если бы каждый релиз оборачивался автоматически. Если этим занимается DevOps, рад законнектиться с ними напрямую.

Why it works:

Почему это работает:

The Opener: Referencing the actual engineering blog post (not a job listing or a LinkedIn post) signals technical credibility immediately. It’s a technical workflow shift. 

Опенер: Ссылка на конкретный пост в engineering-блоге (не на вакансию или пост в LinkedIn) сразу сигнализирует о технической достоверности. Это технический сдвиг в workflow.

The Problem: Shipping safely and managing rollbacks are the obvious problem, we don’t need to tell them what they already know. We establish credibility by assuming they’re using feature flags. Instead, we reframe the problem as maintaining feature wraps on all the new code they’re releasing. 

Проблема: Безопасный ship и управление откатами — очевидная проблема, не нужно говорить им то, что они и так знают. Мы устанавливаем доверие, предполагая, что они уже используют feature flags. Вместо этого мы переформулируем проблему как поддержание feature-обёрток на всём новом коде.

The Solution: We quickly give them an alternative to help them move faster and safer.

Решение: Быстро предлагаем альтернативу, чтобы они двигались быстрее и безопаснее.

The CTA: Two paths — engage directly or delegate. Tagging DevOps shows you understand how engineering orgs are structured.

CTA: Два пути — вовлекаться напрямую или делегировать. Упоминание DevOps показывает, что вы понимаете, как устроены engineering-организации.

Style: 64 words. Direct. No hype. The abbreviation "w/" and informal phrasing keep it from feeling corporate.

Стиль: 64 слова. Прямо. Без хайпа. Сокращение «w/» и неформальные обороты не дают письму звучать корпоративно.

Selling to Technical Directors and Senior Leaders

Продажи техническим директорам и senior-лидерам

Titles you're targeting: Director of Engineering, Director of Product, Director of Security, Director of Infrastructure, Director of Platform, Senior Engineering Manager, Senior Product Manager, Director of DevOps, Director of Cloud Engineering

Должности, на которые вы целитесь: Director of Engineering, Director of Product, Director of Security, Director of Infrastructure, Director of Platform, Senior Engineering Manager, Senior Product Manager, Director of DevOps, Director of Cloud Engineering

What the data says about this tier: Directors reply at 3.4% overall. Senior-level buyers jump to 8.4% on A emails — the biggest absolute lift in the entire seniority dataset.

Что говорят данные об этом уровне: Директора отвечают на 3,4% в целом. Senior-уровневые покупатели подскакивают до 8,4% на A-письмах — самый большой абсолютный прирост во всём датасете по seniority.

This group is underserved by good outbound. That's your opportunity.

Эта группа недополучает качественный outbound. Это ваш шанс.

What this means for technical directors specifically: Directors own specific technical domains. A Director of Infrastructure cares about uptime and scaling. A Director of Security cares about threat detection and compliance. A Director of Product cares about the roadmap for their product area. Broad pitches miss completely because they don't map to anything this person actually owns.

Что это значит конкретно для технических директоров: Директора владеют конкретными техническими доменами. Director of Infrastructure заботится об uptime и масштабировании. Director of Security — об обнаружении угроз и compliance. Director of Product — о roadmap для своей продуктовой области. Широкие питчи промахиваются совсем, потому что не привязаны к тому, чем этот человек реально владеет.

The data calls it out clearly: this group responds to clear relevance to functional priorities and specific use cases. Generic templates and salesy language are the top killers. For engineering directors specifically, technical specificity paired with concrete use cases is what works. For product directors, it's context tied to roadmap themes with one focused value prop.

Данные говорят прямо: эта группа отвечает на ясную релевантность функциональным приоритетам и конкретным use case. Общие шаблоны и sales-овый язык — главные «убийцы». Для engineering-директоров отдельно: техническая конкретика в паре с реальными use case — вот что работает. Для product-директоров — контекст, привязанный к темам roadmap, с одним сфокусированным value prop.

What to do

Что делать

Get specific about the domain they own. Anchor your observation in something visible — an architecture pattern, a recent incident, a product release, a compliance requirement. Connect it to a challenge specific to their function. Keep proof to one relevant example with concrete outcomes. Frame the CTA as a chance to compare approaches, not buy anything.

Конкретизируйте домен, которым они владеют. Привязывайте наблюдение к чему-то видимому — архитектурному паттерну, недавнему инциденту, релизу продукта, требованию compliance. Связывайте это с вызовом, специфичным для их функции. Доказательства — один релевантный пример с конкретными результатами. CTA формулируйте как возможность сравнить подходы, а не что-то купить.

What not to do

Что НЕ делать

Don't pitch broad. Don't use multiple value props. Don't write long intros. Don't use jargon you can't back up. Directors will catch it fast. And don't use salesy framing. "I'd love to show you a demo" reads very differently to this group than "want to see how other companies have set it up."

Не питчите широко. Не используйте несколько value prop сразу. Не пишите длинные вступления. Не используйте жаргон, который не можете подкрепить. Директора это быстро поймают. И не используйте sales-овую рамку. «I'd love to show you a demo» воспринимается этой группой очень иначе, чем «want to see how other companies have set it up».

Example: You're an SDR at LaunchDarkly, emailing a Director of Product

Пример: вы SDR в LaunchDarkly, пишете Director of Product

You noticed their company recently launched a freemium tier alongside their existing enterprise product. It’s visible from their pricing page update and a few tweets from the marketing team.

Вы заметили, что их компания недавно запустила freemium-уровень рядом с существующим enterprise-продуктом. Это видно по обновлению страницы pricing и нескольким твитам маркетинговой команды.

Priya,

With the new freemium tier, I imagine the team’s expecting a lot of new product data. How’s the team set up today to deploy experiments? Guessing that would inform a lot of future roadmap choices that could impact the enterprise offerings.

Would it help if we could get those experiments into product instead of dev?

Atlassian was able to ship 25x more experiments using our feature toggle system. No worries if your crew feels like you’ve got this under control. Thought it was good timing.

Priya, с новым freemium-уровнем, полагаю, команда ожидает много новых продуктовых данных. Как команда сейчас устроена для деплоя экспериментов? Думаю, это повлияет на множество будущих roadmap-решений, которые могут затронуть и enterprise-предложения. Было бы полезно перенести эти эксперименты в product, а не в dev? Atlassian смогли запустить в 25 раз больше экспериментов благодаря нашей feature toggle-системе. Не страшно, если ваша команда чувствует, что у вас всё под контролем. Просто подумал, что момент удачный.

Why it works:

Почему это работает:

The Opener: The freemium launch is a visible, verifiable product decision with downstream impacts on the data they’ll have access to. Framing it as a control problem sets them up to be the hero of the next winning release. 

Опенер: Запуск freemium — видимое, верифицируемое продуктовое решение с downstream-эффектами на данные, к которым у них будет доступ. Подача как «проблема контроля» делает их героями следующего удачного релиза.

The Problem: Experiment velocity gives product the ability to make better decisions. If they can’t control it, they can’t solve it. 

Проблема: Скорость экспериментов даёт product возможность принимать лучшие решения. Если они не могут это контролировать, они не могут это решить.

The Solution / CTA: Positioned first as a question ("how do you deploy experiments?") which opens dialogue. Then the problem is further poked at by questioning if they’d value having an alternative. Then backed with a relevant proof point. 

Решение / CTA: Сначала подано как вопрос («как вы деплоите эксперименты?»), который открывает диалог. Затем проблема углубляется вопросом о ценности альтернативы. Затем подкрепляется релевантным proof point.

Credibility: Engineers don’t love name drops… but product does. The case study was intentionally name dropped. Engineers would respond better to a clearer understanding of how it fits into the workflow.

Достоверность: Инженеры не очень любят name drop… а product — любит. Кейс упомянут намеренно. Инженеры лучше отреагировали бы на более ясное понимание того, как это вписывается в workflow.

Selling to Technical Managers

Продажи техническим менеджерам

Titles you're targeting: Engineering Manager, Product Manager, Security Manager, DevOps Manager, IT Manager, Infrastructure Manager, Cloud Operations Manager, Application Security Manager

Должности, на которые вы целитесь: Engineering Manager, Product Manager, Security Manager, DevOps Manager, IT Manager, Infrastructure Manager, Cloud Operations Manager, Application Security Manager

What the data says about managers: Managers reply at 4.3% overall, with A emails climbing to 6.3% — a 49% lift. Nearly half as many replies added just from writing a better email.

Что говорят данные о менеджерах: Менеджеры отвечают на 4,3% в целом, а A-письма поднимают это до 6,3% — прирост 49%. Почти вдвое больше ответов только за счёт того, что письмо написано лучше.

What this means for technical managers specifically: Technical managers straddle execution and planning. Engineering managers are managing sprints, allocating resources, and keeping their team unblocked. Product managers are defining requirements, prioritizing the backlog, and making tradeoff decisions. Both care deeply about practical usefulness — how does this fit into the work we're already doing?

Что это значит конкретно для технических менеджеров: Технические менеджеры балансируют между исполнением и планированием. Engineering manager управляет спринтами, распределяет ресурсы и держит свою команду разблокированной. Product manager определяет требования, приоритизирует backlog и принимает компромиссные решения. Обоим важна практическая полезность — как это вписывается в работу, которую мы уже делаем?

The data for this tier shows a tension. For product managers in particular, getting too technical too early kills engagement. They want you to speak to priorities and outcomes before you get into the how. Engineering managers are more receptive to technical specificity, but still want it anchored to a workflow they recognize.

Данные по этому уровню показывают напряжение. Для product manager в частности слишком ранние технические детали убивают вовлечённость. Они хотят, чтобы вы говорили о приоритетах и результатах до того, как уйти в «как». Engineering manager более восприимчивы к технической конкретике, но всё равно хотят, чтобы она была привязана к узнаваемому workflow.

The tone should balance professional and direct. Remember that an email's first impression is 8x more likely to happen on mobile — so structure matters. Short paragraphs. Easy to scan. One idea per section.

Тон должен балансировать между профессиональным и прямым. Помните, что первое впечатление от письма в 8 раз чаще формируется на мобильном устройстве — поэтому структура важна. Короткие абзацы. Легко сканировать. Одна идея на блок.

What to do

Что делать

Focus on a specific workflow or technical challenge they're managing right now. Show you understand the tradeoffs they face (speed vs. security, coverage vs. complexity, features vs. infrastructure). Be direct about what you solve and how. Keep the CTA specific — tied to a problem you can address, with a clear next step.

Сфокусируйтесь на конкретном workflow или техническом вызове, которым они управляют прямо сейчас. Покажите, что понимаете компромиссы, с которыми они сталкиваются (скорость vs. безопасность, покрытие vs. сложность, фичи vs. инфраструктура). Будьте прямы в том, что вы решаете и как. CTA держите конкретным — привязанным к проблеме, которую вы можете решить, с чётким следующим шагом.

What not to do

Что НЕ делать

Don't talk about company-wide transformation. Don't overwhelm with multiple value props. Don't write walls of text. For product managers: don't lead with technical specs. For engineering managers: don't use jargon you can't explain if asked. And don't use vague CTAs — "thoughts?" is not a next step.

Не говорите о трансформации уровня всей компании. Не перегружайте несколькими value prop. Не пишите простыни текста. Для product manager: не начинайте с технических спецификаций. Для engineering manager: не используйте жаргон, который не сможете объяснить, если спросят. И не используйте размытые CTA — «thoughts?» — это не следующий шаг.

Example: You're an SDR at LaunchDarkly, emailing a DevOps Manager

Пример: вы SDR в LaunchDarkly, пишете DevOps Manager

Let’s use the same freemium example from above, but let’s apply it to engineering at a lower level.

Возьмём тот же пример с freemium, но применим его к engineering на более низком уровне.

Chris,

How’s the team managing roll outs with the new freemium tier vs. enterprise?

Enterprise is going to want stability. Freemium requires quick iteration. If you could quickly flag features for those tiers would that be easier?

Devs tend to tell us they have internal tools for this. But, using a tool like LaunchDarkly could put this on autopilot by acting as a wrapper for each release.

Chris, как команда сейчас управляет раскатами на новый freemium-уровень против enterprise? Enterprise захочет стабильности. Freemium требует быстрых итераций. Если бы можно было быстро помечать фичи для этих уровней — стало бы проще? Devs обычно говорят нам, что у них есть внутренние тулы для этого. Но инструмент вроде LaunchDarkly мог бы перевести это на автопилот, выступая обёрткой для каждого релиза.

Why it works:

Почему это работает:

The Opener: Opening with a question about an observable truth breaks typical patterns of just calling out an observation directly. 

Опенер: Открытие вопросом о наблюдаемой реальности ломает типичный паттерн, когда наблюдение просто констатируют.

The Problem: The challenge is keeping enterprise customers happy. This means the pressure to ship fast can’t hurt them.

Проблема: Вызов — сохранить enterprise-клиентов довольными. Это значит, что давление «ship быстрее» не должно им навредить.

The Solution: Direct about what LaunchDarkly does with technical specificity. But, framed around the likeliness that they have built internal tools for this. 

Решение: Прямо о том, что делает LaunchDarkly, с технической конкретикой. Но обрамлено допущением, что у них, скорее всего, есть собственные внутренние инструменты для этого.

The CTA: Just asks to see if a solution could be helpful. 

CTA: Просто спрашивает, могло бы решение быть полезным.

Formatting: Short paragraphs, easy to scan on mobile. The progression from observation → problem → ask → solution is clean and quick. (67 words)

Форматирование: Короткие абзацы, легко сканировать на мобильном. Прогрессия наблюдение → проблема → запрос → решение чистая и быстрая. (67 слов)

Selling to Individual Contributors (Engineers, Analysts, Security Specialists)

Продажи индивидуальным контрибьюторам (инженеры, аналитики, специалисты по безопасности)

Titles you're targeting: Software Engineer, Security Engineer, DevOps Engineer, SRE, Cloud Engineer, Product Analyst, Security Analyst, IT Specialist, Infrastructure Engineer, Application Security Engineer

Должности, на которые вы целитесь: Software Engineer, Security Engineer, DevOps Engineer, SRE, Cloud Engineer, Product Analyst, Security Analyst, IT Specialist, Infrastructure Engineer, Application Security Engineer

What the data says about ICs: Individual contributors reply at 5.3% — higher than directors, VPs, and managers. A-level emails push that to 8.0%, a 49% lift. ICs are one of the most responsive groups in the dataset.

Что говорят данные об IC: Индивидуальные контрибьюторы отвечают на 5,3% — выше, чем директора, VP и менеджеры. A-уровневые письма поднимают это до 8,0% — прирост 49%. ICs — одна из самых отзывчивых групп в датасете.

What this means for technical ICs specifically: ICs care about tools that make their work better. Period. Not org strategy, not executive priorities, the thing they're hands-on with every day. If they manage cloud infrastructure, talk about cloud infrastructure. If they run security scans, talk about security scanning.

Что это значит конкретно для технических IC: ICs волнуют тулы, которые делают их работу лучше. Точка. Не org-стратегия, не приоритеты руководства — а та штука, с которой они каждый день работают руками. Если они управляют облачной инфраструктурой, говорите об облачной инфраструктуре. Если они запускают security-сканы, говорите про сканирование безопасности.

The tone should be the most casual and direct across the seniority ladder. Brevity, clarity, and relevance are what drive replies. Salesy tones and vague positioning are what kill them.

Тон должен быть самым неформальным и прямым во всей seniority-лестнице. Краткость, ясность и релевантность — вот что приносит ответы. Sales-овые тона и расплывчатое позиционирование — вот что их убивает.

Important caveat: technical ICs often don't have buying authority. But they have massive influence. An engineer who says "we should look at this" to their manager carries more weight than a cold email to that same manager. Your goal is to start a technical conversation, not close a deal.

Важная оговорка: технические IC часто не имеют права закупки. Но у них огромное влияние. Инженер, который скажет своему менеджеру «нам стоит на это посмотреть», весит больше, чем холодное письмо тому же менеджеру. Ваша цель — начать технический разговор, а не закрыть сделку.

What to do

Что делать

Keep it short. Really short. Reference something specific about their technical environment or workflow. Ask a question about how they're handling something today. Don't pitch — discover. Let your email signature and their curiosity do the selling.

Будьте кратки. Очень кратки. Сошлитесь на что-то конкретное из их технического окружения или workflow. Задайте вопрос о том, как они сегодня с чем-то справляются. Не питчите — исследуйте. Пусть подпись в письме и их любопытство сделают продажу за вас.

What not to do

Что НЕ делать

Don't talk about ROI or business outcomes (that's not how ICs think). Don't write long emails. Don't use marketing language. And don't be salesy, they can’t buy. Technical ICs don’t have time to manage this and will delete your email mid-sentence if it reads like a pitch.

Не говорите о ROI или бизнес-результатах (IC не так мыслят). Не пишите длинные письма. Не используйте маркетинговый язык. И не будьте sales-овыми, они не могут покупать. У технических IC нет времени с этим разбираться, и они удалят ваше письмо на середине предложения, если оно читается как pitch.

You're an SDR at LaunchDarkly, emailing a Senior Software Engineer

Вы SDR в LaunchDarkly, пишете Senior Software Engineer

You noticed they recently merged a PR on GitHub that included a homegrown feature toggle implementation.

Вы заметили, что они недавно смерджили PR на GitHub с самописной реализацией feature toggle.

Sam,

Saw the PR on the feature toggle setup. Looks like you're building it in-house.

Are you wrapping all releases in flags today or just the risky ones? Curious how you're handling the cleanup on stale flags.

Asking bc that's usually where homegrown setups start to get painful at scale.

Sam, видел PR с настройкой feature toggle. Похоже, вы пилите это in-house. Вы оборачиваете в флаги все релизы или только рискованные? Любопытно, как вы справляетесь с чисткой stale-флагов. Спрашиваю, потому что обычно именно там самописные решения начинают болеть на масштабе.

Why it works:

Почему это работает:

Length: 47 words. Direct, technical, and 1:1.

Длина: 47 слов. Прямо, технично и один-в-один.

Personalization: Referencing a specific GitHub PR is about as personalized as you can get with an engineer. It signals: I actually looked at your work, not your LinkedIn.

Персонализация: Ссылка на конкретный GitHub PR — пожалуй, максимум персонализации, который можно сделать для инженера. Это сигнал: я реально смотрел вашу работу, а не LinkedIn.

Tone: "Curious," "asking bc" — informal, peer-level. No corporate language. No pitch. The abbreviation "bc" makes it feel like a Slack message.

Тон: «Curious», «asking bc» — неформально, на уровне peer-to-peer. Никакого корпоративного языка. Никакого pitch. Сокращение «bc» делает письмо похожим на сообщение в Slack.

The CTA: Two genuine technical questions ("all releases or just risky ones?" and "how are you handling stale flag cleanup?") that invite a conversation between practitioners. It says "I know you're not the budget holder" without being condescending. The problem (homegrown pain at scale) and solution (LaunchDarkly) are implied — and would be reinforced by the email signature.

CTA: Два искренних технических вопроса («все релизы или только рискованные?» и «как вы справляетесь с чисткой stale-флагов?»), которые приглашают к разговору между практиками. Это говорит «я знаю, что вы не держатель бюджета», но без снисхождения. Проблема (боль самописных решений на масштабе) и решение (LaunchDarkly) подразумеваются — и будут подкреплены подписью в письме.

The throughline

Сквозная мысль

Technical buyers are the hardest group to write cold emails to — not because they don't reply, but because the standard playbook for "good email" doesn't work the same way.

Технические покупатели — самая сложная группа для написания холодных писем, не потому что они не отвечают, а потому что стандартный плейбук «хорошего письма» работает с ними иначе.

For most departments, writing a polished, well-structured email reliably produces more replies. For engineering and product, authenticity matters more than polish. If your email sounds like it was written by someone who actually understands the work, you'll get a reply. If it sounds like it was written by someone who Googled some keywords, you won't — no matter how well-formatted it is.

Для большинства отделов написание отполированного, хорошо структурированного письма стабильно приносит больше ответов. Для engineering и product аутентичность важнее полированности. Если ваше письмо звучит так, будто его написал человек, реально понимающий работу, вам ответят. Если оно звучит так, будто его написал человек, который погуглил пару ключевых слов, — не ответят, как бы хорошо оно ни было оформлено.

But what changes across the seniority ladder is the scope of the technical context you bring.

Но то, что меняется по мере подъёма по seniority-лестнице, — это масштаб технического контекста, который вы приносите.

For a CTO or VP, it's about a company-level technical shift — a migration, a scaling challenge, a security posture change.

Для CTO или VP это про технический сдвиг уровня компании — миграция, вызов масштабирования, изменение security posture.

For a director, it's about the specific technical domain they own — their infrastructure, their product area, their security architecture.

Для директора это про конкретный технический домен, которым он владеет, — его инфраструктура, его продуктовая область, его архитектура безопасности.

For a manager, it's about the workflow tradeoffs they're navigating every week.

Для менеджера это про компромиссы в workflow, которые он каждую неделю прокручивает.

For an IC, it's about the tool, the repo, the config they're staring at today.

Для IC это про инструмент, репозиторий, конфиг, на который он сегодня смотрит.

The tone stays direct throughout. But the depth and specificity shift. And proof needs to be technical, not just impressive — named customers matter less than relevant architectures, concrete metrics, and evidence that you understand the constraints they're operating under.

Тон остаётся прямым на всех уровнях. Но глубина и конкретика меняются. И доказательства должны быть техническими, а не просто впечатляющими — известные клиенты значат меньше, чем релевантные архитектуры, конкретные метрики и доказательства того, что вы понимаете ограничения, в которых они работают.

89% of emails landing in engineering and product inboxes don't earn an A grade. But for this group, earning that A isn't about polishing your writing. It's about proving you belong in the conversation.

89% писем, попадающих в engineering- и product-инбоксы, не получают оценку A. Но для этой группы получить A — это не про шлифовку текста. Это про то, чтобы доказать, что вам место в разговоре.

That's how you earn a reply from someone who builds things for a living.

Вот так вы зарабатываете ответ от того, кто строит вещи на жизнь.

If you want to see the full benchmarking data across all departments, seniority levels, and industries, the Cold Email Benchmark Report is live.

Если хотите увидеть полные бенчмарк-данные по всем отделам, уровням seniority и индустриям, Cold Email Benchmark Report уже доступен.

And if you want to write emails like these — with real-time coaching adapted to your buyer — see what Lavender can do for you.

А если хотите писать такие письма — с реал-тайм коучингом, адаптированным под вашего покупателя — посмотрите, что Lavender может сделать для вас.

About the Author

Об авторе