Career Growth, Promotion and the Staff-Engineer Path

"How do you grow your people?" "What does a senior engineer do?" "Do you want to be a manager or a staff engineer?" These questions come up in interviews and in 1:1s. This lesson covers levels and ladders, what changes as people get more senior, the manager and individual contributor tracks, the staff-engineer path, how mentorship differs from sponsorship, and how to prepare a promotion case.

Read Lesson 0 first for the answer shape. This lesson builds on Lesson 8 (1:1s, feedback and delegation) and Lesson 9 (mentoring, onboarding and hiring). For how leads think about the next role see Lesson 4.

Everything here is common practice and opinion. Ladders and titles differ a lot between companies, so use the ideas, not the exact words, and always use your own true examples.

Words used in this lesson

• A career ladder (or leveling guide) is a document that says what is expected at each level, so people and managers can talk about growth in the same terms.
• A level is one step on the ladder, for example "Developer 4". Senior usually means a level where the person works with little supervision and helps others.
• IC means individual contributor: someone who does the work and does not manage people. The IC track is the path for people who grow without becoming managers.
• Scope is how big and how unclear the problem is that someone owns. Impact is the result for the business, users or the team.
• Output is the amount of work done (tickets, lines of code). Output is not the same as impact.
• A staff engineer is, in many companies, an IC level above senior. The name and duties differ per company.
• Mentorship is advice and teaching from someone with more experience. Sponsorship is when someone with influence uses it to create chances for you, and speaks for you when you are not there.
• A promotion packet (or case) is a written summary of the evidence that someone already works at the next level.
• A force multiplier is a person whose work makes many others more effective.

Levels and ladders: what they are for

A ladder is a shared language. Without one, "you are not ready to be senior" means whatever the manager feels that day. With one, the conversation can be about specific behaviours.

jorgef's open-source Engineering Ladders is a good example to read because it is short and public. What it says (I read it directly):

• It gives four ladders: Developer, Tech Lead, Technical Program Manager and Engineering Manager, over levels 1 to 7. Levels 4 and above are marked "senior".
• It describes growth along five axes: Technology, System, People, Process and Influence. Each axis has five steps, and "every level includes the previous one(s)".
• The Influence axis grows like this: Subsystem, Team, Multiple Teams, Company, Community. In the Developer ladder, D1 and D2 have Subsystem, D3 and D4 have Team, D5 has Multiple Teams, D6 has Company and D7 has Community.
• The People axis steps from Learns and Supports, to Mentors, then Coordinates and Manages.
• Its own FAQ says the framework "should not be used as a checklist to promote people but instead as guidance to have meaningful career conversations".
• It says companies usually expect a person to be performing at the next level consistently for several months before a promotion is made official.
• For evidence it suggests a mix of 1:1 conversations, feedback from peers and other teams, and self-evaluation.
• It stops at level 7 because "levels 8 and above vary drastically from company to company".
• It says that examples of behaviour per level should be defined by each team, because they depend on the team's system and stack.

Notice what is missing from the five axes: lines of code and number of tickets. Growth is about what you own, who you help and how far your work reaches.

Many ladders exist, and they differ

The lists point to many public ladders. awesome-engineering-ladders groups links for Kickstarter, Dropbox, Rent the Runway, GitLab and Etsy. charlax's list also links Square, Spotify, Medium, Carta, Foursquare, Monzo, Songkick, Khan Academy, CircleCI and others. I did not open these ladders. From the list's one-line notes only:

Reading three of these side by side is the quickest way to see that "senior" does not mean the same thing everywhere.

Scope and impact beat output

The common thread in the sources I read is that moving up means a bigger scope, not more effort at the same size.

A simple way to picture it (my own words, loosely in the spirit of the impact-based levels in the list):

Two cautions:

• More hours is not more scope. A person who works late on small tasks is not working at the next level.
• Impact needs a witness. If nobody can say what changed because of your work, the case is weak. Numbers help: "release time down from 40 minutes to 12", "onboarding of new hires took 5 days instead of 10".

The Career growth section of charlax's list has an article on rewarding simplicity: "Nobody Gets Promoted for Simplicity" (I have only the one-line note: it has ideas for rewarding simple designs in promotions and celebrations). This is a good thing for a lead to think about. The person who prevents an incident, or who deletes code, often leaves little visible evidence. A lead can write that work down on their behalf.

Two tracks: manager and IC

A healthy ladder lets people grow without becoming managers. In the list, Square's framework is described with two tracks and the note that becoming a manager is not a promotion. It is a different job.

jorgef's "Tech Lead vs Engineering Manager" page gives one clear split, which I read directly: the Tech Lead is in charge of the system and the Engineering Manager is in charge of the people. Some examples from its table:

The page also says that in a small team, one person may do both roles, and that each should be able to act in the other's role when needed. Treat the percentages as one framework's opinion, not a rule.

How to choose a track (my advice):

• Try before you decide. Lead a project, run the team's planning for a quarter, or mentor a new hire. See what gives you energy.
• Management is a change of craft. The work becomes meetings, 1:1s, hiring and hard conversations. If you love deep technical work, ask yourself honestly whether you will miss it. The list links Rob Walling's "Why Good Developers are Promoted into Unhappiness" (title and short summary only for me: it argues that management may not be for you).
• You can move back. The list links the idea of an "engineer/manager pendulum" (from an article on technical decay, title only). Many people go back and forth. It is not a failure.

When someone on your team asks "should I become a manager?", do not answer with a promotion. Help them try small pieces of the job and talk about it.

The staff-engineer path

In many companies, "staff engineer" is the next IC step after senior. What it means differs per company, but the lists describe a few shared ideas (again, one-line notes only):

• charlax's professional-programming list has a Getting to Staff Eng section. One article in it says that "coding is a small part" of the job and that you should "figure out what matters and let the rest go".
• It links Will Larson's staffeng.com guides ("Being visible") and a post on staff archetypes. I could not open those, so I do not describe the archetypes.
• It also links a post by an engineer on how to find problems to solve at staff level.
• A post called "What's a senior engineer's job?" is described there as: you need to be more than just an individual contributor.

From jorgef's Developer ladder (which I read), the top levels add multiple teams, the whole company and the community as the reach of influence. The ladder also says levels above 7 differ too much between companies to describe.

My own working description of the staff-level shift, which is opinion:

1. You pick the problem, not only the solution. Nobody hands you a ticket. You find what matters most and write it down.
2. You work through other people. Your output is often a design, a decision or a better habit that others use.
3. You write more. Design docs, strategy pages and decision records (see Lesson 5 and Lesson 12).
4. You build trust across teams. Not by title, but by being useful and honest.
5. You still know the code. Staff engineers who stop understanding the system lose their credibility.

As a lead, your job is to give such people real problems to own, protect their time from too many small tasks, and not use them as "the person who fixes everything".

Mentorship is not sponsorship

Mentorship and sponsorship are different:

I did not find a source in the lists for this exact split, so treat the table as my own summary of a common idea. The related item in the lists is Keith Rabois's quote about expanding "the scope of their responsibilities until it breaks". The list also says that if people often visit a certain person's desk for help, that person may be ready for more responsibility.

As a lead you can sponsor in small, concrete ways:

• Give visible work. Let a person present at the demo, lead the incident review or own the cross-team project.
• Say their name. When a manager asks "who did this?", name the person and the result.
• Open the room. Invite them to a planning meeting where they will learn how decisions are made.
• Recommend them. When a stretch project comes, suggest the person, with your reason.
• Be fair. Sponsor based on evidence and potential across the whole team, not only those who are loud or similar to you. Watch for the biases in Lesson 7.

How to grow people on your team

A plain routine (my own, built on Lesson 8 and Lesson 9):

1. Ask what they want. In a 1:1: "What do you want in 12 months?" Some want depth, some want to lead, some want stability. All are valid.
2. Check the ladder together. Look at the next level. Where are they already strong? Where is the gap? Use the ladder as a map for the conversation, not a checklist (as jorgef's FAQ says).
3. Pick one stretch. One project that is slightly too big, with support. Not three.
4. Give feedback soon and specific. After the stretch, say what worked and what to change.
5. Make the work visible. Presentations, docs, credit in public.
6. Review every quarter. Write down progress. Change the plan.
7. Do not promise a promotion. The list I read has a hiring entry that says a promise of an unconditional promotion is risky, because company conditions and performance can change. Promise a clear path and honest feedback instead.

Promotion packets and evidence

A promotion decision is stronger when it rests on written evidence gathered over time. jorgef's ladder says the usual rule is that the person has been performing at the next level consistently for several months. In other words, you promote a person for what they already do.

A promotion packet template (my own; your company will have its own format):

# Promotion case: <name>, from <level> to <level>## Summary (3 sentences)What they do now at the next level, and why it matters.## Scope and impact (the main section)- Project 1: problem, what they decided, result with a number, who else was affected- Project 2: ...- Project 3: ...## Behaviours against the ladderFor each ladder axis or competency: one or two real examples with dates.## Feedback from othersQuotes from peers, other teams, product. Short and specific.## Gaps and how they are being addressedBe honest. A case with no gaps is not believable.

Tips:

• Collect evidence all year. Keep a running note per person: wins, feedback, incidents handled. The list suggests mixing 1:1 conversations, peer feedback and self-evaluation. Ask the person to keep their own record too (sometimes called a "brag document").
• Use facts, not adjectives. "Reduced the build from 20 to 8 minutes, now used by four teams" beats "great engineer".
• Show scope growth. "Owned a task" in January, "owned a problem" in June.
• Check for bias. Are you comparing the person to the same standard as others? Would you write the same words for someone you like less?
• Share the result early. The person should hear the plan before the committee, and hear honest reasons if the answer is not yet.
• Know the process. Who decides, when, and in what format. Ask your manager and HR early.

When the answer is "not yet", give a precise gap and a plan: "To show the next level, I need to see you lead a project that crosses two teams. Let's choose one for next quarter." Vague answers hurt trust.

Growing yourself as a lead

You also have a career. The lists have a few short ideas:

• Take responsibility for your trajectory. One article in the professional-programming list is summarised as: read books and papers, not only blog posts, and take responsibility for your career path (one-line note).
• Ask for the scope you want. This one is my own advice: read the level above yours, and ask your manager for a project that shows that scope.
• Interview the company too. awesome-cto's Career growth section links "reverse interview" resources and a GitHub list of reverse-interview questions (titles only for me).
• Write your own ladder check. Once a year, read your ladder's next level and mark each line as "done", "partly" or "not yet".

Try it

1. Output or impact? A person closed 60 tickets this quarter. Another closed 12 but removed a flaky test setup that was costing the team 3 hours a week. Who has the stronger promotion evidence? Answer: It depends on the ladder, but the second person has concrete impact on the team, and the number is clear. Tickets alone show output. I would ask what the 60 tickets achieved.

2. Mentor or sponsor? You tell a junior how to structure a design doc. In a planning meeting you suggest she lead the next design. Which is which? Answer: The first is mentorship (private advice). The second is sponsorship (using your influence in a room she is not in, or is in without the standing yet).

3. Not yet. A senior engineer asks about the next level. Write a two-sentence answer for "not yet". Answer: "You do the senior work well. To show the next level, I need to see you pick and own a problem that crosses two teams, and bring others with you. Let's choose one for next quarter and I will help set it up." It names the gap and the next step.

4. Evidence. List three pieces of evidence you could gather this month for someone you want to promote. Answer: For example, a short note on a project they led with a measurable result, two pieces of peer feedback from outside the team, and a design doc they wrote that others used.

Interview questions

Key takeaways

• A ladder is a shared language for growth. Use it as a map for conversations, not a checklist.
• Moving up means bigger scope and wider influence, not just more output.
• Management is a different job, not a promotion. Good companies have a real IC track.
• The staff level, as the lists describe it, is about choosing problems, working through others and writing, while still knowing the system.
• Mentorship is private advice. Sponsorship is using your influence for someone in rooms they are not in. Do both and be fair.
• Promote people for what they already do consistently, and gather evidence all year.
• When the answer is "not yet", name the gap and agree on a concrete next step.
• Ladders and titles differ by company, and I read only one ladder fully. Check your own company's rules and ask HR.

What's next

Next: A security mindset for team leads, Lesson 14. Practise: open your company's ladder (or jorgef's), pick one person on your team, and write down for each axis one piece of real evidence and one gap. Use it in your next 1:1.