Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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.

share|improve this question

closed as primarily opinion-based by Ixrec, durron597, MichaelT, Dan Pichelman, Snowman May 27 at 3:14

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

Why not ask them what they want to be called, and leave it at that? –  user1249 Nov 28 '10 at 22:33
Agreed - I suspect a very big minority (perhaps a majority) find the whole job title thing a bit daft. When I was given a choice of job title, I stopped being a software engineer and became a programmer. To me "software engineer" means "barely out of school, possibly minimally competent, paid on that basis, working on safety and mission critical code in the defence sector". –  Steve314 Nov 28 '10 at 23:09
You mean like Padawan, Knight, ...? –  Scott Whitlock Nov 28 '10 at 23:25
Coveting is almost always a very bad thing to encourage. –  Tim Post Nov 29 '10 at 8:48
@Tim:+1 I think there's 2 reasons to care about your title: your CV, and how the title affects your salary. I know this'll get a bunch of "I'm all about the code, man" responses, but almost everyone cares about their pay as well. –  JohnL Nov 29 '10 at 17:29

11 Answers 11

up vote 54 down vote accepted

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


  • 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.

share|improve this answer
+1 for mentoring (but I reached my limit for today...) –  user2567 Nov 28 '10 at 22:34
+1, it seems like the titles are just a way to indirectly advertise employee's relative salary which seems like a really bad idea to me. –  Dean Harding Nov 28 '10 at 23:10
+1 @Dean Harding: I think you've really hit the nail on the head with that statement. –  Steve Evers Nov 29 '10 at 15:04
@SnOrfus / @Dean - Is having salaries advertised a bad thing? I'd suggest only if your salaries aren't fair. While our salaries aren't publicised we try to keep them such that if they were stuck on the wall people wouldn't have too much to complain about. –  Jon Hopkins Nov 29 '10 at 20:48
@Jon Hopkins: No, I wouldn't say so, but having a title whose meaning is "Makes $X,000/yr" is. Like you said in your answer (+1 btw) "... I also want it to mean something and to be clear to everyone..." - that is what it should be: a description of your responsibilities and abilities. –  Steve Evers Nov 29 '10 at 21:00

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.

share|improve this answer
good points, and not at all an excessive use of bold –  Steven A. Lowe Nov 29 '10 at 3:21
@Pierre: I think your use of bold was effective in bringing out the important parts. –  Matthew Crumley Nov 29 '10 at 9:26
@Steven: OK Steven, thank for giving the right to tease you in return ! –  user2567 Nov 29 '10 at 14:55
@Pierre: anytime my friend, any time! –  Steven A. Lowe Nov 29 '10 at 15:00
@JBRWilkinson: yes. Probably my italian roots ;) –  user2567 Nov 30 '10 at 7:02

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.

share|improve this answer
"job titles are worth exactly as much as it costs the company to grant them" - now thats some serious truth right there! –  GrandmasterB Nov 29 '10 at 6:20

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?

share|improve this answer
Thanks for that helpful comment Alan. My experience is that the more senior developers do more and more architecting by default, and that the lines blur a bit. –  Craig Schwarze Nov 28 '10 at 22:56

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".

share|improve this answer
I'd like to define it as: Senior = group; Principal = single. To use army ranks. Private (dev) -> Corporal (snr dev) -> Sergeant (principal dev). –  Orbling Nov 29 '10 at 3:14

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.

share|improve this answer
At Microsoft, they have also defined an "Individual Contributor", which is basically a senior developer, without management/mentoring responsibilities. –  AviD Nov 29 '10 at 6:13

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:

share|improve this answer
Software Engineer is the best title. My boss wanted to call me "Head of Technological Research and Engineering" - I vetoed that real quick. :-/ –  Orbling Nov 29 '10 at 3:15

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

share|improve this answer
+1, With some corporations, you can only justify giving the experienced guy more money if you give him a loftier title. –  user1842 Nov 28 '10 at 23:00

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.

share|improve this answer
+1 here for the word significantly - it's got to be a real indication of unambiguous difference. –  Jon Hopkins Nov 29 '10 at 9:13

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.

share|improve this answer

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.

share|improve this answer
+1 I know this is a very old thread, but I just found this and think the internal title separate from a flatter external hierarchy is a great idea. That way, developers can hold their employers accountable for paying them fairly for their level of expertise, but you avoid the superiority and conversely resentments from peers seeing each other's titles. –  Brandon Apr 1 '13 at 15:42

Not the answer you're looking for? Browse other questions tagged or ask your own question.