Purpose
If you are a Principal or Senior Staff Engineer, your most important resource is not your technical depth. It is your attention. Where you spend it, for how long, and in what mode — these decisions compound across every team you touch. Get them right and you multiply your impact. Get them wrong and you become a bottleneck, a permanent Catcher, or a well-intentioned presence who never quite transfers what they know.
Two frameworks have helped me think about this precisely.
- The first is the PE Roles framework, developed by Mai Lan Tomsen Bukovec at Amazon S3.
- The second is a concentric circle engagement model I encountered through my mentor, Dhan, which developed independently but addresses related territory.
Neither framework is sufficient on its own. Together, they answer two questions that most role frameworks address separately: what mode of engagement does a situation require? and how do you know when to change it?
This post walks through both frameworks, maps their relationship, and then focuses on what neither fully addresses: the mechanics of intentional transition — how you move from the center of the circle outward, what you install before you leave, and why the conversations you have with your manager about capacity are not soft skills but engineering decisions.
Two Frameworks, One Problem
The PE Roles Framework
The PE Roles framework, developed in 2016 for Amazon S3 and later refined and shared more broadly, starts from a practical problem: at the scale of a complex service like S3, there are more hard technical decisions to make than any single Principal Engineer can cover. You need a model that lets you leverage broader senior engineering talent, helps PEs focus on the highest-impact work, and gives the organization a shared vocabulary for how technical leadership actually operates.
The framework defines six roles:
- Sponsor — The project or program lead across multiple teams. A Sponsor’s job is not necessarily to make every decision, but to ensure decisions get made. That means driving the forums where debate happens, closing the loop, and escalating when something goes wrong. This is a high-bandwidth role. As a mental model: you should not be actively Sponsoring more than two projects at once, and that number drops to one if you are simultaneously Guiding something else.
- Guide — Deeply involved in the architecture of a project, but not “The Architect.” A Guide works through others to produce designs, and produces exemplary artifacts — design docs, bodies of code — that set a pattern the team can carry forward. A Guide influences teams, not just individuals. If you find yourself primarily in 1:1s instead of influencing group decisions, you have drifted from Guide to mentor. Like Sponsoring, Guiding more than two projects simultaneously is a sign something is wrong with how you are allocating your attention.
- Catalyst — Takes an idea that is “kicking around” the organization and turns it into a resourced program. Catalysts write the docs and prototypes that drive buy-in with senior decision makers. Crucially, this is a time-bounded role: once a project is resourced and has a team, the Catalyst moves on. They may take on a Guide or Sponsor role on the same project, but that is a separate decision. You cannot effectively Catalyze more than one or two things at once.
- Tie-Breaker — Makes a decision after a debate and formally closes it with a doc or email to the group. This is a “moment in time” role. A team stuck in consensus-seeking mode needs a Tie-Breaker; once the decision is made and communicated, the role ends. The risk here is a Tie-Breaker who starts resolving every decision regardless of size — at that point they have transitioned from Tie-Breaker to bottleneck.
- Catcher — Gets a project back on track, typically from a technical perspective, under tight deadlines. A Catcher does their own rapid diagnosis, formulates a pragmatic path forward, and drives execution until the project is stable. Like the Tie-Breaker, this role has a natural endpoint: once caught, the project no longer needs the Catcher. The anti-pattern is a succession of Catcher engagements with no time for anything else.
- Participant — Works on something without an explicitly assigned leadership role. Active participation (oncall, picking up a coding task, contributing substantively to design discussions) is valuable. Passive participation (a few points in a meeting, then moving on) should be time-boxed deliberately. The risk is becoming a Participant in too many things — it will consume your daylight hours with no leverage.
The Concentric Circle Model
The concentric circle model organizes similar territory with a different emphasis. Where the PE Roles framework names what you are doing, the concentric circle model emphasizes how deep your engagement is and, critically, what the expected direction of travel looks like.
┌──────────────────────────────────────────┐
│ Participant │
│ ┌────────────────────────────────┐ │
│ │ Active Consultant │ │
│ │ ┌────────────────────────┐ │ │
│ │ │ Supervisor │ │ │
│ │ │ ┌──────────────────┐ │ │ │
│ │ │ │ Owner │ │ │ │
│ │ │ └──────────────────┘ │ │ │
│ │ └────────────────────────┘ │ │
│ └────────────────────────────────┘ │
└──────────────────────────────────────────┘
Starting point: center (Owner / Sponsor)
Direction of travel over time: outward
Velocity: set by team readiness, not by PE comfort
- At the center is the Owner: single-team scope, deep day-to-day involvement, personally driving the most technically complex and ambiguous work.
- Moving outward, the Supervisor maintains technical accountability but operates through mechanisms — tracking, guiding, reviewing — rather than direct execution.
- The Active Consultant engages through the same channels as the broader engineering leadership, attending quarterly reviews and design sessions, but is not monitoring day-to-day progress.
- The outermost ring is passive participation: available when called, but not actively tracking.
The critical design principle of this model is that the center is not the destination. It is the starting condition. A PE entering a high-touch engagement at the Owner level is not choosing a permanent operating mode — they are beginning a time-bounded intervention whose success is measured by how cleanly they can move outward without the project degrading.
Where They Fit Together
The two frameworks are complementary, not competing. The PE Roles framework gives you the vocabulary for what you are doing in a given engagement: Sponsoring, Guiding, Catalyzing, Catching. The concentric circle model gives you the spatial metaphor for how intensively you are engaged and the direction you should be moving.
A Catalyst/Sponsor at the start of a complex initiative is operating near the center — high-touch, high-bandwidth. As the team develops its vocabulary and senior engineers internalize the direction, that same Sponsor should be moving outward to a Guide, converting daily involvement into a Supervisory mode and eventually into consultation as a Tie Breaker. A Guide who never exits the center has not guided anyone — they have created a dependency. Dependending on the audit mechanisms installed, you may be required to go back in. A special role which allows you to operate at border but not go back to the center is a Catcher.
PE Roles framework → What role am I playing?
Concentric model → How intensively, and where am I headed?
Together → Am I in the right mode, and am I moving in
the right direction at the right pace?
The failure mode that neither framework addresses well in isolation is this: engineers who understand their current role clearly but have no explicit plan for how or when to change it. They are accurate about what they are doing. They are not deliberate and intentional about when they should stop.
The Naive Mental Model: Roles as Static Descriptions
The most common way engineers engage with frameworks like these is as inventory tools. You examine your calendar, assign time blocks to different roles, and figure out where your attention is actually going. That diagnostic is valuable. It tells you where you are.
What it does not tell you is where you should be in three months, or what you need to put in place now to get there. This is the naive version of role thinking: roles as stable descriptions of current engagement, rather than as temporary states in a deliberate trajectory.
Engineers operating with this mental model do good work within their current mode. But they do not build the conditions that let them move. They stay at the center of the circle — or in the Sponsor/Guide mode — long after the team no longer needs them there.
The consequence is not just personal. A Principal Engineer who remains in Owner or Sponsor mode past the point of necessity is, by definition, preventing the development of the senior engineers who could be taking that space. The team does not build vocabulary. It does not build the judgment to argue tenets independently. It becomes better at deferring to the Principal, which looks like alignment but is actually stagnation.
The Better Mental Model: Roles Are Phases, Not Positions
The concentric circle model makes the necessary reframe visible in a way a flat list of role names does not. When you visualize engagement as rings, the implicit direction becomes clear: the goal is to move outward. High-touch engagement at the center is appropriate for a bounded period — long enough to establish vocabulary, build mental models in the team, and identify the senior engineers who will carry the work forward. Then you move out, deliberately.
The center is not the goal. It is the starting condition. And the measure of success is not how well you performed at the center — it is how quickly and cleanly you were able to move out, without the project degrading.
This reframe changes what “doing well” looks like for a senior engineer. In the naive model, doing well means executing your current role effectively. In this model, doing well means executing your current role while simultaneously building the conditions that make your role unnecessary.
Capacity Is Not a Soft Constraint
Before discussing how transitions work, it is worth being direct about something that role frameworks often leave implicit: the number of high-touch engagements a Principal Engineer can hold simultaneously is small. Not small as a matter of preference. Small as a matter of arithmetic.
The PE Roles framework is explicit about this. You should not be Sponsoring or Guiding more than two projects at any one time — and that ceiling drops further if you are doing both simultaneously. The reason is not that Sponsoring and Guiding are particularly exhausting. It is that doing them well requires sustained, focused attention. The moment you spread that attention across three or four engagements, you have converted every one of them from Guide to Participant, whether or not your title on the project has changed.
This is where a specific kind of conversational discipline becomes necessary.
The default behavior for senior engineers in fast-moving organizations is to accumulate. A new initiative spins up and someone says your name. A team gets stuck and leadership routes the escalation to you. A promising engineer asks you to review their design. Each individual ask is reasonable. The aggregate is not.
What works — and this is less intuitive than it sounds — is treating capacity as a zero-sum constraint that you make visible to your manager explicitly and consistently. Not as a complaint. Not as a limit you are imposing on the organization. As a prioritization question that only they can answer.
The mechanism is simple: every time something new is proposed, you name what you are currently carrying and ask what should move. “I’m actively Guiding Project A and Sponsoring Project B. I can take this on, but one of those needs to go. Which one matters less right now?”
That framing does two things. It prevents accumulation from happening invisibly, which is how most overcommitment happens. And it converts the conversation from a refusal into a trade-off that the manager is participating in, which is where they should be. Eisenhowever Matrix is an effective tool here.
This is not about protecting your time. It is about maintaining the quality of your engagement on the things that actually matter. A Principal Engineer nominally attached to five projects and actively driving none of them is not adding five units of value. They are adding close to zero — and consuming a disproportionate amount of organizational attention in the process.
The corollary is equally important and contentious : when something small comes in — a one-off consultation, an ad-hoc review, a request to weigh in on a decision that “should only take an hour” — the default answer can often be no or not yet, without a full prioritization conversation. If nobody in the team can tell you exactly what needs to be built or what your role would be, the right response is to wait until there is clarity, not to spend time investigating a vacuum. The signal to engage is a well-formed question, not an open-ended pull on your attention.
Why Engineers Don’t Move Outward
There is a failure mode worth naming directly because it feels virtuous from the inside: the Principal Engineer who stays at the center because they care about the project.
They stay because the stakes are high. They stay because they know the edge cases better than anyone. They stay because transitioning away feels like abandoning something incomplete. And in some cases, they stay because the team genuinely has not reached the point where they could hold the work without that support.
But here is the thing: if a team cannot hold the work after months of close engagement from a Principal Engineer, that is not an argument for staying longer. It is a signal that something went wrong in how the engagement was structured. The question to ask is not “am I still needed?” — that question will always return an affirmative answer if you have not built for your own departure. The question is: “what would have to be true for this team to operate without me at the center, and what am I doing today to make that true?”
This is a systems design problem. You are designing the conditions under which you become less necessary. That requires being deliberate about what you are installing in the team — not just what you are delivering to the project.
What to Install Before You Move
If the goal is to move outward without the project degrading, then what you do during the high-touch phase becomes a design problem with specific, verifiable outputs.
- The most important thing to install is not a process. It is a vocabulary. Specifically: the vocabulary for arguing about the right things. The tenets, mental models, and failure-mode awareness that let a team evaluate trade-offs without needing a Principal Engineer in the room. When that vocabulary is working, you see specific signals. Engineers argue with each other using the right frame, not just the most convenient one. Code reviews surface architectural concerns, not just style issues. Debates about approach reference the team’s tenets rather than individual preferences. Escalations to you become smaller in number and sharper in quality — they are about genuine edge cases, not uncertainty about basic direction. When those signals are absent, the vocabulary has not landed yet. Moving out at that point does not scale — it creates an accountability vacuum that someone else fills, usually in a way that undoes what you built at the center.
- The next thing to install is explicit accountability ownership. You need to identify — not implicitly, but explicitly — the two or three senior engineers who will hold the technical direction after you move. Once identified, you start routing decisions through them, not around them. You attend reviews to observe, not to answer. You let the escalation path go to them first, and come to you only when they hit a genuine limit. That practice — routing through rather than around — is what makes the transition real rather than nominal.
- The last thing is to make the transition visible to your manager before it happens. A Principal Engineer who moves from Owner to Supervisor without announcing it is just becoming less available. That is not scaling; that is withdrawal. The move only works if the manager understands what is changing, why, and what the senior engineers taking over accountability are expected to do with it. That conversation is not optional. It is part of the engineering work.
Setting Expectations Before You Start
The cleanest version of this — and the version that avoids the most confusion — is to set the trajectory at the start of the engagement, not partway through.
When you take on a high-touch role, make the expected arc explicit. Something like: “I’m going to be deeply involved for the next eight to twelve weeks. In that time, I need to establish the core architecture direction, build the vocabulary in the team for evaluating trade-offs, and identify who will own this technically after I step back. After that, I’ll move into a Supervisory mode — design reviews, key decision points, but not day-to-day. I’d like to agree on who those senior engineers are before we start.”
That framing does several things at once. It signals to the team that deep involvement is time-bounded, so they do not mistake presence for permanence. It identifies the accountability transfer as a goal of the engagement, not an afterthought. And it gives the manager a clear criterion for evaluating whether the engagement is working — not just whether the project is moving, but whether the team is developing the capacity to move without you at the center.
The first impression you set in a new organization or on a new team matters more than most engineers expect, and it is harder to reset than it looks. If you enter a new role and signal that you will take on anything that comes your way, the organization will calibrate to that. The workload will grow to fill the available space, and the expectation that you will absorb new asks indefinitely will harden quickly. Setting the expectation that your engagement is structured and bounded from the start is not a limit you are placing on the organization. It is an accurate description of how high-quality Principal Engineering actually works.
The Catcher Problem
One of the clearest diagnostics the role framework provides is around the Catcher role, and it is worth dwelling on because the failure mode is both common and self-reinforcing.
Catching is important. Every organization running complex systems needs engineers who can step into a project that has gone sideways, rapidly build a diagnosis from scratch, and drive a pragmatic path forward under pressure. It teaches real skills and it keeps ambitious initiatives from dying quietly.
But catching is not owning, and a Principal Engineer who is always catching never finds time to build the conditions that prevent the next catch from being necessary. They are managing entropy, not reducing it. The more an organization depends on a specific PE to catch, the less pressure there is to build the engineering practices that don’t require it. The system feeds on its own demand.
The healthier pattern treats catching as a role that transfers, like any other. When a Principal steps into a Catcher role, they are simultaneously identifying the senior engineers who can develop that capacity. The catch is a training scenario, not just a rescue operation. When the project is stable, the lessons from the catch get deliberately propagated — so the team builds the ability to avoid or self-recover from similar situations going forward.
If you are a leader mapping PE engagement across your portfolio and you find that most of your PEs are in sustained Catcher mode, that is not a sign of strong engagement. It is a sign that something is wrong upstream — in how projects are scoped, how technical decisions are made, or how senior the engineering talent below the PE level actually is.
The Organizational Read
Mapping what roles your PEs are playing across projects gives you signal that pure output metrics don’t. The question to ask for each PE is not just “what are they doing?” It is “what is the trajectory?” Are they positioned to move outward in the next quarter? Do the senior engineers beneath them have the mental models and accountability structure to hold the work when that happens?
If most PEs are at the center for extended periods — in Owner, Catcher, or heavy Sponsor modes — without a visible plan to move out, that is a staffing and structure problem as much as it is an individual one. PEs who cannot move outward are usually being held at the center by one of two forces: the team has not developed the capacity to hold the work, or the organization has not created the conditions for the transition to happen cleanly. Both are worth diagnosing.
The goal of the engagement model, at the organizational level, is not to maximize PE presence. It is to maximize PE leverage — which means getting the most impact per unit of focused PE attention. That happens when PEs are moving at the right velocity through roles, not when they are embedded in the same high-touch mode indefin
If There’s One Takeaway
The PE Roles framework and the concentric circle model together answer the two questions that matter for senior technical leaders: what mode of engagement does this situation require, and when should it change?
The vocabulary from the PE Roles framework — Sponsor, Guide, Catalyst, Tie-Breaker, Catcher, Participant — is precise and useful. But vocabulary alone is not enough. The spatial logic of the concentric model adds the missing piece: direction. The center is not where you aim to stay. It is where you begin a well-designed intervention, and the design of that intervention includes a plan for your own exit.
Moving outward is the job. Everything at the center is preparation for that move.