Factors for burnout as a software developer - part 2

TL;DR: I’m continuing my series of posts discussing my personal take on the factors that contribute to developer burnout. I’ll also be sharing potential workarounds and my thoughts on how to address these issues before they take a toll. This is the second part of the series—if you haven’t read the first post, you can check it out here.

The factors I’ll be covering in this post mainly reflect my experience working at a mid-to-large-sized software company, where multiple teams manage and develop different components of a distributed microservices architecture. That said, these insights may not fully apply to developers working in smaller teams or at startups.

🔄 Managing dependencies

What it looks like?

• Waiting for another team to complete their part before you can release a feature or continue work on your end.

  • Imagine a scenario where two systems need to be integrated. Your team is responsible for one of the systems. As planning progresses, it becomes clear that the other team, which manages the second system, needs to develop an API to expose the necessary functionality for integration. At first glance, it may seem like your team has to wait for that API to be completed before starting integration work.

• Repeated back-and-forth communication about issues that need fixing—issues that fall outside your team's scope and require action from another team.

  • These are situations where the other team has completed a feature, but when your team begins integration, issues are discovered in the feature’s flows that need to be resolved on their side.

• Failing, or being at risk of failing, to meet release commitments because necessary work is still pending with another team.

  • This is often a consequence of the above scenarios. Bottlenecks can occur when one team is blocked, waiting for another team to fix an issue—ultimately jeopardizing release deadlines.

Why I think this is a problem for developers is that, when this happens, you—as one of the developers on the team—end up feeling "stuck" and unable to ship the feature because something else needs to be fixed first. You might think this isn't a big deal, but issues like this slowly build up frustration over time and can eventually lead to burnout.

What can we do about it?

• Acknowledge that dependencies are often unavoidable—plan proactively to communicate and track them effectively.
  • In any collaborative effort involving multiple developers, it's essential to establish clear communication guidelines and rules. This ensures everyone working on a feature stays aligned and informed, especially when discussions or changes occur.
  • Collaboration tools like Confluence, Notion, or even Google Docs can be incredibly helpful. Choose tools that allow team members to comment, suggest edits, and contribute to shared specification documents.
• Establish team agreements on expected timelines (ETAs) for shared dependencies.
  • Sometimes, the other team may already be committed to different priorities and may not have resources immediately available to support your feature. This is especially common in large organizations where multiple efforts run in parallel.
  • Instead of pushing for immediate developer resource allocation, ask the owning team for a clear commitment on when they can deliver the needed functionality. This fosters mutual respect and helps with realistic planning.
• Shift the mindset from "us vs. them" to a collaborative "we."
  • At the end of the day, when we ship features, customers don’t see which team built which part—they see the company as a single entity delivering a solution.
  • Recognizing this can help foster a sense of shared ownership and accountability across teams. Adopting a collaborative mindset builds stronger working relationships and better outcomes.
• Practice empathy
  • Don’t lose sight of the "human factor," especially in large teams. Some developers may be ramping up, learning new systems, or still figuring out solutions to their tasks.
  • Show empathy and offer support where you can. Even small suggestions or a fresh perspective can help others get “unstuck” and move forward more confidently

🙀 Lack of context and the feeling of being left behind

What does it look like?

• Efforts are being made across the department or the wider organization that you're either unaware of or lack context about.
• You've been working on a feature story of your own for a week. During stand-ups, others are discussing something that seems important to the team, but you know nothing about it. You stay focused on your own feature and hesitate to dig deeper into what else is happening.
  • Some prime examples of this include conversations between product managers and senior developers about potential features that are being scoped and planned. Other examples can come in the form of cross-team developer efforts, such as framework version upgrades or improvements to the CI/CD workflow.
• You've been on a long holiday (two weeks), and when you return, it feels like a lot has changed or been introduced during your absence.
  • I’ve personally experienced this, and when I got back from holiday, it genuinely felt like I had been gone for too long. 🫠.

Now, why I think this is a contributing factor to burnout is because the feeling of falling behind can be mentally draining for developers. As time goes on and more unfamiliar topics keep coming up in conversations, you can gradually develop a sense of “fear of missing out.” Many good developers—especially those who are committed to continuous learning—fall into the trap of trying to learn everything, which often leads to information overload.

As a result, even though they make an effort to understand a wide range of topics, they often end up with only surface-level knowledge. In the worst cases, this can lead to frustration and mental fatigue from trying to absorb too much information in a short period of time. Most of the time, they don’t truly grasp the deeper meaning of the concepts they’re trying to learn.

What can we do about it?

• Don't be too hard on yourself.

  • Understand that you don’t have to learn everything at once—and most of the people you work with feel the same way. This is a common truth in the software industry, where things are constantly evolving: new tools, frameworks, and trends emerge all the time. What matters is not taking shortcuts—sit down, put in the effort, focus on learning the things you find valuable, and take things one step at a time.

• Ask incremental questions.

  • Ask questions that might seem basic. When you get an answer, follow up. Refine your questions based on what you've learned, and keep iterating until you can connect the dots and concepts. In a healthy software development team, no question is a dumb question.

• Write things down and add them to your to-do list.

  • The phrase "out of sight, out of mind" definitely applies here. Writing things down—especially through journaling or note-taking—gives you the ability to revisit them when you have time. Maintaining a to-do list with topics you want to explore helps you stay connected to ideas you’re curious about, even if you can’t dive into them right away.

• Block time on your calendar to read and explore topics that interest you.

  • This ties back to your to-do list. The best way to gain real understanding is to read source documents yourself—especially the ones everyone else is referencing. It may feel strange to take time to “just read” when you’re expected to write code and close tickets during company time, but investing that time pays off. Being informed directly, rather than secondhand, gives you clearer insight and builds long-term confidence.

🗣️ Too many meetings / interactions

What does it look like?

• Spending a significant amount of time chatting with other employees.
  • This might not be much of a problem in a remote work setup. But in an office environment—especially one where people feel comfortable casually interacting across roles—it can quickly consume your time. In open-office setups, spontaneous conversations are even more common and can easily lead to unintended distractions.
• Frequently being asked to jump on a call to "take a look" at something or to explain a concept.
  • This often happens within your own team, but occasionally someone in a non-technical role will request a “quick 10-minute” meeting—which then stretches into 40 minutes as the conversation gets sidetracked. And let’s face it: being asked to jump on a call ASAP can break your momentum and focus. Once the call is over, you have to switch your context back to what you were doing—which eats up even more of your time.
• A large portion of your schedule/calendar blocked by meetings.
  • As you become a senior or more experienced member of the team, you’re often invited to more meetings than junior developers. These may include feature specification reviews, product planning sessions, and cross-functional syncs. Your input becomes important to ensure technical feasibility and to provide insights into how the feature will work end to end.

I think this is a problem that often isn’t taken seriously enough. The core issue is context switching, which is a limitation all humans face—our brains need time to catch up and adjust to the information we consume and process, and too much of it becomes mentally exhausting. Simply being aware of this is just the first step; there are practical ways we can reduce excessive context switching and, in turn, improve our focus at work.

What can we do about it?

• Be mindful of your time and set clear boundaries.

  • A commonly recommended strategy is to block off the time of day when you're most productive. This requires self-awareness—knowing when you naturally focus best. Once you identify that window, protect it by avoiding unnecessary meetings and distractions. Personally, I block off my morning hours, when I’m most energized and focused, so I can do deep work before the rest of the day fills up with interactions.

• Find a balance—be willing to compromise, but make sure to write things down to avoid losing context.

  • Note-taking and journaling are incredibly valuable in software development. I strongly advocate for taking notes during meetings and discussions. This habit keeps your mind engaged and helps you maintain a clear grasp of what's being talked about. Notes also serve as a reliable reference point you can revisit anytime to recall decisions or discussions.
  • Remember, you don’t have to say yes to every meeting invitation. Assess the purpose and ask yourself: Does my presence add value for the team—and for me? It's okay to decline or request a summary when appropriate.

• Don’t skip preparation.

  • Make it a practice to block 10 minutes before each meeting to prepare and collect your thoughts. This short buffer helps your brain shift context and gets you mentally ready—think of it as a warm-up before a workout or a marathon.

• Practice empathy—especially for yourself.

  • This may sound familiar, but it's worth repeating: Don’t be too hard on yourself. It's easy to get lost in the work and feel like you're not doing enough, or that you're not processing things quickly enough to keep up. In those moments, pause. Slow down, breathe, and appreciate the effort you've already put in. Progress often takes more time than we give ourselves credit for.

🧘 Conclusion

Burnout in software development often stems from more than just workload—it’s rooted in how we collaborate, communicate, and manage our time. In this post, I unpacked how managing inter-team dependencies, lack of context, and excessive meetings contribute to developer burnout—especially within larger, distributed software organizations.

While these challenges are hard to eliminate, they can be managed through intentional practices like setting boundaries, improving cross-team alignment, and giving yourself space to learn and reset. Ultimately, fostering a collaborative, context-rich, and balanced work environment helps us build better software without compromising developer well-being.

Although these shifts in mindset and habits may seem small, I believe they can make a significant difference in creating a healthier, more sustainable experience for software developers.