Effective communication is the key to success,especially when we are not acquainted with the person sitting opposite us. Words that may be common knowledge to recruiters may not be apparent to the candidates, causing a mismatch of expectation. The way we design the job post is actually the first impression that a candidate gets of the company. So, it is imperative that you nail down the job post to attract the best candidates.
(P.S. – Yanko Design Job Board removes such mismatch by connecting you to your target candidate)
The write-up below comes from Bruno Bergher (VP of Design at Gladly) who has been on both sides of the table and shares on how to write a job description that works as an effective communication tool for the company.
Role ambiguity sucks. It leads to disappointed employees, wasted time, failed interviewing processes. If people don’t know exactly what their role is, they can’t perform. If managers don’t define clearly the roles of their employees, they can’t assess their performance. And a lot of that frustration comes, in my experience, from sucky job descriptions.
You probably think job descriptions are terribly boring. I won’t judge you. Most of the time they’re boilerplate text; when writing new ones, hiring managers tend to just copy the last one they used, tweak it a little bit, and publish. If you write them this way, then they’re certainly boring.
I see things differently though: if you design your JDs — instead of writing them — you can turn lifeless documents into an alignment-producing, consensus-driving, ever-evolving communication tool. It leads to effective interviewing, and ultimately to role clarity. I can also find them pretty exciting, but please don’t judge me.
Here I propose that if you approach them as a design project (define the problem, understand your users, generate low-fidelity solutions, iterate), you’ll end up with results which will leave you as excited about them as me.
Keep in mind this approach is most useful for new positions — when you’re hiring the first 2 or 3 people with a certain title (for example, your first few engineers) or creating a completely new role within the company (think hiring the first designer, marketer, salesperson, HR lead, etc).
By the time you’re hiring your 19th designer or your 57th engineer, you should have a job description which is extensible to dozens of roles and a systematized interview process. In other words, I can’t imagine this approach being too useful for a big company.
Purpose
The first key differentiation is between job descriptions and job posts. Posts are a concrete manifestation of descriptions, and can perhaps help attract great candidates, or at least clarify roles. But they’re just text documents. Job descriptions are the soul of job posts.
JDs define what you’re looking for — and very importantly, what you’re not looking for. They take the infinite pool of possible candidates and draw a line around what’s acceptable, and leaving what isn’t outside. A great job description is one with a sharp boundary, removing the blurriness which leads to ambiguity.
Audience
The second key differentiation is about who benefits from JDs. Yes, job posts are for external candidates, but the main audience of the job description itself is actually internal. A great JD is actionable: it lets recruiters identify who to reach out to, it lets employees know who to refer, and above all, it defines the hard criteria for the interviewing team to evaluate.
So instead of writing an ad (aspirational, non-specific, over-inclusive), approach the problem as if you were writing product specifications (straightforward, actionable, uncompromising).
Structure
When you create a new role, especially one with no existing parallels within the team, you’re in fact going through an exercise of defining the boundaries of a very amorphous set of attributes. You hopefully know what the job will entail, and have an idea of what type of professional would be suitable for it, but it doesn’t mean that just anyone with a certain set of skills (or worse: a set certifications/experience) will be the right fit.
When interviewing candidates you’re looking at several other aspects, and you should reflect them in your job description. I approach this by breaking these characteristics into three categories: responsibilities, profile and skills/experience.
Responsibilities: what the hire will do.
Clear, concrete, objective tasks the candidate will execute day-to-day, or be responsible for supervising. This is where you come to full agreement about how far the role extends and define the main criteria upon which performance will be evaluated later on. While this list must encompass the primary technical needs of the job, it should also include secondary but important responsibilities – or even aspirational goals.
Examples: collaborate on product strategy; execute on visual design; maintain database infrastructure; educate salespeople on product features; manage customer acquisition for the product; develop the department’s hiring brand; publish articles in industry publications.
Profile: what are they like.
Objective descriptions of subjective individual characteristics. This is where you draw the line about the temperament, values, social skills and priorities your candidate will need to excel on the job. I see these often taking the shape of an adjective followed by an explanation.
Examples: pragmatic, visionary, flexible, disciplined, charismatic, driven, communicative, results-focused, team-oriented, humble, inspiring, flexible.
What’s really important here is not to just dump a bunch of adjectives into a list. The adjectives in the examples above are all positive, but it’s unlikely that someone would be both pragmatic and visionary at the same time, or that you’d be able to find someone who equally humble and inspiring. Use this opportunity to figure our exactly who you need on your team.
Skills/Experience: what they must have done before.
Justifiable skills which are needed for the job, and/or the experience to prove them. This is the kind of thing you’ll evaluate in resumes and exercises. Be thoughtful about what you actually need here and of true ways of assessing it.
Examples: ability to present in front of large audiences, complete fluency in Ruby on Rails, basic HTML/CSS prototyping knowledge, SPHR certification, good written communication skills, excellent analytical skills.
Ideate (Low-Fidelity)
In my experience, the best way to come up with a representative list of items for each of these is to bring stakeholders (people who will interact with who fills the role and/or be significantly affected by them) into a room and have a short brainstorm session. 5 to 7 minutes for each category seems to be enough but will still make it a generative session, and uncover important attributes which would perhaps not be uncovered if you were just writing them by yourself.
As the facilitator, make sure to introduce controversial points and encourage discussion, so you can achieve the clear boundary lines of the role we discussed above. In this process, sticky notes and whiteboards are definitely your friends.
The output of this phase should be a series of unpolished bullet points, grouped into the three categories. Worry about meaning, not polish, and make sure you have clear agreement/understanding among stakeholders.
Refine (High-Fidelity)
Once you’ve established the requirements, you can write the job post. Now is the time to turn those characteristics into a cohesive, compelling, external-facing articulation of the role. This is a general structure which works for me, trying to order content in a funnel relevant to the candidate:
- Company intro. “Who are these people?”
- Role intro. “Why are they hiring for this position? Is this roughly something I’d want to do? Who would I report to?”
- Responsibilities. “What would I do day-to-day exactly?”
- Profile. “Are they looking for someone like me?”
- Skills/Experience. “Would I meet their requirements?”
- Extra role info. “What are the benefits? Any perks?”
But please go beyond descriptive copy. While you should absolutely be clear and concise, this is a great opportunity to express your hiring brand.
I actually believe it’s a good idea for different departments or different hiring managers to use slightly different tones in their job posts. Some teams are more serious, other more on the funny side, some are competitive, other very collaborative, and that should be reflected here.
Iteration
Before publishing the job post, make sure to gather feedback from the stakeholders. It’s a good opportunity to see if anything went missing as you brought the JD to higher fidelity, or if people thought of missing attributes in the meantime.
Once you start interviewing candidates, you’ll most likely notice details about the job which you didn’t anticipate earlier in that process. You might notice for example that all candidates ask about the full range of responsibilities; or that perhaps it’s unclear to whom they’d report.
This is user feedback! Use these opportunities to come back to the document you’ve prepared and update it with answers to those questions. Share it with the team, clarify the role further, update the job post. It will only make interviewing later down the line and help screen bad fits early on.
Yanko Design has a long established designer following that you can connect to by publishing your requirement on our network. We know that YD Job Board will connect you to the best designers as they follow the best content published by us. Post a job and get featured on our extensive Social Media network.
The original write-up on Medium can be found here.
via https://ift.tt/heniQP
Post a Comment
Note: Only a member of this blog may post a comment.