Engineering Paths for Advancement

Compensation =

i * salary +

j * stock options +

k * benefits +

l * who you get to work with +

m * where you get to work +

n * what you get to work on +

...

Mickey W. Mantle, Managing the Unmanageable

You will be frequently asked what path of Engineering you are most interested in. Your answer never needs to be definite, but you should hone in on what you are most interested in.

Note that there are no times associated with each step, and the company will not always need every step in a path filled at any given time, so these should be taken as generalities.

In addition, no path should be seen as intrinsically superior to the others. This will not be the case for compensation, either.

Each path starts out completely generalized, so you will be exposed to everything initially, but becomes more specialized as you advance.

Why the word "Engineer"?

If Engineers built buildings the way programmers wrote programs, the first woodpecker to come along would destroy civilization.

Gerald M. Weinberg, pioneer of programmer psychology

There is plenty of argument to be made, and I would mostly agree with you, that the word Engineer doesn't fully fit what most programmers do. There are no certifications, and typically not a whole lot of planning involved in the day to day job of most engineers. More typically, there is a fire, aim, ready mentality.

We, on the other hand, will be attempting to not take this tact, and instead plan our work in advance, to the extent it makes sense.

1. Ready: Do your best to create small tasks, estimate, realistically, what you are about to set out on and how long it each will take.
2. Aim: Start assigning tasks and get the general flow.
3. Fire: Start your work, adjust estimates and timelines as early and as loudly as possible.

We may not be Engineers in the fullest sense of the word, after all, if our buildings topple it is usually just a few minutes and a unit test, but we should aspire to be better than just being "programmers".

Why do we have titles at all?

There is much to be said about lack of titles in Software Engineering. The advantages typically manifest best as the less experienced employees feel more comfortable disagreeing and voicing their viewpoints. A lot of small companies start this way.

The flipside comes when the size of the team becomes unmanageable and specialization is required. What ensues is a very awkward transition of both labeling what people do and the level they do it. This process nearly always offends half of the folks.

We are going to start with titles. It helps other parts of the organization identify what folks they need to speak with, and it gives each of you more defined and direct paths to learning and advancement. That being said, every opinion matters, and I hope no matter the title you currently have, you feel comfortable disagreeing with anyone and arguing your case (See No Surprises).

Goals

When having 1:1 meetings with your manager, goals should be discussed in some fashion, at least on occasion. These goals can be set by yourself, but you should always feel welcome to discuss with your manager what types of goals will propel you along your desired path. As with all goals, these goals should be:

• Specific
• Measurable
• Achievable
• Relevant (this is what your manager can help with)
• Time-bound

Senior Engineer

Every path starts with the Engineer => Senior Engineer combination. The difference between an Engineer and a Senior Engineer is not "time" or "seniority", it is instead:

• Knows that all decision-making is a matter of tradeoffs, and can speak to what they are in a variety of questions or issues.
• An understanding of all pieces of the technical stack, and how they work with one another, even if skill level is not equivalent across the board.
• The ability to manage a small project and delegate to a co-worker.

Attributes

Each path will have rough attributes associated with it, approximations of what people who typically follow each path are like. Each will be graded on a 1-5 basis of importance.

• People: You have a deep and personal responsibility in the growth and success of those around you.
• Assembly: You enjoy jigsaw puzzle or Lego style problems, where the way the pieces fit together is more important than what is inside the pieces.
• Context: You enjoy puzzles that involve sorting and grouping, properly inserting seams precisely where they belong.
• Performance: You enjoy puzzles that involve optimization and efficiency, where a little change in effectiveness goes a long way due to heavy usage.
• Mathematics: A little more self-explanatory than the rest, but loving math is no crime.

Paths

Management

This path is all about human development and relationships: helping others succeed personally and professionally. This may be commonly referred to as "soft skills".

This path is closest to normal business operation paths of advancement, and is often associated with the most skilled of a group. This is NOT the case with our technology paths, and folks for these roles are instead chosen by how human-focused they are. Additionally, and importantly, managers of all levels still develop software. (It will be less, but it will not be none, the software development process is ever-changing, and it is important to know how).

While all paths require solid organization skills, this is the one where time management is likely to have the maximum positive or negative impact, because the leverage exerted on others is highest, so the importance is vastly increased.

This path is often associated with job titles that include the word "Manager" in them, and sometimes are called "Team Lead". Do not confuse this with "Lead" or "Tech Lead", which are in the Technical path.

Engineer => Senior Engineer => Manager of Software Engineering => Senior Manager of Software Engineering => Director of Software Engineering => VP of Software Engineering

Technical

This path is all about technical mentorship and sponsorship: helping others to succeed technically. This definitely requires "soft skills", but less so, and replaces that with technical knowledge for more difficult scenarios.

This path typically is associated with job titles that include the word "Lead" (not to be confused with "Team Lead", which is squarely in the Management path). Sometimes this path isn't really given a name, and a company just has some highly paid Senior Engineers.

You should also be familiar with Project Management, as you will be increasingly responsible for splitting up and planning projects. This should be done to maximize development potential for the Engineers.

This path will also house Site Reliability, Infrastructure, and Security specialized Engineers.

Engineer => Senior Engineer => Staff Engineer => Senior Staff Engineer => Principal Engineer => Distinguished Engineer

If these paths feel as though they overlap one another quite a bit, they do.

Performance Review

Performance Reviews are often a very formal, annual process, feeling very much like a waterfall software project. We will instead be using a more agile approach: Every interaction, especially ones outside the norm, with your manager, where feedback is delivered, should be considered a mini performance review.

If you wonder where you stand, never hesitate to ask.