Always follow the boy scout rule during onboarding
Photo by Andrea Sánchez on Unsplash
As a software consultant, you experience new beginnings really often. Unlike engineers at product companies, who maybe stay for years in the same project, we usually stay much less time in our gigs (usually months). This constant change has its benefits and advantages, obviously. Onboarding to a new company, team, workflow, culture, or project can be thrilling and exciting, but blockers like lacking accesses or secrets can also make it challenging and stressful.
I have onboarded to dozens of new projects at this point in my career, this week I onboarded to a new one! While nobody expects you to solve world hunger immediately (maybe next month though! 😉), onboarding fast and providing value from the get-go makes a good first impression to the new people you're working with. This is not a skill I had earlier in my career, and even today, it of course varies from project to project how fast I can onboard (project complexity is a huge factor, let's not deny that).
Ideally, you onboard to a new project where there's an active team that follows best practices, with members who can spare time and effort to explain the intricacies, with good and extensive documentation on how to run your local development environment, and with all necessary accesses granted in your first day. From my experience in consulting, you can consider yourself lucky if you get just one of those. Often the people who are left may have joined just before you did, or there's nobody left who's technical to onboard you. The documentation, if it exists, may be too shallow or just outdated. And it may take days or weeks to get you the necessary accesses, plus nobody knows confidently which ones you need.
The good news? You can still provide value and make good first impressions by applying the boy scout rule: leave everything better than you found it. Even when documentation is lacking or teams are understaffed, there are small actions that make a big difference both for you and for whoever comes after. Here are some tips I have followed myself and brought me success:
1. Ask for a walkthrough of the codebase
Upon arriving, ask if someone knows the codebase well enough to give you a walkthrough. Hopefully such a person still exists. Yes, you can download the code from the repository yourself, take a look, and even ask AI to clarify stuff for you. But a person who is working on the codebase can probably give a better view on what is most important, what brings more headaches, and even explain to you why certain things are the way they are. Try to be the one sharing the screen, this prevents the other person from speeding through. If you're doing this remotely, record the session if possible. It might help someone who comes after you!
2. Do pair programming the first time you run the project locally
You can combine this tip with the one above. If someone else can run the project locally successfully but you can't, comparing the setups and configuration will help bridge the gap. Often there will be configurations, secrets, or just non-document know-how that the other person needs to share with you. Take notes on everything that was missing or not intuitive for you. Once you can run the project successfully, ask the other person to tell you how to test its basic functionality. A great way to understand a product is by playing with it locally.
3. Every time you request an access, record it in a list
Accesses are the bane of any onboarding. Especially in big companies with high security requirements, getting you the needed accesses may take long, since they might require several approvals. Every time you're forbidden to access a tool or documentation you need, don't just ask for the access. Record it in a list. And record alongside the reason you need that access. For example: "Jira> needed for sprint board and backlog", "AWS> needed to access infrastructure in production", "1Password> needed to access the team's vault with secrets", etc. Believe me, when a newcomer joins the team after you, this list will be worth more than gold to them! This is also a great piece of documentation you can share with your new team and employer, they will be delighted that you did this extra effort.
4. Be proactive and ask questions
This might sound obvious to some, but it can be really tough for many people, especially juniors. It is impossible to know everything in the beginning, so just ask about things that are unclear to you! If you have many questions and are afraid of spamming the team's communication channels, instead ask one of the team members for a call where you get to ask all those questions. If a blocker is preventing you from doing essential work, chime in daily about it. It's not your fault that you're blocked, and it's important that you remind the necessary people about it.
5. Take notes
When something is new to you, taking notes will help you focus. It will also ease your mind, which will be stressed trying to remember way too much stuff. It's easier to relax when you know that you wrote something down before. Creating checklists for processes that are new to you is also a great hack when getting used to a new environment (you can stop using them later, when you're already in the groove).
Conclusion
I have always liked new beginnings, probably that's one of the things I like about consulting. Every project you touch leaves a trace of you. Onboarding happens at the very beginning, so improving it multiplies your impact. Don't underestimate it.