Roles catalog
Sponsor
A Sponsor is a project/program lead, spanning multiple teams. Yes, this role can be played by a manager but it does not have to be (at least not at Amazon). If you are a Sponsor, you have to make sure decisions are made and that people aren’t stuck in analysis paralysis. This doesn’t mean that you yourself make those decisions (that’s often a Tie-breaker’s role which you may or may not be here). But you have to drive making sure decisions get made, which can mean owning those decisions, escalating to the right people, or whatever it takes to get it done.
A Sponsor is constantly clearing obstacles and getting things moving. It is a time-consuming role. You shouldn’t have time to act as Guide or a Sponsor on more than two projects combined, and you don’t have to be a Sponsor every year. But if a few years go by, and you haven’t been a Sponsor, it might be time to think about where you can step in and play that role. It tends to build new skills because you have to operate in different dimensions to land the right outcomes for the project.
Guide
Guides tend to be domain experts that are deeply involved in the architecture of a project. Guide will often drive the design but they’re not “The Architect.” A Guide often works through others to produce the designs, and themselves produce exemplary artifacts, like design docs or bodies of code. The code produced by a Guide is usually illustrative of a broader pattern or solving a difficult problem that the rest of the team will often run with afterwards. The difference between a Guide and a Sponsor is that the Guide focuses on the technical path for the project, and the Sponsor owns all aspects of project delivery, including product definition and organizational alignment.
Guides influence teams. If you are influencing individuals, you’re likely being a mentor and not a Guide. A Guide is a time-consuming role. You shouldn’t have time to Guide more than two projects, and that drops to one project if you are a Sponsor at the same time.
Catalyst
A Catalyst gets an idea off the ground, and it’s not always their idea. In my experience, the idea might not even come from the Catalyst—it can be something we’ve been talking about doing for years but never really got off the ground. Catalysts will create docs or prototypes and drive discussions with senior decision makers to think through the concept. Catalysts are not just “idea factories.” They take the time to develop the concept, drive buy-in for the idea, and work with the larger leadership team to assign engineers to deliver the project.
A Catalyst is a time-consuming role because of all the work that needs to be done. At Amazon, that involves prototypes, docs and discussions. It is hard to effectively Catalyze more than one or two things at once. It is important to note that Catalysts, like Tie-breakers, are not permanent roles. Once a project is catalyzed (e.g., in engineering with a dedicated team working on the project), a Catalyst moves out of the role. The Catalyst might take on a Guide or Sponsor role on the project, or not. Not every project needs a Catalyst. A Catalyst is a very helpful (arguably critical) role for your most ambitious, complex, and/or ambiguous problems to solve in the organization.
Tie Breaker
A Tie-Breaker makes a decision after a debate. At Amazon, that means deeply understanding the different positions, weighing in with a choice, and then formally closing it out with an email or a doc to the larger group. Not every project needs a Tie-Breaker. But if your project gets stuck in a consensus-seeking mode without making progress on hard decisions, a senior engineer might have to step in as a Tie-Breaker. Tie-Breakers own breaking a log-jam on direction in the team by making a decision. Obviously, a Tie-Breaker has to have great judgment. But, it is incredibly important that the Tie-Breaker listens well and understands all the nuances to the different positions as part of breaking the tie. When a Tie-Breaker drives a choice, they must bring other engineers into their thought process so that all the engineers in the debate understand the “why” behind the choice even if some are disappointed by the direction. A Tie-Breaker must have strong engineering and organizational acumen in this role.
Sometimes an organization will depend on a small set of senior engineers to play the role of Tie-Breaker because they are so good at it. As a successful Tie-Breaker, you want to be careful not to set a tone that every decision, no matter how small, must go through you. You’ll quickly transition from Tie-Breaker to a “decision bottleneck” at that point—and that is not a role any team needs. If a team finds itself frequently seeking out a Tie-Breaker, it could be a sign that the team needs help understanding how to make decisions. That’s a topic for a different time. The Tie-Breaker role is considered a “moment in time” role, versus Sponsor/Guide which are ongoing until you reach a milestone. Once the decision is made and closed out, you’re no longer the Tie-Breaker.
Catcher
A Catcher gets a project back on track, often from a technical perspective. It requires high judgement because a Catcher drives prioritization and formulating a pragmatic plan under tight deadlines. Catchers must quickly do their own detailed analysis to understand the nuances of the problem and come up with the path forward in the right timeframe. As a comparison, a Tie-breaker tends to step in when the pros/cons of the different approaches are well known and the team needs to make a hard decision. Once “caught” (i.e., the project is back on track and moving forward), a project doesn’t need the Catcher anymore.
Sometimes Principal Engineers can do too much catching. Don’t get me wrong, we are all Catchers sometimes—including me. Any fast-paced business needs Catchers in engineering and management. It teaches important skills about leadership in difficult moments and helps the business by landing deliverables. It also teaches you what not to do next time. However, it is better to generalize a Catcher skill set across more engineers and not depend on a small set of Principal Engineers to be Catchers. If a Principal Engineer plays Catcher all the time through a succession of projects, it leaves no time to develop skills in other roles.
Participant
A Participant works on something without one of these explicitly assigned leadership roles. A Participant can be active or passive. Active participants are hands-on, and do things like spend a few days working through a design discussion or picking up a coding task occasionally on a project, etc. Passive participants offer up a few points in a meeting and move on. In general, if you’re going to participate it’s better to do so actively. Time-boxing some passive participation (e.g., office hours for engineers) can be a useful mechanism to stay connected to the team. However, keep in mind that it is easy for your time to get consumed by being a Participant in too many things.
How to Use the Roles Framework
The Roles Framework is an engagement model. It helps Principal Engineers intentionally plan how they work with teams to have the most impact. It is not a job description. So how do you do use this framework? The first thing is to assess what roles you play today. If you are a Principal Engineer, I recommend assigning a color to time blocks in your calendar for a particular role, like blue for Catcher and red for Participant. Look back across four to six weeks of work when you are color coding. Be thorough and honest with what role you ended up playing (versus want to play) in a meeting or work block. It will give you a sense of what roles you tend to fall into. Then, you can review with other Principal Engineers and managers to see if you are providing the most impact to the team in those roles, or if you should make some adjustments.
The framework provides a shared vocabulary between Principal Engineers, other engineers in the organization, and managers. For example, if you are a Principal Engineer and you get pulled into too many things as a Participant, you can share the framework with your teams and say you’d like to work in other engineers as Participants so you can move into a different role like a Guide for a specific project. The framework also helps communicate expectations to talented engineers to step into stretch roles. For example, a high potential engineer can be brought into a Catcher role as a learning experience. (There is nothing quite like playing Catcher to see what to avoid in your next project.) That might also free up your Principal Engineers will have more time for other roles.
Interpreting Signals About Roles
Often, there are signals from the team that will tell you how you need to adjust roles. For example, if you are a Principal Engineer, you might be in a meeting acting like a Participant, but the team keeps asking you to help them make a decision. In that case, what the team needs from you is to be a Tie-Breaker.
If you are an organizational leader, you can analyze what roles your Principal Engineers play across your projects and think about the signal it sends. Are all your Principal Engineers tied up in Catcher roles? If so, is it a moment in time (e.g., just this month) or a common pattern across the year? If your Principal Engineers are always playing Catcher, that is a signal that something is off in how your engineering projects execute. And those recurrent Catchers won’t have time to be Guides on critical projects or a Catalyst on the team’s next big idea.
Getting Started with the Roles Framework
If you are a leader that wants to pilot this engagement model, sit down with your Principal Engineers and do a full inventory of technical projects and/or decisions in the next six to eight months. Then, identify which of these projects need specific roles. Not all projects need all roles at all times. For example, every project doesn’t need a Sponsor, only the complex ones do. Sponsors aren’t always Principal Engineers either. They can be a talented engineer that has a natural talent for one of the roles or a software development manager. Don’t opt for “coverage” and auto-assign all your Principal Engineers to be a Sponsor. If you do that, your Principal Engineers won’t have time to do much else. The evolution of a project also impacts roles. For example, a new idea might need a Catalyst for a while and then move into needing a Guide.