8 ms·

The Guide to Onboarding Software Engineers

220 points by ochronus 5y ago

simonhamp 5y ago
Some really good reminders and pointers in here, especially making sure the new hire is given time - both in terms of allowing them time to get through things but also making sure that their manager and others have time available and set aside to help the newbie. So so critical. One other thing I would say though is to have them feel they can and do make a meaningful contribution right at the start by assigning a little task that will encourage and aid their learning where things are and how things are done
- ochronus 5y ago
  That’s a really good point! Thanks for calling it out
- chiefalchemist 5y ago
  Early and easy milestones are - for me - a standard pattern for any effort. Let ppl loosen up. Touch their toes. Dust off their confidence. Survey the team. Etc. You don't see pro athletes run from the dressing room and start playing. There's a reason for this. One or two simple and easy X or Y goes along way.
deleted 5y ago
[deleted]
Arisaka1 5y ago
I'll never forget the onboarding in my first job. It was almost perfect. Senior developers who knew how to communicate without making me feel like a toddler (in spite of the fact that I was), small tasks that helped both to build confidence and measure my comfort zone. All that on top of the fact that I worked fully remote. But my biggest issue was pairing me in the immediate visinity of another junior developer. Yes, rationally I understood perfectly that people can be different, and that someone may have more knowledge in a language or framework than me. Emotionally all I kept feeling was fear. Being unable to keep up with him, needing more time to complete my assigned tasks, him being more chill/casual with the lead devs while I'm hammered with my negative self-talk telling me that I waste their precious time and they're better off hiring someone else instead. And the worst part: Interpreting their positive feedback as professionalism. "Surely they don't really mean that, just look at me". Eventually I moved out of that team and got into another team where I'm the only junior developer, meaning that it's finally time for my self-talk to accept that I obviously cannot hold a candle compared to everyone else, and I can focus on learning the codebase and improving myself. Now my self-talk thinks that I got soft-booted out of the old team for being unable to keep up with the other junior developer. What I mean is, some problems can be so personal that you cannot help even if you do everything right.
- mattcwilson 5y ago
  Thank you for sharing. That’s helpful perspective for me, as a manager, to consider. One thing I try very hard to do for my new onboarders is to establish trust and open dialogue with them, as quickly as I can, to make it easier for personal concerns to surface. And then listen to those concerns in full sincerity and confidence. Do you think having something like that established would help? If you had any feedback for how your manager may have helped further, what would you tell them?
- jrochkind1 5y ago
  I have to admit I don't love pairing at all as a way of working, but I have to grudgingly admit it has a lot of value -- when pairing a senior and junior, it's the most effective way of knowledge transfer and skill building in the junior. I don't understand why you'd do pair programming with two new hires!
  - wreath 5y ago
    > I don't understand why you'd do pair programming with two new hires! I don't know or think if it's the most effective way but it sure did help me build confidence approaching a large and old codebase with another new hire. I saw I wasn't the only one struggling and we were helping each other out. Maybe I just clicked with the fella, because we ended up having a great work relationship building awesome shit and friendship too. I dunno, maybe it was effective after all.
    - jrochkind1 5y ago
      That does make sense! Really it seems like the best way to do pairing is to switch up who's pairing with who often, not stick people together permanently. Because there are different advantages to different pairings. And an advantage to the act of switching it up itself, of developing common shared knowledge across the whole field.
      - gkop 5y ago
        Oh yea. Does anyone advocate for tied-at-the-yoke pairs other than consulting firms that like the billable hours?
pards 5y ago
Here's a few things that I've found to work well 1. Onboarding docs - this is a working document on our wiki that describes the step-by-step process to getting a new laptop ready for development, including repos, tools, configs etc. Each new joiner is responsible to update the doc as they work through it to clarify unclear items, or add/update/remove out-of-date instructions 2. Onboarding buddy - this person is there to answer any questions related to onboarding, as well as helping the new joiner to navigate the organisation and get to know who's who. I like the idea of regular touchpoints with expected milestones, too. I might try that.
- synergy20 5y ago
  yes, an updated doc with a onboarding buddy is the way to go,been there done that and it worked out well.
throwaway984393 5y ago
What kills me about engineering onboarding is how haphazard it always is. I don't think I've been in a single company where the company has cared about it enough to make sure there was any engineering onboarding process, much less a centrally-managed process. It's always completely team-specific, so some teams have great onboarding and some have none. I just want a company to give a shit about its employees, y'know? It's the little things that make us feel appreciated. (Little things like "somebody telling us how to get work done in this company") It doesn't even have to be formal documentation if there's at least an introductory training that explains it.
- MattGaiser 5y ago
  Given that different teams tend to work on different projects, can onboarding really be scaled across the company like that? Maybe the HR stuff, but your team might maintain a repo all on its own.
  - throwaway984393 5y ago
    I think it's doable. Teams can keep setup instructions with their repos, and commonly repeated docs can be kept in one place and linked to. Each team can create one page that links to all their setup instructions, and each team manager can add their team's page to a single engineering page. Docs that are relevant to the entire engineering org need to be created by someone assigned by an engineering VP. If nobody tells people to do all of that, it doesn't get done.
  - spaetzleesser 5y ago
    I think it’s totally doable. Even if teams work on different projects they most like will follow similar processes, use similar tools and interact with other stakeholders in similar ways. At my company I notice people that even after years don’t really understand how things work or the bigger context of their work. A weeklong introduction into the products of the company, the different roles and common processes would be extremely helpful.
- codr7 5y ago
  Now imagine pulling the same crap upstream, have your boss and his HR hangarounds click through hours of shitty made up or outdated intranet trivia about you and quiz them on it while leaving them hanging on the impact of the answers or the result. At least some aren't even pretending; what really rubs me sideways is when they pay lip service to caring _while_ wasting your time, makes me want to punch someone.
mgaunard 5y ago
The quality of the onboarding is directly influenced by the quality of your processes. New people might struggle during onboarding because they find the processes unpractical. You can try to force them to learn your workflow, or you can listen and use it as an opportunity to improve the way you do things.
- codr7 5y ago
  I've tried to intentionally use my fresh perspective in constructive ways when in that position, but improving the process is unfortunately rarely a corporate goal so it's mostly rowing upstream so far. The way a company reacts to thoughtful observations about their process says a lot about how they view their employees.
quadrifoliate 5y ago
This 13-step, 150-day program that offloads responsibility on the engineer instead of the team that's accepting them is a tired repetition of the trope that makes the onboarding person miserable. The graphics look good on the webpage, but a practical result of this running helter-skelter and trying to check things off the 457-line Google Sheet with mismatched fonts that they have been given. It doesn't work. This means you don't have a process, and are making the new employee (who is happy to have a job, and doesn't want to offend) often work extra hours to compensate for your lack of knowing how to onboard. Here's my alternative 2 cents – actively build in-house software for this. There is a lot of room for what the software can do since it interacts with your systems – it should be, for instance, possible to write a playbook that simulates an interaction with a copy of production data, so you can see real-world use cases that you will be working to address. Construct a set of coherent steps for how your new employees will learn, and enforce those in software.
- mattcwilson 5y ago
  Sounds legit. Do you have a more detailed writeup of how to go about this? Not just from a technical standpoint, but how to campaign with stakeholders that the value is there, that it’s a good use of team time? And how to campaign with the team to buy them in on establishing and maintaining this onboarding software? One of the practical realities I face often in management is that a weak-but-available solution is at least progress, where big ideas without a clear plan suffer heavy inertia.
  - quadrifoliate 5y ago
    No, but it doesn't have to be all or nothing. Some ideas that you could start with: - A repo that builds a toy version of your company's application. New hires have to write tests for some of the components and present a mergeable patch (which is never actually merged). - A set of scripts that verify that the new hire has access to everything they will need. The script should clearly display current access level and what is remaining.
- stjohnswarts 5y ago
  The right way is to have them mentor with someone even if that slows down the mentor (and it will). Don't assign them to a curmudgeon either. If you don't have the "manpower" then just let them have a couple of months to adjust (assuming they're really hired on and not a consultant) and take it all in, they're already stressed and tacking on a thousand (paper cuts) points of improvement is going to make them feel awful.
chihuahua 5y ago
I'm currently having an "interesting" time onboarding at a new job. I got to pick the team after being hired, and yet it's the worst experience of my 24-year career in software development. The manager is the nicest person I've ever worked with. But my "onboarding buddy" is the most obnoxious, difficult person I've ever worked with. At this company, the manager's role is much less technical than what I'm used to, so the manager ends up not making much of a difference in practical terms. I feel like a complete idiot every day. Whenever I ask anyone on the team a question, I get an answer that only makes sense to someone who's been working there for 5 years. Every time I say "I don't understand, can you please explain what that means," I get another answer that assumes I've been working there for 5 years. Last week (after 3 months) I reached the point where I knew it was time to pull the plug and switch to a different team. The company has extremely complicated onboarding tools and timelines, which are filled with over 100 tasks, which are about 99% irrelevant (and non-technical). It's a giant list of things to check off, but it's so overwhelming and complex that it's useless.
- sage76 5y ago
  > I feel like a complete idiot every day. Whenever I ask anyone on the team a question, I get an answer that only makes sense to someone who's been working there for 5 years. Every time I say "I don't understand, can you please explain what that means," I get another answer that assumes I've been working there for 5 years. I've had this experience, especially the part where none of their answers make sense because they include a bunch of jargon specific to the company that I cannot be aware of.
- mattcwilson 5y ago
  This was the onboarding program that we had had and I’m trying to devise a replacement for. Because yeah, it sucked as both an experience and also in terms of effectiveness. What I’m doing now is a weekly series of recorded hands-on/whiteboard sessions, building up from the 10,000 foot view of the software (the most fundamental user journey) and working piece by piece towards the details. And I’m letting the onboarders steer the agenda - they tell me what they’re ready for next, a few days ahead, and I pull the diagrams/exercises/links/docs ahead and then just kinda wing it. It’s more effective, and enjoyable, as far as I can tell. It’s probably not paced as ideally as it could be, but as a manager I have likited time to give to something like this. We’re getting to the point where I think some of the veteran engineers could take slices and host the discussion. And the recordings will hopefully act as an accelerator for the next batch of newbies. I still feel like there’s a lot better a resources and time strapped manager could do.
chiefalchemist 5y ago
I wish more companies understood that their problem with "The Great Resignation" is (often but not always) rooted in (in their shite approach to) onboarding. If you hire open minded, qualified, and "free thinking" people but don't spend the time to get them to believe in your "product" (i.e., organization) then just like any other sane and self-respecting customer, they will look elsewhere. Why? Because they can. And these orgs not realizing most of what they have left is "can'ts"...well the cycle will just continue. Text book insanity.
- weswinham 5y ago
  Yup! Onboarding can't just be tactical items. New folks have valuable perspective on your company and product. Soliciting new ideas from them not only helps the organization fight decay, but it creates more buy-in from the new person.
scarface74 5y ago
I have two recent perspectives about onboarding. 2018 - the company eventually grew to 60 people before getting acquired for 10x revenue. I was the then new CTOs 3rd technical hire and the fifth technical person overall. He was bringing engineering in house. They were using an outsourcing company at first. I onboarded myself, I scheduled a meeting with sales and the product owner and asked them questions as if I were a customer. The CTO gave me a small project and I reached out to people when I had issues. It was much better than getting a brain dump. I learn a lot more by struggling through releasing a feature. On the other hand, my next company was BigTech where there are standard corporate, division, subdivision and team specific onboarding. They were both appropriate for the maturity of the company. But even in the latter case, I learned by struggling through a feature as part of my onboarding.
- spaetzleesser 5y ago
  The problem in my company is that a lot of engineers are extremely reluctant to reach out to anybody. They barely reach out within their team and even less so to sales or marketing. For these people on boarding would be very helpful. And in larger companies it’s definitely useful to get an overview of how decisions are made, how processes work and so on. Otherwise you may work there for years and still not understand how things work outside your little box.
jedinix 5y ago
At my first job out of college, I volunteered to put together a formal training program for new hires. I did so because my onboarding was an unorganized disaster, and I (somewhat naively) thought I could spare future new hires the same experience. A couple of lessons I learned: 1. You need clearly defined processes and documentation. If you can't clearly define your processes, you can't expect a new hire to learn them. And if you have nothing written down anywhere, your new hires are going to be perpetually lost. 2. You need buy-in from the team, especially managers/leads. It takes time to define processes and write documentation. And it takes time to actually onboard and train a new hire. Managers should recognize this and ensure these responsibilities are distributed across the team.
charles_f 5y ago
I really enjoyed the 30/90/150 days matrix oriented in goals. So far I've ever only seen this as a list of activities to be completed, but having it as goals makes it more useful I guess - you can self assess where you are, and adjust if coming the 30 days mark you still feel like you don't understand x y or z
digisign 5y ago
One smaller thing I liked in my career was a job where each new hire was given charge of updating, improving, and editing the "new hire" wiki, which was started by the old hands. It included a brief history of the system, glossary, tutorial, reference links, etc. New hires are expected to ask questions and improve/update it as they go along. Pretty darn useful. Meant most boring, repetitive questions were quickly answered from "cache."
- JohnCClarke 5y ago
  +1 for this! I've always done this with my teams. And the latest hire becomes the "onboarding buddy" for the next, so they know they need to understand/update the documentation. Also, it's really useful to keep a backlog of simple "technical debt" type tasks so that the new starters have something real, but manageable, to work on as soon as they arrive.
  - digisign 5y ago
    More good ideas. These allow the interesting questions to float up naturally for the experienced folks to answer, so they not only tolerate answering, but actually enjoy it.
- a9h74j 5y ago
  Excellent. 1) Takes advantage of "beginners mind." 2) Provides an outlet for notes an ambitious improver-of-things will be taking anyway.
hbarka 5y ago
Unfortunately what has been somewhat consistent for me during onboarding is that my manager did not bother to make sure I have the needed credentials and roles in advance. Days and weeks were wasted where I had to fend for myself, against NIMBYist “owners” of said systems who were more afraid than helpful. You question why you were hired. “You’re a data /*/*? Oh I’m sorry I will just give you read-only access for now.” “You need access to that system to analyze data? I’m sorry but the your mgr has to approve and then security director.” “You’re a senior *?” I’m sorry we require you to be part of the sprint team first before <make up some shit>”. “Oh I should have added you to that <meeting/team folder/JIRA/Repo/DB/Cloud> but first let me give you some hurdles I can think of because you threaten my status.” This is onboarding. Your manager can do a better job getting this taken care of in advance instead of leaving you to slog through. Run if you see this kind of culture.
- mattcwilson 5y ago
  My experience as a manager has been frustratingly similar. For the same security and least-access reasons, I don’t have a view into the systems permissions tables for all of the tools that my team uses. I also don’t have a “definitely complete” list of what those tools even are, or what roles my current team members have in them. So when it comes to presenting IT with a new hire access request, often the best I can do is to say “please copy the access that person Y (another member of my team) has in system Z to a new account for person X” Because of audit regulations, I have to do this on a one-request-per-person-per-system basis. Bulk changes for a group of users, systems, or both are verboten. IMO, it feels like this is another area where no one is incentivized to own a holistic and efficient outcome. It’s not quite laziness, but it is a mountain of tedious and error prone tape cutting, compounded by information changing rapidly underneath in a way opaque to the people closest to the issue. I suspect that this could be a lot better in a world where “default roles and system permissions for those roles” is a centralized and crowd-sourced document. Like a terraform config. And then any time access needs change in a non-one-off way, you could tf apply the new roles table out to all the systems. Such is my dream, anyway
  - bpicolo 5y ago

220 points by ochronus 5y ago

Some really good reminders and pointers in here, especially making sure the new hire is given time - both in terms of allowing them time to get through things but also making sure that their manager and others have time available and set aside to help the newbie. So so critical. One other thing I would say though is to have them feel they can and do make a meaningful contribution right at the start by assigning a little task that will encourage and aid their learning where things are and how things are done

ochronus 5y ago
That’s a really good point! Thanks for calling it out
chiefalchemist 5y ago
Early and easy milestones are - for me - a standard pattern for any effort. Let ppl loosen up. Touch their toes. Dust off their confidence. Survey the team. Etc. You don't see pro athletes run from the dressing room and start playing. There's a reason for this. One or two simple and easy X or Y goes along way.

deleted 5y ago

[deleted]

Arisaka1 5y ago

I'll never forget the onboarding in my first job. It was almost perfect. Senior developers who knew how to communicate without making me feel like a toddler (in spite of the fact that I was), small tasks that helped both to build confidence and measure my comfort zone. All that on top of the fact that I worked fully remote. But my biggest issue was pairing me in the immediate visinity of another junior developer. Yes, rationally I understood perfectly that people can be different, and that someone may have more knowledge in a language or framework than me. Emotionally all I kept feeling was fear. Being unable to keep up with him, needing more time to complete my assigned tasks, him being more chill/casual with the lead devs while I'm hammered with my negative self-talk telling me that I waste their precious time and they're better off hiring someone else instead. And the worst part: Interpreting their positive feedback as professionalism. "Surely they don't really mean that, just look at me". Eventually I moved out of that team and got into another team where I'm the only junior developer, meaning that it's finally time for my self-talk to accept that I obviously cannot hold a candle compared to everyone else, and I can focus on learning the codebase and improving myself. Now my self-talk thinks that I got soft-booted out of the old team for being unable to keep up with the other junior developer. What I mean is, some problems can be so personal that you cannot help even if you do everything right.

mattcwilson 5y ago
Thank you for sharing. That’s helpful perspective for me, as a manager, to consider. One thing I try very hard to do for my new onboarders is to establish trust and open dialogue with them, as quickly as I can, to make it easier for personal concerns to surface. And then listen to those concerns in full sincerity and confidence. Do you think having something like that established would help? If you had any feedback for how your manager may have helped further, what would you tell them?
jrochkind1 5y ago
I have to admit I don't love pairing at all as a way of working, but I have to grudgingly admit it has a lot of value -- when pairing a senior and junior, it's the most effective way of knowledge transfer and skill building in the junior. I don't understand why you'd do pair programming with two new hires!
- wreath 5y ago
  > I don't understand why you'd do pair programming with two new hires! I don't know or think if it's the most effective way but it sure did help me build confidence approaching a large and old codebase with another new hire. I saw I wasn't the only one struggling and we were helping each other out. Maybe I just clicked with the fella, because we ended up having a great work relationship building awesome shit and friendship too. I dunno, maybe it was effective after all.
  - jrochkind1 5y ago
    That does make sense! Really it seems like the best way to do pairing is to switch up who's pairing with who often, not stick people together permanently. Because there are different advantages to different pairings. And an advantage to the act of switching it up itself, of developing common shared knowledge across the whole field.
    - gkop 5y ago
      Oh yea. Does anyone advocate for tied-at-the-yoke pairs other than consulting firms that like the billable hours?

pards 5y ago

Here's a few things that I've found to work well 1. Onboarding docs - this is a working document on our wiki that describes the step-by-step process to getting a new laptop ready for development, including repos, tools, configs etc. Each new joiner is responsible to update the doc as they work through it to clarify unclear items, or add/update/remove out-of-date instructions 2. Onboarding buddy - this person is there to answer any questions related to onboarding, as well as helping the new joiner to navigate the organisation and get to know who's who. I like the idea of regular touchpoints with expected milestones, too. I might try that.

synergy20 5y ago
yes, an updated doc with a onboarding buddy is the way to go,been there done that and it worked out well.

throwaway984393 5y ago

What kills me about engineering onboarding is how haphazard it always is. I don't think I've been in a single company where the company has cared about it enough to make sure there was any engineering onboarding process, much less a centrally-managed process. It's always completely team-specific, so some teams have great onboarding and some have none. I just want a company to give a shit about its employees, y'know? It's the little things that make us feel appreciated. (Little things like "somebody telling us how to get work done in this company") It doesn't even have to be formal documentation if there's at least an introductory training that explains it.

MattGaiser 5y ago
Given that different teams tend to work on different projects, can onboarding really be scaled across the company like that? Maybe the HR stuff, but your team might maintain a repo all on its own.
- throwaway984393 5y ago
  I think it's doable. Teams can keep setup instructions with their repos, and commonly repeated docs can be kept in one place and linked to. Each team can create one page that links to all their setup instructions, and each team manager can add their team's page to a single engineering page. Docs that are relevant to the entire engineering org need to be created by someone assigned by an engineering VP. If nobody tells people to do all of that, it doesn't get done.
- spaetzleesser 5y ago
  I think it’s totally doable. Even if teams work on different projects they most like will follow similar processes, use similar tools and interact with other stakeholders in similar ways. At my company I notice people that even after years don’t really understand how things work or the bigger context of their work. A weeklong introduction into the products of the company, the different roles and common processes would be extremely helpful.
codr7 5y ago
Now imagine pulling the same crap upstream, have your boss and his HR hangarounds click through hours of shitty made up or outdated intranet trivia about you and quiz them on it while leaving them hanging on the impact of the answers or the result. At least some aren't even pretending; what really rubs me sideways is when they pay lip service to caring _while_ wasting your time, makes me want to punch someone.

mgaunard 5y ago

The quality of the onboarding is directly influenced by the quality of your processes. New people might struggle during onboarding because they find the processes unpractical. You can try to force them to learn your workflow, or you can listen and use it as an opportunity to improve the way you do things.

codr7 5y ago
I've tried to intentionally use my fresh perspective in constructive ways when in that position, but improving the process is unfortunately rarely a corporate goal so it's mostly rowing upstream so far. The way a company reacts to thoughtful observations about their process says a lot about how they view their employees.

quadrifoliate 5y ago

This 13-step, 150-day program that offloads responsibility on the engineer instead of the team that's accepting them is a tired repetition of the trope that makes the onboarding person miserable. The graphics look good on the webpage, but a practical result of this running helter-skelter and trying to check things off the 457-line Google Sheet with mismatched fonts that they have been given. It doesn't work. This means you don't have a process, and are making the new employee (who is happy to have a job, and doesn't want to offend) often work extra hours to compensate for your lack of knowing how to onboard. Here's my alternative 2 cents – actively build in-house software for this. There is a lot of room for what the software can do since it interacts with your systems – it should be, for instance, possible to write a playbook that simulates an interaction with a copy of production data, so you can see real-world use cases that you will be working to address. Construct a set of coherent steps for how your new employees will learn, and enforce those in software.

mattcwilson 5y ago
Sounds legit. Do you have a more detailed writeup of how to go about this? Not just from a technical standpoint, but how to campaign with stakeholders that the value is there, that it’s a good use of team time? And how to campaign with the team to buy them in on establishing and maintaining this onboarding software? One of the practical realities I face often in management is that a weak-but-available solution is at least progress, where big ideas without a clear plan suffer heavy inertia.
- quadrifoliate 5y ago
  No, but it doesn't have to be all or nothing. Some ideas that you could start with: - A repo that builds a toy version of your company's application. New hires have to write tests for some of the components and present a mergeable patch (which is never actually merged). - A set of scripts that verify that the new hire has access to everything they will need. The script should clearly display current access level and what is remaining.
stjohnswarts 5y ago
The right way is to have them mentor with someone even if that slows down the mentor (and it will). Don't assign them to a curmudgeon either. If you don't have the "manpower" then just let them have a couple of months to adjust (assuming they're really hired on and not a consultant) and take it all in, they're already stressed and tacking on a thousand (paper cuts) points of improvement is going to make them feel awful.

chihuahua 5y ago

I'm currently having an "interesting" time onboarding at a new job. I got to pick the team after being hired, and yet it's the worst experience of my 24-year career in software development. The manager is the nicest person I've ever worked with. But my "onboarding buddy" is the most obnoxious, difficult person I've ever worked with. At this company, the manager's role is much less technical than what I'm used to, so the manager ends up not making much of a difference in practical terms. I feel like a complete idiot every day. Whenever I ask anyone on the team a question, I get an answer that only makes sense to someone who's been working there for 5 years. Every time I say "I don't understand, can you please explain what that means," I get another answer that assumes I've been working there for 5 years. Last week (after 3 months) I reached the point where I knew it was time to pull the plug and switch to a different team. The company has extremely complicated onboarding tools and timelines, which are filled with over 100 tasks, which are about 99% irrelevant (and non-technical). It's a giant list of things to check off, but it's so overwhelming and complex that it's useless.

sage76 5y ago
> I feel like a complete idiot every day. Whenever I ask anyone on the team a question, I get an answer that only makes sense to someone who's been working there for 5 years. Every time I say "I don't understand, can you please explain what that means," I get another answer that assumes I've been working there for 5 years. I've had this experience, especially the part where none of their answers make sense because they include a bunch of jargon specific to the company that I cannot be aware of.
mattcwilson 5y ago
This was the onboarding program that we had had and I’m trying to devise a replacement for. Because yeah, it sucked as both an experience and also in terms of effectiveness. What I’m doing now is a weekly series of recorded hands-on/whiteboard sessions, building up from the 10,000 foot view of the software (the most fundamental user journey) and working piece by piece towards the details. And I’m letting the onboarders steer the agenda - they tell me what they’re ready for next, a few days ahead, and I pull the diagrams/exercises/links/docs ahead and then just kinda wing it. It’s more effective, and enjoyable, as far as I can tell. It’s probably not paced as ideally as it could be, but as a manager I have likited time to give to something like this. We’re getting to the point where I think some of the veteran engineers could take slices and host the discussion. And the recordings will hopefully act as an accelerator for the next batch of newbies. I still feel like there’s a lot better a resources and time strapped manager could do.

chiefalchemist 5y ago

I wish more companies understood that their problem with "The Great Resignation" is (often but not always) rooted in (in their shite approach to) onboarding. If you hire open minded, qualified, and "free thinking" people but don't spend the time to get them to believe in your "product" (i.e., organization) then just like any other sane and self-respecting customer, they will look elsewhere. Why? Because they can. And these orgs not realizing most of what they have left is "can'ts"...well the cycle will just continue. Text book insanity.

weswinham 5y ago
Yup! Onboarding can't just be tactical items. New folks have valuable perspective on your company and product. Soliciting new ideas from them not only helps the organization fight decay, but it creates more buy-in from the new person.

scarface74 5y ago

I have two recent perspectives about onboarding. 2018 - the company eventually grew to 60 people before getting acquired for 10x revenue. I was the then new CTOs 3rd technical hire and the fifth technical person overall. He was bringing engineering in house. They were using an outsourcing company at first. I onboarded myself, I scheduled a meeting with sales and the product owner and asked them questions as if I were a customer. The CTO gave me a small project and I reached out to people when I had issues. It was much better than getting a brain dump. I learn a lot more by struggling through releasing a feature. On the other hand, my next company was BigTech where there are standard corporate, division, subdivision and team specific onboarding. They were both appropriate for the maturity of the company. But even in the latter case, I learned by struggling through a feature as part of my onboarding.

spaetzleesser 5y ago
The problem in my company is that a lot of engineers are extremely reluctant to reach out to anybody. They barely reach out within their team and even less so to sales or marketing. For these people on boarding would be very helpful. And in larger companies it’s definitely useful to get an overview of how decisions are made, how processes work and so on. Otherwise you may work there for years and still not understand how things work outside your little box.

jedinix 5y ago

At my first job out of college, I volunteered to put together a formal training program for new hires. I did so because my onboarding was an unorganized disaster, and I (somewhat naively) thought I could spare future new hires the same experience. A couple of lessons I learned: 1. You need clearly defined processes and documentation. If you can't clearly define your processes, you can't expect a new hire to learn them. And if you have nothing written down anywhere, your new hires are going to be perpetually lost. 2. You need buy-in from the team, especially managers/leads. It takes time to define processes and write documentation. And it takes time to actually onboard and train a new hire. Managers should recognize this and ensure these responsibilities are distributed across the team.

charles_f 5y ago

I really enjoyed the 30/90/150 days matrix oriented in goals. So far I've ever only seen this as a list of activities to be completed, but having it as goals makes it more useful I guess - you can self assess where you are, and adjust if coming the 30 days mark you still feel like you don't understand x y or z

digisign 5y ago

One smaller thing I liked in my career was a job where each new hire was given charge of updating, improving, and editing the "new hire" wiki, which was started by the old hands. It included a brief history of the system, glossary, tutorial, reference links, etc. New hires are expected to ask questions and improve/update it as they go along. Pretty darn useful. Meant most boring, repetitive questions were quickly answered from "cache."

JohnCClarke 5y ago
+1 for this! I've always done this with my teams. And the latest hire becomes the "onboarding buddy" for the next, so they know they need to understand/update the documentation. Also, it's really useful to keep a backlog of simple "technical debt" type tasks so that the new starters have something real, but manageable, to work on as soon as they arrive.
- digisign 5y ago
  More good ideas. These allow the interesting questions to float up naturally for the experienced folks to answer, so they not only tolerate answering, but actually enjoy it.
a9h74j 5y ago
Excellent. 1) Takes advantage of "beginners mind." 2) Provides an outlet for notes an ambitious improver-of-things will be taking anyway.

hbarka 5y ago

Unfortunately what has been somewhat consistent for me during onboarding is that my manager did not bother to make sure I have the needed credentials and roles in advance. Days and weeks were wasted where I had to fend for myself, against NIMBYist “owners” of said systems who were more afraid than helpful. You question why you were hired. “You’re a data /*/*? Oh I’m sorry I will just give you read-only access for now.” “You need access to that system to analyze data? I’m sorry but the your mgr has to approve and then security director.” “You’re a senior *?” I’m sorry we require you to be part of the sprint team first before <make up some shit>”. “Oh I should have added you to that <meeting/team folder/JIRA/Repo/DB/Cloud> but first let me give you some hurdles I can think of because you threaten my status.” This is onboarding. Your manager can do a better job getting this taken care of in advance instead of leaving you to slog through. Run if you see this kind of culture.

mattcwilson 5y ago
My experience as a manager has been frustratingly similar. For the same security and least-access reasons, I don’t have a view into the systems permissions tables for all of the tools that my team uses. I also don’t have a “definitely complete” list of what those tools even are, or what roles my current team members have in them. So when it comes to presenting IT with a new hire access request, often the best I can do is to say “please copy the access that person Y (another member of my team) has in system Z to a new account for person X” Because of audit regulations, I have to do this on a one-request-per-person-per-system basis. Bulk changes for a group of users, systems, or both are verboten. IMO, it feels like this is another area where no one is incentivized to own a holistic and efficient outcome. It’s not quite laziness, but it is a mountain of tedious and error prone tape cutting, compounded by information changing rapidly underneath in a way opaque to the people closest to the issue. I suspect that this could be a lot better in a world where “default roles and system permissions for those roles” is a centralized and crowd-sourced document. Like a terraform config. And then any time access needs change in a non-one-off way, you could tf apply the new roles table out to all the systems. Such is my dream, anyway
- bpicolo 5y ago