As a new hire, initial weeks in a company are challenging. I still remember my first month as a full-time Software Engineer. They gave me a bunch of training materials and wikis, tagged me in unfamiliar email conversations, and included me in meetings which I couldn't follow. Heaps of questions like "Am I working too slow on this task?", "Should I spend time understanding every detail of this wiki?", "Is it okay if I ask this question to my mentor?" cornered me. I suffered from lack of confidence and doubted my ability to work which affected my productivity. Over the years, I got many opportunities to mentor new hires. As I interacted with them, I came to know that many of them also experienced degrees of diffidence and anxiety in the onboarding phase. So, if you are a new hire, the following prescriptions may hopefully make onboarding easier, smoother, and more relaxing for you and your team.
Mentor - a wonderful being!
Generally, you would be assigned a mentor who will help you onboard. Let us say your mentor's name is Ava. She is (or should be) allotted some bandwidth to provide answers to your questions and support for troubleshooting. So, feel free to reach out to her.
In your first one-on-one with Ava, you should ask her to explain a high-level (actually, a very high-level) architecture of the service owned by your team, important downstream and upstream services, and customers.
I believe it is necessary to know about these subjects at the onset so that you get a better insight into future team conversations. During one of my onboardings into a new team, my mentor got too excited and started giving me intricate details of the architecture. If this happens with you, don't get overwhelmed. Listen patiently and grasp the gist of it. It is okay to not understand everything, and it is okay to admit that. In case you are not assigned an onboarding mentor, you can ask a teammate to brief you.
Some teams may share with you written documentation of the services they own. If it is high-level, then read it thoroughly, else do a cursory read and mark it for future reference. For any information thrown your way, unless advised, you shouldn't spend a lot of time to understand the details. Cross the bridge when you come to it. You can refer to the documentation in detail when you work on a task related to it.
Although Ava is your go-to person, you can ask questions to other teammates (which you'd have to, in case you are not assigned an onboarding mentor). It is a good way to break the ice with them.
Wikis, documents, instruction links - Bookmark 'em all 📌!
This point may sound trivial, but it is important. You will be given links to onboarding wikis and instructions for setup. Bookmark them right away so that you can quickly find them in the future. It is probable that you will refer to these wikis frequently during initial development/troubleshooting.
Side-note: Technologies and configurations keep on changing. Parts of the setup wiki you are referring to might be obsolete or incorrect. Make corrections if needed and show ownership!
Ask questions the right way
The objective here is to make sure you get answers quickly, causing the least disturbance to your respondent. At work, everyone is busy and in a big hurry. If you frequently ask Ava things that you could easily find on Google, Stack Overflow or even internal wiki pages, I am sure she would roll her eyes.
Before asking her about any error/issue, search for solutions to fix them on Q&A portals.
Understand that answering questions can be taxing. If you ask Ava a question, she must pause her work, answer your question, and resume back. The effort to rebuild the train of thoughts after resuming work is what I refer to as Context Switch Tax (CST) paid by her to help you. This is paid every time you ask a question. It may sound extremely organized but prepare a list of all the questions and then ask them. Hence, Ava will pay CST a single time. I have received positive feedback for following this approach to ask questions.
Let us jump into what I believe a technical question should comprise of:
- Problem statement with the necessary context for your reader
- Your question in a direct way
- Your research or the approaches you tried
Example: "Hi Ava, I am trying to import project Alpha in IntelliJ. I am using IntelliJ version 17.5. Once I import the project, I get compile errors. Do you know what would be the issue? I changed the project SDK to JDK 11. But, it didn't seem to make a difference."
I recommend to mention your research or approaches because:
- You show that you can investigate independently.
- Ava will research approaches other than the ones you shared and this would save both of you some time.
Take feedback to know where you stand
It feels satisfactory to receive some feedback to ensure that you are delivering quality results in time. Even if the feedback is not positive, at least you know that you need to improve. The sooner you know that, the better.
In the fourth week or after your first task is completed, I recommend you ask Ava for feedback and incorporate it.
Sometimes, mentors might say that it is too soon to provide any feedback, which should be fine too. Be confident and give your best! 🤘🏽
Handle the meeting madness
Depending on the team culture, you might end up attending a lot of meetings. In each meeting, there is an assortment of information circulated, which is hard to process in the early stages of your job. As soon as the meeting begins, you will likely have a hard time following the yap-yap in the room. You may get confused and exhausted by the time it is half done. Or, if you are me, you will start daydreaming. Here are some pointers to get involved and gain the best out of team meetings:
1) Brainstorm or Review meeting:
The agenda of this type of meeting is to review a design or brainstorm ideas to solve a specific problem.
Before the meeting, if you get a chance, ask the organizer for the agenda. Spend a few minutes understanding it using internal wikis for reference or ask the organizer to give some context.
Usually, in the opening remarks, the driver of the meeting introduces the to-be-discussed-subject and purpose of the meeting. If you don't understand them, ask the driver to give you some more background in layman terms.
The intention behind this is two-fold. Firstly, you are registering the subject and driver of the meeting in your mind. In the future, you can reach out to the driver for any questions regarding the subject discussed. Secondly, participants become aware that a new joinee is in the room. The generous ones will try to make their points in simpler terms so that you can understand.
After the introduction, understand as much as you can for the rest of the meeting. You must observe that your participation and understanding of the meeting conversations improves over the weeks.
2) Project Planning meetings:
If you don't have prior work experience, it is possibly the first time you are involved in planning meetings.
Don't be shy to ask questions about how your team performs task breakdown, scoping, and estimation in these meetings.
In the first few months, your scoping and work effort estimates may be grossly incorrect and it is alright if that happens. Don't get demotivated and continue participating in the discussions. You will get better at it with experience as you get to know your projects and architecture better.
I hope this post provided you with some useful advice to overcome the challenges at the start of your new gig. All the best!
Cover Photo Credit: Simon Abrams on Unsplash
Body Image Credit: Campaign Creators on Unsplash
Oldest comments (0)