RPA Tools' Tips for Onboarding new Execs

Explore

Shishir's Tips for Executive Onboarding

An 8-week learning plan.

Over my career, I've had the chance to help onboard dozens of executives - either directly/indirectly in my own teams, or in advising others going through the transition. To be honest, most onboarding is not that successful. Parachuting in as a new executive in an already running team can be very tricky, and organ rejection is common. But when this is done well, onboarding can be a springboard for a multiplicative relationship. And it's notable that the bigger the team, the harder this is.

This guide is written with (a) a few principles to think about in this process and then (b) a guide to the

first 8 weeks⁠

Note that this is written as advice to the new executive, but don't let that confuse the situation ー the responsibility of successful onboarding is shared between the leader and the new exec. So feel free to swap the pronouns if the other role applies to you.

⁠

Three Principles

Principle #1: No one knows who you are... and they are going to be skeptical.

⁠

⁠

You've just been asked to join this hot new company/division/project. The leader spent hours selling you, perhaps with board members, other execs, etc all calling you. They stroked your ego and told you how amazing a fit you are and how impressed they are by your background. You're all puffed up and show up for your first day of work.

Then you meet your team. Two of them were passed over for the job. Their reports are perturbed by that too — why did the leader have to go outside the team? Or perhaps it's just general human skepticism — the leader says you're great, so prove it. It can be dangerous to assume that the leader's advocacy for you has been blindly accepted by the team. You will have to earn it yourself.

Principle #2: You have more to learn than you think. And no, you can't learn it later.

⁠

Not only did the leader of the company convince you that you're amazing, they likely convinced you that you already know everything you need to know to be successful. But the bigger and more complex a business / product / project, the more you have to learn. You have a small period of time at the start when everyone will expect you to spend time learning and be very supportive. But at some point, you have to hand back your "Hi, I'm a New Executive" card ー if you ask the exact same question after that, people will quickly think much less of you.

These learning areas can be really broad. Some random examples:

How the product works - "Jane has been here for 2 months and still doesn't know how to do X in the product???"

How the cadence works - what each meeting is, what the expectations are - "Jim just showed up to meeting X with a printed Word doc? Is he from another planet?"

All the acronyms that everyone on the team takes for granted that everyone knows - "Alice, can you get me a PDB and make sure you checked the QRC before the LJE?"

Key moments in the company's / team's history that everyone instinctually refers to - "Steve, we tried that in the {Period X} already. Duh."

Third rail questions - Questions that everyone either assumes are obvious (“Wait, they think that Coda should not be a doc?”) or questions that are known to evoke a much broader discussion (”You want Uber drivers to get health insurance? Oh man, that’s not a small discussion.”)

Everyone's names - "Hey Joe, can you make sure to say hi to Steve on your way in? Wait you don't know who Steve is? He reports to you... and sits next to you!"

How decisions actually get made - “Don’t they understand that you can’t make that decision without going to forum X?”

How the finances work - "Look Barbara, that might work for Company X, but our debt carrying cost is Y and you know that affects our CAC."

Mundane logistics - "Hey Carl, can you make some coffee for everyone? Wait, you don't know where the kitchen is??"

Of course, some of these will happen naturally, just by paying attention. But I have found it amazing how many execs get past their first few weeks without filling in key basics and then are left in a tough situation trying to slyly pretend to already know these things and find some way to learn them without alerting anyone.

Principle #3: What the leader thinks is broken isn't what everyone else thinks is broken.

⁠

⁠

The leader hired you, and probably pitched a few of the first problems. But often, the team is actually focused on a very different set of issues. I've found that in the first few weeks of a job, triangulating the difference between the "top down" and "bottom up" view can be critical. Both are important. The leader's concerns are likely ones that aren't being adequately addressed by the current team, and so they may not seem them the same way. But the reverse is often true too ー while the leader was trying to get everyone to focus on problem A, the team is actually more concerned with problem B (and perhaps that's why they haven't been working on A!). The reality is that you now have to understand and address both A and B.

⁠

Three Key Ideas

These are 3 ideas I've used to anchor an onboarding process.

Key Idea #1: Run the old administration. Clean break. Now you're in charge.

The most important instinct to resist as a new exec is the desire to "prove yourself fast." Everyone will expect it ー "It's been 2 weeks and she still hasn't fixed problem X??"

I encourage setting clear expectations here. Tell everyone that (a) your primary job for your first 8 weeks is learning and (b) in that timeframe, you will try as much as possible to mimic the behavior of the previous administration. Try to follow their cadence and don't change the meetings. Respect the org structure and chain of command that was in place. When faced with a decision you have to make, try to make it using the current philosophies, instead of your new (and likely not yet formed) instincts.

Then pick a time, roughly 8 weeks in, to switch seats. It can often help to turn this into a true Moment (plug: read

The Power of Moments⁠

). Send everyone the signal that you're ready. Some common patterns are to send a strategy email, announce a team reorganization, hold a team offsite, deliver an an all-hands presentation, etc. It doesn't matter much, just make sure the signal is clearly sent that "Ok. I've observed for 8 weeks and learned a lot. I'm done playing the old playbook. I'm ready to play mine."

Key Idea #2: An intentional, documented, well executed 8-week learning plan.

It's easy to say you'll spend 8 weeks learning, but it's hard to do. You will inevitably get pulled into the "hot issue of the day" and you'll have a lot of pressure to swoop in and resolve problems. Quickly, your meeting with the CFO to understand how the P&L actually works will get delayed. Your list of "get to know you" 1-1s will get deferred. Your onboarding with the eng lead who is going to give you the simple inside view of how the code is architected will be deemed not urgent. Your goal to visit every distributed office, to speak with 20 customers, to spend 40 hours on support, to build the product on your own laptop, to attend all your skip level meetings, etc ー all will fall aside.

So the key idea is: fill up your time with learning in a methodical, prioritized way. The rest of this doc is mostly focused on this ー outlining the areas you want to focus on learning, setting up a checklist for each area, and methodically working through it. And then take the key step: pre-schedule all those meetings up front. Similar to

big rocks⁠

, if you fill your time with your learning plan first, it will be less likely to be pushed aside for the priority of the day.

Key Idea #3: A single starter project that is not critical path.

Sometimes it is hard to truly be in learning mode for 8 weeks and you'll feel pressure to do something to actively move the business forward. Your leader's first instinct will be to put you on the hardest problem facing the business. I would resist this urge. Instead pick a starter project that is intentionally not a critical path project. Thinking of

Principle 3⁠

above, focus on a problem B, not a problem A.

As an example, when I took over eng for YouTube, I had a lot of pressure to focus on a big redesign we were doing (Problem A). I surveyed the engineers and realized that there was a lot of frustration around our code push process (Problem B). I made this my starter project ー leaned in to learn as much as I could, worked through solutions with the team, and moved us from weekly to daily pushes. This helped me learn a key system while also earning credibility with the team by solving a real problem. Once it was clear we could solve Problem B, it was easier to turn back to Problem A.

⁠

FAQ

I received a lot of amazing feedback and questions as I was putting together the doc. Here are a few highlights:

What if the CEO isn’t ok with 8 weeks of the “old administration”?

Easily the most common issue with this approach. Your CEO pays lip service to it (”of course you’ll need learning time!”), but actually isn’t committed to an 8-week window where their highest priorities aren’t being addressed. A few thoughts:

Get commitment early, i.e. before you start: Honestly, one of the reasons I wrote this doc was so that execs had a concrete item to exchange with their new boss and come to philosophical alignment. And if you’re really stuck, have them drop me an email. 🙂

Enroll them in the plan, and keep them up to date: Build your 8-week plan, and show it to them. Get them to add to the list. Review your learnings regularly. Don’t wander off alone on your learning journey, take your boss with you.

Spend lots of time together: It’s amazing to me how many execs are hired, and have only four 30 minute 1-1s with their boss in their first 8 weeks. For some people, this represents less time with their boss than they spent in their interview process! I personally aim for daily check-ins during at least the first couple weeks. Also, try to open up wide blocks of discussion time with a change of scenery ー going to dinner with your boss isn’t just something you should do in the pre-hire sell phase.

So what should the CEO be doing to support this process?

This doc is mostly written from the perspective of the new exec, but what about the new boss? A few thoughts:

Commit to protecting the exec and evangelizing this framing: The list of people with “urgent expectations” for the new exec isn’t just you. Once you agree on this framing, you will need to over-communicate it ー “Yes, I know you need that, but Jill is still in her onboarding process.” You may even go a step further and celebrate it ー “So excited that Joe just got through his strategy reviews, and their takeaways were actually quite interesting to me as well!”

Regular check-ins on the 8-week plan: Onboarding should be the primary project, so treat it like one. Check-in regularly, unblock where necessary, extend and encourage where possible

Be available / spend time: No substitute for this. See comments in the last question ー but presume that the amount of time you spend with the new exec should be a multiple of the time you spent in the interviewing process.

Is 8 weeks the right timeframe?

Very common question, interestingly in both directions.

Longer: Many questions about this being longer. For example, one person told me “unless you are in a familiar domain (and I wasn't) I think it's dangerous to write a strategy memo in 8 weeks. I think you need almost 4-6 months to have a solid one (it took me about 16 weeks to be able to articulate anything useful).” Another said “you might want to expand the timeline from 8 weeks to 12 weeks to match a quarter or the first 90 days given how businesses operate...and how much it is to bite off!”

Shorter: But many people also said the opposite: “For a fast moving company, 8 weeks is an eternity. I made it through 3 and then turned back.”

I had one person say they split it up: “FWIW, I have a slightly different approach as I’ve taking on very large roles. What I realize is that it’s simply too much pressure to go from learning to owning in a matter of weeks. So what I do is split idea #1 across four layers in order: (a) process, (b) people, (c) product, (d) strategy. In each case, you signal these four chapters and move through each layer.”

There is clearly a Goldilocks tradeoff here. But in my experience, there is immense pressure to shorten this process, and I much more often see people give up at week 3 than should. So I’ve arrived at 8 as the happy middle.

Particularly tricky onboardings: CPO/CEO, COO/CEO, etc?

There are a few pairings that are particularly tricky. If you were to take pairings and put them on a spectrum, I think you’d find two ends:

High overlap with what the boss is good at / responsible for: E.g. a new CPO working for a product-oriented CEO or a new CMO working for a marketing-centered one.

Low overlap with the boss’s natural skills or tendencies: E.g. a new CFO working for a CEO that hates looking at the financials or a CRO working for a CEO that hates talking to customers.

In my view, both extremes are tricky. Some thoughts:

In the high overlap case: Your goal is to “mind meld” and become an extension of each other. When these partnerships work well, the two people quickly discover that (a) there’s high overlap in how they would approach a problem, (b) the differences are assets, and (c) there is enough trust to talk through any problem. As an example, I’m generally seen as a product-centered leader, and I am lucky to have an amazing product and design leader in

Lane Shackleton⁠

. We’ve worked together long enough to see many problems where we independently come to the same conclusions. But our styles are very different and it allows us to appreciate each other’s approaches, and also to divide and conquer appropriately. We also both have a very direct style and are communicating constantly (not just in 1-1s, but in every communication tool we have). Establishing this level of mind-meld is hard to do but very important.

In the low overlap case: You risk the opposite. The CEO is probably glad to finally have someone take care of this area that they really don’t know well, or worse, don’t care much about. In this case, in addition to your other responsibilities, you also have a burden of educating and empathizing. Spend time helping your boss understand how the job works, what the great people do, etc. Understand what they want in outcomes, even if they don’t understand the mechanics. And from the CEO’s perspective, this requires extra investment since coaching and onboarding may seem difficult. So spend the time to learn, and pull in help as you need it (key advisors who understand that role well, etc).

How should you work with your cross-functional counterparts in this process?

Most of this writeup focuses on either the exec→boss relationship, or the exec→team relationship, and a few people have pointed out that the relationship with cross-functional peers can be just as important. This is definitely true. A few thoughts:

Similar rules apply: Like your new team, they are likely skeptical of you. Sometimes threatened. Take time to learn and build relationships.

Communicate your 8-week plan: Make sure they understand your 8-week plan and how to think about your activities and goals in that period. They are probably waiting on you for something too!

Repeat what you learn back to them: An exec super power is not only learning fast, but summarizing it back better than you heard it. I’ve seen star execs re-summarize topics, draw insightful diagrams (“here’s a drawing of what I think you said”), etc. One of the best ways to show you’re a good listener is to repeat back and see how close you get.

Enlist them in identifying your starter project: They probably have a good pulse on Project A vs B.

What about moving within a company?

One reviewer said “BTW most of this doc is relevant even for someone moving to a new area within a gigantic company, given different subcultures, eng systems and org dynamics to grok.”

100% agreed. In fact, this doc was written while I was still at Google (helping with lots of exec changes) and has gradually adapted when I left.

One note: Many people think that internal transfers can skip a number of the steps here ー they often know a few of the players, have worked in partnership with the team before, etc. I generally encourage people to ignore that presumption. Things tend to be more different than is obvious, and people will still only give a short leash on your learning period. Use it well!

What if you join during a key phase (planning, big decision, etc) ー can you really sit it out?

One person told me “I joined in the midst of semi annual planning to be able to help quickly. In hindsight, that was a mistake as it violates the 8-week plan. You can't not be expected to influence a 6-month or 1-year plan.”

This is a tricky Catch-22. Joining in the middle of processes like these is often the best way to learn. Much of the team is already summarizing what’s happening, what they are worried about, etc and you can witness some impactful discussions. But it’s hard to resist the urge to stay on the edge of the pool. Also keep in mind that if you’re going to onboard for 8 weeks, at most companies, you’re likely to intersect a major milestone (planning, etc) in that process. So this happens more often than not.

My view: This is not an exception. Hold your ground and run the old administration’s plan. Lean on your boss to help figure out what would happen if you weren’t there. Resist the urge to let the pressure prompt you into the driver’s seat before you’re ready.

But wait, I am clearly the {perfect, best, one-and-only, ...}. Does this still still apply to me?

Yes I know, you’re the best. Everyone knows it. There’s a specific problem to be solved and you are the best person in the world to do it. You could probably solve it in an afternoon, why bother with 8 weeks?

I’m sure there are cases like this. Having seen 100s of exec transitions, I think I can say with some certainty: it probably doesn’t apply to you. And also keep in mind, the more true this seems, the higher the expectations are for you. Even more reason to make sure you’re on solid footing ー else you risk another problem, of overpromising, which meets reality very soon.

A huge round of thanks to the following folks for reviewing and contributing to this doc. Their comments have made it immensely better (and any remaining shortfall is entirely my fault!): Ariel Bardin, Aparna Chennapragada, Manik Gupta, Manish Gupta, Oliver Heckmann, Brett Hobbs, Ankit Jain, Diya Jolly, Sriram Krishnan, Kavin Mittal, Lenny Rachitsky, Hosain Rahman, Gokul Rajaram, Peeyush Ranjan, Jonathan Rochelle, Erin Schaefer, Nikhyl Singhal, Tamar Yehoshua

⁠

👉 Next up:
`Designing your 8-week plan`⁠
⁠

⁠

P.S. To see other docs from Shishir, check out

https://coda.io/@shishir⁠

⁠

A few of the 25,000+ teams that 🏃‍♀️ on Coda.

⁠

a77eed08d9f915aabec0346b67a40b7ec93457a9864e51bde1e9239fad175c59624ad1bd252ec5041198bc8e9a52ce31b441ab4767fbb714b9172474278d0b29434f118c46abc5c7a7377f4ad1ea733677ca74d97bc8661e4bbfde8d9cdafabc285f5616.jpeg

⁠

Coda is an all-in-one doc for your team’s unique processes — the rituals that help you succeed. Teams that use Coda get rid of hundreds of documents, spreadsheets, and even bespoke apps, to work quickly and clearly in one place. This template is a Coda doc. Click around to explore.

Find out how to Coda-fy your rituals.

⁠

Connect with a Rituals Architect

⁠