On starting a new Role

I recently started a new role, and transitioning to something new can feel especially daunting after spending 4.5 years at the same company. The transition is never easy, and it can be overwhelming to navigate an unfamiliar environment while adjusting to new responsibilities. As someone who always tries to do things intentionally, I think about how to start well, I looked for resources to help me handle this change more effectively. However, I found that there weren’t many available, particularly for those not in senior leadership positions like CTOs or VPs. So, after a few months in my new role, I decided to write this brief blog post to share my approach and insights.

Be comfortable with the stack and the processes

As an individual contributor, you’ll be valued primarily for the code you deliver. To be effective, you need to be comfortable with both the tech stack and the development processes. While job descriptions often provide a high-level overview, the real insights come from speaking with technical leaders during the interview process — whether it’s an Engineering Manager, Head of Engineering, or Tech Lead. This is your chance to ask deeper questions and gain a clearer understanding of what to expect.

Some key questions I asked:

• Which language or framework do you use for the frontend and backend?
• Which database do you use?
• Which cloud provider hosts your infrastructure?
• How often do you deploy to production?
• Are engineers responsible for deployments, or is there a dedicated team?
• Do you follow Agile methodologies? What recurring meetings should I expect?

Having this information allows you to prepare in advance. For example, before joining Socium, I had never worked with Angular. Knowing it was part of the stack, I used my notice period to read Angular’s documentation and build a simple to-do app to familiarize myself with it. You can do the same with other technologies, such as cloud providers, by exploring the services your new team uses. This proactive approach makes onboarding smoother and helps you hit the ground running.

Learn the domain

I can’t emphasize this enough: prioritize understanding the domain even more than the codebase itself. One key lesson I’ve learned in my new role especially working in a complex domain like payments is that reading the code alone won’t always make things clearer. Without a solid grasp of the domain, the code might seem confusing or disconnected.

More importantly, understanding the domain allows you to actively engage in discussions with product teams, fellow engineers, and stakeholders. As a new joiner, this sets you apart it shows that you’re not just writing code but truly grasping the problems you’re solving. This deeper understanding also helps you anticipate potential challenges, making you a more valuable contributor from the start.

Domain <> Code

Once you have a solid understanding of the domain, diving into the codebase becomes much easier after all, code is just code.

When working on new features, take advantage of the existing code. It provides valuable insights into the patterns your team follows, the overall structure, and best practices in use. Observing how things are built will help you write code that aligns with the team’s conventions.

Another great way to ramp up is by reviewing past pull requests. This will give you an idea of the kind of feedback you can expect from your teammates, highlight areas where you can improve, and help you understand the team’s coding standards and expectations.

If your team has internal documentation or a wiki, make it your first go-to resource. Well-documented projects often contain explanations of architecture decisions, coding guidelines, and onboarding materials that can save you hours of guesswork.

Ask for clear expectations

Ask your manager directly about their expectations for you. I like to get ahead of this during the interview process by asking the classic question: What will success look like in this role? You can take it further by asking about specific milestones for the next three months, six months, and beyond.

At the end of the day, it’s simple your job isn’t The Hunger Games 😅. It’s only logical to understand the criteria by which you’ll be evaluated. A lot depends on it, from your career progression to your salary. Even better, try to get these expectations documented. Having clear, written goals ensures alignment and gives you a concrete way to measure your progress.

Here are some things you shouldn’t do — mistakes I’ve struggled with myself:

Don’t go full firefighter mode

Resist the urge to fix everything that seems wrong. I emphasize seems because, more often than not, things exist for a reason even if they don’t make sense to you at first. Without the right context, making changes too quickly can do more harm than good.

You might also be biased by your previous experience. If you came from a place with different processes that worked well for you, it’s natural to want to replicate them. But every team has its own way of doing things, and what worked elsewhere might not be the best fit here. Instead, approach things with curiosity. Ask questions like “Can you tell me more about why this was done this way?” before suggesting improvements.

Don’t take on everything to prove your value

This was my biggest challenge when starting. I felt a strong need to prove myself, which led me to take on tasks I didn’t have full context on sometimes even with tight deadlines. The problem? Without proper understanding, you risk overcommitting and delivering work that doesn’t align with expectations. Instead, focus on learning first and taking on work strategically. Quality over quantity.