I’m not talking about myself regarding the pull request (okay, I’ll talk about it a bit at the end of this blog post), there is nothing special about it.
I want to talk about how a smooth and comprehensive onboarding process could let me create a pull request on the first day at work. All of these onboarding processes were done in less than 4 hours. Kudos for the people who helped me!
The Onboarding Flow
1. Company-wide onboarding by people management
My first encounter with the onboarding is with People Acquisition Specialist. She gave me a company badge and then explained about the company, the mission, the people and its hierarchy, the values and culture, the career path, and so on. She even doesn’t mind re-explaining the things that were already stated in the offering letter to make sure that I know my rights.
2. Hardware
I received an M1 Macbook Pro. It was decent hardware, faster than my previous one.
3. Team onboarding by the CPO
The CPO greeted me then introduced me to the entire teams that were available at the time, then he lead me straight to my desk. He also explained a bit about the business/products.
4. Business, product, and the first tasks onboarding by the VP of Engineering
I was scheduled an 1 on 1 meeting with the VP of Engineering. For sure, he talks fast and it helped for a shorter meeting, which is good. He explained the core business of the company and how the company products will drive these businesses.
My task at the first day was actually to read the wiki/documentation so I could learn about the culture, standards and whatnot but he also told me about what were my next three real tasks that involve coding. I didn’t waste this part by straightly asking about the expectations of these tasks. By the end of the meeting, I have clear hints on how to solve the problems.
He also gave me a clue about the important individuals in the teams. This was very valuable information that helped me to know who is the correct person to ask if something blocks me.
5. Wiki/Documentation
The wiki is huge and extensive. It even contains a page on how to set up your hardware, minutes of meetings, a tech debts list, and so on. I appreciate the transparency they applied here, no silo at all!
I spent around 30 minutes skimming the wiki.
6. Credentials and access
I can’t tell all the services and SaaS used by the company (NDA stuff, you know), but the credentials and access I retrieved in these 4 hours were quite a lot, up to 8 accounts. Not including the accounts that are shared via the company password manager. Trust is essential here.
If you can’t get much trust, the ball is on you to ask the right person for the right credentials/access that you need to start your work. If rejection occurs, you have to explain to them why you need the cred/access. Just make sure nothing blocks you.
Happy hacking.
The Onboarding Process at my previous company
HR will handle the company-wide onboarding then the rest is up to me. So as Product and Engineering Lead, it’s on me to design the onboarding process for my team did try to put myself in the perspective of a new employee, but it was not deep enough. One thing is for sure, I improved the process bit a bit by asking for feedback from the new employees about the onboarding process. You’re lucky if they are honest enough to point out the missing things or the pain points of your onboarding process.
One of the honest feedback I received is about how people have different ways and paces to adapt. This particular new employee said that the long wiki page that I wrote is useless, “No one will read this wiki page” he said. Before I could counter his argument, he added that he was used to talking in person instead of reading boring texts and he need someone to sit down beside him for prolonged hours because he got a lot of questions in his head. I don’t think that I want to sit for hours beside him but he was right to some degree.
I put too much effort on the wiki documentation but spent less on preparing the onboarding in person. I was enforcing RTFM culture unwittingly.
I am supposed to balance the textual onboarding vs in-person onboarding.
My First Pull Request
As I said before, I did nothing special. I picked the easiest among the first three tasks. Once I got the Gitlab access, I scanned the repositories and guessed which is the right repo that related to the task, then started digging into the codebase. It’s a fronted one, I spend around 15 to try to understand the codebase structures then go straight to the file that I need to modify. Sure, I got questions/minor issues and asked directly to the person that governs the domain. They are all very responsive and helpful. At the end of the day, I submitted a pull request.
That’s it.
>> Home