Change is necessary for growth in software engineering organizations, but adapting to change requires time, energy and resources that can detract from a focus on delivering value. While a certain degree of change is essential, excessive change can lead to change fatigue among developers.
Change fatigue is a negative response to change and can include apathy, burnout and frustration, all of which harm organizational outcomes. Gartner has found that in 2023, employees experienced four times as many organizational changes as they did in 2016.
For software engineering teams, these changes can include context switching across tasks, shifts in project priorities, adoption of new tools and technologies, as well as reorganizations.
The consequences of change fatigue are severe, including resistance to change and employee burnout. Given the prevalence and impact of change fatigue, the key question for software engineering leaders is, “How can I address change fatigue to reduce developer burnout and sustain organizational agility?”
Recognize the Full Scope of Changes That Are Impacting Developers
Software engineering leaders may think that they have an idea of all of the changes that are impacting their teams, but there are multiple factors that create an empathy gap between leaders’ understanding and developers’ experience.
For instance, change fatigue could be unevenly distributed. Leaders tend to focus on the overall volume of changes that are impacting their teams. However, Gartner has found that the level of change disruption, not just the number of changes, is a primary driver of change fatigue. Consequently, even when teams within the same organization experience a similar volume of change, the varying levels of disruption can lead to an uneven distribution of change fatigue risk.
Change also comes from all angles. Engineering leaders may have visibility on changes specific to their organization, such as new technologies or delivery workflows, but the changes impacting developers exceed this narrow scope. Changes coming from the broader organizational ecosystem, as well as from personal and civic life, can compound the impact of changes specific to their role as developer.
Where leaders may see separate, discrete changes, employees are experiencing changes from multiple angles all at the same time. This can be exacerbated by managers communicating all changes with the same priority or failing to clearly prioritize, leaving employees to manage and figure out prioritization themselves. Software engineering leaders must adopt an employee-centric view of change to close the empathy gap that can be created by leaders’ and developers’ differing views of change.
To close the empathy gap and build organizational awareness of change fatigue, software engineering leaders should work with team managers to conduct simple surveys that assess the risk and impact of change fatigue across different parts of the organization.
These assessments should adopt an employee-centric perspective. Consider factors beyond work hours and the cumulative impact of changes on developers’ lives, including changes that engineering leaders may not have direct visibility and control over.
Based on these discussions, software engineering leaders can estimate the degree of fatigue experienced by different teams and build a heat map to visualize change fatigue hot spots across the organization.
Plan and Budget for Change as a Type of Work
Change is a constant in software engineering, but it is not without cost. Just as a factory spends time retooling and training for new widgets, software engineering also has switching costs incurred between projects and tasks.
While developers consider themselves adept at managing change, the primary issue contributing to change fatigue is not their ability to handle change, but rather the lack of effective organizational practices surrounding change management. Engineering leaders must recognize that change is a type of work, and having to deal with a lot of change means less time for focusing on core responsibilities.
Engineering leaders must take ownership of the situation and make the cost of change an organizational responsibility. This involves the following actions.
- Treating Change as a Portfolio of Investments: Evaluate each change initiative based on its potential value, cost and risk. Prioritize changes that align with strategic goals and have the highest ROI.
- Communicating the Value of Changes: Beyond simply communicating priorities, leaders must provide their teams with enough information to understand why a given change is needed and how it will improve things for the developers once implemented.
- Allocating and Prioritizing Resources for Change: Budget time and resources for learning, experimentation and adaptation to change, and recognize that change is not a one-time event but an ongoing process that requires continuous investment.
- Tracking Efforts Contributing to Change as a Type of Work: Ensure that the tasks and time needed to implement changes are reflected in teams’ Kanban boards and project plans.
- Promoting Open Communication and Empowering Developers: Clearly communicate the need for change and listen to developers’ needs and concerns.
- Monitoring and Adjusting the Change Portfolio: Regularly review the impact of changes on developer productivity, well-being and business outcomes.
This proactive approach demonstrates the organization’s commitment to supporting developers’ well-being and productivity. Reactive approaches — such as simply providing resources like meditation apps or health and fitness incentives — can be seen as shifting the responsibility for managing change fatigue onto the individuals experiencing it.
Empower Developers to Evaluate and Implement Changes
Just as developers consider themselves adept at handling change, software engineering leaders view themselves as effective change managers. However, the fact that change fatigue remains a significant problem indicates that current change management practices may not be as effective as leaders believe. Engineering leaders should adopt open-source change management, which involves shared decision making, joint employee-leader implementation planning and two-way communication
Developers’ perspectives on the value and necessity of a change can help to avoid investing in the wrong changes; eliciting their input from the outset is crucial to successful outcomes.
Software engineering leaders must adopt a developer-centric approach to change management that involves developers not just in the implementation of predetermined changes, but also in the process of determining the value and necessity of changes.
Practical steps to empower developers in the change management process include:
- Establishing an inclusive process for proposing, evaluating and prioritizing change initiatives (when changes are necessary due to factors not visible to developers, provide specific guardrails for their input and explain how their feedback will be considered within the broader context of the organization’s needs).
- Providing developers with the necessary context, data and resources to make informed decisions about the value and necessity of changes.
- Recognizing developers’ contributions to successful change initiatives and validating the impact of their input on determining the value and necessity of changes, reinforcing their sense of agency and purpose in driving meaningful improvements.
By adopting a developer-centric approach to change management, software engineering leaders can create a culture of shared ownership and continuous improvement, ultimately reducing change fatigue and driving better outcomes for their organizations.