0 Comments

I have a lot of half-formed thoughts about job titles.

On one hand, the engineer in me loves classification systems, and job titles seem to provide the capability to classify people such that you know approximately where they sit in regards to responsibilities.

On the other, the cynic in me has seen behind the curtain enough to know that titles are at the very least used so inconsistently in our industry that they are functionally meaningless.

Therefore this post is an exploratory piece, written as I try to solidify my thoughts on the subject.

Set your expectations appropriately low.

That’s Classified

Historically, I have to imagine that the purpose of a job title was to provide structure. If you had title X, you were responsible for A, B and C and you were probably paid Z. When it came time for you to move on, someone else could look at your title, understand what was required and what the remuneration was like and make an informed decision about whether or not they wanted to pursue that opportunity. If you saw someone else with said title, even from another company, then you could probably reason about what they do on a day to day basis and how well they were paid.

That seems like a decent enough line of reasoning, and in an industry that is structured and consistent, it could probably work.

I don’t think software development is such an industry.

That is not to say that we don’t love classifying ourselves though:

  • Developer (Graduate/Junior/Senior)
    • Front End
    • Back End
    • Full Stack
    • {Technology Specific}
  • Designer (UX/UI)
  • Leads (Technical/Team/Practice)
  • Architects
  • Tester (Automation/Manual)
    • QA
  • Analyst (Business/Data)
  • Manager (Iteration/Delivery)

Looking at that list, I can kind of explain what each title is expected to do, which is good, but that list is nowhere near close to exhaustive (I’ve left out the differentiation between Engineer and Developer for example), even from my own experience. The sheer variety of titles available just makes extracting any value from the system harder than it could be.

I tried to write some things here about “here are classifications that I think might work”, but all I was doing was creating the situation described in this XKCD comic, so I gave up.

Always With The Rugby Metaphor

Instead, lets look at Scrum.

Scrum has three roles, which are kind of titles, but not really.

  • Scrum Team Member
  • Product Owner
  • Scrum Master

The simplicity in this approach is great, because it doesn’t spend any effort on classifying people in a team. You either help deliver, make decisions and provide direction or you keep the machine running. That’s it.

It doesn’t preclude people from specialising their skillsets either, but nor does it support it. If you’re a scrum team member, then you’re helping to deliver an increment however you can. You might be testing, providing designs, implementing code, automating build pipelines or deploying infrastructure, it really doesn’t care. It fully expects you to be a well rounded person who is capable of contributing in many different ways (even though you might be better at some than others).

Of course, the scrum approach doesn’t really fix anything, its just a different way of looking at the situation.

If you’re correlating titles to remuneration, do you pay all of your Scrum Team Members the same? Probably not, as there might very well be a range of skills and experience there that you want to draw monetary attention to.

But doesn’t that defeat the entire point of them all having the same title? Its the team that is valuable, not the individual.

Reality Bites

The last two paragraphs attempted to explore any intrinsic value that might exist in a job title itself, mostly ignoring the reality.

Unless you work in a highly structured part of the industry (maybe Government?), I doubt a lot of thought was put into your title. Hell, maybe you even got to make it up yourself.

People with the same title can have wildly different salaries, usually as a result of being hired at different times or simply negotiating better. There is generally little to no drive to adjust salaries in line with titles, because all that might do is bring attention to the people who were being underpaid. This inconsistency is probably the biggest hit against titles as a useful mechanism in the wild, but it still assumes that the titles are being used in good faith.

There is a darker side still, where titles form nothing more than a power game for those who enjoy office politics, used as bargaining chips in place of actual monetary recognition.

Salesmanship

To alleviate some of the doom and gloom in the last section, perhaps there is a way that titles can be beneficial regardless of how you acquire them.

As humans, we generally make assumptions when we see that a person worked in a job with title X, and we use that information to form part of our evaluation of a candidate.

“Oh, they were a team leader at company Y, and they did it for 12 months, they probably aren’t terrible at it”.

Even knowing what I know now about the mostly arbitrary relationship between title and actual responsibilities and value delivery, I still would probably scan a candidates professional history and make assumptions like that.

So, there is value in fighting for a good title, ideally one that accurately represents what you do, with the understanding that the main value in the title comes after you leave the place that you acquired it.

Conclusion

In conclusion, I should probably stick to technical posts or posts about Mario Kart or D&D. They are, by far, much easier to write, and honestly, probably more valuable to any poor soul who decides to read this blog.

To paraphrase the principal from Happy Gilmore:

At no point in this rambling, incoherent blog post was I even close to anything that could be considered a rational thought. Everyone on the internet is now dumber for having read it. I award myself no points, and may God have mercy on my soul.

It was nice to get some of these thoughts out of my head though.