AMAZON

TECHNICAL PROGRAM MANAGER

(TPM)
ROLE GUIDELINE

Guideline Last Updated: January 2020, Version 3.0

Contains Expectations for: TPM Individual Contributors. Manager roles use the Tech Manager Role Guideline.

Guideline Notes: This guideline contains ALT-TEXT in images to support screen readers. Revisions to TPM may also
require revisions to the PM – Program Manager Role Guideline and Product and Program Management Comparison
Guide.

Amazon Confidential 1
 Amazon Technical Program Manager (TPM) Role Guideline
This guideline contains the general expectations for individual contributors in the TPM role. It describes the most
common responsibilities, however given the wide variety of businesses and technologies at Amazon, it cannot capture
all expectations. No two Amazon teams are alike and each is encouraged to develop their own approach to delighting
their customers. This alters the way a TPM is expected to operate and what constitutes success.
Each section has a specific purpose:
 Section 1: “TPM Level Matrix” is a high-level view of how TPM functional expectations map to each level. It is
for quick comparisons of level vs. role expectations in hiring debriefs, performance, and promotion discussions.
 Sections 2-5: “What you do” by each level contains the most detail about TPM job expectations. Each section
contains a graphic to illustrate the scope and influence expectations for that level.
 Sections 2-5 “Moving to…” criteria isolate key skills at the next level that should be demonstrated to be
considered for promotion. This is not a promotion checklist. Every promotion case is unique; the results you
deliver (and how they are delivered) also play a role in promotion evaluations.
This guideline does not repeat expectations documented in previous levels (i.e., the abilities of higher levels inherit
those of lower levels). This means a Principal TPM has all of the abilities described in Levels 4-7.
1. TPM Level Matrix
The purpose of this matrix is to provide a quick view of how TPM functional dimensions change by level. It does not
include Amazon Leadership Principles, as they do not change by level. For more detailed guidance, see sections 2-5.
1.1 TPM Functional Dimensions
 Ambiguity: The degree that a technology project1, program2, and/or product3 requirements are defined. Also
clarifies how much supervision is required vs. when a TPM can deliver independently.
 Scope and Influence: Recommended program size (e.g., team4, multiple teams, organization5, cross-org). Ability
to build consensus, secure commitments, negotiate positive outcomes, drive team alignment, and deliver.
 Advises: Who TPMs collaborate with and influence.
 Execution: Concise view of TPM expectations, including which levels are tactical6and strategic7. Effective end-to-
end program management as evidenced by a solid understanding of business requirements, timeliness, quality,
and delivery of the right technical solution for the customer. Includes how a TPM level mitigates risk, escalates
(vs. handles escalations), and a type of trade-off they may make.
 Communication: All TPM levels are expected to provide clear, concise, accurate, and timely communication
(verbal and written) to the right audiences.
 Impact: TPM impact on the business areas (adoption, metrics, dollars, customer, team, and organization).
 Technical: Clarifies the technical understanding needed at each level to drive the right engineering outcomes.
 Process Improvement: Catalyst for faster business delivery, improves the correctness and accuracy of controls;
simplifies or eliminates unnecessary processes.
 Suggested Experience: Recommendation to meet level expectations. A college degree or formal training is not
required if the candidate has equivalent knowledge gained from experience.

1
Project - a point-in-time endeavour with an end date, undertaken to create a unique product, service, or result.
2
Program - a group of related projects, sub-programs, and/or activities managed in a coordinated and ongoing way. Often used to identify and manage different
goals for a single customer or market over a time horizon of several years.
3
Product is any good or service that Amazon sells to customers or offers internally for use by the company or its employees.
4
Team - group of people who work together to solve a particular problem or provide a customer solution. For role guidance consistency, teams are defined as fewer
than 10 people (e.g., two-pizza team).
5
Organization (Org) - a group of teams that together provide one or more product(s) or business function(s). Orgs vary in size, with small orgs typically led by a Sr.
Manager or Director and large led by a VP.
6
Tactical is when someone takes action(s) to achieve specific goals. Actions can be implemented as one or more specific tasks or projects. Includes setting priorities
and success measurements, making short-term trade-offs and either implementing or engaging with others to deliver.
7
Strategic is a leadership skill. Includes defining a mission, vision, tenets, and long-term priorities. Includes ensuring that stakeholders, leaders, and others are
working toward common goals. Requires judgement and experience to make appropriate short-term vs. long-term trade-offs.
Amazon Confidential 2
 1.2 TPM Level Matrix
Dimension L4: TPM I L5: TPM II L6: TPM III L7: Principal TPM
Ambiguity Works on defined Program/product strategy is Business problem, program strategy, Business and architectural
technology projects. Will defined. Technology solution may and technology product solutions strategy may not be defined.
occasionally need not yet be defined. Delivers may not yet be defined. Delivers May not know what the
guidance. independently, but will seek independently, with limited problem is before starting.
direction. guidance. Drives clarity. Delivers with
complete independence.
Scope and Generally works with Works across teams. Influences Works within a VP org. Influences Works across VP orgs. Broad
Influence one team. Influences roadmap priorities, product system owners and architecture strategic influence.
technology at the feature decisions, and decisions.
component level. engineering process.
Advises Peers, Manager Managers Sr. Managers, Directors VPs
Execution Coordinates the delivery Owns a small program. Manages Owns a large program. Manages the Owns a very large program.
of straightforward8 difficult9 and/or cross-functional lifecycle10 of complex11 cross- Manages significantly
technology technology projects/goals. Work functional technology initiatives. complex13 cross-functional
projects/goals. Work is is tactical. Defines program Work is tactical and strategic. technology initiatives. Work is
tactical. Defines requirements and helps Unblocks teams and increases the strategic. Remediates critical
requirements, facilitates engineering teams meet goals. speed of delivery. Negotiates and/or endemic problems.
progress, identifies Accelerates progress by driving resources and priorities. Learning to Effectively force multiplies.
blockers, and increases timely decisions. Clears blockers, force multiply12. Escalates effectively. Manages escalations (is
the visibility of issues. escalates appropriately. Makes Able to find a path forward in difficult escalated to). Makes trade-
Makes trade-offs: trade-offs: time vs. scope vs. cost.
situations. Makes trade-offs between offs: business opportunity vs.
resources available vs. Begins to mentor. short-term needs vs. long-term resources vs. sustainability.
project priorities. needs. Actively mentors/develops Actively develops the TPM
others. Performs Tech promo community, performs promo
assessments. assessments.
Communication Manages meetings effectively. Puts the right people in the room. Drives detailed business and technical discussions/alignment. Is clear
and concise in verbal and written communication (e.g., functional requirements, technical specifications, design documents,
project/program requirements and roadmap, PR/FAQ, status, narratives, OP1/OP2). Trusted to present decisions to leaders up to 3 tiers
above level. Higher levels require ability to communicate across an increasing diversity of areas (e.g., legal, regulatory, finance, PR,
external industry groups, etc.).
Impact Team goals and project- Multiple team goals and Org goals, and program-related Multiple org goals and
related metrics. program-related metrics. metrics. program-related metrics.
Technical14 Able to dive deep and Understands design approaches Understands risks caused by Able to identify
constructively discuss (within technical domain). Is able technical complexity. Able to drive risks/opportunities in technical
proposed technology to spot risks, ask the right simplification and efficiency in strategies, architecture(s) and
solutions. technical questions to ensure existing engineering and or in engineering organization
appropriate trade-offs are made. architectures to unblock innovation structure(s).
and speed of delivery.
Process Improves team Improves project and process Streamlines and eliminates excess Aligns teams and orgs toward
Improvement efficiency. Optimizes efficiency. Optimizes cross-team process. Creates predictable process simple, coherent approaches.
previously defined processes to improve efficiency paths. Creates/optimizes cross-org
processes. and delivery. structures and mechanisms.
Suggested Meets TPM I Tech Bar. 3+ yrs. TPM experience. 6+ yrs. TPM experience. 10+ yrs. TPM experience.
Experience

8
Straightforward problems/efforts have minimal visible risks or roadblocks. What to accomplish is clear (and does not appear to be complicated), but how to
accomplish that work is not clear.
9
Difficult problems/efforts with visible risks or roadblocks; requiring skill and a considerable amount of work to resolve or deliver results.
10
Lifecycle extends from idea to design, to justification and approval, to build and launch, to the continued innovation of the product or program, to eventual
migration to newer solutions and deprecation of older ones.
11
Complex problems/efforts have visible risks, roadblocks, and constraints (e.g., differing customer behaviours/cultural expectations, data quality issues, business
rules, compliance requirements (e.g., financial, legal, regulatory agencies), technology limitations, extensibility asks (e.g., enable clients to customize without direct
work from an engineering team), resources (e.g., headcount, budget),
12
Force multipliers are individuals who either possess attributes or deliver solutions that dramatically increase (hence, multiplies) the effectiveness of a group, giving
them the ability to accomplish greater things.
13
Significantly Complex problems/efforts have visible and not-yet-visible risks, roadblocks, constraints, and many conflict with each other (i.e., resolution of one issue
creates a conflict with the resolution of another issue; multiplied by the number of issues). Requires significant expertise to see around corners, make the right trade-
offs, and design a solution that is appropriately simple (doesn’t add to the complexity). Due to the stakeholders involved (i.e., those blocking or driving the constraint,
senior leaders) achieving alignment is more challenging and trade-offs usually have long-term impacts.
14
Hiring Managers/Bar Raisers – See FAQ #8 for the technical requirements of each TPM level (page 11 of this guideline).
Amazon Confidential 3
2. TPM I
2.1 Scope and Influence

2.2 What you do…

You are a single-threaded owner responsible for the planning, execution, and delivery of straightforward projects related
to an existing technology program or product. You may be embedded within a single technology team or your work may
focus on a small segment of a larger technology program. Your job is to apply project management best practices to
make the team you work with more efficient.
You know how to apply technology to solve problems (Q. What do we need to build to achieve X?). You take the time to
fully learn the products and systems involved with your projects (i.e., components15 and features16, their functionality,
key dependencies, runtime properties, and maintenance characteristics). You understand a broad range of analytics
techniques and know how (and when) to use them. You work backwards17; starting with customers and stakeholders.
You work to understand their needs/problem(s) and provide this business context to engineers. You define project
requirements and work to clarify the technical implementation by driving design discussions. You help the team and
their customers reach consensus. You negotiate included features (and their priority), distinguishing between important
and urgent. You establish milestones and drive sensible deadlines. You manage project communications and may serve
as the first point of contact for team projects.
You run effective meetings and are able to dive deeply into technical details just as easily as convey a high-level plan.
Your verbal and written style is clear and concise. You are able to transform raw thoughts into clear technical
documentation (e.g., functional requirements, technical specifications, design approach, etc.) and project requirements
(e.g., statement of work, responsibility matrix). You ensure the right information about the state of a project is delivered
to the right audience at the right time (e.g., status reports, metrics reports, etc.). You clearly articulate scope, timeline,
owners, risks, and the steps to mitigate those risks at each stage. You identify roadblocks, drive the resolution of
problems, and either manage their resolution or ensure a clear hand-off to the right owner. You make sure each project
has measures of success (e.g., How do you know your project is on track? How do you know it saves money?  How do you
know the performance is acceptable? How do you know your customers are satisfied?). You participate in the interview
process and help train new members of the team.
2.3 Moving to TPM II…
You will be considered for promotion to TPM II if you consistently demonstrate a combination of the following:
 You work independently with 2+ engineering team(s) to successfully manage difficult, cross-functional projects
(from inception to completion) delivering high quality results (e.g., efficient, compliant, secure, testable,
maintainable, low-defects, etc.).
 You manage a small program. You partner with technical managers to secure resources, scope engineering
15
Component is a building block that does not solve a customer or business problem on its own, but is part of a solution. For engineers this
translates to a piece of technology with a clearly defined interface that is indivisible, has minimal internal dependencies, and deliverable
(somewhat) independently. In role guidance the size of a component and/or the degree of difficulty is differentiated by level (with smaller and
more straightforward implementations assigned to lower levels and larger, more complex component solutions assigned to higher levels).
Component examples include:
 In software, an independently executable portion of code/logical functionality (e.g., storage component, library, workflow action to validate
input, etc.).
 In devices, a power supply, motherboard, or a display; each of which has sub-components (e.g., resistors, transistors, chips).
 A product feature can also be broken down into components (e.g., models, datasets, or other functionality that is not directly offered to a
customer but impacts their experience).
 In a systems-of-systems infrastructure, a single system (also sub-system) that on its own does not satisfy the entire workflow need.
16
Feature is any functionality or cohesive set of functions that has value to a customer.
17
See: https://w.amazon.com/index.php/Working_Backwards
Amazon Confidential 4
 efforts, set project priorities, milestones, and drive delivery to meet deadlines to meet program goals.
 You are proficient at transforming raw thoughts into clear, consistent, accurate technical documentation and/or
direction.
 You competently represent your team’s systems to customers and other teams (technical and non-technical).
 You keep the scope of engineering efforts under control and accelerate progress, or operational efficiencies by
driving crisp and timely decisions, identifying and clearing blockers, and escalating appropriately.
 You improve team processes and metrics; you unblock delivery, accelerate innovation, reduce costs, and/or
improve quality.
 You own project status communication. You consistently impart clear and concise summaries for the projects
you own to your leadership/management team and are effective at answering questions in detail.
 You have good working relationships with engineers, managers, and peers. You recognize discordant views and
take part in constructive dialogue to resolve them.
3. TPM II
3.1 Scope and Influence

3.2 What you do…

You are responsible for managing a small or existing technology program, successfully delivering improvements to a
product and/or to meet program goals. You work independently, seeking guidance as needed. You may be embedded in
a single technology team, partnering with the manager and other engineering teams to deliver difficult, cross-functional
projects or you may work with more teams if program goals require it. You may work directly with external technology
providers, customers, partner teams, or sellers. You have a solid understanding of the design approaches and industry
technologies utilized in your program area. You make connections (to people and/or technologies) and make sure the
right people are part of the conversation. You prevent or mitigate the consequences of poor technology decisions. You
recognize when a proposed design is too complex or risky and to mitigate you arrange additional reviews by senior
engineers and escalate appropriately.
As part of your project and program ownership, you know the larger business picture (i.e., customer experience,
organization goals, opportunities, and/or problems) and you deeply understand the technical requirements of the
solutions being built (i.e., architecture18, dependency impacts, efficiency, performance, availability, operability, etc.). You
also take the time to understand the needs of engineers (who have to build, maintain, and extend features for the life of
the system) to make appropriate trade-offs. You partner effectively with technical managers to secure resources, scope
engineering efforts, set project priorities, milestones, and drive delivery. You help teams determine where to iterate to
make improvements. You determine if success metrics are in place, and if not work to define them. You may be
responsible for writing PR/FAQs, supporting OP1-2 efforts (including organizing/collecting data), and other strategic
program documentation (e.g. Narratives).
To meet timelines and minimize disruption to builder teams, you manage the overall schedule, proactively mitigate risks,
and keep the scope of engineering efforts under control. You own program communication. You accelerate progress by
driving crisp and timely decisions, clearing blockers (e.g., “Path to green”), escalating appropriately. You may apply
process improvement methodologies (e.g., Agile, Lean, Kaizen analyses or other approach). You may oversee the roll-out
process, including test, and deployment to Beta/Prod. You plan for the unexpected, making sure that systems (upstream
and downstream) are not broken by changes related to the efforts you manage. You plan effectively to make sure
projects deliver without wearing out key individuals and system maintainability (and ability to evolve) is not
18
Architecture is how we put components and features together to delight customers or solve a business problem. Architecture design includes
deciding what components to build, refactor, or deprecate. An architecture can range from the internal structure of a single service, application, or
web page to a large number of interdependent technologies and hardware that make up a significant product (e.g., process a credit card, how to
pipeline data for analysis, etc.) Full ownership may span multiple teams and even an organization. This changes the way a role operates to be
successful, as larger product architecture work would require influencing and building consensus with more teams and at higher senior levels.

Amazon Confidential 5
compromised. You may be asked to manage post-launch support plans (e.g., triage, issue/ticket management, COEs),
run retrospectives, and/or hold post-mortems. You look for opportunities to incorporate needed system quality and
operational excellence improvements into project plans. You help recruit and interview for your team. You mentor and
help develop others.
3.3 Moving to TPM III…
You will be considered for promotion to TPM III if you consistently demonstrate a combination of the following:
 You manage large, complex technology initiatives, delivering critical solutions, significant improvements, new
mechanisms, or deprecating systems that are no longer needed. These efforts require you to work with multiple
teams in and/or across organizations.
 You are accountable for the overall strategy of a large program. You successfully manage all stages (from
concept to delivery). Your program meets challenging business goals and/or shows measurable improvements in
efficiency or experience for customers, employees/engineers, or business area.
 You understand the architecture of the systems you work with (e.g., workflows, APIs, runtime characteristics,
design limitations, and maintenance requirements). You influence team technical priorities and business
strategy through data-driven contributions. You are able to make a case for project priorities, resource
allocation to achieve a desired business outcome, resolve an architecture deficiency, or unblock delivery.
 You communicate ideas effectively, verbally and in writing, to a wide range of audiences including Directors and
VPs. You foster a constructive dialogue, harmonize discordant views, and lead the resolution of contentious
issues (build consensus). You partner successfully with customers, stakeholders, and engineering teams.
 Your program management practices set a great example to others. You routinely and efficiently deliver the
right things. You define clear goals and objectives. You drive crisp decisions in your program area about what
projects move forward and in what priority order. You proactively identify risks and bring them to the attention
of your team and stakeholders with plans for mitigation before they become roadblocks.
 You are a simplifier. You judiciously add, refine, and remove procedures. By applying project management best
practices, you increase the productivity and effectiveness of the teams you work with.
 You actively participate in the hiring process as well as mentor others - improving their skills and ability to get
things done.
4. TPM III
4.1 Scope and Influence

4.2 What you do…

You are responsible for managing the lifecycle of a complex cross-functional program with considerable impact. Your
program may focus on a single product in a critical technology area or you may work more broadly, managing larger
initiatives that span organizations or geographies in support of a larger business objective. You may also be responsible
for the delivery of large and complex projects that may or may not be tied to a larger program. You may be assigned to
manage the roadmap for an organization, which may include contributing to OP1/OP2 narratives, and ownership of one
or more organizational goals. As a senior technology program owner, you are accountable for the overall strategy as well
as driving teams inside and outside your organization to deliver. You are able to define the program (mission, vision,
tenets), set objectives, analyze data, drive improvements that are quantified with metrics, and influence resource
allocation. You understand the systems in your product or program space, their limitations, scaling factors, boundary
conditions, and reasons behind architectural decisions (Q. Why did we build X? What business goal does it solve? Do we
need to build something else– if so why?).
To ensure business and technical stakeholder needs are aligned, you drive mindful discussions that lead to crisp
decisions. You provide context (past, current, and future) for business/technology choices and a long-term perspective.
You partner with customers and engineering teams to determine which projects move forward and in what priority
order. You use your technical judgment to question proposals and test assumptions (Q. Do we need to build this at all?).
Amazon Confidential 6
You enlist Senior/Principal Engineer to ensure architecture(s) scale (or will scale) to match the “think big” business case.
You make smart trade-offs (e.g., time vs. effort vs. features). You create plans that have clear, measurable success
criteria. You clearly communicate progress and outcomes.
You oversee the gap between teams, processes, and system architectures. You help teams/your organization reduce
exposure to classic failure modes (e.g., requirements not sufficiently understood/documented, ineffective cross-team
collaboration, long-term impact(s) from of the use of third-party technologies, APIs not protected/hardened, insufficient
testing/gaps in QA). You solve ambiguous problems and proactively identify and mitigate risks (before they become
roadblocks). You demonstrate good judgment in how and when to escalate (without damaging relationships). You are
data-driven. You regularly review metrics and proactively seek out new and improved data/mechanisms for visibility.
You ensure your program stays aligned with organizational objectives.
You understand technical program management and engineering best practices. You may be asked to use your
knowledge to assess development processes, test plans, and operations/maintenance requirements. You work with
teams to improve concurrent project delivery. You streamline and/or eliminate excess process. You influence teams to
decouple from dependencies and eliminate architecture problems that stifle innovation or cause user dissatisfaction,
development collisions, and/or outages. You are an excellent communicator. You write effective narratives (Amazon 6-
pager) and present them effectively to Directors and VPs. You routinely deliver the right things with limited guidance.
When confronted with discordant views, you are able to find the best way forward and influence others to follow that
path (build consensus). You actively recruit and develop others by mentoring in your organization and/or at your
location. You provide constructive feedback for engineer, manager, and other peers. You also provide Tech promotion
assessments for TPMs moving to level 6.
4.3 Moving to Principal TPM…
You will be considered for promotion to Principal TPM if you consistently demonstrate a combination of the following:
 You manage important technology programs with broad cross-organizational and/or cross-business impact. You
define requirements, negotiate priorities, and deliver the right solutions and mechanisms.
 You resolve significantly complex problems and provide a long-term beneficial impact on a product, company
technology, or on engineering overall. The problems you solve are significantly complex, but your solutions are
as simple as possible.
 Your contributions are noteworthy and recognized both inside and outside of your organization (e.g., improves
engineer efficiency, simplifies/improves architectural quality, reduces bottlenecks, creates or enables Amazon to
maintain a competitive advantage). You only advocate for the creation of new software when it is necessary.
 You operate with autonomy, showing high judgment in decisions that have technical and business implications.
 You identify and tackle intrinsically hard problems. (e.g., highly complex, ambiguous, extremely complicated,
with little to no existing structure, have significant business or security risk or potential for significant impact).
 You are able to represent, verbally and in writing, complex decisions, tough trade-offs, and potential solutions
clearly to leaders up to 3 levels above.
 You are adept at building consensus. You align teams toward coherent technology strategies. You bring clarity to
complexity, probe assumptions, illuminate pitfalls, and foster shared understanding.
 You are flexible, adapting your approach to meet the needs of project teams.
 You actively recruit for Amazon as well as participate in the hiring/interview process.
 You play a significant role in the career development of others, actively mentoring others, and educating the
larger community on best practices. You provide constructive Tech promotion assessments for TPMs moving to
level 6.
 You’re an exemplary practitioner of technical project and program management – you model best practices in
communications (status reports, program documents, PR/FAQs, stakeholder management), planning and
scheduling, identifying critical path, managing within budget and resource constraints, managing risk, and
escalating appropriately.

Amazon Confidential 7
5. Principal TPM
5.1 Scope and Influence

5.2 What you do…

You are responsible for defining and delivering important programs with broad cross-organizational, cross-business, or
significant technology impact. Your work focuses on very large engineering efforts that solve significantly complex or
endemic problems. You are trusted to operate with complete independence and are often assigned to focus on areas
where the business and/or architectural strategy has not yet been defined. You may own the technology roadmap for
broader set of systems or manage a portfolio of programs. You may be asked to directly lead the design of the solution,
implementation and delivery of a highly complicated cross-functional project in an ambiguous or new technology area.
You consistently bring strong, data-driven, and strategic technical judgment to decisions. You have deep knowledge of
the core system technologies and/or broad understanding of company systems/technologies (relevant to your
program/product domain). You apply this knowledge to invent, evolve, improve, and simplify technologies.
You are flexible, adapting your approach to meet the needs of the program or product for the customer. You identify,
prioritize, and tackle intrinsically hard problems, acquiring expertise as needed. You assess risk, drive clarity, and foster
shared understanding by asking intelligent questions about proposed solutions. You create the correct sense of urgency
for delivery. You proactively drive business and system-level reviews, aligning teams toward coherent technology
strategies and effective engineering processes. You identify gaps/opportunities in or between countries, architectures,
and organizations (e.g., services, workflows, tooling). You decompose complex problems into straightforward solutions
and work to minimize areas where we apply the same TPM or engineering effort year-over-year. You may drive
architecture and/or organization changes to enable teams to work independently and/or achieve a significant efficiency
improvement. You create, optimize, and drive adoption of the critical mechanisms necessary to ensure your program
and/or product will be successful in the long-term (with and without your involvement).
You effectively partner with all levels of leadership. You are adept at building consensus. You are able to represent,
verbally and in writing, complex decisions, tough trade-offs, and potential solutions clearly to leaders up to 3 levels
above to help them understand the decisions they have to make and what options they have. You influence organization
priorities, system owners, business, and technology direction. You manage cross-functional communication to ensure all
stakeholders are informed and needs aligned. You recognize when current programs are susceptible to prior technology
failure patterns and actively steer teams to avoid repeating these failures. You know when a design or solution requires
additional technical guidance (e.g., from senior engineers or subject matter experts). You show excellent judgment in
driving executive-level escalations. You deliver solutions that meet Amazon high standards for customer satisfaction,
efficiency, stability, extensibility, simplicity, and operational excellence.
You amplify your impact by educating the TPM and engineering communities (e.g., in your organization, at your location,
or more broadly) on program management best practices. You participate, sharing knowledge and collaborating with
other TPMs, specifically attending and/or presenting at internal conferences and TPM community events. You help
managers guide the career growth of their team members by mentoring, performing Principal TPM promotion
assessments, and participating in talent reviews.
5.3 Moving to Senior Principal – Tech
Principal TPMs promote into Senior Principal – Tech.

Amazon Confidential 8
TPM CLARIFICATION FAQ
1. What if we find a section of the TPM guideline confusing?
Email tpm-level-clarification@amazon.com. We consider the TPM Role Guideline a “living document” and will update it
periodically based on feedback to improve its usefulness.
2. Is the TPM guideline to be used for hiring?
Yes. Amazon Role Guidelines convey company-wide role and level expectations. To ensure we are consistent across all
organizations and locations, this guideline should be used in all aspects of assessing performance or level. This includes
hiring, performance reviews, next-level goal setting, and promotions.
3. It looks like TPMs have a broader expectation of scope than SDEs and SDMs, is this correct?
Yes. The SDE and TPM roles differ in scope. SDEs, as a builder role, generally focus on team-owned software with the
expectation that as they move towards the Principal level that their focus will expand to significant portions of an
organization’s architecture (owned by multiple teams). While SDEs do need to connect with the customers of their
software and interface with other teams, it is not a major portion of their role.
TPMs are expected to operate in the areas between teams and architectures. Their job is to drive cross-team delivery to
meet a goal. As TPM levels increase, their programs (and projects) are expected to expand in scope and impact to
benefit larger business initiatives and/or portions of the company.
4. Why are there no “Depth vs. Breadth” examples?
TPM focus is generally determined by the scope of their product and/or program. While there are some examples of
TPMs at each end of the breadth and depth spectrum, the reality is whether a TPM is broadly applied or narrowly
applied, depends on organization need. Given this, managers may require additional subject matter expertise when
hiring TPMs at any level. However there is a solid expectation that all TPMs at higher levels can work across
organizations effectively and manage complex cross-functional projects. So when hiring (or promoting) to the TPM III
and Principal TPM levels, it is important to be sure the TPM is capable of fulfilling those level requirements.
5. What is the difference between a PM and a TPM?
Also, see the Product and Program Manager Comparison Guide.
6. Some TPM expectations overlap with Product Manager - Technical (PMT). How do we decide which role to hire?
There is an inherent overlap between the responsibilities of a TPM, PM-T, and PM and who does what is really up to the
hiring manager and the needs of the role. For details on how the roles differ and are the same, see the Product and
Program Manager Comparison Guideline.
7. Some TPM expectations overlap with Software Managers. How can both be responsible for the same tasks?
SDMs are responsible for the employees (SDEs, other engineers) that report to them, the software owned by the team,
roadmap priorities, project definition, development process, and the quality of solutions delivered, their impact on
customers/business, and the day-to-day operations of maintaining that software. If they do not have a TPM (or a PM-T),
then any product, project or program-related responsibilities fall directly to them. At Level 6 (e.g., SDM III) they may
decide to hire a TPM (or PM-T) as a single-threaded owner on a strategically important program or initiative. SDM
guidance is to refer to this guideline to clarify which types of responsibilities fall into TPM expectations.
8. What are the technical expectations of a TPM? I thought they had to meet the SDE I bar, but I see nothing about
coding skills?
The TPM Tech bar is not about coding. It’s about their ability to understand and contribute to the technology strategy
and design for a program or product. A TPM needs to have enough knowledge/ experience with the design approaches
and industry technologies within the expected product/program area to be able to ask the right technical questions and
drive the right technical solution(s). They should be able to contribute to technical discussions and decisions – i.e., able
to understand and evaluate end-to-end system designs for strengths and weaknesses (scalability, latency, security,
performance, data integrity, etc.) as well as balance technical requirements against business requirements. They need
sufficient technical credibility to be respected by the engineering teams they will work with.
TPMs also need enough experience to foresee the consequences of poor technology decisions to determine if the right
Amazon Confidential 9
trade-offs are being made. They need to be able to recognize when the technical information they have been given is
potentially inaccurate, inflated, or not sufficiently understood. This is not as much about possessing specific skills as it is
about having sufficient technical judgment to know when a design is complex or risky enough that it requires further
evaluation from a Principal Engineer.
For Bar Raisers and Hiring Managers, here are the specific TPM technical expectations by level:
When looking at a level, be sure to include all technical expectations, up to and including that level. For more on this
topic see: https://broadcast.amazon.com/videos/22223-Bar-Raiser-Learning-Series-TPM-Hiring
TPM I:
 Has an engineering background (e.g., CS, CE, or EE degree or equivalent experience).
 Understands the industry technologies in program or product domain (e.g., hardware, network, software,
systems) and how to apply those technologies to solve problems (Q. What do we need to build to achieve X?).
 Able to dive deeply into technical details (e.g., key dependencies, design choices, operability, etc.) and drive
constructive discussions with engineers.
 Can transform raw thoughts into clear technical documentation and/or direction.
 Knows how to collect data (e.g., from log files, data stores, SQL, potentially via API, etc.)
 Understands a broad range of techniques for conducting technical analysis and know when to use them.
TPM II:
 Understands the system architecture within program domain. Knows how to make sure dependencies are not
broken by development changes and that program systems are not broken by upstream changes.
 Able to consider the larger picture (e.g., efficiency, availability, operability, scalability, business goals, customer
experience, etc.) and balance it against the needs of engineering teams who have to build, maintain and extend
features for the life of the technology. Incorporates these requirements into project plans.
 Sees patterns and discovers solutions; makes connections to improve project/process efficiency. Knows what
solutions exist elsewhere and how they can be connected.
 Can convey detailed technical knowledge (verbally, in writing, and via diagram) to engineering team(s) (Q. Why
did we build X? What business goal does it solve?).
 Knows how to assess engineering practices for testing, triage and maintenance and work with manager(s) to
establish the right methods for effective project delivery.
TPM III:
 Understands system limitations, scaling factors, boundary conditions, and/or the reasons for architectural
decisions (Q. Why did we build X in this way? What business assumptions were made? What technical
assumptions were made? Do we need to build something else– if so why?).
 Knows how to decouple dependencies (e.g., SOA best practices), prevents duplicate efforts and
collisions/outages,
 Has technical judgment; uses it to inform technology and business trade-offs.
 Capable of holding an engineering team to a high standard for both solutions and engineering practices (similar
to a senior engineer or technical manager).
 Capable of reviewing design decisions (L6 Data Engineer, DBE, FEE, HDE, NDE, SDE, or SysDE design bar).
 Knows how to make sure engineering teams are focused on the right solutions for the customer and
organization. Understands the consequences of short-term solutions and impact on long-term architecture
 Able to simplify concurrent project delivery, including development and testing processes for projects that cross
team boundaries.
Principal TPM
 Has deep knowledge of core system technology in program domain and/or broad understanding of company
systems/technologies. Applies this technical knowledge to invent, evolve, improve, simplify, etc.
 Knows how to drive large-scale engineering efforts that solve significantly complex or endemic problems.
 Able to identify gaps/opportunities within or between countries, architectures, and organizations (e.g., services,
workflows, tooling) to satisfy the needs of program/product customers
 Understands how to decompose complex processes into straight-forward solutions, often inventing new ones.
 Consistently brings strong, data-driven business and technical judgment to decisions.
Amazon Confidential 10
  Recognizes when designs/solutions require additional technical guidance (e.g., from senior engineers or subject
matter experts).
 Able to make the case for technology programs. Influences teams to dedicate resources, and leads the effort (or
finds appropriate owner).
 Knows how to reduce coupling between teams. Looks at where we apply the same TPM or engineering effort
year-over-year to determine what requires us to exert that effort multiple times. Can drive architecture or
organization changes that enable engineering teams to work independently and/or achieve a significant
efficiency improvement.

9. Can you provide specific project examples for each level?

No. Amazon Role Guidelines describe company-wide expectations. Amazon has a huge variety of businesses, customer
needs, technology offerings, and organization types. It is expected that TPMs and their management teams understand
their space and how to map the generalized level guidelines to appropriate goals in their team/organization.
Another reason that we did not include specific examples is to avoid anchor 19 bias. By providing a reference project list
for each level, we risk teams overly indexing on the listed types of projects. They may attempt to pattern match rather
than applying more critical thought on whether an employee is meeting the criteria to be considered for promotion. We
avoid citing artifacts that can be used as inappropriate barriers. (“The project described in this promo doc is similar to
project foo on the list of projects that got people promoted, but this particular project is missing N things that foo had,
therefore, I’m not inclined to promote.”)

19
To understand further, read: https://en.wikipedia.org/wiki/Anchoring_(cognitive_bias)

Amazon Confidential 11