What I wish I knew about onboarding

I started a new role 2 weeks ago. My general strategy:<p>* Read all the things. For me as a technical writer that means reading most if not all the docs on our documentation website. Also means org strategy docs. Also means doing a lot of tinkering (try out the code samples etc).<p>* Record first impressions &#x2F; friction log as I go. Beginner&#x27;s mind has real value!<p>* Meet &amp; greet everyone on my immediate team (~20 people) for 30 mins. More focused on work stuff.<p>* Also meet &amp; greet people in the wider org (~10 people) for 15 mins. This meeting is less focused on work stuff. I&#x27;m approaching it with the mindset that it&#x27;s plain nice to meet new people. But I&#x27;m sure the &quot;rapport building&quot; will also make work easier eventually.<p>* Talk w&#x2F; manager and skip manager about medium&#x2F;long-term projects and eventually get written confirmation via email. My manager has a very helpful framework where you think of 3 levels of projects. First level is immediate value (what the post calls &quot;easy wins&quot;). Second level is medium-term with substantial complexity (these will take lots of meetings and research to find the right problem&#x2F;solution to work on). Third level are stretch projects that will eventually get you promoted (if that&#x27;s what you want).<p>* All the mandatory corp onboarding stuff. Benefits, mandatory training, etc. Just block out focus time and get it done.<p>* We don&#x27;t have an onboarding guide for our immediate team so I&#x27;m creating one as I go. Will be a nice way to connect with any new teammates after me.

As Mike Tyson says: &quot;Everybody has a plan until they get punched in the mouth!&quot;<p>A 100 day personal &quot;plan&quot; sounds good from a management point of view. But if you have to frequently revisit that plan and change it over and over, it&#x27;s perhaps better to reconsider your time scales.<p>I&#x27;m sure there&#x27;s some elite workplaces which are run like well-oiled machines, where the word &quot;onboarding&quot; means something and where people actually care how newcomers integrate. But far more common is a chaotic environment, not just when there&#x27;s &quot;fast growth&quot; but also garden variety &quot;Dilbert-ian&quot; dysfunction or outright toxicity and non-cooperation. In these more common situations I think a much greater emphasis on relationship building works better and MUCH shorter time scales for &quot;a plan&quot;-- like 2 weeks at a time until the place starts to make sense and you know where the cliffs and sharp edges are.

You don&#x27;t have to have plans or strategies for onboarding if you have a goal in mind. Set a goal for yourself, or a purpose. &quot;I&#x27;m going to do X&quot;. Then consider the proactive actions that will help you accomplish it.<p>If your goal is to become the &quot;documentation master&quot; and revamp all the docs, then you can begin building your own scaffolding of docs as you onboard, noting where there are gaps, building a mini knowledge base.<p>If your goal is to elevate your career or get promoted, focus on building relationships and look for a project to take on.<p>If your goal is just to write really good code, then dig into the history of the code, what other parts of the system it connects to, whether there are enough tests, places where you can revamp code without it blocking people or causing issues.<p>Whatever your goal is, you can easily invest tons of work and passion into it. You don&#x27;t have to follow one &quot;way&quot; or do one specific set of steps. But you should be tailoring what you do to meet the goal you set for yourself, or you may end up wasting your own time.

One of the most valuable things you can do during onboarding is update&#x2F;write documentation.<p>Many places have out of date documentation — you should correct or update that information as you go through your first few months. This generates real value for the company&#x2F;team and helps solidify your understanding of how things work. You can also form useful contacts since you may need to seek out the institutional knowledge from senior employees in order to form this documentation.

&gt; Don’t be too quick to judge and make changes!<p>I strongly agree with this point. The people I&#x27;ve worked with who spent their first few days making proclomations about major changes that should be made all turned out to be bad coworkers.<p>Most &quot;obvious&quot; problems a new hire notices fall into one of two buckets:<p>1. Tech debt that everyone knows is less than ideal, but hasn&#x27;t been a priority to change.<p>2. Related to some subtle or complicated issue that causes the unusual implementation to actually makes sense.

I think this is overall very accurate and owning one’s own onboarding is a productive framing. For the content of the introductory meetings, beyond a beginner’s mindset, I’ve found the idea of ‘generating pull’ useful. If you’re looking for specific places where mutual wins can happen (and have some flexibility on what you’re working on), your new colleagues will be a lot more invested in working together, and you’ll probably get up at speed a lot faster.

I like &quot;The first 90 days&quot; by Michael Watkins. It lays out an onboarding strategy that makes sense, with concrete steps. I initially thought that it targets management only, but it&#x27;d work for anyone if you consider yourself a &quot;team of one&quot;.<p>He talks about common traps when starting in a new role:<p>- “Sticking with what you know.” -- when all you got is a hammer..<p>- “Falling prey to the action imperative” -- in my case it&#x27;s sometimes coding before I actually understand the problem<p>- “Setting !unrealistic expectations!. You don’t negotiate your mandate or establish clear, achievable objectives.”<p>- “Coming in with “the” answer. You come in with your mind made up, or you reach conclusions too quickly about “the” problems and “the” solutions. You alienate people who could help you understand what’s going on, and you squander opportunities to develop support for good solutions<p>He then moves on to identifying company culture, learning the internals, establishing relationships and securing early wins to show your worth<p>It&#x27;s a useful model if you need a template for when you join a new company.

There&#x27;s a very delicate balance when dealing with &quot;Resist the urge to change things,&quot; from both sides. As an old-timer, I sometimes find it annoying when new co-workers try to change stuff because they are not used to our stuff. But, on the other hand, it&#x27;s incredibly easy to get calcified in our ways if people wait too long after entering to suggest changes since that &quot;fresh&quot; perspective is gone.

Half of this advice strikes me as great: Get to know the people you&#x27;re working with, and not just your boss. Try to figure out how things work here rather than flailing around trying to make an impact right away<p>However, I think trying to plan 100 days ahead is not helpful for everyone. Especially in a smaller org, it is likely impossible to plan that far ahead usefully right out the gate. I&#x27;m not the most planning-oriented person in general, but even for people who are, I find it&#x27;s often a huge mistake to make a plan right away, as you are spending time and effort to fix your expectations based on dubious or little information. Maybe in a big, established shop where there are already clear expectations about your contribution even a year in, this advice holds up. I&#x27;ve yet to be in a position where I both have enough power to be sure I can stick to a plan I&#x27;ve made for 100 days in the future and have enough certainty in what&#x27;s going to happen on that timescale for it to be relevant.

My own low-point onboarding experience (as a contractor) was when I was expected to use the top of a photocopier as a desk.<p>Really, if you don&#x27;t do some basic prep to take someone on beforehand, you are going to be wasting a shedload of money.

Nice! I&#x27;m in talks to start a new role, this was a super helpful read.

Shameless plug: <a href="https:&#x2F;&#x2F;leadership.garden&#x2F;onboarding-engineers&#x2F;" rel="nofollow">https:&#x2F;&#x2F;leadership.garden&#x2F;onboarding-engineers&#x2F;</a>

I am the only one who thinks `onboarding&#x27; sounds like a method of torture? What is wrong with `orientation&#x27;, `initiation&#x27; or `indoctrination&#x27;?