How to Thrive in Your First 90 Days in a New Role as an Engineer

Your first 90 days are crucial and can define your overall experience in your next position as an engineer. It can be the difference between having an amazing experience and getting along well with your new colleagues, or an experience where you regret the decision that you made. In this video, I'll share my perspective and my expectations as a manager, combined with my experience changing several different positions as an engineer. Let's get straight into it. So, preparation is the key to success in your first 90 days. In good companies, you will have a structured onboarding process where you will have concrete instructions regarding the expectations and specific timelines. That's going to help you a lot. But based on my experience and the experience of others, that's not always the case. I've gone through a lot of onboardings in my career, and a lot of them were not structured well. So it's really important that you proactively focus on making your onboarding as best as possible. To help you to succeed in your first 90 days in your new role as an engineer, I'm sharing a 5-step process that will make you successful. Let's go to the first step. The step number one is to connect with your teammates before you start. In some cases, you won't know who your colleagues are going to be and in which team you are going to be a part of. But if you do know, I suggest that you do your best effort and connect with them before you start. And LinkedIn is great for that. My suggestion is to send them the request for connecting and express the excitement of working with them. Then when they respond, you can ask them some questions that can help you already if you wish to, but not mandatory. An important thing to keep in mind is that you shouldn't feel bad if they don't respond as well. They might not be as active on LinkedIn, and that's perfectly fine. I recommend doing this one week before you start, not earlier. If you do it earlier, they might not have the latest info about a new person joining, and they might also forget about you messaging them since it will be a long time until you start. Now let's go to step 2: start building relationships. Once you start, this should be one of your main focus points. It's important to focus on building good relationships with your team and the people that you are directly working with. You want to ensure to create a great foundation. This will help you immensely to be able to collaborate effectively. So my advice here is to try to schedule one-to-one meetings with all of the people that you are directly working with and be genuinely interested into getting to know them better and understanding their current focuses and their problems. This is also a great opportunity for you to get to know more insights in the current situation. The important thing here is to keep in mind that you rather focus on asking as many questions as possible instead of pointing out your opinions and suggestions, or worse, telling them that this is a better approach. You don't have enough context at this time to provide a valid direction. So if you do have a good suggestion already and you believe that it can be helpful for them, frame it rather as a question. Now let's go to step 3: understand the situation. In your first few weeks, focus on understanding the processes, the codebase, the project, and the business as deeply as possible. Make sure to go through the documentation and ask as many questions as you need to. Don't be afraid of doing that. Curiosity is a sign of a great engineer. A good The best way to understand the situation is to go through the past pull requests and learn from them. Learn from the comments, the changes, how people name the branches, commit messages, as well as the overall scope of the PRs and connection to actual tasks. The important thing in this step is to make sure to align with the current process first. Even if you believe already that something is completely not the way it should be, be a team player and get aligned first. You will be able to propose suggestions for improvements later. As I mentioned before, don't focus on proposing big changes before you have a good understanding of the current situation. I personally made a mistake of wanting to help with the direction as soon as I joined, but I was wrong. This made some people question their direction and also my abilities to being able to make good decisions. Let's go to step 4: Focus on becoming productive. Becoming valuable to the team means that you start contributing to tasks. Be proactive and take on tasks as early as you can and learn as you go. That's also the best way to learn and show your value to the team. What my expectation as a manager is that you should at least have one finished task by the end of the first week. First week. This should be your goal as well. The important thing here is to take on a simple task like a bug or a small improvement and aim towards finishing it. It should go through the code review process, and ideally it should also be deployed to production, but not necessary, especially if the company doesn't have the instant deployment strategy. Once you have your first task finished, it's going to be much easier for you. After this, take on a new task which is a little bit wider scope and finish that one. Increase the scope and complexity of tasks as you finish more and more tasks. A great thing that you can do as well is that if a company doesn't have an onboarding document already, start creating one. Document what was important for you and what steps did you take to get that information. If the company already has the onboarding documentation, focus on making improvements to it. This will show that it's important for you to make things better for new people coming in, and you're not just focusing on yourself. Now let's go to the last step: find and propose improvements. Once you understand the situation, it's important to take the initiative and propose improvements to the codebase, onboarding process, team processes, etc. This will show that you are not only focused on your own tasks, but you also want to help the team and others. I recommend creating a list of improvements as you're learning about the current situation. My recommendation is to talk about improvements to the codebase with the team members on code reviews, pair programming sessions, or daily meetings. Regarding suggestions for the process and onboarding, talk about them with your manager on a one-to-one meeting. Don't frame them negatively. Instead, point them out in a way that could be very helpful to the team and the overall organization. As you're going through the improvements, listen carefully for the feedback. If there is some improvement that you can take on as an initiative, try to fully understand what is the best way to implement it. Also, don't expect that all improvements are going to be honored or done immediately. Changes should be done one at a time and never multiple changes at once. The important thing here is to get a buy-in before making any improvements. If something affects the whole team, make sure to find out what is the best way to get a buy-in from everyone. That could be on the retrospective meeting, planning meeting, or maybe the daily meeting. Don't ever make a change that affects others without telling them. I'm curious to hear about your advice to be successful in the first 90 days. Make sure to share them in the comments. To learn more, you can subscribe to my newsletter It's called Engineering Leadership, where I share similar tips and advice on how to be a great engineering leader. There are more than 100,000 people already reading it, and I publish 2 new articles every week. Thank you for watching, and I'll see you on the next one.