Onboarding peer executives.
While many companies build out an elaborate Engineering onboarding program, the process for onboarding new executives tends to be an ad-hoc, chaotic affair. There usually is an executive onboarding process, but it’s used too infrequently to ever get excellent. Part of the problem is similar to that of an executive job search: every executive and role is unique, and it’s hard to create a repeatable program to handle one-of-a-kind onboardings.
The other part of the problem is that the executive’s manager, the CEO, usually hires a new executive to solve a specific problem. Once the executive starts, the CEO will often turn to focus on their next biggest problem. This happens so frequently that the two most common frustrations I hear from executives about onboarding their peers are “Isn’t this the CEO’s job, why should I worry about it?” followed shortly thereafter by “Why didn’t I worry about it more? I knew leaving it to the CEO was a mistake.”
Even when the CEO is engaged, most new executives want to impress their CEO. You’ll often find new executives struggling a bit with onboarding, while simultaneously reassuring the CEO that they’re doing fine. Your job as a peer executive is to help the new executive succeed, even if no one tells you it’s your job.
I’ll break down onboarding peer executives into five topics:
- Why executive onboarding matters
- How onboarding executives differs from onboarding engineers
- How to share your mental framework
- Defining your roles in respect to one another
- Investing in time working together on an ongoing basis
Peer onboarding, like a surprising number of good executive practices, is straightforward, and easy to do well with some time and attention. By the end of this piece, you’ll have a clear structure for onboarding a new peer executive.
This is an unedited chapter from O’Reilly’s The Engineering Executive’s Primer.
Why this matters
It’s unfortunately true that you can be perceived as a high achieving executive without accomplishing much, but you cannot genuinely be a high performing executive unless you, your peers, and your CEO are doing excellent work. You can create whatever narrative you want about your extraordinary engineering organization who’s excellence was masked by the weak product or sales teams, but you’ll only be exceptional if every part of the executive team functions well.
Your best tools for forming an effective executive team are working with a team-oriented CEO and being deliberate in the executives you hire. Once you’ve hired someone, your best remaining tool is effectively onboarding them. Without a good onboarding process, even strong executives will make missteps, sometimes unrecoverable ones. I’ve seen Engineering executives start by attempting a full rewrite of the company’s technology stack, others significantly accelerate spend until the company itself is at risk, and still more that replace the existing team with their friends. All of these are much easier to prevent than to recover from.
Onboarding executives vs onboarding engineers
As an engineer, you’ll often be responsible for onboarding peers onto your team. In those cases, you’re often implicitly more senior than the peer being onboarded, but you’re both knowledgeable in the shared field of software engineering. Onboarding executive peers is different. You’re truly peers, without any implicit hierarchy between functions, and you often don’t share the context of having worked in a common profession because they might be the new executive for Finance, Sales, or anyother function outside Engineering. Further, engineers (and most other functional contributors) go deep and narrow, whereas executives need to start by going shallow and broad.
Teasing out the distinction between onboarding engineers and executives:
When onboarding a peer software engineer, your goal is to help them understand your current process and one specific onboarding project well enough to implement that one project. After two or three such projects, the new engineer will be relatively ramped up.
The best indicator in engineering onboarding is completing initial projects quickly at a high quality bar, which is typically most dependent on their ability to navigate a large, lightly documented codebase for the first time. Bad signs are making very slow progress on projects, as well as arguing about existing processes before ramping up on them
When onboarding a peer executive, your goal is to help them understand the company’s landscape (business, team, project, and process), with a particular focus on the most critical, current issues. There is so much to absorb, that they will get a very broad overview, and then go deep as required by the immediate fires they need to put out.
Good executives will immediately focus on the highest priority areas, check their plan with nearby peers before beginning implementation, and bring a positive energy (even if things are an absolute mess). Bad signs are inaction on key issues, changing areas that are already working well before addressing higher priorities, or immediately falling back onto previous companies’ approaches that fit poorly in their new circumstances
Sharing your mental framework
George Lakoff’s Don’t Think of an Elephant talks about the power of framing a debate. You can often establish someone’s mental framework with a short phrase like, “Our product changes our users lives.” That frame is challenging to shake, even with data that suggests your users don’t use the product at all. Helping new executives build an accurate mental framework of the business is one of the most powerful acts you can take, and it can only occur in the that executive’s first few weeks on the job.
If you’re onboarding a new peer executive, I recommend covering all of these topics in the first two weeks, even if it means canceling some of your standing meetings to make it possible:
Where can the new executive find real data to inform themselves, rather than relying on existing narratives? The best executives will listen to you, but won’t fully believe anything until they’re able to find data to substantiate your perspective. That’s not because they don’t trust you, but because any seasoned executive has been burned by trusting someone who fervently believed something that ultimately wasn’t true.
Examples: Company dashboards. Board reports. Tableau. Looker. Google Analytics
What are the top two to three problems that they should immediately spend time fixing? (This is traditionally the first question to answer, but I think setting the mental frame is even more important!)
Examples: CEO is very upset with pace of execution. Friction between Product, Engineering and Legal is preventing forward progress on new initiatives. Personal conflict between two senior leaders has frayed cross-functional relationships
What is your advice to them regarding additional budget and headcount requests? The classic new executive move is to privately request more budget from the CEO, who agrees to keep the brand new executive happy, which often creates a cascade of cross-functional hiring that can significantly impact the company’s cash flow. If you don’t want them to immediately request new headcount, you should have an open discussion with them about the consequences.
Examples: Although I suspect the CEO would approve more headcount if you ask today, if you look at Product hiring relative to revenue, we’ve gotten significantly less effective each year over the last three years. I recommend spending time debugging why we’re getting less efficient before further increasing the size of the Product organization
What are areas where many companies struggle, but are currently going well? Specifically you want to steer them away from running their “default playbook” where things are already working.
Examples: Product and Engineering are already planning together effectively. CEO is very pleased with the release cadence (perhaps they are instead frustrated that cadence isn’t translating into revenue). Collaborative headcount process is already reaching reasonable cross-functional equilibrium
What is your honest but optimistic read on their new team? Give them a detailed, transparent look into the members of their team, while keeping in mind that any historical gaps in performance may have been connected to the reason the new executive was hired.
Examples: Two years ago, Design was an active part of planning product work. Then the Head of Design moved from an embedded model to a centralized studio, and the designers generaly lost context on user and business goals. In particular, the impact I’ve seen on the Design Leads has been quite high, going from some of the highest impact folks I’ve worked with to feeling a bit disengaged
Who do they need to spend time with to understand the current state and the company’s implicit power structure? Especially the longest tenured employees who uniquely hold parts of the business in their heads, and individuals who have significant influence over the executive team that wouldn’t be obvious from the reporting hierarchy.
Examples: Head of Quality Assurance or Customer Experience. Long tenured Product Manager. The third founder who isn’t in a managerial role but remains very influential
What is going to surprise them? Particularly things that are done in a unique way at the company, but also quarterly or annual processes whose schedule they might be unaware of.
Examples: Business reviews. Quarterly or annual planning. Written documents for every meeting
What are the key company processes, how long have they been in place, and how are they working? How should they propose changes to any of these processes if they feel it’s necessary?
Examples: Planning. Budget and headcount. Performance management. Cultural surveys
There are, without a doubt, peer executives who will only listen to guidance from the CEO. I’ve been responsible for onboarding multiple executives who fully ignored my advice, and immediately advocated for a full rewrite of our product or technology stack. I felt pretty bad about not influencing them more successfully, but nonetheless glad I tried my best to do so. Although they’re harder to count, I’m confident I’ve prevented many such nightmares by proactively sharing my mental frame with executives before they leap into action.
Define your roles
Effective Engineering organizations start with strong relationships across Product, Engineering and Design, and those relationships are greatly influenced by how well their executive’s work together. Many executives start their new role assuming that it’s more-or-less their old role but in a new company. This leads to implicit assumptions about who does what that may be at odds with how the company currently works, which results in conflict around role definition. You can’t prevent all tension between you and other executives about your respective roles, but you can avoid accidental friction by discussing the areas of intentional disagreement.
The three questions you should work together on are:
- What are your respective roles? Both of you should independently write down your expectations of the other role, then share those expectations with one another. If you find something that you disagree on, that’s great! Either it’s an accidental disagreement that is quick to resolve, or it’s a genuine disagreement that the two of you will need to spend time working through. In either case, you get to skip the step where you’re surprised to learn about it
- How do you handle public conflict? Part of being an effective executive team is appearing aligned with each other, even when you’re not, and that depends on having a clear communication strategy. This is easiest when you agree on how you handle public conflict, usually trying to politely resolve in the current meeting if it’s easy, and but agreeing to take it to a private meeting if you’re far enough apart that you can’t resolve without exposing the conflict to the wider team
- What is the escalation process for when you disagree? It’s inevitable that you will disagree with each other, sometimes on very important topics. I have certainly disagreed with my executive peers on budget allocation, roadmap, acquisitions, and any other topics. Most executives stumble through agreeing on an implicit escalation process for resolving conflicts between each other, but you can also just have an explicit conversation about it. When people complain about politics, often it’s a subtly disagreement about an implicit escalation contract: you can just make it explicit instead
These jobs never stop changing, the relationship between you and your peer that will be the only constant in navigating those changes. Spending time upfront will take a bit of time, but save a tremendous amount of time longer term, and start your relationship off on the right foot.
Trust comes with time
Once you’ve agreed on an initial definition of your roles and how you’ll work together, the final step of onboarding is to schedule ongoing time working together. Your initial agreement won’t actually be quite right, and you’ll only figure out the issues by working through difficult issues together. Executive calendars fill up so quickly that, unless you book recurring time in advance, you’ll only work on very painful issues that escalate past your routine calendar, which are the sort of topics that strain rather than build an early relationship.
The key pieces I’d recommend setting up are:
Spend some time knowing them as a human. Schedule some lunches or dinners to create a few non-transactional experiences together with this new coworker. Executive roles often pull you towards treating each other transactionally, but it doesn’t have to be that way. Try to make this happen a few times a year
Hold a weekly 1:1, structured around a shared 1:1 document, that lasts an hour. Repeated exposure has a magic to it, and an hour is enough time to dig deep into two or three meaningful problems.
If a weekly hour feels like too much, it may be a sign that either your functions don’t work together much, or that your company is at a stage where executives are leading in the weeds, which many early stage companies are. Try the weekly hour a few times, but absolutely move to less time if this doesn’t feel productive
Identify the meetings where your organizations partner together to resolve prioritization and work through any conflict. These might be weekly metrics reviews, monthly operational reviews, quarterly planning, or something else. Once you identify them, make sure both of you attend at least a few sessions together and afterwards discuss any conflict or disagreement to be better aligned in the future
Finally, trust is about doing what you say you will, which takes time to build. You can absolutely immediately enjoy working with someone, but you can only trust them after having them make commitments and seeing them live up to those commitments. This can’t be rushed.
How much progress is possible?
If an engineer is unconstructively argumentative or does particularly poorly in their first three months, you would generally manage them out of the company. Struggling executive hires are often evident within three months, but will often take a year or longer to leave a company. Mediocre but very nice executives last much longer, often remaining indefinitely.
As a peer, your only bet is to partner in good faith, trying to help new executives succeed. Even the best executives need support, and you can significantly change your company’s trajectory–and your experience working within it–by helping them onboarding effectively. Even if a new executive isn’t working out, it’s the CEO’s job to address that, not yours, and pushing too hard will only reflect poorly on you without solving the problem.