Software Engineer Title Ladder

http://changelog.ca/log/2013/08/09/software_engineer_title_ladder

Within the software engineering profession, there is an ordered set of titles that are in usage for software engineers.

I have seen these titles for software engineers at a number of companies, so I think they are probably a de facto standard. (Even if some companies only use a subset of them.)

The engineering ladder seems to range from:

1. Junior Software Engineer
2. Intermediate Software Engineer
3. Senior Software Engineer

... at one end, to:

1. Junior Software Engineer
2. Intermediate Software Engineer
3. Senior Software Engineer
4. Staff Software Engineer
5. Senior Staff Software Engineer
6. Principal Software Engineer
7. Distinguished Software Engineer
8. Fellow
9. Senior Fellow

... at the other end.

Although the meaning of senior software engineer in the former engineering ladder is a bit different than in the latter engineering ladder.

In the former engineering ladder senior software engineer really ranges the combination of the 7 most advanced engineering titles from the latter engineering ladder. I.e., the latter ladder‘s senior, staff, senior staff, principal, distinguished, fellow and senior fellow all get collapsed into the former ladder‘s senior software engineer.

(Note, I‘m not here to argue whether a total order is "best". Or whether titles are a good or bad thing. I only want to document them.)

(I‘m also not here to discuss whether managers should be bestowing these titles, whether your peers should be bestowing these titles, or whether you should take a non-institutional view and start using a title when what you are and what you do fits the definition of that title.)

Here I want to both list out the software engineer title ladder and describe my sense of what these seem to mean, based on my experience with them.

Titles for Software Engineers

So, since there is a range of what is being used for software engineering ladders, let‘s consider a kind of useful middle groundsoftware engineering ladder (that will help us understand what each of these titles mean):

1. Junior Software Engineer
2. Intermediate Software Engineer
   • Note that most people seem to usually call this just Software Engineer, without prepending with the word intermediate. 
     So that just Software Engineer = Intermediate Software Engineer.
3. Senior Software Engineer
4. Staff Software Engineer
5. Principal Software Engineer
6. Distinguished Software Engineer
7. Fellow

Junior Software Engineer

Junior software engineer is the start of the software engineer title ladder. When a software engineer first gets started professionally, that person is (usually) a junior software engineer.

The title junior software engineer generally signifies that either:

• the software engineer‘s skill level is still unknown or
• that it is known and the software engineer needs a lot of hand holding (from other software engineers) to complete any non-trivial amount of work.

(Even software engineers that show a lot of potential tend to start here, until they either get enough experience or demostrate competence at a higher level.)

Usually, in the short-term, junior software engineers have a negative impact on the productivity of a team (because of the hand holding). But long-term, when their skills and experience increase, they can be a good investment.

Intermediate Software Engineer

Like I already said, most people don‘t actually call people intermediate software engineers. "Intermediate software engineer" is usually shortened to just "software engineer". (Which can be a little confusing, when you want to talk about software engineersin general, without a title. But anyways....)

An intermediate software engineer is an engineer who can do work without any hand holding, but doesn‘t yet have the skills and experience to be a senior software engineer.

Typically, although an intermediate software engineer doesn‘t need any hand holding they still need someone to break down a high level task into smaller well-defined tasks for them to work on.

So, perhaps another way of defining what an intermediate software engineers is... an intermediate software engineers is a software engineer who can work on and complete a small well-defined task (but doesn‘t yet have the skills and experience to be a senior software engineer).

Also, intermediate software engineers tend not to have a full grasp of the software development life-cycle (SDLC) yet.

Also, intermediate software engineers tend not to understand the big picture.

Typically, an intermediate software engineer can get their code to work, but does not have the experience or knowledge to do the quality of work, from an architecture, maintainability and testability point-of-view, that you would expect from a seniorsoftware engineer.

Senior Software Engineer

A senior software engineer is capable of being given a high level (and often vague) task, and work completely independently on it and finish it.

I.e., a senior software engineer does not need their work broken down into small well-defined tasks for them; a senior software engineer can take a high level (and often vague) task and break it down into small well-defined tasks themselves!

Although senior software engineer could do it all the work on a project completely own their own and independently, they may have other software engineers help them with the project. Especially in times when it is preferable that the work be done faster. (Like if there is a deadline.)

Typically, a senior software engineer is aware of the full software development life-cycle (SDLC) and have good architecture skills such that things like maintainability and testability are addressed.

Typically, a senior software engineer is expected to provide production support (like waking up at 3:00am to fix some problem on production) and to help deal with company-wide concerns.

Typically, a senior software engineer can be trusted to work independently to solve most problems.

It should be noted that some companies stop at this title -- at senior software engineer -- and have no engineering titles above it. At these types of companies, there is a very broad range of skill wrapped into the senior software engineer title.

However, others keep on going with titles above senior software engineer; and so, so shall we.

Staff Software Engineer

(Some people find it odd that there is a title above senior. But yet, that is what staff software engineer is.)

A staff software engineer is everything a senior software engineer is plus has the ability to be the engineering lead for a small team (of say 3 to 7 engineers).

Note that this does not imply that a staff software engineer is necessarily officially an engineering lead, even if though they could be. It is the ability to be the engineering lead that is relevant.

Although often, even if they are not officially engineering lead, they often become de facto leads.

Often staff software engineers will spend a non-trivial amount of time mentoring and teaching other software engineers, and helping other software engineers improve their skills.

Sometimes staff software engineers may even have high level roles in multiple teams.

Often, staff software engineers help improve the productivity of other software engineers.

This is actually an important point. Not only do staff software engineers have a positive impact on the team, with their own work. But staff software engineers help make other people (on their team and any other team they interact with) be more productive.

And it is not uncommon for staff software engineers to be heavily involved in the recruitment and hiring, of new engineers.

Typically, a staff software engineer is actively involved in architecture and process improvements.

I‘ve seen some companies use the title lead software engineer to mean the exact same thing. (Although even at the companies I‘ve seen the title lead software engineer used, there are still software engineering titles above it too.)

If you can excuse the segue, if you are curious about where the title of staff engineer came from, from what I can tell it comes from the miliary. (See Etymology of the Staff Engineer title for more info.)

Principal Software Engineer

A principal software engineer is everything a staff software engineer is plus either

• they have very extensive industry accomplishments or
• they are someone that the company cannot do without (because they have such a key role on such a key company technology, that loosing them would be devastating to the company).

Typically, principal software engineers will drive and push things in their engineering department or (depending on the size of the company) the company as a whole.

Typically, principal software engineers are self-motivated to the point that they create new work (for themselves and sometimes others) and have their own vision for what needs to be done.

It is not uncommon for principal software engineers to "own" major internal technologies and infrastructure and act as a kind of "technical product owner", creating their own roadmap for those major technologies and infrastructure.

Some principal software engineers will write whitepapers.

Distinguished Software Engineer

A distinguished software engineer is everything a principal software engineer is plus they have done something that impacts the whole company or the broader computer industry.

Typically, distinguished software engineer have some level of fame, in the broader computer industry or within the company, because of their work and accomplishments.

Fellow

A fellow is everything a distinguished software engineer is plus their industry or company-wide accomplishments are astounding.

A fellow‘s accomplishments and contributions are company-wide and extend even further. To the open-source community, to academia or to the industry at-large.

In the world of software engineering, fellows are the elite of the elite.

Typically, fellows can be trusted to work on independent research (with full autonomy) and lead major initiatives.

On Titles

Some extra words on titles.

When I was younger, I used to not care about titles. I didn‘t think they mattered.

My thinking was that, in general, in the absence of people exerting positional power, software engineers will eventually tend to self-organize into social structures that more-or-less reflects their skills and innate temperament. And that this is usually close to an optimal organization, in terms of output of the team. And that this social organization can (and sometimes should) organically change from project to project, and over time. And things should not prevent this social organization from organically changing. And titles can hurt this process.

(Note, I‘m not trying to claim this is actually true here. But just pointing out my thinking on titles around a decade ago.)

Eventually I realized titles did matter, but for a reason I didn‘t realize until later.

Titles are used as proxies for quality by many people.

How do non-technical people judge your skill level? Usually, they can‘t!

These type of people use things like your past titles, your (university) degree(s) and your years of experience (in total and on with specific things) to judge you.

Thus, since you may have to deal with these kinds of people, you may want to care about titles.

For marketing purposes, companies will something ask specific customers to provide a quote that validates their product. (For example, a company might ask the CEO or VP of a well known company to say something nice about their product, that they can publicly display on their website and include in their marketing material.)

Like it or not, titles are like this when you deal with non-technical people involved with hiring. A title X at company Y is in effect like that company saying that you‘re (at least) that good, in the eyes of non-technical people.

(This is why the practice of some companies choosing not to give their engineers senior (or higher) titles, because they are worried about recruiters and head hunters going after them, is actually harmful to the engineer. I was at one place that did this.)

Of course, if you are dealing with other technical people, they can gauge your skills more directly. For example, when I am interviewing engineers, I give them a coding test (where they code something typical of the type of work they would be given, if they were hired).

Although even a technical person doing the hiring may need to find some way to (say) reduce 100 resumes to 5, and only interview those 5. And they may (in part) use titles for that.

So titles can even matter when technical people do the hiring, to some degree.

Leaders versus Managers

Just to be explicit.... I have used the term "lead" a number of times in this. I need to be clear than an "engineering lead" and "engineering manager" are 2 very very different things.

Managers are NOT (in general) leaders, despite many managers liking to promote the idea that they are. (They‘re not. Management is not leadership.)

(And I am someone who has been both an engineering lead and an engineering manager, at various times. So, part of this comes out of experience.)

Managers get people to do things from positional power, even when it is done "with a smile". (People are often worried about getting fired.)

Leaders get people to follow their example. (I.e., they are doing the same type of work as the people they are leading.)

Senior Software Engineer Ceiling

Some companies end their engineering ladder at senior software engineer.

At these companies, there is no staff software engineer, principal software engineer, distinguished software engineer, or fellow. They just have junior, intermediate, and senior. That‘s it.

(Most of the places I have worked have actually been this way.)

At companies like these, there tends to be a huge range of skills under the senior software engineer title. Although I didn‘t always have an opinion on this, I am now NOT a fan of this practice.

Under this practice, exceptional software engineers of 5 years experience are rightly called senior software engineers. But, under this practice, these same engineers would still be called senior software engineers, say 10 years later, after they have lead teams, have mentored other engineers, have been lead system architect, have very extensive industry accomplishments, have gained some fame for their accomplishments, etc.

Without getting too off track, I think having the engineer ladder this shallow is a bad idea because I think it (partially) causes some very very good and very very experienced software engineers who have no desire to go into management decide to go into management just to advance.

(Note, that isn‘t a slight against management. I‘ve done management before, a number of times. If you want to be a manager and have the skills and stomach for it, then go for it. But I know a lot of software engineers who woud prefer to stay software engineers, but the only reason they look to management is to advance.)

原文地址：https://www.cnblogs.com/dhcn/p/10729002.html