The Guide to Onboarding Software Engineers(leadership.garden)
leadership.garden
The Guide to Onboarding Software Engineers
https://leadership.garden/onboarding-engineers/
53 comments
These kinds of negative thoughts are never helpful. We're all learning constantly and had to be the newbie at one time. Push them out of your mind.
I will let you in on one superpower that I was lucky to learn early... read the manuals, yes the manuals to your most important tools and practice. All of them, front to back. Very few people are willing to do this for whatever reason. Result being even if you don't know how to do something exactly you'll be able to look it up in seconds and knock it out in minutes.
Using this strategy, at one job I went from nobody to "god-like" (haha) guru-in-demand simply from reading the manual front-to-back for the Unix Shell we used... in the span of about two months. The resulting scripts I wrote automated about 50% of our team's work to single commands, which was greatly appreciated.
I will let you in on one superpower that I was lucky to learn early... read the manuals, yes the manuals to your most important tools and practice. All of them, front to back. Very few people are willing to do this for whatever reason. Result being even if you don't know how to do something exactly you'll be able to look it up in seconds and knock it out in minutes.
Using this strategy, at one job I went from nobody to "god-like" (haha) guru-in-demand simply from reading the manual front-to-back for the Unix Shell we used... in the span of about two months. The resulting scripts I wrote automated about 50% of our team's work to single commands, which was greatly appreciated.
This! Reading in general manifests to others as if you have superpowers at times. Whitepapers, RFCs, manuals, API docs, regulations, devour them all and the doors will open so fast it will make your head spin. General advice to all, don't get bogged down thinking you need to memorize every algorithm and data structure to be a great programmer. It's more about understanding the domain you work in and knowing how to "stand on the shoulders of giants" within that domain.
Another thing about reading "everything" ... You can a) have solutions ready before other people know they have a problem; and b) in part from that, get a reputation for knowing "everything".
Never say never.
Thoughts like that are like pain. They are wonderful signals that something is wrong. Something needs to change. That doesn't mean we should seek out pain, just that it's a signal we should pay attention to.
And ignoring pain or "negative thoughts" is likely quite harmful behavior. You'll train yourself not to notice valuable signals when they happen.
Thoughts like that are like pain. They are wonderful signals that something is wrong. Something needs to change. That doesn't mean we should seek out pain, just that it's a signal we should pay attention to.
And ignoring pain or "negative thoughts" is likely quite harmful behavior. You'll train yourself not to notice valuable signals when they happen.
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!
I don't understand why you'd do pair programming with two new hires!
> 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.
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.
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.
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.
Oh yea. Does anyone advocate for tied-at-the-yoke pairs other than consulting firms that like the billable hours?
> I don't understand why you'd do pair programming with two new hires!
There's nothing wrong with two new hires pairing. A few things a pair could be doing while the other is writing code:
1. Spike out a refactor of the current viewable block of code that the other pair just wrote or is currently writing. Looking at it as a spike instead of a hard refactor allows a pair partner to experiment and if the spike doesn't result in something better, throw it away; no harm done.
2. Jump ahead and spike out a function that the pair might need soon, but isn't ready to consume yet.
3. Watch for pair getting stuck and help them think. Ask questions like ... are you stuck or just taking a mental break? That's a helpful question because it makes them more comfortable taking mental breaks when they need one without fear that you're judging them.
Keep in mind, pairing is AMAZING when deployed with empathy and less judgement. For those that feel like they are being judged when pairing is likely because you are a bit judgmental when the shoe is on the other foot.
FYI, teams that pair daily, get more done and team members feel less lonely and more like a real team. Go Warriors.
There's nothing wrong with two new hires pairing. A few things a pair could be doing while the other is writing code:
1. Spike out a refactor of the current viewable block of code that the other pair just wrote or is currently writing. Looking at it as a spike instead of a hard refactor allows a pair partner to experiment and if the spike doesn't result in something better, throw it away; no harm done.
2. Jump ahead and spike out a function that the pair might need soon, but isn't ready to consume yet.
3. Watch for pair getting stuck and help them think. Ask questions like ... are you stuck or just taking a mental break? That's a helpful question because it makes them more comfortable taking mental breaks when they need one without fear that you're judging them.
Keep in mind, pairing is AMAZING when deployed with empathy and less judgement. For those that feel like they are being judged when pairing is likely because you are a bit judgmental when the shoe is on the other foot.
FYI, teams that pair daily, get more done and team members feel less lonely and more like a real team. Go Warriors.
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?
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?
In my first dev job I was hired as 1 in a pair of jrs to start at the same time on the same team. We never got along. After about a year I was promoted and the other person was let go for performance reasons.
I never really put myself in the other jr’s shoes so thanks for sharing your story. At the time I was pretty intimidated by her and all the other engineers, I can only assume it was much worse for her.
In retrospect it was obviously a bad idea to hire 2 jrs at once. It was a small company (~10 engineers) and we were their first jr hires. I think the company thought that it would foster camaraderie and a little healthy competition, but I think most jrs have too much impostor syndrome for that to work out.
On a side note I think they did have a good onboarding program for new developers. Outside of normal jr level tasks it was roughly 50% technical support: talking to customers, collecting bug reports, reproing bugs, then finding the right engineer to fix them. Over time I started diving into the code myself to see if I could find what was breaking, then eventually putting up fixes myself. It was a good way to contribute real value to the company while learning how a codebase works.
I never really put myself in the other jr’s shoes so thanks for sharing your story. At the time I was pretty intimidated by her and all the other engineers, I can only assume it was much worse for her.
In retrospect it was obviously a bad idea to hire 2 jrs at once. It was a small company (~10 engineers) and we were their first jr hires. I think the company thought that it would foster camaraderie and a little healthy competition, but I think most jrs have too much impostor syndrome for that to work out.
On a side note I think they did have a good onboarding program for new developers. Outside of normal jr level tasks it was roughly 50% technical support: talking to customers, collecting bug reports, reproing bugs, then finding the right engineer to fix them. Over time I started diving into the code myself to see if I could find what was breaking, then eventually putting up fixes myself. It was a good way to contribute real value to the company while learning how a codebase works.
I have such mixed feelings about healthy competition in this context. I really enjoy it. If I do something a little more performant, or a little faster, I feel good. If I don't, I legitimately look forward to learning what I could have done better (sometimes it's just "be faster" and there's not much you can do in that respect). But honestly I think I'm in the minority in that aspect. I enjoy doing LeetCode even though I'm not particularly good at it (50/50 shot at solving a medium on the first couple tries, at best). But I know a lot of people who are great developers that would crack if they thought they were constantly being compared to someone else, and these are people with the benefit of a decade+ of experience.
[deleted]
Impostor-syndrome is very very normal (I'm 20+ years in the industry and still have it), so rest assured you're not alone. What's most important is that despite negative self-talk you're able to learn the ropes at the pace expected by your team lead and manager.
You don't know what that other Junior Engineer's story and history is. They might not be as Junior as they appear. I've hired "junior engineers" who have been programming since they were 8 years old. Even star engineers will often be overtaken by an even hotter burning, faster shooting star engineer. It's the nature of the industry that you will eventually work with what appear to be savants. There is room in the industry for mere mortals.
Regarding getting "soft booted"; As a manager I would never call a reassignment that. I might refer to a reassignment as "aligning an engineer's assignment with their talents". Sometimes I realize I've thrown someone into the deep end and they need to be pulled out of the water and given something a bit less intense; mea culpa. If someone were truly under performing I would be putting them under formal coaching.
Negative self-talk is dangerous when it leads you into to a downward spiral of under-delivery. I've seen engineers that literally self sabotage because they talk themselves out of actually delivering as expected. They constantly focus on "learning" so much that they never put what they've learned to use in delivering their assignment. They're obsessed with catching up so much that they never even start.
If nothing else, deliver what is expected to you. If you don't understand it, ask with help breaking it down. Every hint, or vague request by a manager or lead is likely a softly stated expectation. Ask for clarification: when would you like this done? how long do you think this should take?
Regarding wasting a lead's time, in my experience (as a lead engineer at one time, and on the receiving end of lead engineer's guidance) they will tell you when you're wasting their precious time. In fact, my technical mentor once told me, "first time you ask a question I'll show you how to find the answer. Second time you ask the same question I'll show you were to refresh your memory. Third time I'll tell you RTFM".
If you're doing poorly, it's likely that you'll be told in some way or another. Otherwise, If you can, don't try to read too much into things unsaid.
You don't know what that other Junior Engineer's story and history is. They might not be as Junior as they appear. I've hired "junior engineers" who have been programming since they were 8 years old. Even star engineers will often be overtaken by an even hotter burning, faster shooting star engineer. It's the nature of the industry that you will eventually work with what appear to be savants. There is room in the industry for mere mortals.
Regarding getting "soft booted"; As a manager I would never call a reassignment that. I might refer to a reassignment as "aligning an engineer's assignment with their talents". Sometimes I realize I've thrown someone into the deep end and they need to be pulled out of the water and given something a bit less intense; mea culpa. If someone were truly under performing I would be putting them under formal coaching.
Negative self-talk is dangerous when it leads you into to a downward spiral of under-delivery. I've seen engineers that literally self sabotage because they talk themselves out of actually delivering as expected. They constantly focus on "learning" so much that they never put what they've learned to use in delivering their assignment. They're obsessed with catching up so much that they never even start.
If nothing else, deliver what is expected to you. If you don't understand it, ask with help breaking it down. Every hint, or vague request by a manager or lead is likely a softly stated expectation. Ask for clarification: when would you like this done? how long do you think this should take?
Regarding wasting a lead's time, in my experience (as a lead engineer at one time, and on the receiving end of lead engineer's guidance) they will tell you when you're wasting their precious time. In fact, my technical mentor once told me, "first time you ask a question I'll show you how to find the answer. Second time you ask the same question I'll show you were to refresh your memory. Third time I'll tell you RTFM".
If you're doing poorly, it's likely that you'll be told in some way or another. Otherwise, If you can, don't try to read too much into things unsaid.
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."
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."
+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.
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.
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.
Excellent. 1) Takes advantage of "beginners mind." 2) Provides an outlet for notes an ambitious improver-of-things will be taking anyway.
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.
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.
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.
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.
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.
- 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.
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.
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.
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.
yes, an updated doc with a onboarding buddy is the way to go,been there done that and it worked out well.
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
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
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.
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.
That’s a really good point! Thanks for calling it out
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.
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.
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.
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.
> I got to pick the team after being hired
This is typical for a company where people who hire you are not the same people you end up working with. The team you picked may not have wanted you. They didn't get to choose you and they didn't get to interview you. Consequently, they may not have thought it's their responsibility to onboard you, so they made it a painful experience for you on purpose.
This is typical for a company where people who hire you are not the same people you end up working with. The team you picked may not have wanted you. They didn't get to choose you and they didn't get to interview you. Consequently, they may not have thought it's their responsibility to onboard you, so they made it a painful experience for you on purpose.
> 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.
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.
It's rare that you get a technical manager in a large company. It's fine for HR-ish stuff, but if they do anything technical, like enter a Jira ticket, it creates problems. Detail is often lacking. This is one of the reasons I prefer smaller firms.
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.
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.
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
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
Theoretically the goal of SSO systems, just hard in practice with inconsistent implementation and the SSO tax [0]
[0]: https://sso.tax/
[0]: https://sso.tax/
Maybe? I am not sure how much "role assignment" is handled as part of SSO vs. how often SSO is purely authentication and there's another app-tier layer that's doing authorization.
"Role definition" is certainly app-tier, by ... uh... definition.
I'm thinking of something more like a literal terraform config that treats roles as resource templates to be instantiated against human accounts.
{ template: "New SE", roles: [ { system: AWS-Live, role: ReadOnly }, { system: SonatypeNexus, role: ReadOnly } ... ] }
And then you just do the equivalent of "tf apply 'New SE' [email protected]" and a bunch of UX or backend automation updates permissions for Joe in all the things.
And then you publish the role templates, and let your EMs, Sr. SEs, and other opinion-havers about roles start tuning/tweaking/extending/adding. With review and approval from Sec and IT. And then if there's some role definition change, you just roll it out like you would a single user.
"Role definition" is certainly app-tier, by ... uh... definition.
I'm thinking of something more like a literal terraform config that treats roles as resource templates to be instantiated against human accounts.
{ template: "New SE", roles: [ { system: AWS-Live, role: ReadOnly }, { system: SonatypeNexus, role: ReadOnly } ... ] }
And then you just do the equivalent of "tf apply 'New SE' [email protected]" and a bunch of UX or backend automation updates permissions for Joe in all the things.
And then you publish the role templates, and let your EMs, Sr. SEs, and other opinion-havers about roles start tuning/tweaking/extending/adding. With review and approval from Sec and IT. And then if there's some role definition change, you just roll it out like you would a single user.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The way a company reacts to thoughtful observations about their process says a lot about how they view their employees.
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
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.
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.
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.
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.
[deleted]
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.
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.
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.
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.
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.
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.
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.
I think part of the issue here is “a company” isn’t a particular human being or team that is specifically incentivized to “give a shit about the employees.”
What this looks like from my vantage point is: anyone who is a director (manager-of-managers) or up is assuming that the line managers (managers-of-non-managers) has it taken care of - their team, their plan, and they can speak up if they need guidance.
The line managers, OTOH, probably don’t individually onboard terribly frequently, even though as a cohort it’s probably constant. So the feedback loops / improvement cycles for a given team are all slow, and there’s no inherent incentive for those managers to try to boost the overall experience. Unless they’re the sort to go “hey, maybe my peers know better plans,” they will all individually toil at this and create an overall sucky picture.
Being perfectly honest, I was in that boat myself until this article appearing this morning prompted me to ask my fellow EMs what they’re doing, and whether we could find a way to improve it overall.
Even if we do though, it’s still going to suffer from tragedy of the commons a bit, unless we deputize some “onboarding improvement” project team to actually drive towards a clearly stated objective.
tl;dr - what feels like “this entire company doesn’t give a shit about me” could just be “my manager is doing what they think is the best possible, given limited resources, and having little-to-no support or awareness from the rest of the organization - and that little bit just isn't enough for me to feel understood and cared for."
What this looks like from my vantage point is: anyone who is a director (manager-of-managers) or up is assuming that the line managers (managers-of-non-managers) has it taken care of - their team, their plan, and they can speak up if they need guidance.
The line managers, OTOH, probably don’t individually onboard terribly frequently, even though as a cohort it’s probably constant. So the feedback loops / improvement cycles for a given team are all slow, and there’s no inherent incentive for those managers to try to boost the overall experience. Unless they’re the sort to go “hey, maybe my peers know better plans,” they will all individually toil at this and create an overall sucky picture.
Being perfectly honest, I was in that boat myself until this article appearing this morning prompted me to ask my fellow EMs what they’re doing, and whether we could find a way to improve it overall.
Even if we do though, it’s still going to suffer from tragedy of the commons a bit, unless we deputize some “onboarding improvement” project team to actually drive towards a clearly stated objective.
tl;dr - what feels like “this entire company doesn’t give a shit about me” could just be “my manager is doing what they think is the best possible, given limited resources, and having little-to-no support or awareness from the rest of the organization - and that little bit just isn't enough for me to feel understood and cared for."
This ^^ exactly my past experience.
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.