Talent & Recruiting Strategy : Getting Your Talent & Technical Teams Speaking the Same Language

I am a Talent Engineer. Needless to say, I get a lot of inquiries, apprehensiveness, puzzlement and general confusion as to why someone in Talent feels that affixing Engineer to their title is warranted.

It’s worth noting that I did not come up with the term. That credit goes to my friend and mentor, Erin Wilson. Although Erin and I agree that using the word engineer is important, the statements below are my personal justifications.

Why Engineer?

Engineer noun (en·gi·neer \ˌen-jə-ˈnir\) : a person who has scientific training and who designs and builds complicated products, machines, systems, or structures: a person who specializes in a branch of engineering.

We are comfortable attaching the word engineer to people working with chemicals, machines, software and electronics, but why not talent? Some talent professionals design, and build complicated systems that grow companies. Just like Engineers! So why then, is our title attached to negative terms like “headhunter”? Why have words like “recruiting,” “sourcing,” “screening,” and “closing” taken on such negative connotations?

In order to change the paradigm of talent acquisition, we need to change the way we talk about our field.

Talent Engineering. The Engine.

A Talent Engineer is someone that is skilled in the function of building, running and maintaining an engine specific to recruiting, interviewing and hiring ( great talent). A Talent Engineer is a very specific type of recruiter, and I don’t think all recruiters should go and add engineer to their title. There is a difference between a recruiter, someone that sources candidates and facilitates interviews, and a Talent Engineer, someone who works on developing a process (engine) that operates within a company.

Think about your company as the machine, the process as the engine and each talented candidates as the fuel. You need all of them working properly for the machine to work. Even if you have the best engine in the world, you can’t go very far without fuel and limitless fuel can’t take you anywhere without an engine.

The crux of this article is not to defend my title, but to show you how working with engineering principles will improve your talent acquisition strategy and solve many of your talent woes.

Defining a Process

Would you ever ask a team of engineers to just “write code” with no established development methodology, deployment cadence or user-stories? No. Now, why do you assume that the best way to find a great hire is to just get as many candidates into your hiring process as possible? No. Now of course there are times when executing and iterating on the fly can work, but at scale? Probably not.

Just as you would approach an engineering challenge, filling a new role requires breaking down the process into smaller steps or stages. Doing so allows you to weigh the pros and cons of building new features, and a step-by-step recruiting process allows you to define the role and what you are looking for. That will allow you to weigh the pros and cons of building specific features (defining requirements for a candidate). Those that would take too much time to build (rare skill-sets) may not be worth the amount of time it takes to build them ( the amount of time it takes to find someone with those skills).

Work in Sprints

Using a well-defined yet customized software development process can do wonders for talent acquisition. Think about opening a position just like engineers think about launching a new feature. Engineers and project managers make informed predictions about what they can accomplish and set realistic expectations internally. Engineers are consistent, they don’t do two-week sprints, and then three-week sprints and then one-week sprints. No, once they set a pace for new feature releases, they stick to it. During an interview process, you shouldn’t do three rounds of interviews for one candidate, and then two for the next and then four for the one after that. Consistency is key.

Similarly, an engineer wouldn’t simply write code without some form of spec or user-story to guide them through their sprint. If they did, at the end of the sprint none of the code would work effectively or leverage the code previously written. Now think about that in terms of hiring. Don’t send your interviewers into each candidate meeting unprepared. Equip them with series of questions that will help determine if the candidate would be successful. Do this, and you are probably going to end up with a much more cohesive hiring decision


Ask an engineer about a time they worked with an undocumented code base. It has to be frustrating to stare at the work of another engineer or even your former self and have no idea why things were done a certain way. It is also frustrating to interview a candidate without understanding why they were moved forward, what concerns the past interviewers had and how the skill-set was vetted. The Talent equivalent of documentation is feedback. Just like good code documentation, candidate feedback that is well-written, thorough and input immediately after an interview (code is written) will help you and your colleagues out immensely. With an emphasis on WRITTEN and IMMEDIATE.

Some of the most worthwhile information you can gather from an interview is nuanced. The longer you wait to document the more the nuances fade away. Documentation helps alleviate redundancy in code and in recruiting it prevents us from asking the same interview questions over and over again. It often amazes me how people attempt to give feedback on a candidate they interviewed days or weeks later verbally.

Do a Retro

Agile software development proposes that reflecting helps team become more effective. This method helps engineers and can help talent professionals alike. After every interview reflect on what happened and what could be improved. This practice will give everyone involved a collective insight not only into the candidate’s experience but also into the experience of each of the interviewers. The idea is to make interviewing a shared experience amongst your team with the ability to walk away with action items that may allow them to iterate on their execution.

Speak the same language.

Talent Engineering is about using the same terms to explain and solve similar problems. People outside of the talent realm tend to have an adverse reaction to “talent-speak”, this is especially true with people in technology focused roles. Who can blame them? Engineers are constantly bombarded with emails from recruiters or recruiting agencies attempting to convince them to leave their job. I have read a lot of these emails. They are presumptive, assuming and for the most part are not relevant to their targeted audience. I have always found that the talent concepts are easier to grasp and better absorbed when they are explained in the nomenclature used by the targeted audience. Doing this will allow your Engineering team to empathize and relate to the problems you face.

Try it! Build out an interview process that mimics your Engineering process and get that talent engine going.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.