How Much Non-Development Related Extra Work is Reasonable?

In the ever-evolving landscape of software development, the lines between various roles often blur. As a developer, I found myself navigating an unexpected surge of non-development-related tasks this trimester due to a variety of team dynamics, including staff shortages and an overwhelming number of tasks concentrated in the testing phase of our process. This experience led me to ponder an important question: How much “extra” work is reasonable for someone whose primary role is development?

A Shift in Responsibilities

Over the past few months, I have been “shifting” wildly between my primary function as a developer and other essential roles within my team. With a shortage of team members and a lack of dedicated testers, I was often called upon to support product maintenance and manual testing tasks. The workload distribution for my role has been strikingly unbalanced—if I had to quantify it, I would say my time spent on development (Dev) versus QA/support work has skewed to roughly 1 to 4.

This leads to the crucial question: How much of this redirection is reasonable for a developer? Is it common for developers to wear multiple hats, especially during times of team scarcity?

The Nature of Work

One insightful perspective shared in the comments posits that there isn’t a strict separation between “development work” and “non-development work.” Instead, there is just work. As software engineers (SWE), our primary goal is to solve business problems, often using code as our tool. This implies that our responsibilities can extend beyond just writing code; they can encompass various tasks that contribute to the overall success of the project.

While it is essential to embrace a flexible mindset and take on necessary responsibilities, it is equally important to establish boundaries. If the workload becomes overwhelming, it is crucial to communicate with management about the situation. For example, if I am tasked with working on a new project while still addressing ongoing tasks, I need to inform my manager that my prior responsibilities will inevitably be delayed. Clear communication about priorities is key—if everything is deemed urgent, then nothing is truly a priority.

The Role of Experience and Position

Another comment rightly points out that the experience level of the developer plays a significant role in how these situations are navigated. Newer team members or junior hires often find themselves assigned various tasks, including those that aren’t strictly within their primary job description. While this can be a valuable learning experience, it can also lead to feelings of being overwhelmed.

As developers gain experience, they may find that their roles evolve. Some positions may shift towards non-coding activities, such as project management or cross-organizational collaboration. Understanding this evolution can help set realistic expectations for both employees and management.

Addressing the Workload

To tackle the imbalance of responsibilities, I recommend conducting a time inventory. By documenting how time is allocated across various tasks—be it QA, support, or bug fixing—developers can present a clearer picture of where deficits lie in the team. Reporting these findings to management at the end of a quarter can bring visibility to issues that may otherwise remain hidden.

Moreover, this practice can highlight the need for more test automation—an excellent way to alleviate some of the manual testing burdens. In my current team, for example, we lack dedicated QA personnel, so we write tests for our code. This proactive approach not only improves code quality but also allows developers to focus on core development tasks.

Conclusion

Ultimately, the question of how much non-development-related work is reasonable varies based on individual circumstances, team dynamics, and personal career goals. While it’s important to be adaptable and support the team during challenging times, it’s equally essential to advocate for oneself and ensure that workloads remain manageable. Effective communication, setting boundaries, and taking inventory of responsibilities can foster a healthier work environment where developers can thrive and deliver their best work.

Remember, at the end of the day, we are not just coding machines; we are problem solvers, collaborators, and innovators in a complex and dynamic workplace.