Great advice from Alex on this question. Regarding "Understanding The Delta", here's a tool you can try:

Ask your manager if he'd be open to starting a draft of your promo packet doc even if he doesn't think you're ready for promo yet. The draft can serve as a spec for where you're meeting the bar and where there are perceived gaps. It's an easy way for the two of you to stay on the same page and reduce the work needed when it comes time to put you up for promo. Think of it as the TDD version of career advancement.

Executive Coach, VP Eng at Mixpanel

David Pan

Agree with Alex on this one. Here's another way to frame the answer:

All companies are in the business of delivering some valuable solution to their customers in a profitable way. Technical complexity is a *negative* most of the time because all it does is increase cost to the company. That can come in a lot of forms:

- More expensive to operate
- More time for other engineers to ramp up and contribute
- More fragile for customers since there are more moving parts

I would argue that staff engineers should help companies find ways to simplify. As an engineer, a good way to create value is by lowering costs, not increasing them. But, of course, your engineering leadership must also think this way for it to be good career advice. I suspect that Meta does.

Every company is a bit different in how they define staff. Here's what I look for:

Most of engineering is about building solutions to problems that are largely handed to them by managers or PMs. But at certain stage of seniority in every career path, you start to become responsible for finding the right problems to solve as well. IMO, staff+ engineers are the ones who have a track record of doing this effectively. It looks something like this:

1) Identify a high leverage problem that few others are thinking about
2) Persuade those around you that this is worth solving
3) Solve it and be right about the impact you expected
4) Repeat

I know it's a high bar but this is how people reach the most senior levels of their profession.

In the behavioral interview, some hiring managers will also give you a shot at a higher level if you've demonstrated a steep growth trajectory over the course of your career. Here are a few thoughts on how to do that in an interview:
* Do your roles and projects paint a picture of expanding impact over time?
* When projects don't go as planned, do you have a good handle on why and how you'd apply those lessons in the future?
* When you talk about moving between companies or teams, do you have a compelling explanation on what you hoped to get out of the move?

Here are a few ideas for how to think about the impact of technical projects:

1) Consider how well they align to the overall goals of your team and the business. Are customers complaining or churning because of reliability issues? Is performance a big differentiator for your product? This is likely to influence how much your management team cares about this type of work.
2) As you mentioned, sometimes the customer of your work is other engineers at the company. It never hurts to get feedback from your customers. If your work moved the needle in a big way for a few people, it should be easy to get feedback to back that up. If your work made a small difference for lots of people, it might be easier to measure.
3) Lastly, it's just true that the impact of tech debt projects is often hard to quantify. That's why it helps to have an eng leadership team that understands software development and has good judgement when it comes to technical impact. You can't run a team on numbers alone!