Module 3: Getting the Title

The Promotion Packet

The rule that makes staff promotions hard is stated plainly in GitLab’s handbook. You do the job first. Then you get the title. The promotion packet is how you prove the first part.

The Company Rule and the Coach’s Rule

GitLab’s line is a company saying it. John Sonmez says the same thing from the coaching side: “You can’t wait for the promotion to start doing staff work. You have to prove you can do it first.” Two very different sources, one rule. Everything in this module follows from it.

Source: How to Become a Staff Engineer, John Sonmez.

The Template

Will Larson’s promotion packet has seven sections.

# Promotion packet: [your name], Senior -> Staff

## 1. Staff projects
What you did, the impact against a defined goal, why it was
hard. Brief, with links.

## 2. Organizational improvements
The high-leverage ways you made the org better.

## 3. Quantifiable impact
Revenue. Tickets reduced. Latency cut. Numbers.

## 4. Mentorship
Who, and what they went on to do.

## 5. Glue work
The coordination work, and what it unblocked.

## 6. Advocacy
Which teams and leaders know your work, and what they
value about it.

## 7. Gap analysis
Every skill or behavior gap, each with a one-sentence plan.

Source: Promotion packets, Will Larson.

The Process

Larson’s point is that the packet is not a form you fill in the week before calibration. It is a working document you start years early. His sequence:

1. Get clear on why you want staff.
2. Set expectations. Promotions take quarters to years.
3. Share the empty packet with your manager and ask for guidance.
4. Write the first draft in one hour.
5. Edit it two days later.
6. Get feedback from peers in staff-plus roles.
7. Share it with your manager and spend the conversation on the gaps.
8. Review it in 1:1s, and again every time you get a new manager.

Ritu Vincent’s advice from the same guide: “be super open and honest with your manager about what you want from your career.”

Find Your Sponsor

Your problem: many engineers who have done staff-level work never get the title, and the reason is not the work. Nobody argued for them in the room where the decision got made.

That is Will Larson’s most uncomfortable finding.

Why the Packet Is Not Enough

Larson calls promotion to staff a team activity. A calibration meeting is a constrained setting. Headcount for promotions is limited, the people in the room have limited time, and your packet is one of many. A sponsor is someone who advocates for you in that setting, and in budget and staffing decisions where your name would otherwise not come up.

Your direct manager is your primary sponsor. They control the packet and speak for you in calibration. Larson’s second instruction is to cultivate your skip-level manager, so the person one rung up remembers your impact when the discussion happens.

The Question to Ask

Larson’s guide suggests one question for your sponsor, and it is worth asking every cycle.

It turns a vague conversation into a gap list, and it tells you whether your sponsor has thought about your case at all.

The People Who Already Did It

Terry Brown, who mentors engineers into staff roles at Mews, adds a source Larson does not: the other staff engineers at your company. They planned this path themselves, and in Brown’s experience they will share what worked. His added test: if a staff engineer at your company will not help you with this, “they’re possibly not staff engineers.”

He also recommends the direct conversation with your manager about visibility, amplification, and evidence, and if your company has no progression framework, reviewing ones at progression.fyi with your manager to find a fit.

Source: Becoming a staff engineer: some resources, Terry Brown.

What Happens Without One

John Sonmez’s fifth promotion blocker is “not building sponsor relationships,” and his third is lack of visibility, which he treats as the same problem: staff-level work that the people who decide promotions never see. Larson’s version is more specific, because he names who those people are and what they need from you.

Source: How to Become a Staff Engineer, John Sonmez.

The Staff Project Myth

Ask most engineers how you get to staff and they describe a staff project: one big, ambiguous, high-visibility piece of work that proves you can operate at the level. Larson’s interviews say most staff engineers never did one.

What the Interviews Found

Diana Pojar said Slack does not require one for promotion. Nelson Elhage was skeptical of the whole idea, pointing out that some staff engineers are most valuable as “gurus and routers” rather than project leads. Dan Na and Damian Schenkelman reached staff by passing through engineering management.

Some did. Ritu Vincent led an 18-month project at Dropbox to support multiple user accounts in a single process. Ras Kasa Williams became tech lead on Mailchimp’s analytics platform initiative.

Larson’s conclusion is that the requirement is informal and company-specific, and engineers often discover whether their company has one only during promotion discussions. Which is one more reason to send the empty packet to your manager early.

Source: Staff projects, Will Larson.

If Your Company Requires One

Larson names three characteristics of a real staff project.

• Complexity and ambiguity. The problem is poorly defined and important.
• Divided stakeholders. People disagree on both the problem and the approach.
• High visibility. Senior leadership is watching, so success and failure are both public.

If you take one on, run it with Reilly’s chapters 5 and 6 from lesson 2.4. Her structure for the start of a project, the “if you’re feeling overwhelmed” section, and the six blockers exist for exactly this.

If It Does Not

Build the portfolio instead. GitLab’s list of staff initiatives from lesson 1.4 is a ready-made portfolio: owning the triage report, running RCAs, becoming a DRI for an architecture blueprint, setting a cross-team standard, mentoring two people formally, representing the group to leadership.

None of those is an 18-month project. Together they are the evidence that you are already operating at the level, which is the only thing GitLab’s promotion rule asks for.

Source: Staff Engineers, GitLab Handbook.

Why Do One Anyway

One of Larson’s interviewees said her staff project gave her “experience, knowledge, and confidence” that mattered more than the title. A staff project is optional for promotion. It is not optional for learning how to lead something that spans an organization. If nobody hands you one, the portfolio gets you promoted and a cross-team migration of your own choosing teaches you the job.

The Five Things That Block a Promotion, and the Ones You Cannot Fix

John Sonmez lists the personal habits that stall a staff promotion. Will Larson lists the structural ones. They belong side by side, because the first list is what you can change and the second is what you can only route around.

The Five You Can Fix

Source: How to Become a Staff Engineer, John Sonmez.

The Ones You Cannot

Larson’s guide on getting the title where you are names two structural barriers.

Uneven opportunity. Organizations favor some teams over others without meaning to. Infrastructure over product. Headquarters over remote offices. Staff-level problems land on some teams more than others, so the engineers on those teams get more chances to show staff-level work. Larson’s advice is to recognize the pattern and align with it rather than fight it.

Semi-permeable boundaries. Leadership positions are harder to reach if the existing leaders do not identify with you. Larson’s survey found roughly half the women he interviewed changed companies to reach staff, a rate of promotion friction he did not see for men.

Source: Getting the title where you are, Will Larson.

How to Tell Which One You Are Hitting

Reilly’s chapter 9 lists five metrics to keep an eye on in your current role. The chapter’s structure asks: what is important to you, where are you going, what do you need to invest in, and then, can you get what you want from your role.

If you have fixed Sonmez’s five and the packet from lesson 3.1 has been reviewed for two cycles with the gaps closing and no promotion, the blocker is structural.

Source: The Staff Engineer’s Path, ch. 9, Tanya Reilly.

Stay or Switch

Larson’s numbers: about two thirds of the staff engineers he interviewed were promoted at their current company. One third changed companies to get the title. This lesson turns that into a decision.

The Base Rate

Two thirds in place means the default is to stay, and Larson’s whole “getting the title where you are” track (packet, sponsor, room, visibility) is the playbook for it. One third switching means leaving is not failure. It is a standard route, and for underrepresented groups a statistically likely one, as lesson 3.4 covered.

Source: Getting the title where you are, Will Larson.

The Clock

John Sonmez estimates the senior-to-staff transition takes 2 to 4 years of demonstrating staff-level impact, and that most staff engineers reach the role 8 to 15 years into their careers. These are his estimates, not survey data, so treat them as a rough clock rather than a rule.

The useful part is the shape: two years of visible staff-level work with no movement is a signal. Four is a verdict.

Source: How to Become a Staff Engineer, John Sonmez.

The Switching Track

If you decide to switch, Larson has four guides for it.

• Deciding to switch companies: making sure you are leaving for the right reason and not to escape a fixable problem.
• Finding the right company: which companies have staff roles that match your archetype, and which have the title but not the job.
• Interviewing for Staff-plus roles: Larson’s finding is that “most companies struggle with their Staff-plus interview loops,” so the format varies from a repeat of the senior loop to presentations and deep dives on past work. Ask up front what the format is, who the interviewers are, and when leveling gets decided.
• Negotiating your offer.

The Paths That Are Not “Staff at a Different Company”

Reilly’s chapter 9 lists more options than stay or switch. Keep doing what you are doing. Work toward promotion. Work less. Change teams. Build a new specialty. Take a management role. Change employers and go up a level. Change employers and go down a level. Start something. Go independent.

Two of those matter here. Changing teams inside the company is a way to fix the uneven-opportunity barrier without leaving. And Larson’s interviews include several people who reached staff by passing through management, which Charity Majors calls the engineer/manager pendulum.