What I wish I knew about onboarding
eugeneyan.com
eugeneyan.com
* 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).
* Record first impressions / friction log as I go. Beginner's mind has real value!
* Meet & greet everyone on my immediate team (~20 people) for 30 mins. More focused on work stuff.
* Also meet & greet people in the wider org (~10 people) for 15 mins. This meeting is less focused on work stuff. I'm approaching it with the mindset that it's plain nice to meet new people. But I'm sure the "rapport building" will also make work easier eventually.
* Talk w/ manager and skip manager about medium/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 "easy wins"). Second level is medium-term with substantial complexity (these will take lots of meetings and research to find the right problem/solution to work on). Third level are stretch projects that will eventually get you promoted (if that's what you want).
* All the mandatory corp onboarding stuff. Benefits, mandatory training, etc. Just block out focus time and get it done.
* We don't have an onboarding guide for our immediate team so I'm creating one as I go. Will be a nice way to connect with any new teammates after me.
Of course where I've worked the firing threats start on day 1, and they obviously expected (Unholster for one) that I work at home. Those guys wanted the whole install to be done at the end of day 1.
A 100 day personal "plan" sounds good from a management point of view. But if you have to frequently revisit that plan and change it over and over, it's perhaps better to reconsider your time scales.
I'm sure there's some elite workplaces which are run like well-oiled machines, where the word "onboarding" means something and where people actually care how newcomers integrate. But far more common is a chaotic environment, not just when there's "fast growth" but also garden variety "Dilbert-ian" 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 "a plan"-- like 2 weeks at a time until the place starts to make sense and you know where the cliffs and sharp edges are.
If your goal is to become the "documentation master" 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.
If your goal is to elevate your career or get promoted, focus on building relationships and look for a project to take on.
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.
Whatever your goal is, you can easily invest tons of work and passion into it. You don't have to follow one "way" 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.
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/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.
Expecting the newest member to update the docs seems to be pretty common but has always struck me as pathological. The person with the worst understanding and least perspective is the one who's expected to teach it to others.
In my mind this is just an extension of good software engineering practices: if your system has a bug or error which requires development time to fix you should find and fix the root cause of the error. Similarly if you are onboarding and you are blocked by undocumented processes you should go out of your way to find out the root cause of the issue and fix it for future developers.
I strongly agree with this point. The people I'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.
Most "obvious" problems a new hire notices fall into one of two buckets:
1. Tech debt that everyone knows is less than ideal, but hasn't been a priority to change.
2. Related to some subtle or complicated issue that causes the unusual implementation to actually makes sense.
The first few sentences say something to the effect of "All problems are people problems; some masquerade as technical problems. Successful transitions embed themselves in the social fabric of their new position and figure out what those people problems are."
He talks about common traps when starting in a new role:
- “Sticking with what you know.” -- when all you got is a hammer..
- “Falling prey to the action imperative” -- in my case it's sometimes coding before I actually understand the problem
- “Setting !unrealistic expectations!. You don’t negotiate your mandate or establish clear, achievable objectives.”
- “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
He then moves on to identifying company culture, learning the internals, establishing relationships and securing early wins to show your worth
It's a useful model if you need a template for when you join a new company.
This is especially important since a lot of SWE can talk through what a solid system should look like etc but have no idea how to put that in practice with the constraints of real life. The above is a good "rite of passage" to weed out those who only do the talking.
[1] The company I work for got bought out. And the new owners are "taking charge."
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'm not the most planning-oriented person in general, but even for people who are, I find it'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've yet to be in a position where I both have enough power to be sure I can stick to a plan I've made for 100 days in the future and have enough certainty in what's going to happen on that timescale for it to be relevant.
Really, if you don't do some basic prep to take someone on beforehand, you are going to be wasting a shedload of money.
Still though, my absolute favorite was the quasi-government project requiring very costly and involved background checks for us to even be on the project, in which all of us would be working from home and where we had to work through two layers of people in order to do anything. As in, I had to talk to someone, who could talk to someone, who theoretically were blessed enough to put their hands on the keyboard, somewhere. It was 6 months of the most ridiculous meetings I've ever experienced, and then they were mad that we hadn't done anything. :-(
And then in another gig, I got sent to Boulder Co, via Denver for something like a three hour meetining, which once again resolved nothing, though this time I was in the back of the plane. I liked seeing the Rockies, but really...
Perhaps Covid has made things better now, at least with such idiocy as this?