Tech Job Titles
As an industry, we’re gradually heading towards a uniform set of job titles for engineers. It’s a bit slow, but I think we’re starting to get convergence; LeadDev can have a “Staff+” conference and the name makes sense.
Generally, we can sort engineering IC grades into three major bands –
The junior band – which counterintuitively goes up to “senior engineer” – is focused on executing tasks;
The mid grades – staff engineer and senior staff engineer– which are focused on solving problems;
The senior grades – principal engineer and beyond – which are focused on asking questions to find out what the problems even are.
Junior Band
Junior jobs are usually about executing a task. You get a fairly concrete statement of what needs to be done – ranging from “fix this class” at the more junior levels to “make a server that does this” at the more senior ones – and you need to make that happen. As people move up through this band, they progressively need less supervision, up to a senior engineer, who should be able to independently execute any task they receive, and also supervise other people. That is, at the top of this band you’re a fully independent professional engineer; it’s the first level which could meaningfully be a “terminal level” that someone simply stays at.
Mid Band
Starting at Staff, each successive job level starts to represent a change in the nature of the job, not just its scope. The mid grades, Staff and Senior Staff, are about solving problems rather than simply executing on tasks. A Staff engineer may be given a concrete problem (like “we need to systematically identify and merge duplicate websites in the search index, with the exact meaning of ‘duplicate’ being an open question”) and told to have at it; they need to figure out what the right tasks to do even are, and may execute on them independently or with a team.
The difference between Staff and Senior Staff I tend to couch in terms of “dependent” and “independent” teams. An independent team is one that has customers – to figure out what the problems are, you need to do product management to it, and your success or failure is based on whether your customers’ problem was actually solved. A Senior Staff engineer is someone who can lead one of those. A dependent team, on the other hand, is part of an independent team; its problems are set by the needs of the wider independent team they’re a part of.
(My own example: I got promoted to both Staff and Senior Staff for running high-capacity search at Google, where the basic problem was “we need to add several zeroes to how many documents our search engine can support, and the current theory of search engines doesn’t give good answers about how to do that” – and later on, turning search into an (internal) service for not just web pages but everything)
Senior Band
In the senior band – Principal and beyond* – you stop even getting concrete problem specifications, and are simply given an area of the company or an area of the business space. At these levels, your job is to figure out what the problems even are, and then make sure that the requisite teams exist to be solving the problems and executing on the tasks. You are walking around asking hard questions, and making sure they get answered.
The level names are a bit less well-defined up here, because there are fewer of them, so I find it’s instead more useful to look at the senior grades in a company and “count down” from the top. The topmost level (most commonly called Principal, Distinguished, or Fellow, depending on the size of the company) is usually doing this at the scope of the entire company (“what are the problems that we face, and what can engineering do to make them better?”) and successive levels below those are doing the same thing, but in a more focused area, such as “storage” or some particular product or family. My current role at Twitter is a good example – the title is Distinguished Engineer, and the job spec is “go talk to a bunch of people, figure out what’s broken, and fix it.”
You’ll note that the word “engineering” doesn’t actually show up in that job spec, and it’s not a coincidence: at these levels, the boundaries between job families like engineering, product management, people management, design, sales, and building maintenance get fuzzy. A key role of senior people is to act as a nexus between all the different specialities, and identify places where collaboration can make a huge difference.
Four Disciplines
Let’s turn now and talk about the things each project needs, and how senior leaders fit these things into their role.
Generally, every profession has four skill categories:
The core technical skill of that profession - writing code, or litigation, or driving a taxi. This is obviously the skill that varies most from profession to profession.
Product management - Figuring out what needs to be done and why, crafting and maintaining a narrative, and getting and keeping everybody on board with it.
Project management - Turning strategy into tactics, keeping the trains running, making sure that nothing is being forgotten or ignored by mistake, and generally bringing order out of chaos.
People management - Building the teams, finding the people you need, growing them as people and helping them in their careers, and ensuring that they can work together to succeed.
There are two lenses through which we can look at these: career development and team building. From a team perspective, every project needs leadership along all four of these axes – really “four plus,” since most projects require more than one technical skill. From an individual perspective, nobody is equally good at all four of these; most people have one or two they love and are good at, one or two they can do if they have to, and one or two that they hate and don’t want to work to get better at.
This is fine: it’s one of the basic reasons you want a team, so that one person isn’t trying to do all of these things. You don’t need a separate person for each one, and you certainly don’t need to tie these roles to the job title on someone’s business card; it’s fine (and healthy!) for an engineer to be product managing, or a project manager to run a team, or for someone to be both eng manager and tech lead. But the overall team leader needs to make sure that all these kinds of leadership are present.
This takes us to the job of a senior leader: if you’re at the level where you need to identify problems that need to be solved and make sure they’re taken care of, it’s on you to:
Figure out what needs to be fixed
Convince people it needs to be fixed
Build the institutional momentum behind fixing it
Assemble whatever teams need to be assembled
Pull together all the needed resources
Execute
This is what end-to-end leadership of a project is about. Steps one through three are ultimately about product management, but can’t happen without a deep understanding of the other three skills: a deep technical eye will reveal a much better idea, even a fundamentally different and better idea, than a less-technical one, and without a crisp project and people plan, nobody is going to believe it can be done and you’ll never get institutional momentum. Steps four through six require all four of the skills full-force, which is why assembling the right set of leads early on can be extremely helpful.
My experience
Most of what you're doing at the level of a principal or distinguished engineer is assembling teams and you might also lead them. In fact, the boundary between an individual contributor and a people manager gets incredibly fuzzy at this point. _(people management) _ You might be giving them direction. _ E.g How are we going to _turn this from an intractable mess into something realistic? (project management). I found that one of the biggest parts of my day-to-day work is really helping with more of the product management side of a team - figuring out what needs to be done and why._ . C_onvincing people is a huge aspect - figuring out a way to clearly and precisely articulate what is the problem and why it is a problem that needs to be solved. _(product management). But on the other hand, sometimes I'm also writing code. For example, right now I am writing code for the team I have right now where I happen to be the only engineer who's working on a particular set of problems. (core technical skill)_
________________________________________________
*Just to make this more confusing, a handful of companies (like Microsoft) use “principal” for a mid-band job, and “partner” for the senior role. Job titles aren’t standardized enough yet to take them at face value
