Should we use progressing job titles for programmers?

Question

I'm currently thinking about job titles for my team of programmers. Historically it's been pretty flat, with most people just "Programmer", and a very few people "Senior Programmer". But both those titles cover a wide diversity of experience and salary.

I was thinking of replacing this with a progression of five levels -

• Developer
• Senior Developer
• Principal Developer
• Architect
• Senior Architect

I'd be interested to hear what people think are the pros and cons of such a scheme. On the positive side, I've found that programmers actually covet good titles. On the negative side, it's been suggested to me that such a hierarchy can create resentment. I'd welcome your thoughts.

Update: Thanks for all the great answers! It's certainly changed my thinking on this subject, and I will probably retain the flater structure at this point.

Answer 1

This is wrong in so many ways I'm struggling to express it:

First:

• Architect is a role of it's own, it's not just a programmer with more experience. Don't confuse the two.

Second as a manager I can't think of anything worse than sorting this out:

• What do these titles actually mean? What does a principal developer do that a senior developer doesn't? Do they get paid more? Do you expect more from them? How do you measure this?

• Is there completely free movement between these? So if all your seniors start performing to a principal level do they all become principals? If not how are you going to cope with the resentment and demotivation that will come about (and massively outweigh the motivation boost the few people who get promoted gain), as well as the competition when you actually want people pulling together.

• How are you going to structure your project when a senior developer happens to know the most about a key technology but is being forced to answer to an architect who hardly understands it.

Third, as a developer:

• To the outside world: yes I like a decent title but I also want it to mean something and it to be clear to everyone what that is. The outside world don't understand this structure and don't care.

• Internally I want projects and teams where people are being given opportunities and rewarded based on what they're doing there and then, not based on something they may have done previously which has now been cast in stone.

I favour two levels: developers (who code) and senior developers (who code but who also regularly and constantly provide mentoring, process improvement suggestions and leadership). That's it.

Edit: But I would say you get significant credit for not including "Junior Developer" or "Trainee Developer", possibly the worst job titles in the world. Don't give someone the title "Junior Developer" unless you want them to act in a "Junior" way.

Answer 2

Those progressive titles remind me my martial arts classes.

That was very motivating! We worked hard to get to the next level, ... by fighting each others.

This is exactly what is going to happen in your team :)

With the difference that in martial arts classes we where there to learn how to fight individually. In your team they should learn how to collaborate effectively instead.

That's why I suggest you not to use progressive titles in teams.

Answer 3

I got a great lesson in titles working for Autodesk around 1990. There was a guy there named John Walker who, as a "programmer", was one rung below me on the corporate ladder and made less than half my salary. He also was the single most influential person in the company, and his immediate prior title was "President". Oh, and he didn't need much salary - as the second-largest shareholder, the $0.10 quarterly dividend was plenty for him to finance his spectacular seaside villa and buy the occasional $400K scanning tunneling electron microscope.

People who have worked for a few years and paid attention come to understand that job titles are worth exactly as much as it costs the company to grant them. Your flat job titles are actually pretty good. If I were you, I'd leave them alone and concentrate on providing a really fantastic work environment and devising more meaningful rewards.

Answer 4

I tend to think of Architect as a role rather than a career progression. Someone could be an incredible developer and provide tremendous value, but not have the systems thinking needed for an architect role.

We use a similar heirarchy for career progression (without the architect titles) - e.g.

• Developer
• Developer II
• Senior Developer
• Principal Developer

Perhaps you could have one more level beyond Principal where the role can be Architect or uber-Developer, but the title is something more generic?

Answer 5

It looks redundant.

What is the difference between "senior" and "principal"?

And isn't an architect "senior" by definition?

Developer -> Senior Developer -> Architect should suffice for all intents and purposes.

Maybe you should approach the problem from a different angle. Instead of abstract titles with those seniority gradations issue titles which describe the particular role of the persons in question. It's not immediately clear where the difference lies between three "Senior Developers", but it's obvious what they do if they are called "Online division architect", "Integration team leader" and "Custom solutions architect".

Answer 6

No, don't. It's too easy to guess salary based on structured advancement, that is, from what I've seen/experienced. Other times it's also insulting to see some dot-com-hire-them-if-they-breath developer who never improved beyond a "learn C++ in 24 hours" book (and probably spent that much time on it too) running around with a Senior Developer title when someone 5 years younger deserved it more. In general, the title should be dictated by the role. "Team Lead" leads the teams, "Senior Developers" often mentor other developers, "Junior Developers" have less than 2 years experience and "Developers" are the bulk of what you should have.

Answer 7

Twice in my career an employer has asked what I wanted to appear on my business card. Both times I answered, "Software Engineer" and both times I received cards that said "Senior Software Engineer". Presumably this was because the senior qualifier sounded 'more professional'. Whatever...

I took from this that titles are pretty much meaningless. The next time anyone asks, I know exactly what title I'll choose:

• http://www.youtube.com/watch?v=Y5RQNBFKK30

Answer 8

I would only suggest progressive titles if there is some differentiation in pay, responsibility, and/or job duties.

Answer 9

progressive titles only make sense if the team members are of significantly different skills and abilities

for team organization, titles based on team roles would make more sense

i have no idea what a principal developer would be; in ordinary usage this term would indicate the single person who did the most work on the project, e.g. the principal developer of Perl was Larry Wall. It is not a job title.

Answer 10

The title should match the job duties. You can attach different levels to differentiate levels of salary/bonus.

As a professional, you want your title to reflect what you do and save you the trouble of going into a lengthy description when you meet someone at a convention or job interview.

Not sure you have describe some problem this is going to solve other than being flat. Your team is probably not so large that everyone doesn't know who is who. It may show those outside your department that people are progressing.

Answer 11

To a large extent, it all depends and if you ask several people you are going to get several different answers on the subject.

As Pierre 303 pointed out, some people will find the progression of job titles to be extremely motivating, where as Jon Hopkins pointed out, there can be some issues involved with having progressive job titles in general.

One thing you might want to do is consider putting this to the team and getting their feedback on what they think a good system might be; however, you should also be sure you can why having a progressive system of titles is a good idea. As people commonly say, "Don't fix something that isn't broken." If you are running into issue with clients whom are meeting with your team getting confused as to the internal hierarchy (this can occur but tends to have a bit of a cultural bias) but if that isn't an issue then you need to look at the reasons that making a change is a good idea.

If you are having issues with tracking things internally for human resources purposes then you might want to implement an internal system such as a simple "Developer I though N" that can be used when it comes time for reviews and to be able to set the requirements to move up to a higher salary range. That allows you to be able to track someone's career development while still having simple job titles such as Programmer and Sr. Programmer.