Decide as a team we must… helping a team resistant to change

Dileep Marway - Oct 10 '22 - - Dev Community

Change is a difficult subject and it’s one that many struggle to implement. There is no shame in admitting that I have had times where change has been accepted by the whole team and other times it has not been accepted.

But, I’ve certainly tried to learn from each failure and also the successes.

When we are bringing change to a team, it can be extremely difficult. Generally changes fail to be accepted as team members cannot see the value clearly enough.

Resistance is a natural and normal reaction to change. What a leader should do is to diagnose the root cause of resistance.

Test your web and mobile apps on Android online Emulators. Ensure your apps are compatible across latest and legacy Android operating systems, devices, and browsers.

What is resistance to change

This is the reluctance of adapting to change when it is presented, and it can be shown in a flow of emotion through time as:

Denial > Anger > Confusion > Depression > Crisis > Acceptance > New confidence

It is normal to flow via these emotions, and the same can be applied to real-life scenarios such as grief.

What is important to accept as a leader is that everyone is unique in their mindset, people should not be judged, rather they should be understood as their views may be warranted. As a leader, you should be deeply cognizant of the fact that a team member may see something which you may have missed.

Three categories of Employees

Employees generally will fall into 3 categories in relation to how they accept change:

  1. Early adopters — those who are open and willing

  2. Hesitant to change — those who are 50:50 as to whether they want to accept the change

  3. Will not change — those who 100% will not accept the change

Based on my experience, the top causes of change resistance are:

  1. Mistrust and lack of confidence

  2. Emotional responses

  3. The fear of failure

  4. Poor communication

  5. Unrealistic timelines

Applying this to an automation framework, it is important to take the team on the journey. The initial step of selling the value of why we are pushing automation, what value it will add to others, how it will impact the team and what timelines are being set are key sells.

From my experience automation has failed to be implemented for me where product, engineering, Qa and the business are not aligned with the value of the change and how it will add value for them. If one person is against the idea, it will ultimately result in failure.

It is important to reflect that change is never easy, and at times we will succeed, whereas at other times it will feel very difficult. What is important is that there is always learning to be taken in both success and failure.

An approach which has helped me in the past is ADKAR.

What does ADKAR stand for?

  1. Awareness — do we know why the change needs to happen?

  2. Desire — is there any support for the change?

  3. Knowledge — do we have the knowledge in the team on how to apply the change?

  4. Ability — do we have the skills to implement the change?

  5. Reinforcement — how do we keep the change in place?

Test your mobile applications before going live. All you need is a computer with internet connection. Test your app android emulator for iOS on LambdaTest.

Compatibility testing tool

Relating ADKAR to selecting a new compatibility testing tool like LambdaTest:

  1. Awareness — do we have a clear objective on why we need the tool — for instance will using this tool mean that we can increase our device and browser coverage, thus giving a better user experience and we sell more products.

  2. Desire — is there a desire to give a better user experience to our users or it may be that there is support on the basis that it meets our cost needs.

  3. Knowledge — Is there any specialist knowledge needed to apply this change? In this case, it would be useful to have a team that has compatibility testing built into their testing approach.

  4. Ability — Does the team have the ability to understand the ‘why’ around the change. In this case the tool must be used and built into the testing plan.

  5. Reinforcement — to keep the tool in place, can we track usage and can we see if customer issues are going up or down around usage on particular devices/browsers.

What does ADKAR address?

It addresses poor communication as it forces you to plan out the approach for change and reinforcement drives communication.

Change is easier to be accepted where we answer these questions:

  1. What’s in it for me?

  2. What does it mean to me?

When you appeal to both individual and group concerns, you increase the chance of change success.

ADKAR cannot fix everything, but you can proactively manage and minimize the resistance.

Once you have determined the barrier point for resistance, you can work to get buy-in from the team.

I have personally used ADKAR to implement all forms of change and the main aspect which has helped me is the fact that it adds some forward planning and also minimizes the risk.

In this article, take a look at some aspects of simulation and some ways through which we can use iOS emulator for pc.

How can you take a team on a positive journey of change?

  1. Collect employee input before change takes place

  2. Show value in the change by educating employees

  3. Include the team in the change management plan

  4. Listen emphatically to employees

  5. Create a feedback loop to improve the plan

  6. Show passion and use data to back up your cause

  7. Identify influencers in the team

  8. Change can be broken into a mini proof of concept

Summary

Summarizing, change is never easy — though like anything, the challenge can be overcome if a team works together.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .