Title inflation

Software Engineering Titlenomics 101

I want to be a Software Engineer III when I grow up, said no one ever.

But if one were to say that, what qualities do you think a person would need to have in order to qualify for a job title as prestigious as Software Engineer III? Odds are, the attributes you come up with would be non-trivially different from the ones I come up with, and that is pretty much the standard across the industry. The standard of course being, no standard at all.

Most titles only mean something to the organization that comes up with them, and aren’t completely transferable to other orgs with similar sounding titles. Every org has their own unique needs, and their career paths and titles will be crafted to reflect those needs.

If you are lucky enough to work in an org with competent management, the career paths available to you there may be documented in some way, such as in the form of a skills matrix that describes all the possible job titles up for the taking and the skills necessary for attaining them. In general, the more skills and experience you have, the more prestigious of a title you can be allowed to have. But, assuming you genuinely want to be a “good” engineer, it’s important that both the matrix and your day-to-day work align with your own personal goals, and that the matrix has as little ambiguity as possible.

To be fair, some organizations may not be ready to formalize their career paths, because there isn’t a need to justify differentiating the responsibilities in their engineering roles yet, either due to team size and/or because the problems they are trying to solve just don’t require it. This can make complete logical sense from the organization’s point of view, but it’s important to keep this lack of structure in mind if you are earlier in your career and want to ensure that your growth doesn’t stagnate due to a lack of mentorship or direction.

At any rate, title differentiation within a given function is essentially meaningless without some sort of documentation describing in clear and objective language how the responsibilities and skill set of one title differ from another, along with disciplined evaluation of employees against that criteria by leadership and management. I love being called senior as much as the next engineer, but giving someone a title before they are ready for it is doing both them and your organization a disservice. They will eventually discover either through their daily work or from searching for a new job that the title wasn’t deserved yet, and the growth of your organization may stagnate due to a lack of real experience in more senior roles. It’s better to instead be honest and transparent with your reports when they are not ready for a promotion, and to work with them to develop a career plan that will get them to where they want to be and where your team needs them to be. Most if not all people will greatly appreciate your transparency and genuine effort to help them succeed in lieu of a fake title.

If you are the leader of a team that you feel is lacking expertise in a given area, hiring externally is a much better option than pushing someone into a role they are not ready for yet. The needed expertise will help keep your org on track for continued growth, attract engineers looking to work with more experienced or smart folks (pro tip, this is most engineers), and eventually open up even more opportunities for growth for your teammates.

If you are an engineer that feels like you may have been subjected to title inflation or are otherwise concerned about your own career trajectory, it’s important to remember that titles mean different things to different companies, and being senior at one company may not qualify as being senior at another, depending on what each company values. If you are just getting started in software engineering or are someone that experiences imposter syndrome often (like me!), it can be difficult to feel like your career is on the right track or not without the right structure, enough experience, or solid mentorship. In these situations, I’ve found exploring the engineering matrices and ladders of companies with more mature engineering organizations to be very helpful:

It’s also important that increased responsibilities comes with increased pay. At most organizations, pay should be tied to your engineering level, but I have both heard of and personally experienced situations where that has not been the case. You can use resources like Comparably or Glassdoor to get an idea of what your pay should be, or you can reach out to me directly and I will happily share my compensation history with you in the spirit of transparency.

Transparency is the best tool we have for keeping title inflation low, and can also be a huge boon for diversity and inclusion: the more information individuals who have worked in the industry share about their own paths and the uncertainties they’ve experienced, the more empowered newcomers and members from under-represented groups will feel to make their own career decisions.