Job descriptions that work

If you’ve managed people before, you’ve probably been there. Somebody on your team decides to head out for greener pastures and you need to backfill. You also need to figure out how to get their work done without overburdening the rest of your team.

As you wade through a process with HR and Finance to get the job requisition opened, at some point, you need a job description. So you go in the wayback machine and dust off whatever was used in the past. Or maybe your HR person does this for you (because you are busy, right?). Or maybe you don’t have a starting point so your HR person hops on google and does some cutting and pasting.

You know you’ve been there; I certainly have.

This, however, is not an area where you want to press the ‘easy button.’ It’s worth a bit of time investment to get it right.

I reviewed the archetypes of poor job descriptions a few months ago, but let me summarize the common issues we see in security:

• Excessive years of experience with technology XYZ. Yes, it is true that there are highly specialized architect-level roles for larger companies that require deep expertise. But there are far too many that assume that technologies can’t be learned, particularly if the job is to operate and maintain instead of integrate and design.
• Requirements that are not aligned with market pay. You are not going to get a pro with 10 years of security experience for $95K. Sorry.
• Laundry lists of responsibilities. Don’t throw in the kitchen sink.
• Titles that aren’t aligned with responsibilities. Similar to the above, responsibilities are often in line with more senior roles when the titles are more junior, to try to game the comp system.
• Including educational requirements. Generally speaking, these shouldn’t be necessary in our industry. You are better off directly getting a sense for what somebody knows, how bright they are, and how hard they work. Education is a poor proxy in security.
• Just being sloppy. Things that are cut and pated in that clearly don’t align; using words that no real human would actually use; stuffing the JD with boilerplate.

Why does this matter?

• Job descriptions are your advertisement to the world. In a market where supply is significantly less than demand, you should really focus on your first impression. It matters.
• Most recruiters don’t know security and will take the JD as verbatim. This means that as they narrow the funnel to match all your requirements, there won’t be many people left at the end, and the ones that are there will cost more than you can afford.
• If you have excessive experience requirements, you will miss out on potentially amazing candidates that are able to learn quickly, and that you can afford (and who are more likely to be loyal)

So, enough of what not to do. Let’s talk about what good looks like.

1) Ensure title, responsibilities, and comp are all synched up (and please do be transparent about comp)

2) Be simple, clear, and concise. Keep bullet points limited. Use language that real people do. Avoid ‘corporate talk’.

3) Keep to a standard, clean format. It should be:

• Company and job summary
• Responsibilities
• Requirements
• Benefits/ additional information

 The below JD does a nice job of all the above points:

4) Go one layer deeper to get to the skills you really need, not poor proxies for them.

• Describe what you want people to know and be proficient with
• Don’t use education as a proxy
• In your hiring process, test these skills directly

See this example from JPMC for an application pen tester:

5) Develop other content in and around the job description to make you and the company stand out

• Include a summary of the company and why it is an exciting place. But do this in simple, relatable terms, not terms that come across as HR boilerplate. 
• Add a ‘a day in the life’
• Create a video job description to build an initial degree of familiarity with the hiring manager and the culture

‍