/ Project Handbook

Pair TAM Relationship Best Practices

Pairing TAMs on launch projects has become our standard operating procedure—it benefits the whole team and our partners. It enables us to work more efficiently and interdependently, without siloing projects to one person. This document outlines the baseline expectations for primary and secondary TAMs on a project. The Pair TAM Best Practices / Example Approaches section provides tips from successful TAM pairings that you and your pair can adapt for future projects.

Baseline expectations

Primary TAM

  • Is the primary “driver” and DRI for the project.
  • Takes the lead on defining the pair TAM relationship at the start of the project or whenever pairing begins, if mid-project.
  • Directs secondary TAM on tasks that they can help with. If there are no day-to-day tasks for a secondary (such as for a smaller project), then we expect the secondary to still accomplish the baseline expectations for a secondary TAM (see below section). 
  • Adds Project Updates in Linear.
  • Ensure that the project thread is regularly updated at a rate that makes sense for the given project so that the secondary can follow along.
  • Delegates tasks to secondary as needed when going AFK (or partially AFK) or to load-balance when other projects become busy.
    • If both pairs will have overlapping AFK, arranges coverage in advance.

Secondary TAM

  • Follows project threads and project updates in Linear (reading just SITREPs would be fine).
  • Joins partner calls when they can (or as needed).
  • Takes on any tasks as directed by primary TAM.
  • Fills in as primary when primary TAM is AFK or needs to load-balance when other projects become busy.
    • When filling in as Primary TAM, performs all baseline expectations for Primary TAMs.
    • If both pairs will have overlapping AFK, arranges coverage in advance.

Pair TAM best practices / example approaches

The following are just various approaches for a successful pair TAM relationship; please add the experiences that have worked for you and could be good models for others to adapt. 

Best practices

After syncing up to define the pair relationship, consider creating a table in the project P2’s top post or Linear, outlining who generally will be responsible for common tasks on a project, as directed by the primary TAM. Common tasks can include: partner comms, calls, posting SITREPs, working with designers and developers, overseeing QA, verifying QA issues, etc.

Proposed example “task table” – can change as the project changes.
Regardless of the tasks outlined here, Primary and Secondary TAMs are expected to perform the baseline expectations as described earlier in this document.

TaskTAM responsible
Partner comms and call coordination@tam1 
Overseeing design and development work@tam2
Posting SITREPs@tam1
Reading SITREPs@tam2
Overseeing QA process@tam1
etc…
  • Both TAMs should proactively communicate their availability and inability to complete any tasks so that alternative arrangements can be made. 
  • TAMs should escalate any concerns around the pairing relationship to their lead. 

Pair TAM toolbox – example approaches

In this section, we’ll compile authentic examples of pair TAM strategies, methods, and communications that have led to positive results. Everyone is encouraged to contribute, ensuring that, over time, this becomes a valuable reference for all.

  • Splitting partner-facing work/comms and other project work:
    • If a partner is located in a time zone that is closer to one TAM’s location, that TAM can handle most of the partner-facing tasks (calls, comms) while their pair handles the technical aspects such as overseeing the design and development work.
  • Splitting work in terms of strengths and interests
    • If one TAM has a particular strength or interest in one area, that could be another way to divide up the work. 

Considerations for Pair TAM assignments

Usually, one person gets assigned as the primary TAM when a project needs to kick off. It’s a stretch, but it’s preferable if we can have two TAMs assigned at the start of a project, but that’s usually not the case. Once a project needs to be assigned a pair TAM, we start by looking at capacity. Capacity is a subjective question, and we’ll always aim to check in with the TAMs to ensure they have the bandwidth to take it on, either before considering it (usually when we have multiple projects that need assignments) or when we can ask if there’s room for one specific project.

Other considerations are the partner’s time zones or preferred working hours, specific skills needed for complex projects, indicated interest, or a specific TAM’s wish to gain experience on specific A8C products. 

TAMs are encouraged to contact their team lead with any questions about specific assignments. It’s also important to remember that no one is required to continue working on a project if they feel uncomfortable with the subject matter, the site owner, or the content for any reason.