In defense of job titles

I've noticed that the startup-flavored tech industry has certain preferences when it comes to your job-title. They like them flat. A job tree can look like this:

  1. Intern (write software as a student)
  2. Software Engineer (write software as a full time salaried employee)
  3. Lead Software Engineer (does manager things in addition to software things)
  4. Manager (mostly does manager things; if they used to be a Software Engineer, maybe some of that if there is time)

Short and to the point. The argument in favor of this is pretty well put by:

A flat hierarchy keeps us from having to rank everyone against some arbitrary rules. What, really, is the quantifiable difference between a 'junior' and a 'senior' engineer? We are all engineers. If you do manager things, you're a lead. When you put Eclipse/Vim/VisualStudio behind you, then you're a manager.

No need to judge some engineers as better than other engineers. Easy. Simple. Understandable.

Over in the part of the tech-industry that isn't dominated by startups, but is dominated by, say, US Federal contracting rules you have a very different hierarchy.

  1. Associate Systems Engineer
  2. Junior Systems Engineer
  3. Systems Engineer
  4. Senior Systems Engineer
  5. Lead Systems Engineer (may do some managery things, may not)
  6. Principal Systems Engineer (the top title for technical stuff)

Because civil service is like that, each of those has a defined job title, with responsibilities, and skill requirements. Such job-reqs read similar to:

Diagnose and troubleshoots problems involving multiple interconnected systems. Proposes complete systems and integrates them. Work is highly independent, and is effective in coordinating work with other separate systems teams. May assume a team-lead role.

Or for a more junior role:

Diagnose and troubleshoot problems for a single system in an interconnected ecosystem. Proposes changes to specific systems and integrates them. Follows direction when implementing new systems. Work is somewhat independent, guided by senior engineers.

Due to the different incentive, win US government contracting agreements versus not having to judge engineers as better/worse than each other, having multiple classes of 'systems engineer' makes sense for the non-startup case.


I'm arguing that the startup-stance (flat) is more unfair. Yes, you don't have to judge people as 'better-than'.

On the job-title, at least.

Salaries are another story. Those work very much like Enterprise Pricing Agreements, where no two agreements look the same. List-price is only the opening bid of a protracted negotiation, after all. This makes sense, as hiring a tech-person is a 6-figure annual recurring cost in most large US job-markets (after you factor in fringe benefits, employer-side taxes etc). That's an Enterprise contract right there, no wonder each one is a unique snowflake of specialness.

I guarantee that the person deciding what a potential hire's salary is going to be is going to consider time-in-the-field, experience with our given technologies, ability to operate in a fast paced & changing environment, and ability to make change as the factors in the initial offer. All things that were involved in the job-req example I posted above. Sub-consciously certain unconscious biases factor in, such as race and gender.

By the time a new Software Engineer walks in the door for their first day they've already been judged better/worse than their peers. Just, no one knows it because it isn't in the job title.

If the company is one that bases annual compensation improvements on the previous year's performance, this judgment happens every year and compounds. Which is how you can get a hypothetical 7 person team that looks like this:

  1. Lead Software Engineer, $185,000/yr
  2. Software Engineer, $122,000/yr
  3. Software Engineer, $105,000/yr
  4. Software Engineer, $170,000/yr
  5. Software Engineer, $150,000/yr
  6. Software Engineer, $135,000/yr
  7. Software Engineer, $130,000/yr

Why is Engineer 4 paid so much more? Probably because they were the second hire after the Lead, meaning they have more years of increase under their belts, and possibly a guilt-raise when Engineer 1 was picked for Lead when they weren't after the 3rd hire happened and the team suddenly needed a Lead.

One job-title, $65,000 spread in annual compensation. Obviously, no one has been judged better or worse than each other.

Riiiiight.

Then something like #TalkPay happens. Engineer number 4 says in Slack, "I'm making 170K. #TalkPay". Engineer number 3 chokes on her coffee. Suddenly, five engineers are now hammering to get raises because they had no idea the company was willing to pay that much for a non-Lead.

Now, if that same series were done but with a Fed-style job series?

  1. Lead Software Engineer, $185,000/yr
  2. Junior Software Engineer, $122,000/yr
  3. Associate Software Engineer, $105,000/yr
  4. Senior Software Engineer, $170,000/yr
  5. Senior Software Engineer, $150,000/yr
  6. Software Engineer, $135,000/yr
  7. Software Engineer, $130,000/yr

Only one person will be banging on doors, Engineer number 5. Having a job-series allows you to have overt pay disparity without having to pretend everyone is equal to everyone else. It makes overt the judgment that is already being made, which makes the system more fair.


Is this the best of all possible worlds?

Heck no. Balancing unconscious bias mitigation (rigid salary scheduled and titles) versus compensating your high performers (individualized salary negotiations) is a fundamentally hard problem with unhappy people no matter what you pick. But not pretending we're all the same helps keep things somewhat more transparent. It also makes certain kinds of people not getting promotions somewhat more obvious than certain kinds of people getting half the annual raises of everyone else.