Skip to content

· 17 min read

From senior to principal: the work that happens between teams

What changes at each step of the technical career, from senior to staff, senior staff and principal, why the change is about behavior and not technique, and how it shows up in a payments team organized into a core line, a customer line and platforms.

The question I hear the most

In career conversations with the team, one question comes up more than any other: "what am I missing to become staff?".

It almost always comes from someone very good. A senior person who solves any problem that lands on the team, who delivers with quality, whom others look for when something breaks. And the honest answer is almost never "learn more technology".

For a long time I struggled to explain what it was, then. Until I read a two-part series by Caleb Mellas and Thiago Ghisi, in the Level Up Software Engineering newsletter, that organized what I felt. The first part covers what is expected of a staff engineer. The second, the behaviors that lead there.

Both texts talk much more about behavior than about knowledge. Knowledge is what you know. Behavior is what you do with it, over and over, without anyone asking.

What is staff, after all

Until ten or fifteen years ago, senior was the ceiling for anyone who didn't want to become a manager. To keep growing, a person had to trade code for people management. The dual-track career, with a technical track parallel to management, came about to solve that: keeping people who are technically great without forcing them to manage people.

The first part of the series defines the role well: staff is someone who works beyond a single project or team, across a larger area of the organization. They are part of engineering leadership, manage relationships with other areas and connect technical work to business priorities. What defines the level is not technical depth, but the size and shape of the impact.

I like to look at this from the company's side. At each level, the kind of result the person helps move changes: the delivery of a team, the result of a product line, the goals of a whole area and, at the top, the company's strategy.

The strategic impact of each level on the company STRATEGIC IMPACT ON THE COMPANY SeniorStaffSenior staffPrincipal The team's deliverytiming and quality The line's resultrevenue, cost ora product's experience The area's goalsOKRs and initiativesthat cross the lines The company's strategywhere the business goesand what technologymakes possible
The strategic impact of each level: from a team's delivery to the company's strategy.

One caveat before moving on: titles are not a yardstick. The same "staff" can mean very different things from one company to another. Sites like levels.fyi help compare. That's why, throughout this text, I'd rather talk about what the person does than about the job title.

Blast radius

The first of the three expectations the series describes has a name I really like: blast radius. Anyone who works with infrastructure knows the term. It's how far the damage reaches when something fails. A good part of reliable systems architecture, like the cells and isolation the AWS Well-Architected framework recommends, exists to shrink that radius: if one part goes down, the rest stays up.

I like to use the same image for careers, only the other way around. At each level, the blast radius of your decisions grows. And that works both ways: a good decision by a principal improves the whole area, and a bad one also spreads across the whole area.

The blast radius of each level: team, line, whole area and company Senior Staff Senior staff Principal The company and the domainthe technical direction of payments The whole areacore, customer and platforms together One line, several teamsthe boundaries between teams Your own teamthe team's system and delivery THE HIGHER THE LEVEL, THE WIDER THE REACH OF EACH DECISION, FOR GOOD AND FOR BAD
The blast radius of each level: how far the effect of a decision reaches, good or bad.

In the team I lead, that radius has a very concrete shape. I've told in another article how I organized payments into three parts: the core line, which takes care of the payment itself, with a careful pace and regulatory weight; the customer line, which takes care of how the customer gets to the payment, with a fast pace and a focus on experience; and the platform teams, which support both.

A senior person takes good care of one of the boxes. A staff engineer takes care of the lines between the boxes of an area. A senior staff engineer crosses all three parts. And a principal answers for the technical direction of payments as a whole.

Deep or wide

The blast radius has a shape, and the series describes two. Impact can be deep, when it changes how a whole line works. Or wide, when it creates a foundation that many teams start using.

Two shapes of impact: deep, across a whole line, and wide, across many teams DeepWide changes how a whole line worksa foundation many teams start using PixBank slipBanking e.g. redesigning how settlementworks across the whole core line shared platform e.g. a deploy pipeline thatevery line starts using
The two shapes of a large blast radius: deep in one line, or wide across many teams.

In the design I use, the core line is the natural place for deep impact: redesigning how a settlement works, for example, touches every payment product at once. The platform teams are the natural place for wide impact: a better deploy pipeline, or a standard way to observe services, reaches every line.

In both cases, the criterion the authors use is the same, and I agree: the impact has to show up in the business. Revenue, cost or customer experience. Technically brilliant work that moves none of these three rarely sustains a promotion.

Planning horizons

The second expectation is about time. Each level looks at a different horizon: someone starting out thinks in hours, a senior in weeks, a staff engineer in quarters and a principal in years.

Planning horizons: from hours to years, and the rituals of each HOURSWEEKSQUARTERSYEARS Implementation Senior Staff Principal today's taskexecutes the planshapes the roadmapthe area's vision Day to dayWeeklyMonthlyPlanningOKRsOffsite EACH HORIZON'S RITUALS: WHOEVER ONLY JOINS THOSE ON THE LEFT EXECUTES THE PLAN; WHOEVER SHAPES THOSE ON THE RIGHT HELPS WRITE IT
Planning horizons: the higher the level, the further ahead the influence reaches.

The authors connect this idea to David Allen's horizons of focus, from Getting Things Done, and Tiago Forte's horizons of perspective, from Building a Second Brain. I went to check both while writing, and the image that stuck with me is a staircase: each step looks further ahead. And they show that the company has rituals for each horizon: the day to day, weekly meetings, monthly reviews, planning, OKRs and annual leadership gatherings.

The difference between senior and staff shows up clearly here. The senior executes the plan they received very well. The staff engineer helps write the plan: anticipates a need, champions an item on the year's roadmap, secures room and resources for it.

On my team, an example would be someone in the core line who notices, two quarters ahead, that a regulatory change will require work across all three parts, and brings it to planning before it becomes urgent. Or someone in platform who turns a DevEx pain spread across teams into a goal for the area.

The common mistake, according to them, is living on short, easy tasks that give a feeling of progress and little impact. Researching for this text, I found an article by Will Larson about this, "Work on what matters", in which he calls this kind of work snacking. Snacks are nice, but they don't feed a career, and they still wear you out.

Four levels of autonomy

The third expectation is about autonomy, and it's the one I use most in career conversations. It comes from a text by Randall Koutnik, which I read while preparing this article, "Implementers, Solvers, and Finders", and the authors add a fourth level.

Four levels of autonomy: implementer, solver, finder and driver ImplementerSolverFinderDriver receives the taskand how to do it receives the problemand picks the solution picks which problemis worth solving carries what mattersto the end, adjusting course where the senior usually iswhere staff+ needs to be, moving between the two
Four levels of autonomy. The senior solves well; the staff engineer picks the problem and carries it to the end.
  • Implementer: receives the task and the way to do it.
  • Solver: receives the problem and chooses the solution.
  • Finder: chooses which problem is worth solving, and sometimes says the suggestion they received is not the priority.
  • Driver: carries what matters to the end and adjusts course when the scenario changes.

The senior is usually in the solver role, and is very good at it. The staff engineer needs to act as finder and driver at the same time.

The authors point out three traps, and I've seen all of them. Staying in the solver role forever, waiting for the problem to arrive. Becoming a loose finder, who points out problems and helps solve none. And the opposite: losing touch with implementation. A good staff engineer moves between the four roles as the moment demands.

What I looked up

While writing this article, I wanted to check whether what I felt in practice matched what other people had already written. I went after two books.

The first was Staff Engineer, by Will Larson. He describes four ways of doing the role: the tech lead, who guides the execution of a team or group of teams; the architect, who answers for the technical direction of an area; the solver, who dives into the company's hardest problems; and the right hand, who extends an executive's reach. What helped me was realizing there is no single right way to be staff.

The second was The Staff Engineer's Path, by Tanya Reilly. She grounds the role in three pillars: big-picture thinking, executing large projects and leveling up the people around you. She is also the author of a talk every senior should watch, "Being Glue", about the glue work that keeps teams running and is rarely recognized.

Putting it all together, I see the same pattern: at every level above senior, the work shifts from inside the team to the space between teams.

The first step: from senior to staff

The second part of the series gets down to behavior. For the first step, Mellas and Ghisi point to three: deciding strategically, multiplying others and influencing beyond your own team. And all three happen in the same place.

The boxes have owners; the lines between them are where staff works Customer line Core line Platforms App and channelsDevicesLink AcquiringPixBank slipBanking InfrastructureDevExData The dotted lines contracts, dependenciesand decisions that crossteams: nobody ownsthem naturally. That's where staffshows up.
The boxes have owners. The lines between them don't: that's where staff work happens.

Who owns the contract between the core and the customer line? Who notices that three teams are solving the same problem in three ways? Who sees that a decision that's good for one team pushes cost onto another? The boxes have owners. The lines don't. And that's where I look for staff signals.

Deciding strategically

The senior asks how to solve it well. The staff engineer asks whether this is the right problem to solve now.

Revisiting references for this text, I went back to an idea from Jeff Bezos's 2015 letter to Amazon shareholders that captures this difference well. He splits decisions into two types: two-way doors, which can be undone without great cost, and one-way doors, which can't. The first should be fast and stay close to the team. The second call for care and the participation of those who will be affected.

Two-way and one-way doors: reversible and irreversible decisions Two-way door you can go back without great cost a screen test, an experiment, a flag on for 5% of customers decide fast, close to the team One-way door going back is costly or impossible a public API contract, the data model of a settlement, a regulatory rule decide slowly, with those affected
Two-way and one-way decisions. Part of staff work is knowing which kind each door is.

In my design, the customer line lives on two-way doors: a screen test, an experiment, a feature turned on for part of the customers. In the core line, a lot is a one-way door: the contract of an API other teams consume, the data model of a settlement, a regulatory rule.

A clear sign that someone is ready for staff is knowing which kind each door is. Not treating an experiment as if it were an architecture decision, and not treating a contract change as if it were an experiment. When the door is one-way, the staff engineer records the decision, and here ADRs, the architecture decision records proposed by Michael Nygard, help a lot: the decision, the context and the alternatives are written down for whoever comes next.

Multiplying others

This is the hardest behavior for someone who built their career by being the one who solves things.

Looking through High Output Management, by Andy Grove, I found the idea that best sums this up: a manager's output is the output of the team they influence. The same logic applies to staff. Impact stops being measured by what you deliver and starts being measured by what you unblock.

Where impact comes from at each level: your own work and work multiplied in others SeniorStaffSenior staffPrincipal what I deliver with my own hands what I unblock in others ILLUSTRATIVE: THE PROPORTION CHANGES, TECHNICAL SKILL DOESN'T GO AWAY
As the level rises, less and less impact comes from your own hands and more and more from what you unblock in others.

The Level Up piece quotes an idea from Tanya Reilly that I also found in her book: one of the ways to have impact is to support other people's ideas. Not everything needs to come from you.

An example from my design: a core engineer who documents an API contract well and sits with the customer line until they can consume it on their own has multiplied more than if they had built the integration with their own hands. It was more work that week and saved months.

Influencing beyond the team

When I designed the structure, it became clear to me that the boundary between teams is also the boundary between products. That's why I made a point of bringing product leadership into the design, and not deciding only from a technology standpoint. The same goes for anyone who wants to be staff: you can't influence technical direction without understanding where the product wants to go.

In practice, this is not glamorous. It's explaining a technical risk to someone in product without jargon. It's understanding why customer support is complaining before proposing the solution. It's noticing that two teams expect different ways of working together, one wanting to be served as a service and the other thinking it's a collaboration, and talking until they're aligned.

The second step: from staff to senior staff

If the staff engineer takes care of an area's boundaries, the senior staff engineer starts answering for initiatives that cross all of them. The authors point to three behaviors: leading critical initiatives end to end, developing people across many teams and ensuring operational excellence over time.

Think of a new regulatory requirement that changes the payment journey. It touches the core's rules, changes screens and flows in the customer line and calls for infrastructure and data adjustments in the platforms. No team can deliver it alone. Someone needs to see the whole path, break down the problem, agree on the interface between the parts and follow through to the end. In Team Topologies vocabulary, it's the moment when teams leave service mode and enter collaboration for a set period. Leading that collaboration, and returning it to service mode once the interface is clear, is senior staff work.

Operational excellence is the least visible part. For this part, I went back to the four metrics in Accelerate, by Nicole Forsgren, Jez Humble and Gene Kim: deployment frequency, lead time to production, time to restore and change failure rate. A senior staff engineer doesn't look at them for one team. They look at the whole area and ask why one line ships all the time and the other once a week, and what needs to change in the platform for that.

And developing people is no longer limited to their own team. The senior staff engineer helps develop the next staff engineers, across all three parts of the design.

The third step: from senior staff to principal

At the principal level, the blast radius is the whole domain. The authors talk about owning a domain, driving innovation and mentoring that adapts to any level, including managers and directors.

In payments, owning the domain means answering questions no team asks on its own. How does the team design need to evolve when the business changes? Which technical debt becomes business risk in the next two years? What technology, or what way of working, opens a possibility that doesn't exist today? It's also the level at which the person consciously applies what Conway described: if the organization shapes the software, a principal thinks of the organization as part of the architecture.

Mentoring changes in nature. A principal helps managers make technical decisions, takes part in hiring and level calibration and influences what the company recognizes and rewards. I clearly remember a performance committee I've already written about here: having someone technical at that level in the conversation changes the quality of the decision.

At this point, the person works as close to executive leadership as to engineering. They are the bridge between what technology can do and what the business needs.

What holds people back, at any step

The Level Up piece lists three traps, and I recognize all three from career conversations:

  • Lack of strategic vision. Technically beautiful projects that connect to no priority. They become a distraction, however good they are.
  • Not being able to delegate. Holding on to the hard tasks because "it's faster if I do it". It is, once. By the tenth time, it's a bottleneck.
  • Weak communication with other areas. Not knowing how to negotiate dependencies or explain a technical problem to someone who isn't technical.

None of them is a lack of ability. They are habits of a very good senior, which worked up to that point. I read the book the series recommends on this, by Marshall Goldsmith, and the title already sums up the idea: What Got You Here Won't Get You There.

What this changes for those who lead

Writing this text brought me a responsibility I didn't see so clearly: the team design creates or removes the opportunity for someone to act as staff.

If the boundaries are fuzzy, nobody knows where to act. If a team carries too much, there's only energy left for the work inside the box. If every problem that crosses two teams goes straight up to management, the engineer never gets the chance to solve it.

So part of my job is to open that space. Make clear which problems live between teams, give someone the chance to lead one of them and recognize the glue work that doesn't show up in any commit.

Where to start

For anyone facing one of these steps, the authors suggest three moves, and I agree with them:

  1. Look for role models, not checklists. Look at someone who already works at the level you want and watch how they handle a conflict, a hard decision, a meeting with product. The career ladder says what is expected. A good example shows how.
  2. Tackle the behavior that limits you the most. Instead of piling up new skills, find the habit that holds you back the most today. Ask your manager and your peers.
  3. Understand how it works at your company. Talk to people who were recently promoted. Ask what the day to day is like, which projects counted and who supported them. Each company values different things.

Closing

The step from senior to staff, and every one that comes after, is almost never technical. Technique is the ticket in, and anyone who reached senior has already paid it.

What changes is the address of the work. It moves from inside the team to the lines that connect one team to another, then to the whole area, then to the domain. It was by looking at the team design I lead that I finally understood this: the boxes show where each person works, and the lines show where the next careers happen.

Sources