Skip to main content

New TPM Onboarding

Applies to all TPMs who have not previously held the position on their specific team. Expectations for a TPM role are listed here. Onboarding consists of 3 main objectives:

  1. Getting to know the team
  2. Learning the codebase
  3. Understanding how to lead (optional if previously held leadership position)

Milestones#

Here is what is expected of a new TPM at the beginning of the semester.

Week 1#

Team members are likely still arriving on campus or settling into their new schedules, so learning from experienced members will be difficult. The first week focuses on the TPM's independent learning.

What the TPM should do before the next meeting:

  • Obtain contact information of everyone on the subteam. (Preferably phone numbers and Facebook included).
  • If it's an old project:
    • Ask developer leads or the PM for credentials and permissions to necessary repositories or accounts, as well as documentation on progress.
    • Sweep through codebase, can run through general architecture of stack.
  • If it's a new project:
    • Write clear design document about the overall architecture and major components. The document should indicate why this particular design is chosen.
  • Installed necessary components and repositories.
    • [Stretch] Can run existing app. May require assistance of previous team member if code is poorly documented or broken.

What to expect in the subteam meeting:

  • Spotty attendance. Schedule conflicts should be resolved by the PM by the next meeting.
  • Get to know team members and roles, what they've worked on in the past, what they're stuck on, and note what they want to do and learn this semester. This will be useful in task assignment and should be relayed to developer leads.
  • Discuss product vision, this semester's goal, and next steps with PM and team members. Note existing issues.

Week 2#

Initial tasks can be suggested for each team member. We encourage ownership — experienced team members should know what they have to do and declare a deadline that they're expected to meet. TPMs should fully understand their responsibilities by the second week.

What the TPM should do before the next meeting:

  • If it's an old project:
    • Begin actively participating in the team's developmental process. Set up a specific time to meet up with 2-3 other developers and program (does not have to be recurring). The purpose is
      • For the TPM to learn how each team member works and how they're developing towards the end product
      • Establishing that development is done outside meetings
      • Team bonding
    • Be able to run existing app on its platform.
  • If it's a new project:
    • Research and document potential tech stacks and platforms for the app, and the reasoning behind the final decision. A good tech stack should be chosen for scalability, support, and suitability, not for familiarity.

Unblock developers by assigning a task to yourself involving a deep-dive into the codebase or the libraries it uses. The TPM should not assign themselves a feature, now or ever; their role is to unblock other developers, communicate, and make larger decisions. Seek help from developer leads for unblocking difficulties.

  • Create milestones for the project this semester, considering each team members' abilities. This will be presented to the developer leads.

What to expect in the subteam meeting:

  • Complete attendance. Report to the developer leads absent members who did not provide at least a 3 day notice. This could be an early warning of a much larger issue.
  • Make sure designers are working on pertinent features that should be implemented next in the release cycle (or that they are even further ahead). If not, discuss with the PM and the designers. Lack of future design means development can starve.

Week 3#

The TPM will present in their milestones in the weekly TPM meeting to the developer leads and other TPMs for feedback. TPMs for new teams will present architecture and tech stack choices. TPMs should be comfortable within the team and with the codebase by the third week.

What the TPM should do before the next meeting:

  • Create milestones for each developer on the team in terms of skills they want to develop. Work with each team member. Try to use an objective metric. Their progress will be assessed at the end of the semester.
  • Identify one issue in development on the team that could reasonably be solved within the week (with help). Set it as the goal for completion.
  • Set up casual meetings with new developers to resolve any initial issues in development or HR.

What to expect in the subteam meeting:

  • Members should have completed whatever goals they set for themselves. If any member does not (including the PM) and did not provide at least a 3 day notice, show your concern, then let the developer leads know. This could be an early warning of a much larger issue.
  • Some inexperienced members will not know what to do. Discuss with more senior developers on the team and assign inexperienced members a small task with the purpose of exploring the codebase while doing some useful work. Communicate that although the initial task may seem trivial or boring, it's to give them a smooth learning curve. Dish out more involved tasks if early ones are completed quickly (and let developers leads know about the good work!).
    • Requirements:
      • The task should not involve writing much new code, but might require reading/scaning through a lot of existing code.
      • The task should be well-defined. TPM should have a clear estimate of completion time and necessary steps if they were asked to do it themselves.
    • Good Examples:
      • Fix some small design issues that are not too trivial
      • Add a small feature improvement
    • Bad Examples:
      • Some task that might require non-trivial refactors

Week 4#

The TPM is ready to assume responsibility over the project, responsive to all developmental issues by the fourth week.

In each weekly TPM meeting, the TPM should report on the status of individual developers in the team, any issues they've had, and the goal for the next week. Milestones missed should be regarded as anomalies and a discussion with developer leads is necessary.

In each subteam meeting, the TPM should learn of each developer's status, see a demo of their progress if it is visual, and compile a set of small tasks necessary to bring the team closer to the next milestone. Whether the tasks are assigned or chosen by developers is up to the team. The TPM should continue meeting up with developers on the team in casual coding meetups to facilitate progress and communication.

What to expect in the subteam meeting:

  • Inexperienced developers should begin to understand the project. Assign them larger tasks that they can own (build from scratch).