Winning over hearts and minds at work: ADKAR my favorite change management approach
A post on five simple steps to help you affect change in your data organization, using Hamilton as an example.
Personnel in data organizations are notoriously stubborn with adopting change. Anyone who has tried to push through better practices like MLOps, LLMOps, new tools, or just general software engineering principles to make their team more effective, can surely attest to this fact. Why? Change is hard! People can be stubborn, stuck in their ways, and otherwise are trying to determine “what’s in it for me?” before going through with a change. You might have the best idea, or best solution, and hope that everyone just gets it, but if you can’t get them to “adopt” or “use” what you’re proposing, there is little value in what you have then. So what are you to do? How can you approach tackling this problem of getting people to change? Answer: ADKAR.
What is ADKAR?
It is a mnemonic to remember a sequence of steps to help you instill change. It comes from the field of “change management” (yes there is such a discipline!).
It stands for:
Awareness
Desire
Knowledge
Ability
Reinforcement (or reward)
Each word is a step that models the process you need to convert someone to change; the easiest change is when an individual gets the internal motivation that’s required to change their behavior. Therefore ADKAR is meant to help you frame what to do and in what order to get someone motivated:
Awareness: Explain the need for change.
Desire: Foster a desire to participate and support the change.
Knowledge: Provide the knowledge required to change.
Ability: Ensure the capability to implement the change.
Reinforcement: Implement measures to sustain the change.
I was fortunate to learn about ADKAR many years ago from a friend who helped banks with internal changes. I have successfully applied ADKAR in many different organizations and contexts in my career. It effectively revolves around communication, and you needn’t be an extrovert to execute this well, as ADKAR gives you the scaffold with which to base your communication on. So my hope with this post is that I’ll also equip you to be able to do the same, no matter the context (try to spot the meta structure of this post for example ;)). Afterall, the reward you’d get for pushing through a change successfully, is hopefully a good one. Like in a workplace setting, it will likely open up rewards (e.g. promotions), and other opportunities for you in the future (oh you managed to get initiative X done, why don’t we give you Y to now solve)!
An ADKAR example
Motivating Scenario
Let’s create some context to motivate an example scenario of applying ADKAR. So let us use Hamilton, an open source package that I created at Stitch Fix, that makes users naturally write code that adheres to software engineering best practices; it’s great for data, ML, and LLM, and even web work…
More specifically:
In the data world, e.g. creating machine learning models, fine tuning LLMs, pre-processing data, etc., the iteration cycle of development -> production is a cyclical process, where work invariably builds off of earlier iterations. At most companies this involves code touching many hands. If you can speed up these iteration loops, then the business can reap more benefits, because you can more quickly find what works and ensure you can quickly adjust to the changing world around you (e.g. bringing in LLMs).
Let’s say you are the MLOps platform person, or perhaps an architect, or even senior IC/manager/director of a team of data scientists and engineers. The team is hampered by slow code hand-off so iteration is slow (low ROI), and then when production outages occur (which they do too frequently), only the person responsible for the code can really fix/give any insight into it (bus factor of 1), and no-body likes inheriting anyone else’s work (no shared maintenance costs).
You are trying to bring in Hamilton, because it will standardize how everyone approaches writing code, and therefore provide a uniform way for processes and systems to be integrated which will solve all your problems! But, it’s not a drop in solution, you need people to write code that fits with Hamilton. The team is naturally averse to change, for some it could impact their perceived job security (yes, I’ve met individuals who like being the only one who knows things because it means job security), or are confident that their code is never the problem, and others it means redoing prior work, etc.
With that, let’s step through how one might use ADKAR to create a series of steps to get the team onboard!
Applying ADKAR
Here I’ll explain my strategy with each step, and provide some examples that I would use in our hypothetical (but realistic) scenario. You should be able to take what’s here and apply it to your situation.
Awareness: Highlight the Need for Change
I like to think there’s three things you have to do for this first step: (1) identify the problem(s), (2) find a good articulation, (3) communicate to your stakeholders!
Identify the problem. To be able to highlight the need for change, you need to crisply identify the problem(s) you’re trying to address. For example, begin by clearly outlining the problems — slow code hand-off, frequent production outages, the lack of shared maintenance, and that there is Hamilton, that can be a solution to these problems.
Determine how to articulate. My advice is to use real examples from your organization to illustrate how these problems are impacting efficiency and output to ground the problem(s). This makes the need for change more tangible and urgent. In our example we could reference a recent outage, or project that was impacted adversely when someone left, or teams did things in two different ways that lead to problems.
Communicate to stakeholders. You then need to target the places where your stakeholders frequent to tell them, usually multiple times. So get up on your soapbox and start telling people. In my experience you frequently need to tell people multiple times that there’s a problem and a solution to it. So speak at your all-hands meetings, go to other team meetings, and set up 1-1s. In our example I would engage with senior team members, data scientists, and engineers to discuss these challenges, ensuring that the need for change is understood across the board and that Hamilton can solve them well.
If you do this correctly, you should be able to ask people “have you heard about X” where X is the problem/solution, and they should nod their heads. So in our case here, we should be able to ask people “have you heard of Hamilton and the problems it’ll solve for us?” and they’ll be able to answer.
Desire: Building the Will to Change
So now you’ve got people’s attention, i.e. they’re “aware”, you now need to build the “what’s in it for me” part of the story. What you say here will obviously be different based on your context and circumstances, and even the individual. So I like to think the three parts are (1) be prepared to address concerns, (2) highlight benefits if change was implemented, (3) personalize the message.
Address concerns. You will likely get some push back, change is hard after all. If there are concerns, make them feel heard, and address their concerns if you can. These concerns should feed into ensuring you have the right content in later steps. With our example, we could acknowledge individual fears about job security, and the apprehensions regarding adopting new tools. We could emphasize that Hamilton is about making software engineering simpler and allows, for example, data scientists to focus more on their work rather than engineering. It is also a popular open source project so learning Hamilton will be transferable to other jobs, unlike the custom software engineering that everybody currently resorts to.
Highlight benefits. This part is important, as it will help (a) keep people thinking about the future, and (b) intrinsically motivate them to get the activation energy required to continue to have their attention for change to go through. In our example I would focus on how Hamilton can make their work easier and more efficient, which can mean more work done, and therefore better performance reviews for example.
Personalize the message. This one is hopefully obvious, but the benefits might not all be equal, and thus you will have to ensure you’re highlighting the right things to the right person. In our hypothetical example, I would tailor my communication to show how Hamilton can help each role specifically, from MLOps to data scientists to data engineers. For example for managers we could point out the benefits of faster iteration cycles and reduced dependency on individual knowledge silos, thereby making their ability to run a team smoother and simpler, which will make them look good.
If you do this correctly, then people will have the internal motivation to continue to take the time to implement the change. That is, you’ve answered for them “what’s in it for me?” and they’re bought in.
Knowledge: Providing the information to be able to change
So now people are motivated and know what and why they’re doing something, we now need to give them the knowledge they need to do it. Naturally this step is pretty tied into the next one - ability - so you might combine the two when planning things. The core part of this step is to make sure you have the knowledge resources required.
Knowledge resources. These are your reference materials/resources to, for example to use for training sessions (next section), that you’ll use to help get people up to speed on what to do, to implement your change. How much, and what you do will depend on your context and circumstances. For example, with data and technical work, this should include documentation, tutorials, hands-on sessions, case studies, examples etc. In the context of our example, we would have:
Reference materials on Hamilton, e.g.:
Documentation - https://hamilton.dagworks.io/en/latest/
Migration guide/best practices - https://hamilton.dagworks.io/en/latest/concepts/best-practices/
Tutorial material to help people grok the basics in a hands-on manner.
Tutorial notebooks that you’d use in a workshop/training session to teach people Hamilton.
Provide examples that relate to the problem to help them see what needs to be done:
Like examples found in the Hamilton repository
Or off-the-shelf bits of code from hub.dagworks.io that relate to the use cases internal to you.
After you have completed this step, people should have the knowledge required to implement the change, however they might not have the ability to do so.
Ability: Empowering one with the skills and resources required
Okay great, you’ve got motivated people, they have the knowledge, and now you need to make sure they have the space/time/ability to implement the change. For example, if you aren’t aligned with management to actually get time to (a) hold a training session, (b) carve out time within your project planning process then it’s unlikely change will happen. Similarly, if there aren't the computational resources, or if people don’t have the active skill set required, you’ll need to ensure people can get what they need. So I like to think about this part as (1) time, (2) skill development, (3) support.
Time. Change takes time. You need to ensure that you have the time to impart the knowledge required, and then also the time for them to make the change. So in our example, this would mean holding training sessions to ensure everyone has a chance to practice and internalize Hamilton. It would also mean aligning with management to ensure that work accounts for the Hamilton work that needs to be done. It could also mean that you spend more time yourself, and help write a script that can bootstrap work for people to reduce the time it takes to implement the change. Speaking from experience, you get a much better reaction if you can provide tools to help speed things up. In our example we could provide a means to use ChatGPT4 to help translate people’s code to Hamilton.
Skill development. If you’re trying to change how people do something by using a tool/new methodology, etc. then they’ll feel more comfortable and confident with it the better their skills are with it. So ensure that you can provide the right training sessions, content, and align it to make them master what you need to do. So in our example, this could manifest as ensuring the tutorials and examples show realistic code that maps to machine learning or LLM use cases, and then also helps cover the breadth of what one can do with Hamilton to ensure they know they can use it for various contexts easily.
Support. People will have questions and need help. Make sure you have a process or means to hear and understand what people’s needs are so you can quickly iterate and fill in any gaps you might have missed. Knowing what’s hard early will help ensure you can mitigate this for other folks if you can. So in our example this support process could manifest as (1) a dedicated slack channel to receive help questions, (2) regular office hours for people to drop by and cover some topic, (3) pairing/mentoring with folks on task so that they can learn from someone who knows Hamilton well.
Okay we’re almost there, one more step.
Reinforcement: Ensuring Long-term Adoption
So to make things stick, people need some sort of reinforcement/reward for implementing the change! The way that I like to think about this step is (1) monitor, (2) celebrate, (3) reward.
Monitor. There’s a thing called the Hawthorne effect, which basically means that if you observe someone, they’ll change their behavior because they’re being observed. So with respect to trying to implement a change, if people know that progress is being monitored and reported on, they’ll in all likelihood pay more attention to it. Since you monitor it, you can then use gamification to, for example, create a leaderboard or a weekly report etc. In our example we could have a weekly report of ETL/pipelines modified/incorporating Hamilton, which could be ranked by team; no one likes being last.
Celebrate. Most people like to be celebrated, so you should do a song and dance about people progressing/achieving/meeting the change required. In our example we could then dedicate some time in a weekly or bi-weekly meeting to report and praise/congratulate those that have implemented the change/moved things forward. For an introvert this step might be uncomfortable, but take it as a growth opportunity to channel your inner cheerleader here. Otherwise by celebrating it’ll hopefully create some fear of missing out (FOMO) for those that have not yet completed the change and thus encourages them to do so.
Reward. This should ideally be linked to the earlier step “desire” and reinforce it, e.g. reducing outages, and therefore better quality of life for folks. If you’re in management linking change to performance is a strong motivator 😉, but we don’t all have that carrot. For some, the reward might not be immediate, like faster iteration cycles (which might take a month+ to realize), in which case other rewards might be necessary to continue to motivate folks. In our example, we might ask management for a little bit of budget and reward folks with t-shirts or other swag as work is completed; e.g. the t-shirt might be something clever like “got Hamilton?”. Or, if more appropriate, rewarding teams for reaching milestones by taking the team out to lunch, or doing an outing, or in this remote world sending everyone something to then have a shared online experience.
That’s it. That’s the five steps! Not too difficult right?
To close
In this post I explained and then walked through ADKAR, a mnemonic to help you run a change management process by modeling what needs to happen to get someone to “change”. It is broadly applicable, and has proven to be especially helpful for me in my experience being in the data/ML world where I have tried to change habits/behavior or introduced new tools for adoption. I hope it’ll be just as effective for you. Please share this post if you found it insightful!
On the earlier meta-note, I have even used ADKAR to help me think about how to structure and what to cover in this post:
By writing this post I have created awareness of ADKAR.
Then hopefully created some desire to use it by selling how straightforward it is to use.
Provided you with the explanations and examples to give you with the knowledge and ability to try it yourself.
I however, won't be able to reinforce anything for you, but hopefully you being successful is the reward that will reinforce you using ADKAR again! That said, if you end up applying ADKAR, I’d love to hear how things went!
Want to know more about Hamilton or DAGWorks?
Just in case you’re in the data space and use python, check out Hamilton if you haven’t already, it’ll speed up how your team moves and operates by standardizing how code is written. It’s your one tool that is applicable across LLM workflows, ML pipelines, data processing, etc! If you’re after expertise and tooling for building out ML, DS, or LLM initiatives reach out to us at DAGWorks, we’d love to chat and learn more.