Skip to content

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

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
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.

Image result for skeptical woman

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.

Image result for chart going down

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
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
). 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
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
, 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
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
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.


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”?
So what should the CEO be doing to support this process?
Is 8 weeks the right timeframe?
Particularly tricky onboardings: CPO/CEO, COO/CEO, etc?
How should you work with your cross-functional counterparts in this process?
What about moving within a company?
What if you join during a key phase (planning, big decision, etc) ー can you really sit it out?
But wait, I am clearly the {perfect, best, one-and-only, ...}. Does this still still apply to me?

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:

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

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

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

Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
) instead.