TLDR;

Job Descriptions are often a useless grab bag of bullet points that may or may not be related to accomplishing the mission of a role. In the vast majority of cases, they focus on compliance rather than optimizing them as a tool that supports a positive culture. If you focus on the mission and the tenants that support that mission, Job Descriptions can be a valuable tool in your arsenal for building a great culture.

Use the Tool Correctly

Job descriptions get a bad wrap. They are, all too often, a bag of useless bullet points that you ignore until you try to use them to fire someone. If that is your experience with Job Descriptions, you have been wasting a valuable tool. Job Descriptions can be culture carriers for your organization. Done right, they give your organization members a concise and targeted nugget of culture that is both actionable and useful. You can use it as a razor in day-to-day decision-making, hiring, or any other area where you need a guide for behavior.

Role as a Path, Rather Than a Destination

Photo Credit - Stephen Leonardi

Think of a role as a path rather than a destination. The terrain changes as you traverse it, and you will stop to rest at several points in the journey, but the path remains. Within each role, you have a mission and a set of tenants that guide you down that path. The mission and the tenants don't change. The things you focus on change, the scope of the role changes, but the kernel that makes the role doesn't change. If you think that the mission and the tenants change as you advance in a role, you likely have two different roles, not one.

Concrete Examples

Let's work through some concert examples to illustrate the benefit of job descriptions. We will work through both Software Engineers and Managers.

Software Engineers

A Software Engineer only really has one mission. That mission is to:

Produce quality deliverables that provide business value sustainably, to production on time.

It's worth noticing a few things about this mission. Nowhere do I say that the software engineer's mission is to write code. Nor do I say that their mission is to be at stand-ups or respond to tickets or anything else that is a typical daily occurrence. Those things are essential, but they are essential because they contribute to the actual mission's success, rather than being essential in and of themselves. The implication is that the team members are on the hook for doing anything needed to accomplish the mission. That probably includes writing software, but it may consist of many other things as well, and they are all part of the job if they drive the mission. Let's go through the different parts.

Quality deliverables

This implies that the software that the team deploys to production has a low defect rate and doesn't fall over in production.

That provide business value

This reminds us that the reason we invest in developing software is that it drives the business. We don't deliver software because it is elegant or exciting. It may also be elegant and exciting, but its only purpose is to provide value to the organization. Everyone on the team is on the hook for ensuring that the software that gets deployed provides value.

Sustainably

This implies that the software is sustainable, that it can be maintained and improved. Wherever possible, we don't hack things together and throw it over the wall. When we need to deliver something quickly, we reduce scope, not quality.

To production

There is no such thing as 'dev done'. Software is worthless until it is in production, serving customers. We gauge the success in our mission by what gets into production.

On time

Technology doesn't live in a vacuum, and as much as we would like to believe that it shouldn't matter when something makes it out, it does. 'on time' implies that when we give a da

Complementing Missions for Roles

Mission statements for roles on the same team should complement each other. At the same company where I developed the Mission statement for the Engineer role, I also created the Mission Statement for the Manager. Those mission statements were very similar.

Deliver a team that produces quality deliverables that provide business value sustainably, to production on time.

This mission is almost the same as the software engineer's mission. We still hold the Manager accountable for the same things, but we added the team's extra accountability through the statement 'Deliver a team'.

Role Tenets

We hold people in a role accountable for delivering on that role's mission. We support that mission and make it more understandable by adding tenets that provide additional guidance.

The tenants associated with the software engineer's mission are as follows.

Continuously Improve

Improve yourself by learning new tools, techniques, and strategies. Improve your software by making it more readable, maintainable, and more efficient. Improve your environment by adding tooling, technology, languages, and processes. The team and everything it owns is made better by your participation.

Take responsibility

You should feel responsible for everything your team owns. Never say, "that's not my job."

Simplify and Communicate

Drill down to the root of problems so that y. Eliminate clutter and complexity until your solutions are clear and succinctly address the problem. Communicate those problems and solutions well.

Ship it

Deliver your software to customers eagerly. Learn from customer feedback and your metrics.

Be courageous when facing possible failure. The sooner we understand which approaches work and which don't work, the sooner we can test the next iteration.

Respect what's gone before

Understand the systems, processes, and code in place before replacing them. The past embodies large amounts of wisdom and history. Throwing that away as a knee-jerk reaction is a waste at best and a potential disaster at worst. That doesn't mean that you shouldn't refactor, or that you can't replace code wholesale. It does mean that you do it after studying the reasons for that code or process's existence, weighed its value, and the risk of changing it.

Raise up your peers

Be a team player. Embrace opportunities to collaborate. Help the team improve across the board. Mentor your peers. Helping each other is a virtuous cycle. They gain our strengths, and we gain theirs.

Resist being a silo

Share knowledge, share responsibility, make sure you can still go on vacation without the system being unsupported. If you see a silo, help remove the silo in that area. Take on work in the space, dig into the codebase. Make sure that there is more than one person that knows the area by becoming that other person.

Understand your customer

Understand who your customers are and how they use your systems. Work vigorously to earn and keep customer trust. Keep your customers in mind when making changes.

Be Present

Pay attention to what's going on in meetings. Pay attention to what people are saying and try to understand the reasons they are saying it. Shut out distractions when working so you can focus on what you're doing.

You should have no more than six to ten of these tenets. That is about as much as a person can focus on at any given time.

Defining The Terrain

Photo Credit - Pierpaolo Lanfrancotti

We have defined the mission and the tenants for the software engineer role; now, let's define the terrain. The terrain is defined by how the job changes over time. For software engineers, it generally goes from Junior Engineer (SDE-I) up through Principal Engineer (SDE-IV).

SDI-I - Junior Engineer

An SDE-I is an entry-level role. The engineer is expected to grow out of the SDE-I position in a 1-3 year time span. An SDE-I is expected to need lots of support and coaching in their daily work and growth. An SDE-I's scope is generally the task, and their focus is on themselves and growing their ability. An SDE-I is expected to focus primarily on sprint work and growing their skills.

SDE-II - Engineer

An SDE-II a capable engineer. The SDE-II's scope is the story. The SDE-II focuses on larger units of work that need further break down. The SDE-II's focus is on the team. They are expected to focus on the team's work, breaking down work for the SDE-Is and raising up their peers.

An SDE-II is expected to primarily focus on sprint work and growing the SDE-Is and SDE-IIs around them.

SDE-III - Senior Engineer

An SDE-III is a capable senior engineer. The SDE-III's scope is the epic, and their focus is on two or more teams. The SDE-IIIs support the other engineers on their team and nearby teams, break down epics into stories and support the work on those stories over time. The SDE-III primarily focuses on a single team, takes work from that team's backlog, and generally raises up that team. However, they also 'consult' with teams around them and help SDE-IIs on other teams as availability permits. An SDE-III is expected to spend roughly half their time focused on sprint work and the rest on growing the people and the organization around them.

SDE-IV - Principal Engineer

An SDE-IV is the principal engineer for the organization. The SDE-IV's scope is a large unit of work that spans months of time and multiple teams in the organization. We call that an initiative. Their focus is on the organization rather than a single team . The SDE-IV takes an initiative, or in some cases, creates an initiative, breaks that initiative down into epics, and supports the other senior engineers across multiple teams in building out those epics. The SDE-IV spends most of their time helping the engineering teams make better technology decisions, grow the engineering teams, and consult with the leadership on technology matters.

The SDE-IV is expected to focus primarily on growing the people and organization in their purview.

There are a lot of steps between a Junior Engineer and a Principle Engineer. Even with that wide disperity, you can see how the SDI-I focus and scope descriptions are a subset of the principal engineer's focus and scope descriptions.

Fostering Adoption

Your team has to buy into these things for it to work. It's not something you can mandate and expect it to magically be adopted. It's not going to happen. To foster adoption, you should get your team to participate. Not everyone is going to be interested, so the process you create for participation should be opt-in. One thing that I have done successfully is put the Job Class Description in a Github repo in a text format (in this case Asciidoc), and let my team make PRs against the document. Only a small percentage of the team participated but we were able to have long, thoughtful discussions about each change in those PRs, and those PRs were durable records of that discussion. That process also had the side benefit of highlighting potential future leaders that merited additional mentoring investment.

Using the Job Description

The Job Description can't be a one and done thing. To be useful, you must use them continually. There are two significant areas where you should make extensive use of the description, your Continuous Performance Improvement process and in hiring. As the organization leader, you should have those in the front of your mind, use them vocally when the opportunity presents itself, and generally use them as the tool they are designed to be.

A Note on Tilting at Windmills

Photo Credit - Gayatri Malhotra

If you are not the CEO, you probably will not be able to change the way your organization handles Job Descriptions. So don't expend political capital with no return. Job Descriptions are a valuable tool, and in startups or similarly flexible organizations, it can be a low-cost way to reinforce culture. It is far from the only tool, and in larger, more rigid organizations, the probability of change is so low that it is probably not worth it.

Appendix - Examples

SDE Job Description

Description

Mission: Produce quality deliverables that provide business value sustainably, to production on time.

Tenets

Write testable and tested code
Design maintainable and runnable systems
Continuously Improve
Take responsibility
Simplify and Communicate
Ship it
Respect what’s gone before
Resist being a silo
Understand your customer
Be Present

Write testable and tested code

Write tests that are readable, maintainable and transferable. Follow and evolve the standards your team uses.

Design maintainable and runnable systems

Design systems that serve your customers, stay up, and are monitored. Make sure they can be maintained and extended by the team.

Continuously Improve

Improve yourself by learning new tools, techniques, and strategies. Improve your software by making it more readable, maintainable, and more efficient. Improve your environment by adding tooling, technology, languages and processes. The team and everything it owns is made better by your participation.

Take responsibility

You should feel responsible for everything your team owns. Never say “that’s not my job.”

Simplify and Communicate

Drill down to the root of problems so they can be solved fully. Eliminate clutter and complexity until your solutions are clear and succinctly address the problem. Communicate those problems and solutions well.

Ship it

Deliver your software to customers eagerly. Learn from customer feedback and your metrics.Be courageous when facing possible failure. The sooner we understand which approaches work and which don’t work, the sooner we can test the next iteration.

Respect what’s gone before

Understand the systems, processes, and code in place before replacing them. The past embodies large amounts of wisdom and history. Throwing that away as a knee-jerk reaction is a waste at best and a potential disaster at worst. That doesn’t mean that you shouldn’t refactor, or that you can’t replace code wholesale. It does mean that you do it after having studied the reasons for that code or process’s existence, weighed its value and the risk of changing it.

Raise up your peers

Be a team player. Embrace opportunities to collaborate. Help the team improve across the board. Mentor your peers. Helping each other is a virtuous cycle. They gain our strengths and we gain theirs.

Resist being a silo

Understand your customer

Understand who your customers are and how they use your systems. Work vigorously to earn and keep customer trust. Keep your customers in mind when making changes.

Be Present

Pay attention to what’s going on in meetings. Pay attention to what people are saying and try to understand the reasons they are saying it. Shut out distractions when working so you can focus on what you’re doing.

Career Path

SDE-I - Junior Engineer

An SDE-I is an entry level role. The engineer is expected to grow out of the SDE-I position relatively quickly, in roughly a 1-3 year time span. An SDE-I is expected to need lots of support and coaching in their daily work and growth. An SDE-I’s scope is generally the task, and their focus is on themselves and growing their ability. An SDE-I is expected focus primarily on sprint work and training.

SDE-II - Engineer

An SDE-II a capable engineer. The SDE-II’s scope is the story. The SDE-II focuses on larger units of work that need further break down. The SDE-II’s focus is the team. They are expected to focus on the work that the team needs to do, breaking down work for the SDE-Is and raising up their peers.An SDE-II is expected to primarily focus on sprint work, but also focus on growing the SDE-Is and SDE-IIs around them.

SDE-III - Senior Engineer

An SDE-III is a capable senior engineer. The SDE-III’s scope is the epic, and their focus is on two or more teams. The SDE-IIIs support the other engineers on their team and nearby teams, break down epics into stories and support the work on those stories over time. The SDE-III primarily focuses on a single team, takes work from that team's backlog and generally raises up that team. However, they also ‘consult’ with teams around them and help SDE-IIs on other teams as availability permits. An SDE-III is expected to spend roughly half their time focused on sprint work and the rest on growing the people and the organization around them.

SDE-IV - Principal Engineer

An SDE-IV is the primary engineer for the organization. The SDE-IV’s scope is the initiative, and their focus is an entire organization. The SDE-IV takes an initiative, or in some cases produces an initiative, breaks that initiative down into epics and supports the other senior engineers across multiple teams in building out those epics. The SDE-IV spends the majority of their time helping the engineering teams make better technology decisions, helps grow the engineering teams and consults with the business leadership on technology matters. The SDE-IV is expected to focus primarily on growing the people and organization in their purview.

Manager Job Description

Description

Mission: Deliver a team that produces quality deliverables, that provides business value sustainably, to production on time.

Tenets

Create the conditions for your team’s success
Be transparent
Do the basic stuff well and without fuss
Epitomize the culture
Deal with conflict don’t ignore it
Make decisions
Take responsibility
Ensure knowledge is organizational
Understand your customers
Be Present

Create the conditions for your team’s success

Create the conditions and culture to enable a bunch of highly-skilled people to perform well. Be there for them when they have issue issues. Coach them along with their skills (both technical and soft skills). Help them become a better team and gel around their goal and vision. Give your team what they need (not necessarily want). That may be hardware, software, monitors, better communication tools, reasonable working hours, good team events, etc.

Be transparent

Keep your team in the loop, but manage to avoid worry or churn. Has someone important left the company? Bring the team together and let them know why honestly. Is there a re-org happening in another department that might impact your team and the relationships they had with that org? Tell the team, keep them informed on essential things. Put their minds to rest on things they might hear that might cause unnecessary worry.

Do the basic stuff well and without fuss

Holiday requests, one-to-ones, reviews, flexible hours, expenses, sick leave, etc. All the tedious things that the manager has to do with some internal tool. Do it well, fast and without fuss.

Epitomize the culture

Epitomize the behavior that you want to see in your team. People emulate their leaders. The best way for you to propagate good culture into the team is by providing a clear example of a person that conforms to that culture.

Deal with conflict don’t ignore it

Deal with problems with team members. Someone might be relentless, always thinks they are right, disruptive to all the other team members, is leaving work half-done, or not following the process, being negative on chat or in code reviews or wants to over-engineer everything to death. Deal with this. Resolve conflicts between people. Handle Performance Improvement Processes well, including the build-up, the communication, the aftermath.

Make decisions

Make calls on things and take the flak for doing so. Make these calls when required. Solicit feedback, get opinions and comments from the team, be fair and reasonable. When the decision is made, socialize it with the team and back it up with why you made that decision. Most of the time the team should be able to make decisions on its own. When it can’t, you are there to move the team forward.

Take responsibility

Success belongs to the team, but failure belongs to you. Take responsibility for your team’s failures even when you may not feel that you are responsible. Finger pointing undermines your ability to lead and undermines your teams' sense of ownership. When failures occur, root cause and understand those failures. Work to ensure that the underlying reasons for those failures are understood and mitigated to reduce the incidence of failure in the future.

Ensure knowledge is organizational

Don’t rely on individual superstars. Build knowledge in the team. Cross-train extensively. Ensure that those individuals are documenting what they do, create processes around those things and have other people do them from time to time. Design your team such that knowledge is backed by the processes, tools, and culture rather than individuals.

Understand your customers

Understand who your customers are and how they use your systems. Work vigorously to earn and keep customer trust. Always have the customer in mind when making changes.

Be Present

Be present in the context in which you are in. In meetings, pay attention to what’s going on in the meeting. When talking with an individual, pay attention to what they are saying, try to understand the reasons they are saying it. When working, shut out outside distractions, focus on what is in front of you.

Career Path

SDM-I - Manager

An SDM-I is a team manager. The SDM-I’s focus is the individual member of team. The SDM-I’s scope is the team. The SDM-I focuses on growing and enabling those individuals, ensuring that they are empowered to deliver on the product. Where required the SDM-I’s is responsible for removing those individuals that, for any reason, can’t meet the requirements specified in the SDE Mission and Responsibilities.

SDM-II - Senior Manager

An SDM-II is a manager of one or more teams manager. The SDM-II’s focus is the individual members of the teams that report to them. The SDM-II’s scope is a small number of teams. The SDM-II focuses on growing and enabling those individuals, ensuring that they are empowered to deliver on the product. Where required the SDM-II’s is responsible for removing those individuals that, for any reason, can’t meet the requirements specified in the SDE Mission and Responsibilities.

SDM-III - Director

An SDM-III is a Director. The SDM-III’s focus is on a sub-organization the interaction between the teams that make up that sub-organization. The SDM-III’s scope are a group of related teams that make up a sub-organization. The SDM-III focuses on growing and enabling those teams, ensuring that they are empowered to deliver on the product that the SDM-III supports. Where required the SDM-III’s is responsible for changing processes, teams and team organization when those teams can’t meet the goal’s specified for the organization.

SDM-IV - Senior Director

An SDM-IV is a Senior Director. The SDM-IV’s focus is on an organization and the interaction between the sub-organizations that make up that organization. The SDM-III’s scope is a group of related sub-organizations. The SDM-IV focuses on growing and enabling those sub-organizations, ensuring that they are empowered to deliver on the product(s) that the SDM-IV supports. Where required the SDM-IV’s is responsible for changing processes, sub-organizations and the organization when those groups can’t meet the goal’s specified for the organization.