Starting with a new team

Here we go again #

Tomorrow, after taking four months of paternity leave, I’ll be getting back to work at Meta, and will start with a new team. My previous team was dispersed after the recent layoffs. So here I’ll be starting from scratch, with new team members, a new manager, new technologies, new high level goals - but with the same org within the same company.

This won’t be the first team I’ll be joining. During my career, I’ve been able to identify some habits which help me ramp-up with a new team. I’d like to share those here.

Let go of your ego #

One of the best tips I got from Ajit, (a past tech-lead of mine) is this: ‘Be shameless about your lack of knowledge’. Even if I have so-and-so years of experience, I’m still the noob on the team. I don’t have context about what’s going on with the team, why things have been built or decided the way they did - so it would be foolish of me to lay down my agenda before learning first and getting my hands dirty with the team’s work.

Asking questions helps build trust with the other team members. When asking questions, clarifications, justifications for why and how things have been shaped into today’s reality - you’re implicitly telling those people that their time, opinions and experience matters to you. That is the cherry-on-top getting the information you’ll need when starting with the new team.

Respect the past, but question the present #

Saying something like: “Is X really built using Y? That’s stupid” is a horrible idea. If you haven’t been to the team, you don’t have context on why things have been built the way they did. It’s fine to ask why things are the way they are - but do so respectfully. Maybe there was a hard-deadline. Maybe there was someone on the team who was aggressively pushing to some area and then left? Maybe a thousand other reasons.

But, as the new team member, you have the unique perspective of coming in with a fresh look onto the team. People who have been to the team for some time may be accustomed to inefficiencies, broken processes and sub-optimal systems - just because both have been there for a long time. It’s fine to question those. You might get a good-enough justification for your question, and you might not. You might decide that you want to replace a certain component - and you might fail doing so - but by trying - you’ll gain some experience with why things are built the way they are.

Use BFS and DFS approaches to talk to people #

I remember reading similar versions of this suggested by Andrew Bosworth as well as in the The Staff Engineer’s Path. When you get to a new team, identify people you should talk to. Ask them who else you should talk to, and follow that graph. At some point, you’ll encounter some back-edges, which is good. Traverse the graph in whatever approach you’d like. It’ll help you identify the key actors in the org, important (recurring) good and bad ideas, etc.

Maintain a glossary #

During the first few weeks/months with a new team - I come across way too many terms and acronyms which I don’t know. I’ve built the habit of maintaining a glossary of terms and acronyms of the new team. Specifically, I use nvAlt which is a simple but fast note-taking MacOS app. Its search is super-quick and helps getting written information back quickly.

During meetings I write things I don’t understand in my glossary. Unless this is a 1:1 meeting, I don’t want to stop the meeting multiple times asking questions. After the meeting, I grab someone from the team, saying something like: “Hey, I didn’t understand some of the terms during the meeting. Can you please help me clarify those?”. Then, I fill out the meaning of the missing terms. Now I have those terms available for me for the next time I’ll encounter those.

Join the oncall rotation ASAP to experience reality #

Without any exception, every time I joined an oncall rotation with all the rotations I’ve joined - I felt that I was under-qualified joining. I did the team training, shadowed someone, reverse-shadowed by someone - but still, I felt under-prepared. During my first oncall shift on the L7 load-balancing team, I’ve experienced one of FacebookMeta’s hardest outage. I was definitely not ready to handle that one - but I’ve learned a lot handling it with the team.

Designing, building, testing and maintaining a piece of code in a void is one thing. Supporting it in production is a totally different thing. As the saying goes:

You write your code differently when you know it can wake you up in the middle of the night.

By joining the oncall rotation and supporting production you learn about weak areas of your product, improvement areas - and the people who help you when there are issues. All those are very valuable.

Rewrite the ramp-up plan #

As the most-recent-new-person on the team, you have the best view on what’s missing from the team’s current ramp-up program. When ramping up - keep in mind that you can suggest changes to the program. It’ll help your credibility with the team, as well as making the ramp up of the next person easier.