I’ve recently had the opportunity to give feedback on, think about, and even write some job descriptions in various contexts. This led me to reflect a lot on how I’ve used job descriptions as a tool to help me throughout my career in software development, and even leap me to different positions quickly. I’d like to share some of that experience with you.
One of the first things I did as a new software developer was read through the job description at my new workplace a few times. I had saved a copy from my application, and I found it really useful to solidify what the expectations for me were. That said, it was good I had saved it — not all companies are great about keeping job descriptions openly available. I’ve seen colleagues have to go to their company’s hiring page to be able to pull their role and the next role up, and those are often only available if the company is actively hiring in those positions.
For anyone reading this who has control over the availability of job descriptions: Don’t hide them. Literally everyone benefits from being able to refer regularly to what they’re supposed to be doing and what they would do at the next level. Having these documents accessible also enables everyone to take charge of their own learning and career goals, which can help make career progression more equitable.
Anyway! Once I had reviewed my position, my 1-on-1s became much more productive. It’s a lot easier to go into a conversation with your manager and say “Hey, I’m supposed to know how to do X but it’s never come up,” and push for those opportunities when you know what X is. Without clear expectations, it’s far easier to end up in a situation where you’re surprised with a bad performance review. If you’re lucky enough to also have a technical mentor, knowing what languages or frameworks are the company’s focus — now and on the horizon — helps to direct the resources and training they can point you towards.
So once you know what you’re supposed to be doing, you need to get the job description for the next position you want. This is partially to direct any training/learning/coaching you’re doing, but also to make promotion conversations infinitely easier. Having worked at a place with clear job descriptions easily available (and a progression matrix, and mentorship programs — it was awesome) all I had to do was pull up the next level and say “I’m already doing all this, can I be promoted?” It was like flipping into easy mode, and my manager instantly got the process in motion.
For places that have weaker job descriptions, the conversation might need to shift to something like “Hey, I think I’m doing all the stuff for the next level, what am I missing?” I’ve had this conversation too. Sometimes the answer is “Nothing, let’s get on this.” Other times it’s “Well, there’s this one thing you need to get stronger at first.”
If you’re horribly unlucky, the answer will be something out of both your and your manager’s control, like budget constraints or arbitrary expectations of time in the previous role. This situation is awful and frustrating, and most companies do what they can to help you when you’re stuck this way. It’s not uncommon for people to just leave instead of waiting for the issue to resolve itself.
You did it! You got your promotion and did the happy dance and started getting comfortable in the new role! Now it’s time for job descriptions to take on another role: Helping you help your team.
If you’re now in a senior or staff role, mentorship might be explicitly part of your duties. If you’re an intermediate, voluntarily mentoring junior developers will help both you and them grow. The easiest way to mentor? Grab that set of expectations and start guiding your mentee through them.
This really is a bit of a cheat code for coaching or mentorship:
“Hey, you need to get really good at Peer Reviews for the next level. Let’s pair on some until you get comfortable!”
“I noticed you don’t talk in planning. In order to get to a more senior position you need to practice speaking up, whether or not you know the right answer.”
“You seem really interested in Agile stuff. We have a training program for Scrum Leaders, would you want to start on that path?”
If you have career paths and job descriptions at each level, it’s clear what strengths a person needs to develop to get to their end goal. There’s less possibility of your biases (everyone has them) directing the goals as more of the process is self-directed by the mentee. Using these tools and the mentee’s feedback you can create a game plan that can guide a relationship for years.
Now you’ve climbed the ladder, you’re at the top, and writing job descriptions has fallen to you. This is a big, intimidating responsibility. Hopefully enabling and empowering your employees to self-direct their own career growth is a big enough motivator to get the job done. If not, there’s another huge advantage to job descriptions: directing the entire company culture.
You want a strong culture of mentorship? Now mentorship is an official responsibility at every level. You care a lot about test driven development? Looks like TDD just became a core competency. Brand image and knowledge sharing are important? You might want to add some developer advocate positions, or make technical blogging a requirement.
There are lots of subtle culture pushes you can make through careful writing of job descriptions. Clearly written competencies and responsibilities can make clear to everyone what the company values. Spending the time to really think about what you want that culture to be and how to make it obvious to all is always worth it.
Whether just starting your software development career or many years down the path, job descriptions have a lot to offer. For guiding your own career, helping to guide others, or shifting an entire company’s culture, these documents are essential. Make sure they’re clear, accurate, and accessible and you’ll reap the benefits.