Software engineers have the highest turnover rate of any industry with an average tenure of 2~3 years. Why? Because people leave managers, not companies, and as Nicole Sanchez and Danilo Campos point out, tech is full of poor managers. I’ve been one of them!
Part of what makes a poor manager is a lack of investment into the day-to-day activities of management and an over-emphasis on the day-to-day activities of a practitioner. One of these day-to-day management activities is understanding the work that is being done, why it’s being done, and how it’s being done. Because this is a constantly adapting answer, it’s important to spend time communicating these things to potential new-hires and existing team members. How else can we expect others to understand what is expected of them? Or what a growth trajectory could look like within your team or broader organization? One way to communicate this is to write job descriptions.
It’s very very tempting to rely on job titles as a proxy for a job description. But when we rely mostly on job titles we are implicitly considering three things: the skills we’re looking for, the level those skills are at, and what behaviors we want to encourage or discourage. This reduction collapses context and we wind up posting think-pieces about “what does ‘senior’ even mean anyway?” or twitter rants declaring “devops is distinct from site reliability engineering!”. That communication to the future hire or to the team often does not occur.
To communicate the necessary skills and levels and behaviors you seek, write a job description with clearly written expectations about what skills at which level are necessary for the given job titles activities within your team or departments context.
“Ugh” you grunt. “I read my job description, the most important phrase was ‘other duties as assigned!’” And you’re right. A lot of job descriptions are miserable. They’re written under duress by overloaded engineering managers trying to satisfy HR while simultaneously navigating the difficulties of leading an engineering team towards accomplishing the organization’s goals.
As a result, job descriptions are often a list of buzzwords tied to the technology stack with years of experience assigned. It’s the simplest path towards a somewhat valid job description. Plus it allows the recruiting team to write job posts and perform pass/fail analysis of candidate resumes or brief phone calls.
We can do better, and our current and future employees and team mates deserve better. They deserve a functional understanding of what is expected from them for the day to day and what they can anticipate as a reward for growing their skills.
So how do we write useful job descriptions? Ones that accurately convey expectations and career trajectory in a meaningful way to team members?
Write Better Job Descriptions
When writing job descriptions, explicit is better than implicit. Describe the behavior, activity, or skill that you use day-to-day. . Don’t rely on “computer science fundamentals” to convey “Transforms data from event streams into a reportable format.”
Second, use language that is growth oriented, not credential oriented. Sure, you can use “computer science degree or relevant experience” as shorthand, but isn’t what you really want “has delivered features and bug fixes to production web applications”?
Third, avoid value judgements about the person. “Good engineers perform code review in a timely manner without being an ass,” while laudable, places too much emphasis on the actor and not enough on the activity. Instead, “Performs code reviews by providing specific, actionable and compassionate feedback in a timely manner.”
Fourth, remove anything that is extraneous. Attempting to put every last detail of what it means to be a senior developer on your team into your job description can wind up encouraging investment in minor activities or skills that are nice to have but not core. Instead, leave enough white-space that your team members can fill in the margins with the unique and beautiful ways they build up your team. These unique skills may even lead to writing a new job description if they wind up being incredibly worthwhile.
Describing Behaviors and Activities
When describing activities for your job description, focus on the activities that people with the role spend a significant amount of time on. If you expect your engineers to invest in test automation, for instance, you would include a behavior of “writing automated tests that validate the use-cases for features under the team’s purview.”
Further, It is useful to include why the activity is performed or the behavior is encouraged. While “Delivers features and bug fixes at the direction of the business and product team” is a decent start for developers and may even be acceptable for an engineer in their first or second job it fails to encourage developers to understand and act in line with the motivation for the features. This results in a “I do as I’m told” mentality. Instead, consider “Makes discernable progress towards business objectives by delivering features and bug fixes aligned with the direction of the product and business team.”
We’ve made the explicit additional responsibility that the work that is being done drives tangible progress. Now a team member has a better idea of how they’ll be assessed and how to adjust their behavior to support that assessment.
Describing Skills
Skills are even harder to describe objectively than behaviors and activities. This is where most job descriptions and job postings fall over, and how you get job listings asking for 8+ years swift experience, I encourage the use of a fluency model to describe skills.
Fluency models focus on the level of mental effort required to leverage a particular skill. Technology organizations greatest costs are time, thought and effort. Making explicit the relationship between time, thought and effort and the skills you are cultivating brings the focus towards what the organization gets out of higher-skilled workers.
Fluency has less to do with the person and more to do with their abilities. This helps us more effectively decouple value judgements, i.e. “Great React Developer.” Instead, we can be more specific and say that an associate front end developer “requires active support to design and implement React components with data or event inter-dependencies.” It avoids judging the person and sets an expectation that support will be provided. For more senior team members, a corresponding “supports other team members in designing and implementing components with complex data or event inter-dependencies” may be appropriate; and will also signal to your associate level team members that one of the ways they can advance their career is by supporting those around them.
Most people are familiar with fluency as a concept. When we ask questions about fluency we give people the opportunity to communicate in stories. Stories give a higher-fidelity understanding of the person’s actual skills. The question “What was the last challenge you struggled with when implementing a feature in React?” is both much easier to ask and answer and gives a much richer field for follow-on questions to dive in and develop a more nuanced view (or detect possible bullshit).
Now Write A Job Description!
Take 30 minutes right now to write a job description. What are the day-to-day activities you perform in your role? What are the skills you use most frequently? Where are the edges of fluency between your role and more or less senior ones?
Next, post it up as a comment on dev.to! I’ll do my best to read each and every one and give specific, actionable, and compassionate feedback.
