The approaching message is the initial point at which the recruiters have the chance to get the attention of their candidates, or the opposite, to miss the opportunity to talk (you could also read “pitch”) and present them the job they think fits them. Basically, at this initial moment my candidates can be won into a discussion and recruited for the role I am looking to fill or, on the contrary, I loose them and get ignored.
More than anywhere else, it is critical I build a suitable message with an impact that not only attracts attention, but also generates interest and curiosity on the part of the candidate. Things are like this, as developers represent a professional category constantly assailed with offers about new professional opportunities.
For this reason, if you understand what works and what does lead to failure when writing the approaching message you send to a developer, you can often make the difference between a mediocre results and good, desired results that will help you close the job much sooner.
In this first article out of a series of three, you will be introduced to the first mistake most recruiters do when approaching an IT candidate, whether is on Linkedin, Xing or Stack Overflow. The reason I chose these 3 mistakes is because they are widely spread and very common.
Saying too much, too early – clutters the candidates with information without probing their availability
The vast majority of recruiters’ approaching messages in IT recruiting are read on mobile devices. From my point of view, this means that to get a reaction (preferably positive, to continue the discussion) from a candidate, ideally the message does not require scrolling. Long, complex messages with a lot of information are a very common mistake and can be equated with trying to say a poem on a single breath. Trying to get too much, too fast, is often a sure way to get nothing in the end.
What do messages like “too much, too early” contain?
- All technologies included in job description
- A lot of information about the project in which the candidate will work in;
- Description of the company that hires
- A variety of links, to ATS, company website, future team, project etc.
Why is this a mistake?
It forces the developers to consume too many resources for something that 5 seconds before did not even exist in their minds. In case their even remotely willing to engage in such daunting tasks.
What resources does the candidate consume during the process?
The most important, would be 3: time, attention, decision
- Time – reading a wall of text, consumes ineffectively the time of a developer. Besides, if your text is presented as a uniform and condensed block, without paragraphs, spacing and optimal introduction of information, the time your candidates should allocate to such a message that also contains links requiring to be accessed, becomes a decision that needs a to do list attention. “what goals do I have for today? To read up to 5 Tolstoy “War and Peace” like river messages with included links … I would read more, but a day has only 24 hours”.
- Attention – If I want navigate through a message that contains information about a lot of separate things (from the company the recruiter represents, up to the detailed steps of the recruitment process, the technologies used and the stage of development of the project for which the developer is recruited for) it will require me mental effort, or… pending. What may be harder to understand for some of us in IT recruiting is that this kind of message, have it all template like, are read while the candidate is at work. The level of attention these messages require could impair the quality of coding at work for most developers. What happens then? Guess what! Your candidates will choose to be attentive on their work and, and give very close to none volume of active RAM memory (aka “attention) in their minds to your messages. That is when you got dockerized in “pending” mode within a 0 allocated resources application, namely, no reaction from their side.
- Decision – when you are dealing with a large amount of information to be processed, the decision, which contains not only what you do, but a lot of what you choose not to do, becomes difficult to format. Basically, not only do the developers have to process a lot of information, but they are in the position of having to do it without even being able to question the essential ingredient of any career decision: the need for change! Do I need or want to change something in my career, RIGHT NOW?
All this information is useful and essential in the recruitment process. The problem is not their volume and variety, but their early exposure during recruitment process to a candidate who had previously shown zero interest in learning about them.
And thus we come to the two major shortcomings that have it all first message suffers:
- Does not previously probe the developer’s interest, availability, or curiosity. If I could not send these messages in writing on Linkedin, let’s say, could I use them to approach a candidate live while walking down the street? I would say no.
- Presents a plethora of information that refers to subsequent stages that are relevant only later. It’s like I have a first romantic date where I am presented with all the subsequent details of a possible marriage. Who does this?
Test the candidates’ readiness or curiosity before asking them to go through too much information about which they had no previous interest. It will be a lot easier for them to take the decision of talking to you. Keep in mind, it’s a first date, not a prenuptial agreement. Pace yourself and run the process step by step!