Joining A New Team: A Checklist

·

4 min read

Joining A New Team: A Checklist

When I join new teams, I expect some sort of onboarding, but I also do not rely on anybody to fully onboard me. People have things to do. Regardless of whether there is a buddy assigned to onboard me, my familiarity with the tech stack used, the state of the documentation, or whatever variables there may be, I have the means to know what I want to know.

I do an “internal audit”. It’s about deep-diving into what I am getting into. As I go through each topic, I also document what I see as I see it. No biases whatsoever, with full disclosure that I am looking into these things from a fresh perspective — most likely with no context of why things are the way they are.

This is a list of the things that I look into when joining a new team or department. These may also be helpful if you are creating a new team or receiving projects from another team. Some are more applicable to an incoming Team Lead. Use what makes sense to you. :)


Domain

Know the domain

  • What is the team’s mission? (from Business, Product and Tech perspectives)

  • Where are we right now?

Know the projects

For each project,

  • What does it do?

  • How does it contribute to the overall mission?

  • Tech stack and infrastructure

  • Is it in Production?

  • Is this a main / critical project?

  • Main clients and transactions

  • Is it legacy? Scheduled to be sunset or replaced? Why?

  • Does it have recent changes (feature-wise)?

  • Is this a part of any near-future roadmap?

  • Any issues?

    • Incident tickets, what severity?

    • Tech debts

  • Repository

  • Documentation

  • Project owner

    • Previous owner of the project?

    • Who handles this currently?

Know the roadmap

  • What are you actually working on today?

  • For each roadmap item,

    • Purpose, deadline, stakeholder

    • RICE priority

  • Where can we see the full roadmap for this year?


People

Know the team composition

  • Who are the Tech Team members?

  • Who are the Product Owners?

  • Who are the people we usually talk to? (e.g. Designers, Business, other tech teams)

Meet the people

  • Know the team organization (reporting lines, including horizontal leads)

  • For each person, schedule short 1:1s (just 15 minutes)

    • Role in the team

    • Career goals

    • Do you like what you are doing right now?

    • How open are you to changes?

    • How long have you been working in this team?

    • Previous teams, if any

    • Previous leads, managers?


Processes & Performance

Know the end-to-end processes

  • Product lifecycle (PDLC)

    • Including product and business requirements documents
  • Development lifecycle (SDLC)

  • Sprint activities

    • Creation and handling of stories

      • What do the stories look like?

      • Handling of the icebox

    • What happens during daily stand-up?

  • How is <tool> used?

    • Repository setup (e.g. GitLab, Github)

    • Project management / issue-tracking / bug-tracking tool (e.g. Jira, Trello)

    • Cloud platforms (e.g. AWS, GCP)

    • Testing tools (e.g. Behave, Cucumber, Selenium, Appium, K6, Jmeter, Zephyr)

    • Monitoring platforms (e.g. Dynatrace, Splunk, Datadog, Grafana)

    • Knowledge base (e.g. Confluence, Notion)

  • Quality engineering

    • Automated tests availability

    • Performance testing

  • Release engineering

    • CICD

    • Config change and feature flag management

    • Other deployment processes outside automation (e.g. manual approvals)

    • Production tickets

  • Site reliability engineering

    • Incident management

      • What happens during escalation?

      • Post-mortems and root cause analysis

    • Observability and monitoring

  • Business As Usual support activities (e.g. service client onboarding)

  • Attendance and core hours

  • Communications

    • Meetings (e.g. sprint ceremonies, weekly sync-up)

    • Communication channels (e.g. Slack, MS Teams)

Know the current team performance

  • Mesh team metrics

  • DORA metrics


Learnings

  1. The checklist does not happen in a day :D You don’t have to know everything all at once! :))))
  • It can get overwhelming depending on the status of the team and the services :D

  • It’s a gradual process so I just get a high-level overview first. Once I have a feel of the landscape, I prioritize which ones I need to dig deeper into.

  1. Depending on your role in the team, you may need to focus on some of the items only but everyone in the team should be aligned even in high-level terms only.