The Design of Job Descriptions
A bottom-up, alignment-oriented approach
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.
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.
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).
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.
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.
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.
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.
If you choose to follow this approach, please let me know, I’d love to hear your experience. And if you have any questions, please add them to the comments or get in touch.
You should consider following me on Twitter.