I have an exciting opportunity to redesign the career tracks in my current company. Each department decides its own titles, job descriptions, salary ranges, and progression. I'm pretty excited, as I've seen how the nature of formalized roles and the criteria for promotion can have a profound impact on culture and morale.

What are the best rationales for setting up parallel career tracks? What are some specific gotchas to avoid?

  • Interesting question
    – HLGEM
    Jul 27 '12 at 14:28
  • Could you add some context as to the type of business and what type of career tracks you'd be creating?
    – Jared
    Oct 11 '14 at 22:20

Here's what I've got so far...

DO create a new track if:

  • switching between jobs at the same track is at times virtually impossible without complete retraining. For example, one cannot move from chemical engineer to software engineer without some significant education.

  • you want to encourage growth in particular areas - people don't see that there is an ability to get promoted by specializing in an area.

  • you need a competitive advantage for certain roles - you can't pay the base rate of an "staff member" and get the skills of "specialized staff member" - so you need to sets of roles to clean up the pay infrastructure.


  • Creating a new track just to pacify people in your department

  • Any form of favoritism

  • Creating roles that won't make sense a year from now or to someone coming into the department.

  • Terminology that can't be understood quickly by most managers and many employees

COMBINE when(*):

  • People are able to change career tracks by changing teams but with no real change in skill set or ramp up time, other that what would be expected from a team change within a career track.

  • Pay grades are very close and skill set differences even at the more senior levels are minor.

  • You can't figure out why they are separate.

  • There is a perceived higher status to one path over the other that has absolutely nothing to to do with the reality for the business or the reality of the talents of the people.

An interesting side note is that people in an organization turn over in 2-4 years, so the crazy managers who came up with the skill sets and tracks 4 years back, are substantially different from the crazy managers hiring and promoting people in those same career tracks today.

  • 1
    Avoid Arbitrary and/or unnecessary road blocks to progression. Specifically I am talking about requirements like a degree or certification that does not impact the ability to do the work just the ability to reach the title. Jul 27 '12 at 19:42
  • @Chad - agreed, I'm a big favor of "blah blah blah certificate/degree" or equivalent experience. Show me you can do the job. Training can be a leg up, but not the whole thing... Jul 27 '12 at 23:41

I would consider that most tracks need to have at least three levels:

  • Junior or trainee
  • Intermediate
  • Senior

Then for some tracks you might want a level that is reserved solely for the very few experts in their field who you would prefer to pay a senior management level salary to in order to retain them as technical experts rather than force them into management get a pay raise. You could call this expert level. This will help you avoid turning a great developer into a mediocre manager.

The majority of your employees should be at Intermediate level but Senior should be attainable. Expert level should be rare and should require significant contributions to the organization and/or the profession.

You should spell out what tasks (and level of independence at performing them) a person at each level should be able to accomplish, so that people can know what they have to do to move from Junior to Intermediate and Intermediate to Senior. HAving the differences described helps immensely when you have to explain to one employee why you promoted someone else but not her/him. It also helps that underperforming employee see that once the performance criteria is met, he or she can still get promoted. Some of the worst employees I ever worked with were ones who were capable of doing senior level work but who had gotten the idea that they wouldn't get promoted no matter how good the work they did was.

In particular, I believe the move from Junior to Intermediate should be automatic once certain criteria have been met. Keeping people at trainee level once they are no longer trainees is short-sighted and ultimately bad for the company. You will lose the best ones (who can easily find intermediate level jobs elsewhere) and retain the worst ones.

  • 1
    Thanks for the thoughts... but maybe I wasn't clear - I'm looking at when to separate or not separate tracks... not the bell curve of progressive levels or how to separate them... Jul 27 '12 at 14:40

Based on your comment on HLGEM's answer, it seems you're trying to figure out when to break up into different career tracks. I'm assuming you're looking at something like "when do I break down the Engineer career track into Electrical Engineer, Software Engineer, Mechanical Engineer, etc."?

If this is really your question (or even if it's not), I'd answer "Break them up when it makes business sense." If the specific responsibilities of one job are different than another, but the expectations for promotion (i.e. performing work independently, leading others, reviewing designs, etc.) are similar enough you can leave them together. On the other hand, if you pay a software engineer differently than an electrical engineer then this would be one reason to not just have them both in an "engineer" career path. You should resist making separate tracks just enough to reduce unnecessary complexity. You also don't want to change these very frequently, so resist change to an extent so you can keep from creating, then removing titles later.

You should also consider that there are forks in many career paths. You want to enable people to pursue careers that fit their strengths. For instance a software engineer may decide to go down a technical path or a managerial path. You could have an intermediate step of "principal engineer" and "lead engineer" title to express the different focus of their roles even before they completely diverge, but isn't required. Eventually one would become a "technical architect" and the other a "development manager" or something like that.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .