- Published on
How to smash your onboarding process
Jumping from company to company in the software field is quite common. There are so many opportunities, and every one of them seems more tempting than the other. Onboarding into a company or a role is happening quite often since job-hopping is a thing in our field. Many blog posts explain and guide how to onboard people efficiently, but almost nobody talks about how engineers should help themselves get up to speed on their new role. Being able to get up to speed is a handy skill that you can master that will help you in a lot of ways.
Mainly it's your company's responsibility to onboard you. However, not every company is doing it correctly or investing in its onboarding process. It is common to join a company where it's unclear what your priorities are or what exactly you should be doing. Your colleagues seem equally busy. Everyone is friendly, but there is no road map for what you need to accomplish. The only way to get up to speed is to self-onboard 🤷♂.️ However, other companies are more mature, have guides, checklists, and documentation, and will give you time to learn and understand their way of working, but you can't just take as much time as you want to start contributing to your team's goals.
Either way, there are things that you can do to speed up that process that will benefit both you and your company. This is what we will discuss in this blog, ways, and tips to speed you up on your new role!
Don't be religious ⚠️
Every company has an onboarding process. Some companies have excellent documentation, and ways to onboard you were they give you everything you need to start with, whereas others lack structure and throw you in the ocean. There is no perfect onboarding process, but there are definitely ones better than others that make the transition smoother. It is pretty hard to sustain operations in a good state in our field mainly because the rate of change is enormous, and it requires a well-structured system to keep it up to date and improve it.
Whatever your company's onboarding process is, don't be religious about it. They will probably mention that to you, but
if they don't, usually, this exists as a guide to help you get up to speed. It's hard to have one way of recruiting people
and expect everyone to be up on their feet at the same time because people are different. People learn, process, and
understand differently because every brain has its own way of learning. So I would suggest using the onboarding
documentation as a guide and trying to collect information from other resources, like meetings or discussions with
colleagues. Maybe you learn better when you see visuals, so you could watch some videos instead of reading a vast
document. The point is that
you have to take ownership over the onboarding and don't expect the company to teach you
everything because it's your responsibility as well.
Typically, software engineers prefer to read code instead of documentation, so go for it. Dive into the codebase and
try to follow the flow from the outside world into the system. If your team is working on a large software system, you have
to prepare that there is a slight chance that you might not understand anything at all, but that's fine,
don't let that discourage you! We have all been in this situation before, and there is no problem; it is expected.
Use the debugger 🐞 and try to follow the flow from the request to the system's response. Try to identify the user journeys of your system, pick one and try to understand what's happening line by line.
Remember, you don't have to understand every detail of the codebase but just an overview of
- how the system operates
- how it is structured
- what are the main parts
- and what are the project's dependencies.
Depending on your level, you might find this way of learning easier or not. If you struggle to understand what the code does, you can always as a colleague to pair.
Ask to pair, then ask again and again -- unless the team is close to delivering something vital, you might want to give them some time; otherwise, ask for pair. Pairing is one of the best techniques for sharing knowledge across our industry. Many companies, when you join, assign you a buddy who is closer to you and helps you get on your feet. Your buddy is a great candidate to ask for a pairing. If you don't have a buddy, don't worry, you can ask any team member to sit together and work.
There are different things you can ask for from your pair:
- You can ask him to run you through the codebase and explain the code's main concepts,
- Work together on a task.
- Try to present your understanding of the system to verify that you didn't make any wrong assumptions or ask questions.
Pairing is not only helpful in understanding the codebase, of course. It exposes you to many knowledge resources and enables quick feedback. It also gives you information about how your colleagues work. While pairing with a team member, you get to see how they think, how they write code, their standards, and how they communicate. That's why I think pairing is probably the best way of speeding up your onboarding.
There are a lot of people having imposter syndrome in the first weeks of their new job. That will not sound helpful, but you shouldn't feel like an imposter! It would be best if you were confident of your skills and the company's skill in evaluating you and offering you the role. The first couple of weeks in a new company or position is really taught, and your brain will need some time to digest all the information you tried to consume, so please get your time! The last thing you want is to burn out in the first few weeks of joining a team.
Don't compare yourself with others; don't do overtime to speed up because that will hit you later. It's easy to get overwhelmed initially, especially if the system is big and complex. Try to manage your energy and time efficiently, and don't stress when you will start contributing. As long as you are doing your best, then there is no reason not to feel confident.
Dive to unknowns ⁉️
If it's not for pairing, then doing things you don't know is probably the best way to learn. It is expected that
when you join a new team, there will be a lot of unknowns in many domains, code, process, communication, structure, values,
and the list goes on and on.
Don't be afraid to ask questions! In life, you are the only one responsible for what you
know and what you want to learn. This should apply within your role in your new team. You are responsible for what you
what to learn, so go ahead and ask!
Also another piece of advice is
don't be afraid of taking ownership of things that might seem difficult. Good teams will
embrace you to do this and will help you achieve the goal. Pushing yourself in difficult situations will give you a lot
of resources for knowledge. If you are stuck in such a task, communicate it with your team and ask for help. This is
what a team is for, to cover each other and help each other so that they can all be more robust and achieve great things.
Keep notes 📝
Notes are an essential tool at the beginning of your new role. There will be a lot of unknown terminologies, tools, domain concepts, etc. It's good to keep a log of all your questions and unknowns. The faster you resolve this, the quicker you will be able to understand more and eventually get up on your feet. It's an excellent technique to keep notes from meetings at the beginning where you probably don't understand everything and then discuss it with your manager or a colleague. Hopefully, you are meeting with your manager regularly; maybe you have a 1-1 weekly so that could be a good opportunity to ask questions or some guidance for the next steps forward.
Final thoughts 💭
Time helps people adapt to a new role and workplace the most. It is hard in the beginning, especially at that point when you realize how much you don't know and need to learn. However, take stock of your skills, strengths, and experience. You were selected for the position because people believe in your ability to be effective in your role. You can do this!
It would be great if every organization had a robust onboarding program, but not all do. By demonstrating initiative, you can quickly add value and integrate into your role by reaching out, asking for advice, delivering small wins, and being patient.