maurits

Jan 2312 min read

How to overcome resistance to change in technology teams

Throughout my career in technology there has been a recurring theme of change and the accompanying struggle. Managers often attribute change project failures to resistance, but I've come to see resistance not as an obstacle but as an aspect that can be understood and turned to advantage: a drive for change.

In this article, I'll share practical insights and strategies, accompanied by a few anekdotes, for how to overcome with resistance to change, reshaping it from a challenge into an opportunity for growth and innovation.

In summary, my strategies for overcoming resistance are:

Embrace resistance: The value of your team members lies in their critical thinking and their drive for perfection, so absence of resistance should be reason for concern. Take input and feedback before anything else, and continuously test ideas and progress with stakeholders.
Create a desire to change: Use data to prove the benefits of the change clear to your team, both how the change affects their work as well as the value to the business. Acknowledge and address emotional concerns like fear of risks, negative past experiences, and breaking out of the comfort zone. Involve the team by actively listening, and share ownership and responsibility of the process and results.
Create a sense of urgency: Sometimes the status quo can be harmful, for example as a consequence of regulatory changes, changes in the competitive landscape, customer feedback, or team performance issues uncovered by an audit. Communicate these external and internal forces clearly and constructively to the team.
Create ability to change: Make sure that the organization has all the knowledge, expertise, and tools available to execute the change. Prepare the organization for the change, including roadmaps that may be affected. Budget well for training, consultants, hardware, and services.
Manage change like you would manage any project: Depending on the size of the project, create a vision, strategy, goals, and roadmap. Define roles. Constantly communicate progress and ask for feedback. Work iteratively and adjust the plan to changing and unforeseen circumstances.
Build trust: Create a safe environment in which people can criticize without retaliation and where their successes are celebrated. Lead by example by being the first to embrace the change and being transparent about your own struggles. Actively ask for feedback and show what you have done with that feedback. Push control and ownership down the chain of command. Never avoid confrontation and allow people to move on to other opportunities, if the new situation does not match their preferences.

Bonus: don't believe the myth that a majority of change projects fail.

1. Embrace resistance

Resistance to change is often misunderstood and unfairly labeled as a problem. Refer to it as 'willingness to change', and instead of supressing resistance, consider how you can increase willingness. The 'resistance' is then valuable input to help improve the change plan.

Consider that your team members probably have a different perspective on the current situation and the proposed change because their experience differs from yours. Their input can reveal your blind spots and improve the proposed change. A lack of feedback (or lack of resistance) should be a reason for concern.

Acknowledge that a change can be risky. While the current situation might not be ideal, at least it's familiar and predictable. Share your plan for reducing the risk of the change. Before and while changing, continuously test ideas and evaluate progress with stakeholders.

In my first role as team leader, I noticed some issues with our work processes. We were bogged down by bureaucracy, moving at a snail's pace, stakeholders and team members were unhappy. Stakeholders had to fill out an extensive "Project Request Form" (PRF), projects were scheduled far into the future rather than aligned with stakeholder planning, and results weren't shared until they were deemed "done." I figured we could fix things , amongst others by scrapping the PRF entirely and by planning sessions with stakeholders on a regular basis. To my big surprise, this idea and any other idea for change was greeted with resistance by the very team members that complained about the current situation. After a while they got under my skin because there was no movement and the resistance remained despite the problems that needed to be solved.

Things changed when I changed my attitude and worked with the resistance instead of against it. I learned why my ideas weren't accepted and implemented. The team members told me that they vividly remembered the chaos from the days before the PRF and were afraid it might make a comeback. In a series of sessions, we worked together to identify the problems with the current setup and the worries from the pre-PRF era. The resistance transformed into a collective willingness to change. We eventually settled on our version of Kanban, keeping the planning and analysis perks of the PRF while bringing back flexibility and the ability to shift gears on short notice. In conclusion: by embracing resistance, I was able to get quality input from the team improve the change and the resistance turned into high willingness to change.

2. Create a desire to change; want

Change takes time and effort and might pose a risk. When the advantages of change aren't immediately apparent, people often prefer maintaining the status quo.

Identify what drivers are important to your team and explicitly illustrate how the proposed changes benefit those. Whether the team's drivers are factors like product quality, efficiency, reputation, or autonomy, or anything else, consider why the team would want to change.

Highlight the organizational benefits stemming from the change, such as cost reduction, improved processes, or other advantages.

Present a compelling case using both rational and subjective arguments. Utilize data and indisputable evidence for rational persuasion, while also highlighting the more subjective aspects such as making work more enjoyable.

Remember point 1 about embracing resistance. Don't expect to have your arguments blindly accepted, but test your thoughts, ask for feedback and adjust the change proposal.

When I aim to create a desire to change to release more often and earlier, I use this combination of arguments. I highlight the benefits to the team and the organization using rational and subjective arguments.

Rational team benefit: Large-release teams often encounter challenges despite rigorous testing, with releases containing numerous hard-to-fix bugs. In contrast, smaller releases boast lower complexity, resulting in fewer, less expensive bugs that are discovered faster and fixed more easily. This enables roll-forwards instead of roll-backs.
Subjective team benefit: more frequent releases with fewer bugs lead to higher customer and stakeholder satisfaction, thereby improving the team's overall reputation.
Rational organizational benefit: Any completed but unreleased work holds potential monetary value for the organization. If you have a great PO, then they calculated that potential value. Every day that the completed work remains unreleased is missed revenue, while the investment (cost of engineers for example) is already done. This increasing cost of delay can be illustrated effectively with visual tools such as graphs.
Subjective organizational benefit: Occasional large releases often induce anxiety and stress, especially when dealing with potential mistakes or complex cross-team dependencies. Too many organizations have a yearly 'release freeze' to deal with the risk during their peak season. Frequent and early releases contribute to a lower-stress organizational environment, fostering better cooperation and alignment among teams. This approach makes navigating changes in direction more manageable and less disruptive and removes the need for a release freeze.

3. Create a sense of urgency; must

In the dynamic landscape of your business, change is not an option but a necessity. For leaders it is crucial to continuously raise awareness about the evolving context in which your organization operates. This heightened awareness ensures that when change becomes imperative, your team not only senses the urgency but comprehends the imperative need for action.

Context changes can stem from a multitude of sources, both external and internal. External factors include regulatory alterations (e.g. GDPR), shifts in the competitive landscape with new market players, evolving customer feedback, and fluctuating security and compliance concerns. Internal factors include changes in financial performance, team productivity issues, or shifts in organizational culture.

Regularly updating your team on these contextual developments establishes a proactive approach. By keeping them informed, you pave the way for a shared understanding that change is not just an option but a collective obligation. This practice builds a sense of urgency organically, making your team more responsive and adaptive to the evolving needs of the organization. In essence, by creating this heightened awareness, you ensure that when the call for change arises, it's met with a united understanding that we must change.

In a past role, I collaborated with skilled engineers who had a decade-long history with the company's flagship product. Their expertise and direct customer connections made them product and customer needs experts. I wanted to introduce a process to gain customer insights through other departments, but the team didn't feel the need, because "what could those new people tell us what we don't already know". So they confidently rejected any proposed changes from junior colleagues and each feature change was greeted with fierce resistance. They wanted the best for the customer and didn't realize they overlooked the evolving customer culture and expectations.

To settle the dispute, I decided to investigate these 'junior' feature requests, their relation to the market, their impact on customer satisfaction, and contribution to revenue & market share. Research by the Product Owner showed that the market had evolved and customer expectations had changed, but the team experts confidently claimed that this didn't apply to their customers. Then the Customer Care department showed an increase in complaints from customers due to unmet needs, and this got the team experts wondering. Finally, the Marketing & Sales department showed a decrease in marketshare (despite increase in revenue) and linked it to lower customer satisfaction and product quality. These results created awareness and a sense of urgency for the team; they realized that we must change how we learn about customer needs and demands. We developed a process to continuously gain customer and market insights to stay aware of the changing context.

4. Create ability to change; can

Once you have embraced resistance, and your team wants to change, and a collective sense of urgency permeates the organization, the stage is set for successful execution of the proposed changes. However, even with this alignment, resistance may persist if the organization lacks the ability. The key to successful change lies in various factors.

Start by ensuring that the organization possesses the necessary knowledge and expertise. Acquiring knowledge can be facilitated through training, while expertise can be bolstered by recruiting experienced professionals or enlisting external consultants.

Equally vital is guaranteeing that your organization is well-equipped with the essential tools for change, including the required hardware and software. This foundational infrastructure is indispensable for the seamless implementation of proposed modifications.

Consider the organizational readiness for change, taking into account factors like timing. Optimal conditions may necessitate waiting until after the peak season to initiate a substantial change project. Anticipate potential productivity dips and errors in the initial phases of implementation, making it imperative to adjust the roadmaps of impacted projects accordingly.

Allocate your budget wisely for this change initiative. While some aspects may appear costly, it's crucial to remember that the expense of a failed change outweighs these initial investments. A well-planned and adequately resourced change effort is more likely to yield positive and lasting results.

I once worked with a team grappling with planning issues – projects extending beyond timelines, unclear or missing requirements, and frequent mid-project direction shifts rendering completed work worthless. We delivered a valuable, bug-free product, but dissatisfaction prevailed about the process. When a team member suggested adopting Scrum, the whole team enthusiastically hopped on board.

We initially started the change project like we started any software development project; we just started. But this approach exacerbated the problems. We had massively long meetings, a rigidly fixed 4-week sprint that hindered adaptability, and we had noticeable productivity decline. We lacked the ability to change.

I secured a team-wide training budget, required Scrum experience for new hires, put up a white board, displayed the scrum board and burndown charts on monitors, and shared change progress and impact with stakeholders in the sprint review.

These changes proved transformative to our ability to change. The team reduced sprint length to 2 weeks and found ways to increase flexibility within sprints. Stakeholders accepted initial dips in productivity and soon noticed increased productivity, accountability, and predictability. Our success became a model for other teams, inspiring a positive ripple effect across the organization.

5. Manage change; will

Overcoming resistance is an ongoing process, not a singular event. A change is a project and should be managed as such. Bad change management will lead to a return or increase of resistance.

Crafting a comprehensive framework for successful organizational change involves the meticulous development of a vision, strategy, and a roadmap enriched with achievable milestones. Alignment within the affected organization is critical.

A risk analysis can be useful, focusing not only on identifying potential challenges but also on formulating strategies to overcome them early in the change process.

Roles and responsibilities must be clearly defined to establish a collaborative and accountable environment. Identifying change agents, those driving the change, and stakeholders who will be affected and should be kept informed ensures a shared commitment. Delegating tasks, granting ownership, and managing expectations are integral components of this role clarification process.

Have transparent and regular communication with stakeholders. Openly sharing progress, actively soliciting feedback, and adapting plans based on insights received contribute to a culture of transparency and responsiveness.

Embrace an iterative and flexible approach. Aim first for a Minimum Viable Product (MVP) or even start with a Proof of Concept (PoC). That allows for gradual adjustments, learning from each phase, and adapting strategies based on evolving insights. This iterative methodology ensures that the change process remains responsive to the dynamic needs of the organization.

The situation after the change is your product, the change is your project.

I recently worked with a team grappling with persistent issues in their software product. Stakeholders were unhappy because the product was buggy and they rarely saw new features. The team was unhappy, constrained by a perpetual bug-fixing cycle, and lack of time and people to add functionality.

The team's senior architect proposed a transformative solution: transitioning from their monolithic product to a set of microservices. This change would require a change in the technology stack, product strategy, and the workflow. This was a big change that needed proper management.

In the first investigative phase, I asked the senior engineer to build a PoC. I used that with the Product Owner to create a vision for the future situation. I mapped out a meticulous plan, identifying incremental milestones to transition to a microservices architecture. This involved systematically extracting functionality from the monolith and establishing corresponding microservices. To maintain a balanced sprint focus, we dedicated a fixed timeframe in each sprint to this transformation, seamlessly interwoven with new feature implementations and essential bug fixes. Transparent communication with stakeholders throughout this process kept them informed and engaged, as they witnessed not only ongoing improvements but also the addition of new features.

This deliberate, step-by-step approach not only resolved the immediate issues but also laid the foundation for sustained improvement and innovation in the team's software development practices.

6. Build trust;

I wasn't sure whether I would add this point, it seems so obvious it's almost a cliché. But too many people don't realize just how important trust is and how easily it can be broken.

In one instance, a CEO vigorously advocated for risk-taking and boldness within the organization, only to sharply criticize those who made mistakes the very next day; he did not build a safe environment for risk-taking. Another example is of a Product Owner who emphasized the importance of data-driven decisions for her team, yet consistently relied on her own 'excellent intuition' for decision-making.

Fortunately, positive leadership examples abound. Another CEO, aiming to promote CO2 reduction, led by example, opting for public transport. Also, I once had a manager who, in moments of disagreement, pushed control and ownership down to me by encouraging me to try my approach. In case of failure,I learned and felt supported to discuss the situation with him. In case of success I felt encouraged.

Trust can be built and cultivated in several ways.

Lead by example and show the behaviour that you want to see from the people in your organization.

Create a safe environment for experimentation and risk taking. People are new to the change, so mistakes will be made. As a leader, take ownership of mistakes that are made, and celebrate the individuals who succeed.

Ask for feedback and show or prove what you have done with the feedback. This is active listening.

Finally, push control down the chain of hierarchy, avoid micro management. A professional who owns a problem is more likely to solve it and learn from it.

MDBLeadership