nerdleader

I have heard or read once or twice that job titles do not matter. The people saying this are attempting to communicate that while everyone on the team has a role, it is unacceptable to say, in today’s digital age, “that is not my job”. Even if it is not one’s job, we want our teammates to help out, find whose job it is, and be a part of the solution. Laudable. Yet inevitably, the people saying “titles do not matter” are those in positions of power and influence, whose own titles perhaps do not matter, and are fighting against centuries of precedent.

Indeed, we use titles to communicate who we are, what we can do, and what we are capable of handling. In this two-part post we will look at how to create job titles with communicative power, starting with individual contributor titles and following up in two weeks with manager titles.

Kings, nobles, officials, soldiers – officers and enlisted alike – have treated titles with deathly seriousness. At work we are expected to adhere to societal norms where we follow people with more experience or who have been given authority by the organization we are working for. Historically, there are very specific ways of using titles and honorifics to enforce respect and a chain of command, and it has only been during the 20th century explosion of the middle class that we have seen the creation of long, unusual titles. Let us bring some order back to the situation by breaking down the pieces of a title and creating some standards for our use.

One great example of how to manage titles appropriately is the United States Navy. Unlike soldiers, who have ranks such as Private and Sergeant, enlisted sailors have a “rate”, which is a combination of their job (aka a “rating”) and their pay grade. For example, a “hospital corpsman” (medic) rating is abbreviated as “HM”, and if you are a Petty Officer, you might be “3rd class” – therefore, your rate could be “HM3”, indicating you are a Hospital Corpsman, Petty Officer 3rd class (specifically, Hospital Corpsman, 3rd class). The Navy has your job and pay grade combined into 3 alphanumeric characters.

In the civilian world, we want to use titles to communicate duty/role, relative level of experience, and relative level of authority efficiently and quickly. For IC titles your goal is to allow individual achievement and advancement while also allowing others to understand your team member’s expertise (their naval “rating”, in other words). In other words, just like in the US Navy, you need to show progression and duty. While reviewing standardized team titles, if it seems like an individual fits into a few different levels / grades, pick the higher one. I build titles using the following pattern:

<grade> <aspect> <role> - like Senior Software Engineer, or Lead Data Architect

Grade

I really appreciate how close we are to standardization for the grade / level of experience we show in titles. In order:

• Junior - 0-1 years of experience, requiring heavy supervision
• Staff - 2-5 years of experience, regular levels of supervision (I suggest following convention and not using the word “staff” in writing)
• Senior - 5-8 years of experience, mentorship expectations
• Lead - 11+ years of experience, mentorship and management expectations (this can be a terminal position)
• Principal - 15+ years of experience, ownership of large functions or platforms (this can be a terminal position)
• Distinguished - 20+ years of experience, ownership of large functions or platforms, expectations of evangelism, patentable ideas, and trailblazing (this can be a terminal position)

You should allow for a few years in each grade, expecting that after 12-15 years a developer should be able to hit Lead status – and perhaps not have a promotion afterwards. “Principal” should be reserved for certain positions or as a reward for certain accomplishments, and “Distinguished” should be rare and used as a reward or enticement for a unique hire or retention.

Aspect

Next, I believe we should use a descriptive technology aspect in our title. As we hyperconverge responsibilities within technology these would certainly vary:

• Infrastructure – server & host administration, storage, and other sysadmin duties
• Network – specifically network operations, a dash of security
• Security – security ops, a dash of networking and infrastructure
• Cloud – software-based cloud infrastructure; highly multi-disciplinary
• DevOps – pipeline and efficiency-based developer operations
• Software/Full-stack – full-stack programming oriented
• Back-end/Front-end – programming within specific tiers
• Data – data storage and usage
• Product – externally facing, revenue-generating and multi-disciplinary
• Quality – eliminating bugs, enhancing security and performance

Etc.

In this way we can understand more about the expected expertise an individual should have – whether for performance management or for hiring purposes.

Role

Next, let us talk about role – what an individual does for their job. It communicates expertise, but also responsibility. Some roles are operations-centric, while others are creation-centric:

• Intern – anything, but with extensive mentoring and guidance. Do not use “grade” as part of this role
• Analyst – operations-focused role responsible for executing on plans and previously-created procedures
• Administrator – operations-focused role with heavy tool usage and primary responsibility for operational outcomes
• Engineer – primary creation-focused role with heavy usage of tools and education
• Architect – secondary creation-focused role focused on interconnection and long-term sustainability
• Scientist – research role for r&d, primarily used for data

But what about special modifiers? “SAP”, “Supply Chain”, “Global”, etc. There may be instances where you need this level of specificity, but it is likely pigeon-holing for the individual. Do you NEED to include “Oracle” in the job title? Seems extraneous and unnecessary, so I tend to avoid brand names and too much specificity. Yes, having "Java" in the title has a certain communicative power, but I feel that it is more of a limiter than an asset. Technologists are strongly multi-disciplinary within their role - developers know multiple languages, administrators know multiple tools and systems, etc. Save the specificity for a job description.

At this point we have clear titles that effectively communicate to prospects, team members, peers, etc., what the relative level of experience and expertise are for the position. In two weeks, let us examine how to standardize Manager titles and further discuss removing specificity.