How I avoided burnout during my onboarding as an experienced developer

I’m in a conference room, sipping my first coffee of the day and trying not to yawn as my colleagues discuss their daily tasks during the standup meeting. While I recognize some terms, most feel vaguely familiar, and I’m just working to stay engaged. 
  
I recently took on a new role as a backend developer at Infobip during a challenging time for the IT industry. This is my first non-entry-level position, and in my previous role, I had a lot of responsibility, stayed in the loop, and felt comfortable. Now, I’m eager to regain that level of confidence and prove the skills I highlighted in my CV. 
  
On the flip side, I’m cautious; I know burnout all too well, and trying to learn everything at once is a mistake – especially since my new team is large and already excelling on various projects. 
  
Yet here I am, writing an article about successful onboarding! Feeling confident in my role, I can identify several things I did right that made my experience smooth. These insights may be helpful whether you’re starting a new chapter in your career or supporting someone new on your team. 

The first thing is making a plan. 
  
In an ideal world, you would have a dedicated (and enthusiastic!) manager who will set up a clear plan for you. 
  
I was fortunate to have a supportive manager and a well-structured onboarding plan with the necessary resources, actionable items, goals, and milestones. In my first week, I met with my manager to review it, which allowed me to ask questions and provide feedback. This clear roadmap was invaluable; whenever I felt unsure, I could easily refer back to it. 
  
If you’re not as fortunate, your company may not prioritize onboarding plans, so you’ll need to take the initiative: ask your manager and teammates about their expectations, prioritize them, and document everything. Schedule regular sync meetings to review your progress and achievements. 
  
One thing to be cautious about is to make your plan feasible – now is not the time to be unrealistic or overly ambitious! 
  
The plan should focus on essentials, not “nice to haves”, covering what you need to understand your new team’s workflow. This doesn’t mean you need to learn the entire codebase immediately or perform at your previous level right away. 
  
To ensure my plan’s success, I frequently shared its items with my team – and you should do the same. This ongoing sharing boosts motivation and makes it easier for colleagues to provide timely tips, actively contributing to your onboarding. 

Along with your first tasks, there will be a lot of theory and explanations. You’re probably eager to know everything you can possibly squeeze out of your colleagues. They also might tend to flood you with all the knowledge they have.   
  
Do yourself a favor and don’t try too hard. Seriously.  
  
Now is the perfect time to review the basics thoroughly but don’t overload yourself. Take charge of your limits; I often said, “Thanks for explaining this! Let’s pause now, as I can’t absorb more. How can we apply this?” 
  
Your teammates are deep into the project codebase, so they may not realize when you’ve hit your information limit. Assist them in assisting you – if there’s a lot to learn, take breaks and use summarizing and rephrasing to check your understanding.

You might have a mentor during onboarding or naturally seek help from senior colleagues, but don’t stop there! Engage with everyone on your team, asking questions individually, regardless of their experience level.  
  
And don’t hesitate to ask the same question multiple times; different perspectives can deepen your understanding. 
  
Here’s what I did: I spoke with seniors for insights on projects they were passionate about, reaching out to four colleagues for introductions to five different projects. I also chatted with interns to learn which concepts and tools were essential for getting started. Having an “administrative buddy” helped me quickly set up accounts, permissions, and tools, making it logical to ask interns, as they had just gone through the onboarding process. 
  
Talking to each team member individually has valuable side benefits beyond the technical knowledge; it helps build connections and strengthen relationships. 
  
I shared snippets of my personal and professional experiences during technical discussions, which often encouraged others to open up. Asking about the team’s history helped connect the dots and provided better insight into our projects’ scope and structure.

You’re probably eager to get started, solve problems, share your experiences and show your expertise. That’s fine, but don’t force it. Now is the best time to shift the focus from yourself to your new team. Step back and listen. 
  
You’ll naturally learn your team’s workflow through meetings and daily tasks. To make this process more efficient, ask questions about why things are done a certain way and how the team established their procedures and processes. Avoid pushing your previous methods right away; instead, take time to observe the team dynamics. 
  
I had to figure this out for myself.  
  
Trained as a Scrum Master, I naturally leaned toward Scrum practices, but my new team is quite anti-Scrum. They use a simple Kanban board, are flexible with sprints, and keep meetings to a minimum. Initially shocked, I chose to observe instead. After a few months, I realized they’re not anti-Scrum; they’re anti-ceremonies that didn’t work for them. Embracing their agile approach shifted my perspective, and I learned to appreciate the simplicity. 
  
You can only improve things once you understand how and why they’re done. Be patient; your presence is already changing team dynamics, so avoid causing chaos by trying to “fix” everything at once. 

Those daily meetings described in the intro – where people are talking but you don’t understand much – will happen for some time. It’s okay. For now it’s good enough to be aware of what’s generally going on in the team.   
  
Recognize keywords which are frequently popping up. Instead of focusing on what you don’t know, focus on deepening your knowledge one area at the time. Don’t allow yourself to get overwhelmed with other areas you haven’t tackled yet. You’ll get there. 
  
By the end of onboarding, you should have covered most areas, though this depends on your team’s focus. If your team works on a single feature, it’s easier, but if they juggle multiple products, like mine, it’s more challenging. That’s why I prioritized learning products one by one with my manager. 
  
So, adjust the pace of switching tasks to your cognitive style. If you’re focused on one area and more productive sticking with it, let your colleagues know. Just ensure it aligns with team priorities. 

Pair programming is a great way to get a feel for a project. When tackling your first tasks, you likely won’t be working alone. Typically, you’ll either shadow someone or be mentored while you type. However, neither fully captures the benefits of proper pair programming. 
  
When I pair-programmed with colleagues, we made sure to follow the best practice: one person navigates while the other types, and we regularly switched roles. This helped me gain confidence in making changes and understanding the project’s domain. Plus, pair programming turns the task into a team effort, reducing individual pressure.

Onboarding is a great time to brush up on the basics, something we rarely have time for during regular work. As a new employee, you’re encouraged to spend time learning. 
  
If you struggle with Imposter Syndrome, use this period to address any knowledge gaps. Don’t worry about looking inexperienced – unless you misrepresented yourself during interviews, it’s perfectly fine to work on areas for improvement. 
  
I revisited Java basics, a language I hadn’t touched in over five years. I asked for a book recommendation, and it paid off. Starting from the fundamentals helped me build confidence and later tackle more advanced topics.

Being relaxed during onboarding doesn’t mean being lazy; proactivity matters. If you need something or feel unsure about your progress, ask for feedback and act on it. 
  
However, these tips may not always apply – perhaps your team is just forming, or you were hired for a short-term project. Be pragmatic and adapt to your situation. 
  
Successful onboarding is a team effort and vital for the organization’s success. By sharing my experience, I hope to inspire you to create a welcoming environment for newcomers – after all, we’re all starting somewhere!