Co-written by Alexis* and Adrienne

Most people switch jobs every few years, but as an ex-Facebook RPM, I* switched teams every six months. I saw a lot of different teams quickly early in my career, and learned that the set of tasks that makes you successful in one team does nothing on the next team.

Tackling a wide variety of problems ranging from Instagram Video Chat to Newsfeed Content Integrity, I noticed that I’d get drastically different outcomes depending on how I approached my onboarding for each new team.

I wanted to share two patterns I identified between great onboarding vs. bad onboarding to set yourself up for success.

1. Identify short-term wins that add value to the team immediately

The best way of identifying short-term wins is to schedule 1:1s with your team members. 1:1s can be a very effective or ineffective tool depending on how you approach it, however:

Great PMs build trust not just by getting to know the team, but by being strategic about how they can add value right away. Here are some patterns I discovered in the basket of first projects that tend to be immediately helpful in contributing to building trust:

Reducing process imposed by the broader org, by negotiating it down with the org, or looking for a more efficient minimal way to do it.

Example: After the launch of Tesla Voice Assistant, Adrienne noticed that her engineers were spending a lot of cycles manually uploading the translations from the Localization Team to the language model. She identified a drain on her engineering team’s productivity and spearheaded an automated, self-serve solution the Globalization team could use to upload model training data and free up her engineers’ time to work on other products on the roadmap.

Mediating interpersonal conflicts, where the PM plays the role of an un-opinionated listener to break an impasse.

Example: When I first joined a Growth team at Facebook, I noticed a pattern where engineers spoke negatively about a particular client team. I learned that just two months ago, the client team had accused our team of cannibalizing their goal metric and escalated the issue to the leadership. Our team thought that was unnecessarily aggressive and thrashy. The unresolved resentment from both sides resulted in micro-friction like avoiding meetings with each other or delaying code reviews. Upon realizing this, I immediately scheduled time with the client team’s PM to hear their grievances; he was happy that I made the first gesture to understand them. For me, it was the easiest thing since I had none of the emotional baggage. The client team’s PM and I ended up jointly publishing a memo that outlined how we plan to work together in future, and also set a joint goal committing to look out for each other’s objectives.
Documentation of a popular service or dependency that a lot of other teams depend on and ping engineers for help. If a team’s long-term goal is to build the infrastructure that powers many services around the company (a common engineering vision), then crisp documentation is important in order to build other teams’ confidence in the work your team is doing. It also saves engineering team’s time, now that other teams can look at the documentation, instead of having to ping with one-off questions.
Finding a new client or application for the work the team has already done, looking for new impact at low cost.

Often, the PM is the only person who can articulate latent needs. Your team is largely focused on executing on the trees, and your responsibility is to rigorously examine the forest.

2. Look out for red flags affecting team alignment that needs to be addressed immediately

Here are common red flags I’ve discovered that are useful to identify early after joining a new team. Look out for:

Goals and priorities alignment: Ask your teammates in 1:1 to explain the team’s goals and priorities, and why they are the goals and priorities in their own words. It’s a red flag when…
- People can’t articulate them
- People disagree with each other on the goals and priorities
Future of the team: Ask your teammates in 1:1 about the team’s vision. It’s a red flag when a team…
- Should have a vision, but does not
- Agrees on a single vision, but has zero conviction
- Disagrees on the vision
- Misunderstands the vision
Conflicts: Ask your teammates in 1:1 about dynamics that you should be aware of. It’s a red flag when there are…
- Interpersonal conflicts
- Two suns (i.e. two or more people have strong opinion and authority, leaving the team in frequent impasse)
- Strong personalities
- Too much reliance on one engineer/person
Morale: Ask your teammates in 1:1 about what they’re excited by, and how their energy level has been in the past 3 months till now. It’s a red flag when there’s…
- Low excitement levels
- Burn out

Any of these red flags are foundational issues that shrinks a team’s ability to think creatively and execute effectively. Understanding them in a 1:1 setting is useful, because getting the team back on track by addressing these red flags head on, or even simply articulating these red flags with words is valuable for a team.

You can use this basket of skills to understand the right things your team needs to be successful. A successful PM is not defined by a successful completion of a set of predetermined tasks. Instead, a successful PM, when first joining a team, meets the team exactly where they are.

There were many more frameworks and examples I wish I could expand on for figuring out the most important things a team needs to get right. If you’re interested in learning more, please fill out this interest form (Google Form), and we will organize a group coaching session as a follow up.

Product Managers at Work

2 Ways To Diagnose Your Team for…