Changing Lanes Without Crashing: A No-BS Guide for Engineering Managers

What do engineering managers identify as the most challenging part of their job? The answer is nearly unanimous: managing people. Even with well-honed emotional intelligence and a naturally self-aware disposition, great managers will encounter situations that rigorously test their social and communication skills. 

If you could master just one skill to enhance your career as an Engineering Manager, let it be change management. In this post, I cover the key concepts you need to know about and their practical applications.

Understanding change

Change happens every week; sometimes, we deal with small changes like reducing the scope of a feature. Sometimes, we have to migrate from a monolithic application to a microservices architecture (or the other way around). 

Understanding how change management works will transform how you think about team engagement, prioritize initiatives, and coordinate multiple stakeholders and agendas within the organization. It is a judo move that will keep giving. 

Change is not about what you want to achieve but what others think they will achieve if they embrace change. Change is less about processes and more about people — their security, personal chances of success, and how much they can see themselves as individuals in the future you propose.

One of the biggest misconceptions is that change is a collective activity — it may look like it on the surface. Still, when it comes to implementation, it is actually a very individual process. You, as a change agent, need to be able to manage change at both the team and the IC level. 

No matter how strong the culture is in your team or organization, people adapt to change if you can help them answer very specific questions:

• What does this change mean for me?

• Is my job safe?

• Can I see myself in the future they are describing?

• Can I trust them? Why are they planning to do this?

• Will I still be okay with this team if I don't change?

Change also happens gradually and in stages

The Kübler-Ross model, or the five stages of grief, is often used to explain individuals' different stages when they experience dramatic change. From grief to job loss, we all have to deal with different nonlinear stages of adaptation.

Source: This variation of the Kubler-Ross Change Curve charts the phases of emotional states and actions against time in three stages.

You may not consider some of the changes you want to implement as dramatic as a job loss. However, even if the changes are mild, people will still experience different degrees of acceptance, denial, engagement, and commitment.

Change is not a linear process.

Most change initiatives fail because people driving change do not understand the individual needs of those who will implement the change. How do you implement change and, most importantly, make it stick?

In their seminal book, Switch: How to Change Things When the Change is Hard, Dan Heath and Chip Heath outline a methodology for instilling behavioral change. They call it “The Rider, The Elephant, and the Path,” and it is worth noting that they based it on the work of Jonathan Haidt, a renowned NYU psychologist.

(Note: You can watch Dan Heath explaining the whole concept in this video, but let me reiterate it for you quickly here, too.)

The premise behind this is centered on our knowledge about two separate systems in our brain — rational and emotional. As Haidt proposed, we should think about it as a rider on top of an elephant.

The Strategy

The rider represents the logical, rational part of your brain. That is the part that analyzes, plans and solves problems.

The elephant, on the other hand, represents your emotions. Needless to say, that is the system that powers up your actions.

As you already know, logic plays a surprisingly small part in driving our behavior, but even when we are aware of this, we still trust our ideas and the rationale behind them to drive action.

As Dan Heath puts it:

“The rider can try to lead the elephant or drag it. But if the two ever disagree…who would you be on? The elephant has a 6-ton weight advantage. And it’s exactly that power imbalance making adopting new behaviors very hard.”

Based on this, the Heath brothers concluded that to implement a change, you need to

• Give directions to the rider that will help them get to the destination,

• Motivate the elephant by tapping into emotions,

• and finally, shape the path to allow them to get to the destination quickly and without encountering any significant obstacles.

So, let’s go through those three elements in detail and discuss how you could implement them within your team.

1. The Rider

To motivate the rider, you need to do two things. First, you need to provide direction, which means explaining in detail the nature of the change. Second, you need to provide the knowledge that will help the rider get to the destination.

Here’s why: what manifests itself as resistance to change more often than not is just a lack of clarity. Not everybody can navigate uncertainty the way you might.

Understanding the next steps for something you have never done before does not come naturally. Humans like predictability.

For example, you may feel comfortable saying, “I don’t know if this is going to work, but let’s try it, test it, and see what happens.” For most people working in engineering, this feels natural and is a good way to propose changes, but the truth is that very few people feel comfortable not knowing if things will work. 

There will be anxiety and resistance whenever there is a chance for failure. This is why being agile is so hard. Stakeholders do not like uncertainty, and managing stakeholders effectively requires people who can drive change effectively.

In practical terms, as the Heath brothers point out, this involves following a simple, 3-step process:

Step 1. Reducing the analysis paralysis: We naturally tend to overanalyze problems. The trouble is that such behavior often leads to a complete failure in making decisions and moving forward. Thus, unless you translate the change into something your team is already familiar with, they might respond to it by overthinking it.

Step 2. Scripting the critical moves: The rider represents logic. Because of that, it will only respond to clear instructions. To motivate the rider, you need to translate the goals for the change into concrete behaviors it can perform. For the rider, clarity dissolves resistance.

Step 3. Giving the Rider a Compelling Destination: Logic thrives on goals. A compelling destination will engage the rider and motivate them to undergo the journey. So, give it a vivid image showing the possible outcomes of the change.

Speaking from experience, this might be the easier part - for example, it didn’t take too much to demonstrate the value of merging ~40 repositories into one. The paralysis came from technical questions such as “How are we going to deploy things?” or “Is this going to make Pull Request reviews more messy?”. My job was compiling pros and cons and demonstrating logically why we should move to a mono-repo. Yes, some things got a bit more complicated, but the benefits outweighed the downsides that were rightfully pointed out by the team. 

2. The Elephant

It is much harder to find arguments that ignite emotions than logic. However, at the heart of understanding how to motivate the emotional side of our brains lies the idea that smaller goals motivate us more.

Research study after another has proven that setting up big goals has a diminishing effect on our motivation. Goals motivate people only when they have received positive rewards and feedback from reaching them in the past.

That’s why, to motivate people emotionally, you need to break the change into smaller chunks to offer faster gratification for implementing it.

As Dan Heath notes: “Hope is elephant’s fuel. And when a task feels big, emotions will resist.”

How can we overcome resistance on a practical level?

Never initiate a big change in one go. Instead, break it into smaller steps and set milestones that deliver wins quickly for the team.

One scenario that comes to mind was getting our product and company SOC2 certified - I didn’t unload all of the requirements, checklists, and changes in one go. Instead, I started to make changes step by step, and the more sensitive ones, like installing a monitoring agent on everyone’s computers - had to be tackled initially, with assurances and clear outcomes. People were resistant because it felt like the company was becoming too rigid and that we would be monitoring their every step, where, in fact, all we needed was to ensure that our security baselines were covered. 

After explaining and assuring that I couldn’t care less if they also shop on Amazon during work hours (who doesn’t?), people eased into the fact that compliance does help us land more customers and makes everyone’s life easier in many aspects.

#3. The Path

The final element of the strategy is the path — the process both the rider and the elephant will go through to reach the destination. Just as you need to engage people’s emotions and give them logical arguments to overcome their resistance to change, you also need to shape the path to allow them to absorb it. After all, the fewer the obstacles to implementing the change, the more likely it is to happen.

This may mean automating certain processes, enabling extra resources while change is introduced, providing time and space for teams to communicate, and making data available across the business to build transparency. Removing friction will clear the path for bigger changes to be adapted.

Going back to the mono-repo migration, I have involved the team in figuring out the biggest risks and how to overcome them. Their main concern was managing big pull requests spanning multiple projects and how to roll out changes incrementally. The migration was going to happen regardless because we felt the pain of managing too many repositories - but rather than just implementing the change, we made the process highly collaborative so that everyone could participate and understand the final state before it even arrived. 

In Summary

To introduce change successfully, you should consider

• Defining what the future would look like.

• Defining the steps/ direction people can take to get there.

• Providing safety. Address how change will affect each person and help them see themselves in that future. You may need to do this with each person or each team separately.

• Defining concrete, small steps or actions the team can take to see progress. Use those steps to create ownership.

• Celebrating progress, even the smallest wins.

• Make sure you have involved everybody who may be affected in any way by the change.

• Make sure you involve even the people who will not participate directly but have some influence (PMs, QA, other stakeholders). 

Introducing change in your team or the organization involves two types of work that must happen in parallel.

The first type of work is the change itself — for example, helping your team adopt a new methodology, moving to a new delivery process, creating a new team structure, etc.

The second type of work is managing people during the change. It may involve running 1:1s with multiple people to manage their expectations, writing weekly updates on progress, and opening new communication channels for people to ask questions, etc.

Change management takes extra work that is not in your job description, and it is a thankless job because, if you are successful with the change, everybody should feel it was because they embraced it, not because you led it.

If you are interested in learning more about change management, here are a couple of great books to get started:

• Switch: How to Change Things When Change Is Hard, by Chip Heath and Dan Heath.

• Leading Change, by John P. Kotter, 2012

• The Little Black Book of Change: The 7 Fundamental Shifts for Change Management That Delivers by Paul Adams

• Making the emotional case for change: An interview with Chip Heath