Onboarding

Talk and Observe: A Framework For Engineering Onboarding

My early days at Facebook as an engineer were quite difficult

I've been "the new engineer" at 7 different companies in my career, at varying levels of seniority and company size. I've also directly worked with 100s of software engineers where the same topic comes up repeatedly: onboarding.

The onboarding period, usually the first 2-3 months in the company, is critical for learning and building relationships. The Talk and Observe framework enables exactly that: quick and confident ramp-up for engineers.

It's impossible to "solve" onboarding for software engineers, but based on the feedback I've heard, this gets us pretty close 😇

What happens in onboarding?

Starting a new role in a tech company is daunting because there's so much to learn, both technically and non-technically. Some of the questions you'll need to answer in the first few months of the team:

Who do I go to for help?
What should I work on?
How do I release my code?
What new tools do I need to learn?

Successful onboarding is just as much about relationships as code. The first 2 questions above actually have nothing to do with technology and everything to do with people.

⛔

A common failure mode among new engineers is to spend all their time reading and writing code instead of talking to people.

Talk and Observe is a methodical approach to ramping up as a new engineer, and it has proven extremely useful across seniority levels and company sizes. As the name implies, the first part of successful onboarding is talking to people on the team. The second part, often overlooked, is about observing how people spend their time.

Talk 🗣

Your goal when joining a new company is to rapidly understand what your colleagues do. Unsurprisingly, an effective way to do this is by talking to them directly!

I recommend Boz's career cold start algorithm as a starting point. In a conversation with each teammate, Boz recommends asking them about details you should know as the noob, asking about the biggest challenges the team is facing, and finally asking who else you should talk to.

I additionally recommend spending a few minutes discussing your colleague's motivation and background. Why are they working on this team and what are their goals?

There are 2 important insights you'll get from talking to so many people:

You'll get an idea of organizational priorities when the same challenges and projects come up repeatedly. Figure out how your work connects to these priorities.
You'll find the same names come up repeatedly as recommended folks to talk to. These are the linchpins of the organization; the people who are powerful and trusted. They are likely to be on the critical path of your work.

Make it a priority to talk to your colleagues – aim to have at least 10 1:1 meetings in the first 2 weeks. At a minimum, you should chat with your direct manager, skip-level manager, and immediate team. Once you have a better understanding of your work and the team structure, you can convert some meetings to be recurring.

Take advantage of the fact that you're the new person on the team, so it's ok to be trigger-happy with scheduling time. If you don't have anything concrete to ask, just be curious: "I'd love to understand your experience on the team."

Most people already know the importance of talking to your new colleagues after joining a new company. What is less understood, yet extremely valuable, is the next part of the framework: the value of observing.

Observe 👀

Actions speak louder than words. The goal of observing is to better understand priorities and patterns by analyzing people's actions.

Luckily for us, software engineers naturally create many artifacts of their work that are easy to observe. The guiding question is "How can I observe an engineer's output and time allocation?"

Here's the data you should look up for every engineer you work with:

Code contributions. How many PRs are they submitting in an average week, and how many lines of code is that? How many comments do they leave on other people's code?
Design docs. Are there publicly accessible design documents or architecture diagrams that you can search by author?
Experiments. In Big Tech, most engineers will run experiments to ensure their changes are safe – what experiments have they started or modified?
Wiki contributions. Look at the edit history of the central team/company knowledge base and find recent contributions by the author.
Calendar: Some companies have public calendars by default, so you can see how many meetings each person has (and with who).

There is a treasure trove of intel in these simple questions:

An engineer's code is a fundamental marker of progress. Does this team write a lot of code with high churn, or is it lower volume? What is the company's culture around code review – are there detailed comments or blind accepts? This should directly impact the code you put up for review.
The number and scope of experiments give you a baseline for what it means to ship software. How much diligence and communication goes into each experiment update?
An engineer's contributions to design docs, wikis, or experiments are indicative of their top priorities. Out of 100 things an engineer could be doing, they chose to spend their time on this – why?
Observing someone's calendar reveals norms around communication, and shows how "plugged in" each engineer is into various initiatives. Most group meetings will also have a paper trail of notes and action items that reveal tons of context.

Effectively, your goal is to "stalk" each employee to get a deep understanding of their true priorities, interactions, and challenges. Once you understand the tooling at your company, this is extremely high leverage: looking up data for each employee should only take 15 minutes.

The benefits of this are immediate and deep:

Since you know what everyone is working on, you can tailor meetings to ask detailed, thoughtful questions. Connect the dots between your work and theirs.
By understanding ongoing projects, you can identify opportunities or inefficiencies. For example, someone may tell you that Project X is important, but all their time is actually being spent on Project Y.
Finally, you are able to onboard culturally. Things like team meetings, code reviews, and launch reviews differ based on the norms of that company.

⭐

Go through the Taro top 10 content about onboarding as an engineer.

The combination of talking to your new teammates and simultaneously observing their behavior sets you up for successful onboarding. Especially for more senior engineers, understanding a team's dynamic and building trust is a prerequisite for landing impact.

Talk and Observe lets you build relationships quickly while also understanding the team's unique culture. Now you'll crush your new role 🎉