A Good Recruiter Message Is a Small Technical Brief.

Developers rarely object to being contacted; they object to having to perform unpaid discovery before they can decide whether a conversation is worth having.

Most developers do not object to being contacted.

They object to having to perform unpaid discovery before they can decide whether a conversation is worth having.

An opening message that says “I have an exciting opportunity that matches your background” gives the developer almost nothing to evaluate. The next step is usually a call, where they are expected to discover the company, role, location, employment model, salary range, stack, seniority, and actual problem one question at a time.

That is not a conversation yet. It is a filtering task transferred to the person who received the message.

A better recruiter message is a small technical brief. It does not need to be long, and it does not need to reveal confidential information. It needs to contain enough context for a developer to make an informed decision without opening a calendar.

This helps both sides. Developers spend less time on conversations that were never plausible. Recruiters get fewer polite but unqualified replies and a clearer reason when someone says no.

The first message has one job

The first message is not supposed to close the candidate. Its job is to make the next decision easy.

For the developer, that decision is usually one of three things:

• this is clearly not relevant;
• this could be a fit, but I need one missing detail;
• this is worth a proper conversation.

A message can support those decisions without becoming a job description. It should answer the questions that change the decision, not include every benefit, acronym, or sentence from the requisition.

The practical test is simple:

Could a developer reject this opportunity for a clear reason without taking a call?

If the answer is no, the message probably withholds too much information.

The six parts of a useful recruiter brief

1. Say who is hiring

Name the company unless there is a specific and credible reason not to. Include the product or business context in one sentence.

“A Series B fintech” is not the same signal as “a 90-person payments company building the ledger and reconciliation systems used by European merchants.” The second description gives the developer something concrete to recognise or rule out.

If the search is confidential, say so plainly and explain when the name can be shared. “I can share the company after an NDA” is a process detail, not a substitute for context. Give the industry, stage, product, and reason for confidentiality when possible.

2. Describe the problem, not only the title

Titles travel badly between companies. “Staff Engineer” can mean architecture ownership, a platform team, technical leadership across several squads, or a senior individual contributor with a different title.

Describe the problem the person would own:

The team is splitting a high-traffic monolith into independently deployable services while keeping the current checkout flow stable. The role would own service boundaries, migration sequencing, and the operational model with two other senior engineers.

That gives a developer more useful information than “we are looking for a Staff Backend Engineer with microservices experience.” It also makes the approach more personal without relying on empty praise.

3. Separate must-haves from searchable keywords

Most developers expect a role to have requirements. They do not expect every technology mentioned in the company’s history to be a hard filter.

Distinguish between:

• essential for the first months: for example, production ownership of distributed systems;
• useful but learnable: for example, a specific cloud provider or framework;
• context only: tools used elsewhere in the organisation.

This distinction matters especially for senior developers. A person may be a strong fit for the problem while missing one item in the stack. Conversely, they may match every keyword without having owned the relevant decisions.

A recruiter does not need to make the technical assessment alone. They do need to represent the role accurately enough that the developer can decide whether their experience is relevant.

4. Put the working conditions near the top

Location and compensation are not administrative details to reveal after interest has been manufactured. They determine whether a role is possible.

For European developers, include the practical conditions that affect the conversation:

• country or countries where the employer can hire;
• remote, hybrid, or office expectation;
• meaningful time-zone overlap;
• employment, B2B, or contractor model;
• salary or rate range, including currency and whether it is gross or net when relevant;
• expected start date and interview shape.

Some details may genuinely vary by country. Say that rather than hiding the entire range. “€85k–€105k gross base depending on country, plus the stated equity package” is more useful than “competitive compensation.”

Clear conditions do not make a role feel transactional. They make it possible to have a respectful conversation with the right people.

5. Explain why this person was contacted

Personalisation should be evidence-based, not flattering.

“Your profile is impressive” is not a reason. “I noticed you led a PostgreSQL migration while keeping the existing API compatible; this role has a similar data migration problem” is a reason.

The reference does not need to be perfect. It needs to show that someone looked at the developer’s work and can explain the connection in one sentence. If the recruiter cannot name the connection, the message may be too broad to send.

This also gives the developer a useful correction path. They can say, “That project is not representative of the work I want now,” or “I was involved, but I did not own that area.” A specific reason creates a better no as well as a better yes.

6. Make the requested next step small

Do not ask for a 45-minute call as the only possible reply. Offer an easy next step that lets the developer request missing context or decline without friction.

For example:

If the problem and conditions look relevant, I can send the full role brief or answer questions here before we schedule anything. If it is not a fit, a quick no is completely fine.

The developer should not need to protect the recruiter’s feelings in order to protect their own time. A clear opt-out is part of good outreach, not a sign that the recruiter lacks confidence.

A copyable first-message template

Here is a compact structure that works for a serious first approach:

Hi [name] — I’m recruiting for [company], a [product/context] company based in [location].

The team is working on [specific technical or product problem]. This role would own [scope and decisions], with [team or reporting context]. The important experience is [one or two capabilities]; [specific technology] is useful but not a hard requirement.

The role is [remote/hybrid/office] for people who can work in [time-zone condition], using a [employment/B2B] model. The range is [range and currency], and the likely start window is [timeframe].

I reached out because [specific evidence from the developer’s work] seems relevant to [the problem]. Would you like the full brief here? No problem at all if the scope or conditions are not right.

This is enough to start a real decision. It is not enough to answer every question, and that is fine. The purpose is to make the next exchange informed rather than to turn the first message into a complete interview pack.

What developers should ask for when the message is vague

Developers do not have to write a long explanation when an approach is missing context. A short reply can convert a generic message into a test of whether the sender has a real brief:

Thanks for reaching out. Before I decide whether to schedule time, could you share the company, the problem this role owns, location/work model, engagement type, compensation range, and expected start date? I’m currently most interested in [focus] and can consider [availability condition].

If the recruiter answers directly, the conversation may be worth continuing. If they avoid the questions and send another request for a call, that is useful information too.

A public profile can make this even easier by stating the developer’s focus, location, availability, engagement preferences, and contact requirements in one place. The profile is not an invitation to contact someone about anything. It is routing information for a better first conversation.

Why this is not anti-recruiter

It is tempting to frame recruiter outreach as a conflict between developers defending their inboxes and recruiters trying to maximise response rates. That framing creates bad incentives.

Recruiters also lose time to vague roles, incomplete internal briefs, changing requirements, and candidates who were never eligible under the real conditions. A structured first message exposes those problems earlier. It may reduce the number of replies, but it increases the proportion of replies that can become useful conversations.

The goal is not to make every recruiter write like an engineer. It is to make the request specific enough that a developer can understand what they are being asked to consider.

The same standard should apply to developer profiles. A profile that says only “open to opportunities” asks recruiters to do the same unpaid discovery. State the problems you want to work on, the scope you can own, the conditions that matter, and the kind of message you will respond to.

Good matching is not produced by making either side more available. It is produced by making the relevant context visible before either side spends significant time.

A better definition of response quality

Recruiter outreach is often measured by reply rate. That number is easy to understand and easy to distort.

A better set of questions is:

• Did the developer have enough context to make a decision?
• Did the message explain a real connection to their work?
• Could the developer decline without a follow-up campaign?
• Did the recruiter learn something useful from the response?
• If there was a call, did both sides arrive with the same understanding of the role?

The best result is not always a positive reply. A clear, early no protects the developer’s time, saves the recruiter a sequence of follow-ups, and keeps the channel usable for a future role that may actually fit.

That is the standard a developer marketplace should support: contact that earns attention through context, not contact that assumes access to it.

If you are a senior developer in Europe, you can create a public Reachdev profile with your focus, availability, and contact terms. Use it as a professional link even before a marketplace conversation appears, and let serious recruiters understand the conditions before they ask for your time.