The Guide to Onboarding Software Engineers
leadership.garden
leadership.garden
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.
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.
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 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.
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.
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.
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?
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.
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.
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."
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.
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.
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.
- 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.
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.
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
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.
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.
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.
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'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.
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.
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
[0]: https://sso.tax/
"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' joe@example.com" 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.
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.
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.
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.
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.
The way a company reacts to thoughtful observations about their process says a lot about how they view their employees.
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.
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.
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.
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.
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."