Career Advancement without Titles

I’ve been thinking a lot about how to build a career ladder in the company I work for without having a bunch of different titles. I believe that specificity, while it can provide clarity, also creates limits, and as such, I’d love to build a software engineering organization where everyone thrives and grows together, without the need to specify who gets what title.

I’ve been lucky to have worked in places that have agreed with this philosophy to greater and lesser extents, and so I’ve seen both sides to some degree. I think it’s clear that I’m advocating for one extreme, so I’ll get right to what I see as the pros and cons of the two approaches.

Old-school

The old-school, title-driven career ladder, in my mind, goes like this: A person enters the workforce as a [software engineer|programmer] Level I, and is compensated within the bounds of that title and pay band. As they work hard (?) and get time and experience under their belt, at some point their employer says “hey good job — you’re now a [software engineer|programmer] Level II. Here’s some more money”. This advancement might be based on company-specified rules of advancement or the subjective evaluation of their boss. There might also be personal goals involved — the kind that you write down at the beginning of some period and then look at again sometimes.

This process continues until you reach [software engineer|programmer] Level V, at which point you have to pick a new direction in your career advancement or sit at level V. When you talk to your boss about money, there’s a reasonable chance they’ll say something to the effect of “boy I really see where you’re coming from. We value you a lot as an employee. Please understand that your pay-band has an upper limit, and you’re close enough to that limit that my hands are tied!”

So you start looking at your options for other types of advancement. Often your choices at this point look like either a technical path (some type of “architect” role) or a management path (team lead, manager, director, etc). For many, this is a difficult choice because they are skilled in both paths and don’t want to choose just one. Whichever path you choose, you are faced with a lot of competition for that role. Lets say you decide you want to pursue the technical path. The chances are quite good that your company already has an architect, if they have any interest in the role. Now what? It would appear that your career has stalled until that position (be it an architect, a team lead, a manager, whatever) is vacated or you decide to jump ship to a company with such an opening.

The pros of such well-defined positions are clear: it’s easy to see where you are on the ladder; next steps are often easily identifiable; your duties are likely well-documented and their mastery is within reach. I’m sure there are countless other benefits I’m forgetting or am simply not aware of. There are also significant cons: your advancement through the ranks of your position is outside of your control, perhaps even arbitrary; the skill set you’re allowed to practice is limited to the scope of your position; your focus will tend to be on your own advancement and not the advancement of your team. Again, there are countless other reasons that this classic approach is flawed.

A title-less approach

A different way that this problem has been approached is by starting with the claim that titles don’t matter. Of course there are countless arguments on both sides of this as well, but we’ll say that in our organization we just don’t care. Everyone on the software engineering team is simply a [software engineer|software craftsman|engineer|whatever]. There are many needs that the team has that are met by the skills of the members of the team. Is there a story with some hairy architectural needs? Well I remember that Joe is good at that particular type of architecture, I’ll ask him and he’ll teach me. Then I’ll be better at that particular type of architecture. Is there a story that needs a lot of front-end work? I remember that Sue is quite good at front-end. I’ll ask her. Would the team benefit from a greater quantity of playful interaction? Nate is good at making that happen — let’s see if he’ll help us get there.

As a team proceeds in this manner, each member of the team is able to identify needs of the team that they are already good at fulfilling, and hopefully they can identify needs that are just outside of their comfort zone and step up. Interactions of this nature help people to exercise the skills they already have, as well as encourage them to help others build similar skills. I believe they also encourage a healthy organizational awareness that is lost when your role is overly-well-defined.

In the classic example a person looking back at their years of service within a company might see that they’ve advanced from position x to position y, and they might feel that they’ve learned the company-specified skills that were required to do so. In this model, a person looking back at their years of service might (hopefully) see that while their title hasn’t changed, they’ve overcome personal fears and become quite good at doing x, y and z. They might also see that their team has overcome significant challenges and become more streamlined. They take pride in this because they can see the changes in the team that they facilitated, as well as the changes they’ve made personally. This is intrinsic recognition of growth, which I claim is much more valuable than the extrinsic recognition of growth bestowed by a superior through title-based advancement.

Challenges

There are needs filled by the old-school methodology that aren’t trivially filled by this approach.

Ambiguity can lead to discomfort. Having spent time in typical org structures, many people come to rely on their job description for their professional identity. Getting from the “I do these things and they help my employer in these ways” mindset to the “my team does these things that help my employer and I contribute in ways that change constantly” mindset is a big jump.

Compensation is often handled in conjunction with positions. We are all accustomed to the idea that if you want more money, do the things defined by the next job in your growth plan, and when you are adequately performing those duties, a performance review will eventually result in a promotion or something like that. I’m not aware of a way in this growth framework to tie the two together. I would like to challenge the idea though — as an industry we assume that compensation and career progression are necessarily tightly coupled. I’m not sure how I feel about this, but I think that some of the companies pushing for more transparency (put all the salaries in public) might feel that the two don’t have to be so closely related. The idea of using a formula to fairly determine one’s compensation is appealing to me, but maybe that’s only because all the other methods I’m aware of (performance reviews and such) are so appalling.

Conclusion

I certainly don’t have the answers to the questions implied here. I’m also pretty confident that these ideas aren’t new ones. One of my hopes in writing this blog post is that someone will read it and say “oh you mean you want to do [whatever it’s already called]. That’s already all thought out and documented. Go read about it [here]”. Even if you don’t have that answer, please feel free to share your thoughts on my thoughts — that’s why they’re here.