Your Ineffective Job Descriptions are So Last Century

I’ve been skimming over the Silicon Valley job descriptions for the past few months. And practically all the job postings look the same, with the trite conventional wordings that have been in use for the last 20 to 30 years. They contain a lot of fluffy words, with minimal impact. 

To me, the job descriptions are stuck in the patterns of the 1990s (when I first entered the workforce). Job descriptions seem to be all about checkboxes, buzzwords, and catchphrases – nothing more.

Here are a few examples of job descriptions that I’ve seen on LinkedIn (I’ve changed a few words to obfuscate actual companies):

  • Company X is seeking an individual with rich experiential depth in the classical program management paradigm of balancing venture against core product initiatives within the linear constraints of scope, time, cost, and quality.
  • We believe in empowering our teams to own all aspects of bringing Company B to life. As a software engineer, you’ll get the opportunity to make key contributions across our engineering stack – this includes developing and improving frameworks across our frontend and backend services, in addition to making direct contributions to your team’s product area.
  • What You’ll Bring to The Table: 3+ years of experience as a Software Engineer and a Bachelor’s degree in Computer Science, or equivalent work experience. Strong coding abilities in at least one language. Python or Java experience preferred. Experience building and deploying flexible backend systems at scale. Strong fundamental understanding of data structures and algorithms. Strong collaboration and communication skills, both verbal and written. Ability to be flexible and adaptable in a dynamic startup environment. Strong desire to learn about new technologies and systems.

Notice the pattern? It’s a lot of very generic stuff. Ho-hum. Very boring.

 

Join Us - cropped

And because it’s generic stuff, guess what – the resumes you attract will also be somewhat generic. The resumes you get will tick off the checkboxes of your requirements. Yes, I’ve worked to balance initiatives against constraints of time, scope, cost, and quality. Sure, I have fantastic verbal and written skills – can’t you see it already in my resume with similar buzzwords?

Shifting the Job Description: More Outcomes, Less Outputs

A majority of the world has shifted to Agile since the Agile Manifesto was published in 2001. And yet the Recruiting paradigms seem to be stuck in the past, not moving forward all these years. How do you start changing the way you recruit through your job descriptions (or, conversely, the way you present yourself on resumes)?

Agile has always been about value and outcomes (though many people still think it’s all about processes like Scrum or outputs like a backlog or story map release plan). Checkboxes like Programming in Python, or Ability to Lead Product Initiatives with Constraints, are still needed to provide a baseline for the types of candidates you want to attract. But they don’t have to take up a majority of what you provide in your job description. 

One way to start bringing the job descriptions forward to today is patterning it after the Agile principles. Why not highlight the outcomes that your delivery teams have achieved, instead of concentrating on a checklist of outputs? Show real examples in your job descriptions by highlighting actual stories of what your teams have accomplished. Heck, if I see these kinds of stories, I’d feel more inspired and more likely to apply for that job, since I’d like to be in on the fun and experience. 

Here is how I would have changed a few of the above examples:

  • Our program managers help our executives providing easily readable dashboards of our delivery team capacities. These dashboards help executives make decisions faster, shortening our strategic planning meetings from a full day to just one hour.
  • Our engineering teams are very empowered to solve problems in both the frontend and backend. Along with their respective product managers and customer support reps, they have devised solutions that helped propel our product to fantastic reviews. Our reviews on the Apple and Google App Stores went from an average of 3.2 stars to 4.6 stars in the last two years.
  • What You’ll Bring to The Table: 3+ years of experience as a Software Engineer and a Bachelor’s degree in Computer Science, or equivalent work experience. Your strong coding abilities in any language (Java and Python preferred) will further help our teams scale up and build flexible systems. Our teams are continuing to build flexible backends and automation that enabled us to scale from a single colo to 4 regional data centers. Our deploy process used to take 5 hours for a single colo with 35 machines. We’ve now brought it down to 3.5 hours for all four regional data centers with hundreds of machines, and are looking to bring it down to 2 or less.

Of course, I made-up the changes from the initial copies I got from LinkedIn. I hope, though, that what I did shows you what I mean by using real value and outcomes of your teams in your job descriptions. Doing these kinds of changes will make your job descriptions more effective. It gives people a better idea of your organization and what it values. And it’s another way to differentiate your company from all the others. Job descriptions like these show potential applicants what’s in store from them, aside from the trite benefits packages that also seem to be highlighted in these job descriptions.

And if you were a potential applicant, wouldn’t you clamor to work at a company when you see job descriptions such as these?

Are you ready for next year’s performance review cycle?

Part 2 of 3

I kicked off this series on preparing for next year’s performance reviews with my first suggestion – have a monthly 1:1 with your manager, dedicated to your performance and career.

Now, onward to my second suggestion:

Businessman running with briefcase

Suggestion 2 of 3:

Document your monthly performance reviews like a monthly diary.

I suggest writing down whatever you’ve discussed with your manager regarding your performance somewhere – a notebook or a Google doc, for example. Keep it lightweight – limit it to one page or less, but don’t scrimp too much on the details. At the end of a year, you should have a page for each month.

Your diary should have pertinent details over time. Write down things that you’ve learned and how you’ve leveraged them in your job. Chronicle what you’ve accomplished and achieved, including the resulting outcomes of your efforts. 

Most people focus on outputs: “did X number of code reviews” or “launched Y version of the product with these features” or “mentored two new hires and an intern.” These outputs may look useful, but what’s better is to write down the outcomes. How did your code reviews help the team? Were your team members’ skills up-leveled? The new features you released – how did those impact customer retention, or how did that increase sales opportunities? Having these outcomes shows your impact and can be used to highlight achievements for possible promotions.

And – depending on what your company uses – write your goals down in these monthly diary entries. Write down your OKRs (Objectives and Key Results) or MBOs (Management by Objectives) in your monthly diary entries. 

More important than the goal, though, is the journey you’re going to take in the next year to meet this goal. Just as a long road trip from San Francisco to New York City requires you to map out your routes and where you’ll stop along the way, your goal should have a possible journey that can show progress stops. 

Having these journey stops mapped out in your diary shows how you’re going to achieve your goal. And – like a road trip – you can always change the route along the way, or even the end destination – depending on how the year unfolds. You might want to end up in Boston instead of New York City, for example.

I hope this second suggestion has started the gears of your mind moving along. I would love to hear any intriguing thoughts you may have about this.

In the meantime, until the next newsletter, cheers!

-JF

Are you ready for next year’s performance review cycle?

Part 1 of 3

So, are you ready for next year’s performance review cycle? We’ve all been living with a pandemic for a majority of this year, with almost everyone working remotely. The usual visual cues of physically seeing people at work are out the door. Which begs the question – do people “see” how you’re performing in this new world of virtual work? Remember the saying – out of sight, out of mind. Will that come to haunt you come performance review time in 2021?

I have three suggestions for you so that you’re more prepared. These suggestions should help come performance review time next year. (I’m making an assumption you’re company’s performance review cycle happens during the first quarter of every year.)

Businessman ready to sprint on starting line

Suggestion 1 of 3:

Each month, dedicate one of your 1:1s with your manager to lightweight performance discussions.

Your performance review relies on what your manager says and writes. Most people receive feedback very late, given that the performance cycle happens once a year. The only time you receive immediate feedback is usually when something negative comes up. And generally, under these circumstances, you might be put on a PIP (Performance Improvement Plan). 

Good, consistent performance is seldom brought up. Or if it does get brought up, it’s usually spoken in general terms. And depending on how many people report to your manager, your manager may not necessarily see or bring these up regularly.

Most good managers I know have regularly scheduled one-on-ones – either weekly or bi-weekly. So, dedicate one of these meetings each month to talk about your performance – both good and bad, so that you get time-appropriate feedback immediately.

Your manager might be surprised if you bring this up since he/she/they might not be used to having these discussions out of cycle. Let them know the benefits. One of the universal pain points of yearly performance discussions is the recency effect – people can only remember the last two months, maybe three at best.

Well, that’s it for this week’s newsletter. I hope this first part intrigues you, and that you’re looking forward to my next newsletter. In the meantime, feel free to e-mail me if you have any questions about this first suggestion.

Cheers, 

-JF