Module 4: Your First Year at Staff
Four lessons for the week after the promotion lands. What changes on day one, how influence scales past your own calendar, the seven traps, and what AI coding agents did to all of it.
| Source | Used for |
|---|---|
| GitLab Handbook | The four changes, minimum mentoring, the 90-day plan raw material |
| Tanya Reilly, The Staff Engineer’s Path (ch. 7 and 8) | Role model, the four levers of influence |
| Will Larson, staffeng.com | Operating at Staff, learn to never be wrong |
| Hands-on Architects | MOI model, psychological safety, the four traps |
| Alex Ewerlöf | Ivory tower and embedded-in-one-team anti-patterns |
| Maxime Najim (Target), Paula Muldoon (Zopa) | Lesson 4.4 only |
Day One: What Changes
Three sources describe the first weeks at staff. A company handbook, a book, and an interview. They describe the same shock from three angles.
The Company Version
GitLab’s handbook opens with “You became a Staff Engineer! Now what?” and then lists four changes to expect.
- Shift from hands-on to hands-off. Guide, coach, align, organize. Take the most critical or complex topics, and otherwise empower others to take your old place.
- Context switching. The handbook is direct: “it’s difficult to help people and get your job done at the same time. Remember, it is now your job as a leader to help people too!”
- Be an example. People will refer to how you handle disagreements, proposals, and your own growth when deciding how to handle theirs.
- Peer accountability. Hold others to their commitments and guide them toward improvement.
Source: Staff Engineers, GitLab Handbook.
The Book Version
Reilly’s chapter 7 is titled “You’re a Role Model Now (Sorry).” It has a section called “But I Don’t Want to Be a Role Model!” and then explains why you do not get a choice. Her framework for what a good job looks like at this level has four parts.
- Be competent. Know things, be self-aware, hold high standards.
- Be responsible. Take ownership, take charge, create calm.
- Remember the goal. There is a business, there is a user, there is a team.
- Look ahead. Anticipate what you will wish you had done, expect failure, optimize for maintenance over creation, create future leaders.
GitLab’s “be an example” is Reilly’s whole chapter compressed to three words.
Source: The Staff Engineer’s Path, ch. 7, Tanya Reilly.
The Interview Version
“There’s a misconception that you become a Staff engineer and then you’ll be in control of the work you do. That’s absolutely the opposite of what happens!”
Larson’s explanation is feedback delay. Mentorship, strategy, and relationships all pay off slower than code, so the first year feels like operating blind.
The 90-Day Plan
No source has one, so here is one built from GitLab’s initiative list and Reilly’s maps.
Draw the three maps from lesson 2.1. Pick two people to mentor formally. Sit in on your manager’s counterpart meetings.
Take ownership of one glue item: the triage report, the RCA process, or a working group. Write one seven-section doc on a decision your group keeps relitigating.
Become DRI for one architecture blueprint or cross-team standard. Represent your group to leadership on one recurring forum. Measure your deep-work ratio and fix the calendar.
Influence at Scale
Reilly’s chapter 8 is titled “Good Influence at Scale.” The chapter’s structure is the lesson: four levers, each one applied to an individual, then to a group, then as a catalyst so it keeps working without you.
The Four Levers
| Lever | Individual | Group | Catalyst |
|---|---|---|---|
| Advice | Answering questions, reviewing plans | Office hours, written FAQs, being the person whose opinion a whole org can find | The structures that make advice flow without you |
| Teaching | Pairing and explaining | Tech talks, onboarding docs, guides like this one | A culture where teaching is expected |
| Guardrails | Catching a mistake in review | Linters, templates, platform defaults that make the right thing easy | A team that owns the guardrails |
| Opportunity | Handing someone a project that stretches them | Making sure stretch projects get distributed and not hoarded | Sponsorship as a norm |
Source: The Staff Engineer’s Path, ch. 8, Tanya Reilly.
Reilly’s structure makes the argument on its own. Whatever you do for one person is capped by your calendar. The group and catalyst versions are the job.
The Leadership Frame Under the Levers
Hands-on Architects build their leadership section on Gerald Weinberg’s Becoming a Technical Leader and its MOI model. Motivation: know what drives the people you influence and align it with company goals. Organization: understand the dynamics and build alliances. Ideas: communicate the vision and plant the seeds.
They add psychological safety as a precondition, and warn that blame and threat cultures produce burnout and fear-driven behavior. Their alignment rule: your leadership style has to fit the company’s culture, or good intentions produce frustration.
Source: The Staff Engineer Toolkit, Hands-on Architects.
The Minimum
GitLab’s handbook sets the floor: “begin formally mentoring 1-2 others in their own careers” and “becoming a reviewer mentor.” Two mentees and a reviewing role are the smallest version of Reilly’s advice and teaching levers. Start there.
Source: Staff Engineers, GitLab Handbook.
Being Wrong in Public
Larson’s guide “Learn to never be wrong” is about the shift from winning debates to getting the room to a shared answer. His observation is that complex projects fail more often over personal conflict than technical problems. Three techniques:
- Listen through questions. Ask specific ones before giving your view.
- Define the purpose. “Our aim here is to decide X?”
- Read the room. When people are too far apart, escalate or split into smaller groups rather than forcing consensus.
Source: Learn to never be wrong, Will Larson.
Pick one of the four levers. Write down what you do with it individually. Then write down the group version. If you cannot, that is the gap.
The Code: Your daily unfair advantage in software engineering.
Join 350,000+ software engineers, tech leads, and CTOs who start their morning with The Code.
The Seven Traps
Your problem: one of these seven is you right now, and the ones that bite hardest are the ones that look like doing the job well.
Hands-on Architects list four traps. Alex Ewerlöf lists anti-patterns, two of which apply to the individual. Larson adds one. Seven named failure modes, each with a fix.
| # | The trap | The fix |
|---|---|---|
| 1 | Unknown unknowns. Ambiguous problems are the job, and rushing them produces confident wrong answers. | Gather information before deciding. Seek diverse perspectives. Prototype to test assumptions. Use your network (architects, domain experts, TPMs) to find blind spots. |
| 2 | Overengineering. Elegant solutions nobody needed. | “Good enough now beats perfect later.” Incremental improvement with feedback loops. |
| 3 | Losing touch with coding. Covered in lesson 2.5. | Pair programming, small tasks, reviews, hackathons. |
| 4 | Over-specialization in proprietary tools. Vendor lock-in for your own skills. | Map what you know to the general concept behind it. Explore open-source alternatives. Keep skills transferable. |
| 5 | The ivory tower. You spend your time in leadership meetings and understand the tech through reports from managers and tech leads. | Ewerlöf’s test from lesson 2.5. If you cannot form an informed opinion about a system without asking someone, you have lost contact with it. |
| 6 | Embedded in one team. You break that team’s ownership and undermine its autonomy. The team defers to you instead of deciding. | Scope yourself to the group, per GitLab’s line in lesson 1.2, and hand the team back its decisions. |
| 7 | Needing to be right. You win the technical argument and lose the project to the personal conflict it created. | Larson’s three techniques from lesson 4.2. Listen through questions, define the purpose of the meeting, read the room. |
Traps 1 to 4: Hands-on Architects. Traps 5 and 6: Alex Ewerlöf. Trap 7: Will Larson.
The One About Your Manager
Hands-on Architects add a trap that is not on the list because it is not yours to fix: a manager who measures you by commit count when your work is architecture and cross-team alignment. Their advice is to define success metrics together and review them quarterly.
“If your manager doesn’t support your growth or align with your values, find an environment that does.”
Read the seven. One of them is you right now. Write down which, and the fix.
Staff Engineering With AI Coding Agents
None of the nine sources this guide is built on says a word about AI coding agents. Reilly’s book is from 2022. Larson’s guides are older. GitLab’s page was last updated in March 2026 and still does not mention them. This lesson fills that gap with two staff-plus engineers writing in March 2026, and it reopens lesson 2.5.
The Economics Changed
Paula Muldoon, a staff engineer at Zopa Bank, argues that the standard advice for staff engineers (mentor, strategize, stay out of the code) was built on the old cost of writing code. Her examples: a set of features that took six months to build in January 2025 takes one month in March 2026, and a system analysis that used to need a research spike takes 20 minutes.
Her conclusion is that staff engineers need to get hands-on again in 2026, because the tradeoff judgment the role exists for is worthless without direct experience of the tools.
“There’s no way you can know that unless you have hands-on experience building with these tools.”
She expects the role to recalibrate again around 2027 as the tooling matures. That is the Hands-on Architects side of lesson 2.5, with a date on it.
Influence Becomes Execution
Maxime Najim, a Distinguished Engineer at Target, describes three shifts.
First, discovery compressed. He fed internal documentation to a coding agent to check it against the actual code across more than 20 repositories, and turned a month of discovery into two or three days and a data strategy proposal.
Second, the influence problem from lesson 1.1 has a new answer. Instead of lobbying a team to prioritize a change, a staff engineer can show up with a working implementation. In his words, the conversation moves from “can you prioritize this” to “here’s the solution, does this look right?”
Third, the value shifts to verification: test strategy, guardrails, evaluation harnesses.
“Your value stops being about how fast you can implement something and starts being about whether you trust this.”
What This Does to the Guide
Three lessons change.
- Lesson 2.5’s floor moves up. “Enough code to hold an informed opinion” now includes enough agent-driven work to hold an informed opinion about agents. A staff engineer who has not run a multi-repo change through a coding agent cannot set direction on how their org should use one.
- Lesson 4.2’s guardrails lever gets bigger. Najim’s verification point is Reilly’s guardrails at group scale: the staff engineer builds the evaluation harness the whole org’s agent output runs through.
- Lesson 1.4’s task list gets a new item. GitLab’s 18 initiatives predate agents. The nineteenth is owning the org’s standards for agent-written code: what gets reviewed how, what context files exist, what the cost ceiling is.
Take one cross-team change you have been lobbying for. Build it with an agent. Bring the PR instead of the ticket.
By this point you should have:
- A 90-day plan built from GitLab’s initiative list
- Two people you mentor formally
- The name of the trap you are already in, and its fix
- A position on how much code you write now that agents write most of it
Module 5: Keep Learning
Three sources publish reading lists. This module merges them, removes the overlap, says who recommends what, and turns the result into three calendar entries.