What I wish I knew about onboarding(eugeneyan.com)
eugeneyan.com
What I wish I knew about onboarding
https://eugeneyan.com/writing/onboarding/
13 comments
Did your boss try to get you to read things on your own time? If the work requires reading something, it has to pay me to read it. If it's my own time, for my own benefit, reading for free, flat-out cannot read anything other than the Bible, which I haven't finished. And if your boss doesn't like it he can literally go to hell. Which is both more and less metaphorical than is widely believed.
Nope, I am not expected to read work stuff outside of working hours.
During the first 2 to 6 weeks on a job (it probably varies more than this) most corporate US environments expect significant amount of time to go to processing/onboarding. When providing status updates in meetings just state as much, usually with little to no specifics. I've yet to see anyone respond at all within the first month. What's remarkable to me is the amount of overhead/cost associated with these institutional mechanics, despite tools like Workday, which frankly I don't see as actually being effective. Staff counts of 2 and more (in addition to the new person) with these tools still can't manage to communicate with new staff where to go, where to send equipment, etc which reveals a significant need in the market.
Yeah a Stanford professor told me you need 6 months to be productive in a coder job. 3 months, others have said. To pull your weight, and then pull more than your weight.
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.
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.
When I onboard someone I fully expect them to spend a good chunk of their first days / few weeks reading and not being tremendously productive - absolutely within working hours.
This comment is terrific even though I'm not sure I quite agree with the sentiment. Upvoted.
[deleted]
As Mike Tyson says: "Everybody has a plan until they get punched in the mouth!"
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.
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.
You don't have to have plans or strategies for onboarding if you have a goal in mind. Set a goal for yourself, or a purpose. "I'm going to do X". Then consider the proactive actions that will help you accomplish it.
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.
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.
One of the most valuable things you can do during onboarding is update/write documentation.
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.
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.
> Many places have out of date documentation — you should correct or update that information as you go through your first few months.
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.
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.
A lot of documentation is rote. For example new hires usually follow a “getting your dev environment setup” guide which can have small errors or issues. Simply updating the guide to reflect new undocumented processes is a simple thing that brings value and does not require in depth experience.
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.
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.
But the person with the most "beginner's mind".
> Don’t be too quick to judge and make changes!
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.
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.
Often tech debt stems from political and cultural issues that cannot be (easily) fixed. And even when that's not the issue, are obviously non-trivial costs to resolve. It's been hard for me personally to realize how cultural, even religious Silicon Valley and technology work is. I tend to think there's a common appreciation for certain values, openness and transparency in execution, and these are not the case.
If you're joining an established team you should consider yourself a cultural anthropologist, and seek to understand the human-related aspects of why things are the way you observe. You have not yet earned the legitimacy to have your big, disruptive changes considered, and once you do understand how we got where we are you'll have likely modified & tempered your original positions.
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.
Did you delete your HBR link? It was interesting: https://hbr.org/2021/11/how-to-succeed-quickly-in-a-new-role
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."
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."
Glad it was interesting! I’d realized the part referenced was a while in, so wasn’t sure if anyone would want to read that far to get to it.
I like "The first 90 days" 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'd work for anyone if you consider yourself a "team of one".
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.
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.
There's a very delicate balance when dealing with "Resist the urge to change things," 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's incredibly easy to get calcified in our ways if people wait too long after entering to suggest changes since that "fresh" perspective is gone.
IMO you should gain trust of your new colleagues before you start changing things. At the very LEAST, understand the reasoning and circumstances that resulted in the status quo. Many times I see people come with an attitude towards status quo and get distracted by trying to change things too soon and too quickly that you see them stumble and have a poor onboarding experience.
Understand the system and the organization for a while, ship features and fix bugs (or whatever else) with the current setup, then everyone else will trust your judgement when you make suggestions because you have skin in the game now.
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.
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.
I wish. In my situation, it's new management that is onboarding [1] and they have changed how we do things in my department, for the worse.
[1] The company I work for got bought out. And the new owners are "taking charge."
[1] The company I work for got bought out. And the new owners are "taking charge."
Half of this advice strikes me as great: Get to know the people you'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
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.
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.
My own low-point onboarding experience (as a contractor) was when I was expected to use the top of a photocopier as a desk.
Really, if you don't do some basic prep to take someone on beforehand, you are going to be wasting a shedload of money.
Really, if you don't do some basic prep to take someone on beforehand, you are going to be wasting a shedload of money.
Man, if I had even a tiny % of the dollars I saw companies waste on things like this when I rolled in as a consultant, I'd be retired on my personal island. Some of my favorites were when they would demand I fly to some office at the last minute, only to discover that the people I needed to work with were located in some other part of the country, where I would basically twiddle my thumbs for weeks waiting for some access to something or some piece of information, for the supposedly most high profile thing in the entire company that was supposedly costing them huge $$ for every minute we sat around.
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. :-(
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. :-(
Yes, tell me about it. I once got sent from London UK to Newark NJ to attend a one hour meeting in Princeton NJ and then got flown back (to be fair, all Virgin First (Upper) class). The senior accountancy partner I was there to support went on Concorde. Anyway, it must have cost god knows how many thousands of GBP, and didn't resolve 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?
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?
I remember being put in the furthest building used for storage as a consultant one time. They forgot I was there!
Nice!
I'm in talks to start a new role, this was a super helpful read.
Shameless plug: https://leadership.garden/onboarding-engineers/
I am the only one who thinks `onboarding' sounds like a method of torture? What is wrong with `orientation', `initiation' or `indoctrination'?
Onboarding is the very first time you realize you made a mistake.
* 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.