Job levels

Someone asked a question about job levels. I’m paraphrasing here for the sake of brevity and anonymity:

As an early-stage startup, we made a deliberate decision to hire an experienced engineering team. As such, all our engineers have the same title. We’re now exploring the introduction of different levels and would love to hear your thoughts.

I certainly don’t claim to have all the answers however, I have been a part of implementing various approaches (flat, multi-track, sub-levels, etc.) with mixed results.

I’m currently of the view that unless you are a mega-corp (and perhaps even then) or Government:

• External title != internal role. Externally, people can call themselves whatever they want, within reason.
• Don’t use roles/titles and promotion to reward and recognise people. Have a smaller set of roles with large overlapping pay bands and use expectations to provide additional compensation.
• Accept that some people will want to focus on deep coding and that’s ok. Some folks will want to extend into other duties, and that’s ok too.
• Use roles as a way to provide clarity and focus on what’s expected. Expectations are the things people can meaningfully compare, hold themselves accountable to, and be assessed on.
• Look for ways to provide people with opportunities to extend themselves in their current role. If in doing so, they periodically fulfill the expectations of other roles, recognise and reward them for that. Don’t demand they do it all the time, and don’t delay that recognition and reward until they’re “officially” in another role.
• Even within a role, there are likely fundamental things we expect of everyone, and then specialisation that allows people to contribute in different but nevertheless meaningful ways.
• Avoid creating roles based on “jobs to be done.” The classic example is tech or delivery lead. Depending on the nature and scope of the work, it could be performed by a junior engineer, or a principal.
• People management really is a different skill set. No really. You may or may not need specific roles but whatever you go with, give people explicit and ongoing support and training.
• Minimise the number of vacancy-based roles. Make them accessible to internal staff (as well as external candidates) and invest in opportunities and training to maximise their chance of success.
• Don’t create “unicorn” roles by back-solving for people you want to retain. They lack clarity of expectations, lead to the perception of (if not actual) favouritism, and easily become misaligned with real business needs.
• In a small startup, roles are far less clear. If you’re vetting people sufficiently in the hiring, you’re likely to bias towards people who will pretty much do anything, so the above matters far less.

Companies want to attract and retain people, and to set pay and benefits. Individuals want to feel a sense of progression and achievement, and to signal this to others.

A mistake I’ve made repeatedly in the past is trying to capture everyone’s needs in some form of job level structure where the only way is up, and in which people are inadvertently incentivised to compete and outshine one another.

These days, I advocate for a simple structure with multiple overlapping levers. One in which there is more clarity in what’s expected, more opportunity to be recognised and rewarded, and more flexibility in how organisations can support people to grow and perform at their best.