Onboarding Staff+ Engineers
How to effectively onboard staff engineers
I’ve been interviewing, shaping the recruitment pipeline, onboarding and working closely with other Staff engineers. In my current gig as a Senior Staff engineer, I find myself digging into a new cluster (roughly 100-200 people) every few months which means I practically need to be onboarded as if I was new.
I also mentor aspiring senior engineers who are on their way to becoming full blown Staff engineers. A common theme is the differences between senior engineers and Staff engineers which start from day 1.
I have seen some great onboarding and some terrible ones, both with long-lasting impact on the performance.
To make onboarding more approachable, I packed some of the best practices in this article to set a good baseline.
Why?
Let’s first touch upon why onboarding a staff engineer is any different than “normal” engineers like backend, frontend or data engineers.
Scope: while most software engineers are hired to work on the products that are fully owned by one team, staff engineers usually work in a scope that spans across multiple teams and products.
Depth: obviously, a wider scope means that the staff engineers don’t get to be as deep as dedicated engineers in all those products and technologies. However, their very value proposition depends on knowing enough to lead the technical aspects of those products.
Time span: While most software engineers are held accountable for tactical work like fixing bugs or adding features, Staff engineers usually deliver their full potential by focusing on the long-term strategic initiatives.
There 4 aspects to consider when onboarding:
Tech
People
Operation
Product
I’ve described these aspects in a separate article:
Any staff engineer worth their salt knows how to self-onboard but the goal of the onboarding is to shorten that process so they can deliver impact ASAP.
Poorly onboarded staff engineers struggle or leave.
How?
Staff engineers come in all shapes and sizes. There are at least 4 archetypes (some even count 6). Good onboarding however, shares these elements:
Gets the practical matters out of the way
Starts small with a clear roadmap for growing the scope
Provides opportunities to do actual engineering work
Feeds them with relevant information to build the context
Helps build their network of influence for maximum impact
Gives them ample time due to the larger scope and longer horizon
Establishes regular touchpoints to facilitate the flow of value delivery
What?
Buddy
A buddy is a current employee who handles onboarding the fresh staff engineer. The buddy is even more important in the remote work era to ensure the new hire is quickly up and running.
For a staff engineer onboarding pick a buddy who:
is positive and can present the company to make a great first impression
is social and has a large network to be able to connect the staff engineer to relevant people
is available and can spend the time with the new Staff engineer (it takes roughly 1-2 month depending on the scope)
has been at the company long enough to know both the immediate domain, but also the surrounding ecosystem to help put the answers to the staff engineers’ questions in the larger context
knows about various practical matters like logging time reports, expense reports, entrance, how to get access to this or that system, etc.
ideally has the same rank or higher in the IC ladder (eg. principal engineer)
It is best if the buddy is not their reporting line. When people are new, they really don’t want to make a bad impression by asking stupid questions. That’s exactly the problem the buddy is supposed to prevent by being there for the stupid questions, because it is more expensive to go ahead with stupid assumptions.
To the buddy
As a buddy, make sure to set aside a couple of undistracted hours on the day of the onboarding. Schedule a daily check-in for every day in the first week, then gradually space out the syncs to once per week as the new Staff engineer builds their network and get busy with others.
At your syncs, make sure to cover:
How are they feeling so far? How is their first impression? Are there any sources of frustration that can be eliminated? Ask open ended questions to hear their perception.
Is there anything they need? Do they need access to the systems? Do they have questions that you don’t have the answer to and should be forwarded to someone else?
How has their world model developed? It is important not to shove your opinions down their throat. Use this chance to have a dialogue and learn from their fresh perspective. If they misunderstood something critical, correct them. Otherwise let them evolve their view as they go.
Meet & greet list
Effective staff engineers bridge communication gaps between teams. They need to expand their tentacles across the org and absorb the organizational knowledge to convert it to wisdom. While senior engineers spend most of their time in the code, Staff engineers spend a large part of their time with the stakeholders, their peers, and dotted reporting lines.
The people dimension is key to successfully carrying out their function. That is why you should prepare a list of people for them to meet.
I usually organize it in a table that has 4 columns:
Name: the name of the person
Title: their formal title in the org
Topic: things to talk about when meeting that person
Location: comes handy in multi-hub or multi-time zone setups
Don’t book the meetings for the new recruit. Let them be in charge of introducing themselves and booking the meeting. Help them with the intro only if they ask for it.
Any healthy and dynamic organization is like live beings and change all the time. It is extremely useful to have an up todate picture of the organizational structure, so they know where they are, what the dependencies and dependents are.
To the new staff engineer
As a staff engineer, you can ask these questions to help you become a more effective leader in a shorter time:
What is working well? It is easy to focus on the problems. There is a risk to go around with a solution at hand and look for problems. Don’t fall into the trap of premature diagnosis or accidentally break things on the way to fix them. Take your time.
What has been frustrating? These are potentially areas where you can make an impact but be diligent in assessing the impact radius of each problem. Sometimes, you spend a month only to empower one team. Sometimes, you spend an hour unblocking an organization. Don’t commit to anything until you know enough to pick your priorities.
What do you hope I can help you with? Many staff engineers have dotted reporting lines. While you don’t owe anyone, it is good to hear the expectations to spot the commonalities. Don’t have “it’s not my job” or “it’s above my pay scale” attitude. Hear them out and see how you can be part of a solution.
How do you/your product contribute to the business objectives? The answer can vary depending on the function and quite frankly sometimes the answer is unknown. I’ve found the 5 whys to be a useful technique to find the underlying cause.
Who are your stakeholders? While the end user is the kind, most teams have internal known or unknown stakeholders. It pays dividends to unearth those dependencies during this technical, business and organizational discovery phase.
As you explore the T-POP (technology, people, operation, and product) aspects of the organization, draw maps and diagrams to help you understand their relationship. Every meet & greet is an opportunity to find pieces of the puzzle that help you build the biggest picture about how the business runs and where you can have an impact.
Unlike EMs or PMs, Staff engineers have zero mandate over product or people. As leaders, many staff engineers rely on their soft skills to influence the organization. Get to know key individuals, their values and fears. Because when it’s time to drive change, you must translate the change to something they resonate with.
If your org has a mature remote/async collaboration culture and tooling, it’s still very useful to have that first interaction F2F (face to face) whether it is onsite or via VC (video call).
It is totally normal to be on a meet & greet frenzy upon your start. But try to space them out after the first week so that you can get some focused time to process the information and think during working hours.
A good way to think about it is the weekly meeting/focus ratio. For example if your work week is 40 hours and you spend 24 at meetings, you’re only left with 16 hours of focused work. This gives a ratio of 24/16=1.5x which can be a lot depending on your impact radius (this is an actual number from my first week as a sr staff engineer supporting an org of roughly 450 people and I barely scratched the surface with that ratio).
Whatever is your weekly meeting/focus ratio, it’s best to reduce it by half after the first month. As an engineer, your main contribution still depends on thinking and making sense of things to come up with solid solutions.
Anchor team
Your new hire is anxious about their impact. It doesn’t help that the role of staff is vague by definition. “It is more of an attitude than a role” as an ex-Google staff engineer put it.
Let the staff engineer start with a smaller T-POP: than what they’ll eventually cover. For example, if the staff engineer is supposed to cover an entire cluster, let them start from one team or subcluster. Staff is a technical role. By starting closer to the action, they get a chance to have a solid understanding of the technology.
There are 3 ways to pick that team, but it boils down to T-POP: pick a team that the staff engineer knows at least its technology or domain or people.
For example, if you pick a team whose technology is something familiar to the staff engineer, they can use something they know (technology) to learn something new (domain) while getting to know the team (people).
Allow them to get their hands dirty with technology. The “engineer” in the “staff engineer” is there for a reason. Engineers love details. If you take away this chance from them, there’s a substantial risk that they will not mature in their role and end up as some ivory tower abstract role that’s frustrating for them and expensive for the org.
At the anchor team, have a few starter tasks ready. The tasks should be easy enough to give the new staff engineer an introduction to the moving parts but hard enough to demand some digging and T-POP discovery. A good Staff engineer is an expert in bringing clarity.
Whatever anchor team or starter tasks you pick, don’t throw your new staff engineer at the organizational wasteland. Just because they’re a higher-level engineer doesn’t mean they have to start by cleaning up your mess. The anchor team exercise is part of the first impression that will hopefully build a long-lasting relationship. Given how long it takes to properly onboard a staff engineer and the long-term initiatives they’ll be working on, it’s important to get the first impression right from the get-go.
Allow them some quick wins. This gets them versed at YOUR company. No win? No problem. Give them time to make mistakes and learn. While modeling good work, don’t correct everything they do. Allow them space and time to ramp up. It takes months to fully get up to speed.
Don’t judge too fast. Many staff engineers are clever people and like an iceberg, they may just show a fraction of their skills when they are new. Giving the wrong advice hurts the trust you’re trying to build.
Some onboarding processes get the Staff engineer stuck in the anchor team. This is overkill for the value they can bring to cross-team collaboration. Have a clear roadmap with checkpoints for unlocking their scope. Remember: the main goal with the anchor team is to introduce them to TPD and equip them for strategic work not to get them stuck in tactical work.
To the manager
Despite the dotted reporting lines, as the official manager, you’re responsible for making sure the staff engineers have the right knowledge, mandate, and responsibility to do their job effectively. Don’t leave this part to the buddy:
Knowledge: have regular 1:1’s. If you miss one, make sure to reschedule that time ASAP. Staff engineers can be quite powerful and popular among your engineers. Make sure that you take enough time to be aligned or the result is a frustrating and counterproductive relationship.
Mandate: Don’t wait too long to get them involved in setting strategies and standards for the organization. They should get involved in whatever technical leadership forum you have in place. If the decisions are made behind closed doors your staff engineer will not be truly empowered to fulfill your expectations.
Responsibility: Have an ambitious vision for your new staff engineer. Motivate them to change the trajectory of the company. Ask more of them than they realize they can handle. Staff engineers generally rise to the level of expectations, especially if you have hired well.
Being a staff engineer is different everywhere. You can share stories about both successes and failures. Tie back anecdotes to the challenges they are currently facing. This helps them assimilate culturally.
Some places over-index on cross-functional collaboration. Others, writing. Whatever the tough areas are, show them how it’s done early on. When setting expectations, don’t be too specific because you may come across as micromanaging but don’t be too vague either.
Access to the room
If you are an engineering leader with Staff+ Engineers reports, one of the biggest mistakes is to exclude them from important discussions that provide non-technical context.
The fallacy stems from the fact that the Staff+ Engineers are primarily concerned with tech. But tech doesn’t live in isolation. It’s tightly coupled to people and product aspects.
If most of the discussions are happening behind closed doors and where the Staff+ Engineer is excluded from, don’t expect them to be as productive when it comes to executing the ideas without context.
To understand this, we can refer to the origin of the word “Staff” and how it is used in military:
The term “staff” is used in the military to promote great soldiers as role models without giving them extra command and control responsibilities.
Staff officers assist the commanders in planning, analysis, and information gathering. The commanders have authority and accountability over their subordinates. Staff officers don’t. —Beyond Staff Engineer
Staff+ cannot assist the engineering leaders without having the contexts that are discussed behind closed doors. As a rule of thumb, always bring your Staff+ engineer to the key meetings. And if for any reason, they miss it, make sure to fill them in as soon as possible.
Conclusion
Staff engineers can have a high impact on the organization. Onboarding them can be tricky given their scope, depth and time span. Done right, they can be a huge asset to the organization, so please take your time to maximize their impact with proper onboarding.
References
Aakash Gupta’s post on how to onboard product managers
Paulo André‘s post on self-onboarding in a leadership position.
Hit the Ground Running - How to Ramp Up at Your New Job in 3 Weeks (paywalled, I read the open part)
Asking open ended questions
Why an onboarding "buddy" is essential for every new employee