Winning over hearts and minds work: ADKAR my favorite change management approach(blog.dagworks.io)
blog.dagworks.io
Winning over hearts and minds work: ADKAR my favorite change management approach
https://blog.dagworks.io/p/winning-hearts-and-minds-at-work
30 comments
^ @asplake knows lots about this. He's literally written the book on positive change management: "Agendashift: Outcome-oriented change and continuous transformation". If you're at all involved in organizational leadership, do yourself a favor and read his book.
> Without mentioning "overcoming resistance to change"
Isn't that implied in getting someone to change?
> organisational development (OD) community
Could you explain how OD relates to change management? ChatGPT says they have some overlap but they aren't the same thing -- and the post is about change management not organizational development. So I'm confused by your comments :)
Isn't that implied in getting someone to change?
> organisational development (OD) community
Could you explain how OD relates to change management? ChatGPT says they have some overlap but they aren't the same thing -- and the post is about change management not organizational development. So I'm confused by your comments :)
Yes, I very much took the resistance to change aspect as implied.
The line between change management and OD is blurry, not least because one is often used to achieve the other. That it is so often misapplied perhaps explains my response. Not that I take it back!
The line between change management and OD is blurry, not least because one is often used to achieve the other. That it is so often misapplied perhaps explains my response. Not that I take it back!
Fair enough! Thanks for explaining.
[deleted]
I recall being at an organization where an engineer wanted to clean up the code. He ran complexity analysis and showed some of the Java functions had a cyclomatic complexity of 1000, when it is generally agreed that this should never be more than about 20. This was because Android had a "dex limit" in the number of methods it could support at the time. Engineers couldn't add new methods because of this limit so all the functions just got bigger and bigger and no one other than the original engineers could make changes.
This engineer tried to make the team aware but the senior engineers were, IMHO, wanting to avoid culpability more than looking for a fix. The bad practice had fixes but they were expensive and they had kicked that can down the road for years. It was also a form of job security.
He was marginalized and eventually fired for having a toxic attitude.
After reading this post, I really wonder if he could have done anything differently. His attempts were sabotaged by people more committed to protecting their fiefdoms and 401k trajectories.
This engineer tried to make the team aware but the senior engineers were, IMHO, wanting to avoid culpability more than looking for a fix. The bad practice had fixes but they were expensive and they had kicked that can down the road for years. It was also a form of job security.
He was marginalized and eventually fired for having a toxic attitude.
After reading this post, I really wonder if he could have done anything differently. His attempts were sabotaged by people more committed to protecting their fiefdoms and 401k trajectories.
Yep, I can most definitely empathize! When I was a fresh grad I remember realizing something similar -- some people prefer "to not rock the boat" if they're comfortable...
I think the key here is in determining the "desire" part for the people involved. Sometimes you need to get creative, but I acknowledge that this part can be a tough nut to crack sometimes. You can therefore also use ADKAR to figure out why your change might not go through now that I think about it.
I think the key here is in determining the "desire" part for the people involved. Sometimes you need to get creative, but I acknowledge that this part can be a tough nut to crack sometimes. You can therefore also use ADKAR to figure out why your change might not go through now that I think about it.
> people more committed to protecting their fiefdoms and 401k trajectories.
Well yeah, why shouldn't they be? If I ever have to choose between what some young whippersnapper says is a good refactor for an android app and what's best for me and my family, I'm picking the latter every time. In a well-functioning company these two things wouldn't be at odds.
Well yeah, why shouldn't they be? If I ever have to choose between what some young whippersnapper says is a good refactor for an android app and what's best for me and my family, I'm picking the latter every time. In a well-functioning company these two things wouldn't be at odds.
What’s the general solution here? The problem is misalignment of incentives. But paying people more won’t magically fix it. Is it that mgmt needs a lot more technical understanding? This crops up all the time you’d think there’d be a well worn solution.
I can imagine working with this guy is a total joy. First he starts writing some bespoke Python package that he wants to force the entire team to use. He describes it as something "that __makes__ users naturally write code that adheres to software engineering best practices" (emphasis mine). Generally, "software engineering best practices" means "this is my strong preference and the rest of you should adhere to it".
He then begins running around, breathlessly ADKARing everyone into using it. After reading the article, ADKAR appears to mean beat everyone over the head with your solution until they give you the greenlight so you stop bothering them.
Or put another way: ADKAR is a process by which you make the effort of adopting the change appear easier than dealing with someone harassing you about the change every single day.
He then begins running around, breathlessly ADKARing everyone into using it. After reading the article, ADKAR appears to mean beat everyone over the head with your solution until they give you the greenlight so you stop bothering them.
Or put another way: ADKAR is a process by which you make the effort of adopting the change appear easier than dealing with someone harassing you about the change every single day.
Thank you for sharing this acronym. For a while I was using the concept of marketing awareness stages to foster change in my engineering teams. In marketing people are either unaware, problem-aware, solution-aware, product-aware, or fully aware. ADKAR seems to map out similar phases. Will try it out.
The specific example here - pushing an organization to use your bespoke Python framework, that you believe to be the best solution for all Python programming tasks - does not inspire confidence.
Can you be more specific, confidence with what exactly? :)
I'm interpreting your reaction to the thought that "if it's so good, why doesn't it sell itself?" -- in which case I would suggest you put yourself in the shoes of someone on a platform team, or a manager trying to get everyone to do things a certain way, and they'll explain that for brand new greenfield things, adoption is generally much easier, but for existing people and processes change is difficult - so even with a better solution it just doesn't sell it self without some help.
I'm interpreting your reaction to the thought that "if it's so good, why doesn't it sell itself?" -- in which case I would suggest you put yourself in the shoes of someone on a platform team, or a manager trying to get everyone to do things a certain way, and they'll explain that for brand new greenfield things, adoption is generally much easier, but for existing people and processes change is difficult - so even with a better solution it just doesn't sell it self without some help.
Sometimes the people involved have to be ... exchanged for other people. I've probably been that person at times and seen others needing to move on for the benefit of everyone. Yet staying in the familiar can be deceptively comfortable.
“better practices like MLOps, LLMOps”
Umm, what do these practices entail exactly? MLOps I can guess, but I think is probably of questionable utility, and certainly not a mature enough practice to outright assume it’s “better” than existing practices.
LLMops I hadn’t heard of, but it sounds like a really bad idea.
Umm, what do these practices entail exactly? MLOps I can guess, but I think is probably of questionable utility, and certainly not a mature enough practice to outright assume it’s “better” than existing practices.
LLMops I hadn’t heard of, but it sounds like a really bad idea.
Here's a reasonable post by nvidia that can help put the terms in context (take it with a grain of salt given the marketing overtones) https://developer.nvidia.com/blog/mastering-llm-techniques-l... .
MLOps is akin to DevOps but takes into account getting machine learning models to production and how to instill a process so that you can iterate and avoid outages, etc.
MLOps is akin to DevOps but takes into account getting machine learning models to production and how to instill a process so that you can iterate and avoid outages, etc.
“What Is LLMOps?” https://www.databricks.com/glossary/llmops
I was equally wary because I assumed a similarity to “ChatOps” but, in fact, MLOps and LLMOps are about operating ML/LLM services, not using them to automate ops.
> Personnel in data organizations are notoriously stubborn with adopting change.
I think you could remove the words 'in data organisations' and get a sentence that is even more true.
It is very rare to find people in an established organisation who are up for change without significant management. I suppose that is inevitable when you think that someone has been doing a job for years and suddenly, here you are saying that things need to change. What they hear is, naturally, that they are doing a bad job.
I think you could remove the words 'in data organisations' and get a sentence that is even more true.
It is very rare to find people in an established organisation who are up for change without significant management. I suppose that is inevitable when you think that someone has been doing a job for years and suddenly, here you are saying that things need to change. What they hear is, naturally, that they are doing a bad job.
Very true!
Author here, happy to answer questions/criticism.
Otherwise if it's more cathartic, feel free to post stories of how you've seen/lived through a change management process... good or bad.
Otherwise if it's more cathartic, feel free to post stories of how you've seen/lived through a change management process... good or bad.
What does "Awanesss", "Kaniolige" and "an Refovation" mean on the first image?
that's DALLE3 trying to write words and not succeeding. I used the intro paragraph as text and asked it to make an image for the post :)
[deleted]
[deleted]
My favorite change management approach (is totally not made up, I promise) consists of three main pillars.
It's also a well known fact that tripods and pyramids and triangles are mystically powerful, so my methodology is totally legit, obviously.
- Pillar 1: Every opinion counts, but only if you can do the work
This boils down to removing managers who are not individual contributors from the decision making process (and potentially from the teams). I hear that Facebook are trying this out after their endless money started drying out. My advice is to not allow engineering managers who are not individual contributors in the first place.
- Pillar 2: Working without distractors, aka let us work without poker cards (aka estimations) and micromanagement check-ins (also known as standups)
This boils down to removing positions not related to building software from the process of building software. Such actions can be mind blowing to some, because it's a well known fact that we, engineers, can't make any decisions for ourselves what to build and what is its priority, and we obviously need some non-engineer who knows better to tell us what to do. But I urge you to entertain the thought and make a mental leap to a world where software engineers are capable adults who can build a great product, prioritize their work, and ship with confidence without a person with a BA degree called Josh who is "overseeing" their work.
- Scrum Master (that can be a full time job, apparently). Just don't use SCRUM as a whole, and if you have to, try to only incorporate some stuff from it if the engineers see as useful (like retros, or some form of daily sync). Anything else that stipulates also a role/position or some weird ritual with candles or cards, just throw it out of the window and thank me later.
- Product Owner/Manager. In corpo world, MITM is not a type of attack, but an actual job description, a well respected middle man who gets paid for repeating things (poorly) from one group to another and gets to, for unknown reasons, decide what is important and what's not. Just don't do this to yourselves and allow your developers to talk to "outside" people.
- Agile Coach (yes, that exists as a full time job as well) from the process of software development. Motivate the developers by spending the savings from not hiring these roles into the engineering team's next salary increase.
- Pillar 3: It's done when it's done
The more management types are sniffing around trying to pressure you into release or how to build whatever feature, the more they are slowing the process of a good, reliable software with well thought of features. So they just have to be patient or hire a new development team. It's done when it's done, deal with it.
Conclusion
I call this approach to change management: "Great Tactics For Owning Management", in short GTFOManagement, and I fully intend to write a book about it and then not release it.
It's also a well known fact that tripods and pyramids and triangles are mystically powerful, so my methodology is totally legit, obviously.
- Pillar 1: Every opinion counts, but only if you can do the work
This boils down to removing managers who are not individual contributors from the decision making process (and potentially from the teams). I hear that Facebook are trying this out after their endless money started drying out. My advice is to not allow engineering managers who are not individual contributors in the first place.
- Pillar 2: Working without distractors, aka let us work without poker cards (aka estimations) and micromanagement check-ins (also known as standups)
This boils down to removing positions not related to building software from the process of building software. Such actions can be mind blowing to some, because it's a well known fact that we, engineers, can't make any decisions for ourselves what to build and what is its priority, and we obviously need some non-engineer who knows better to tell us what to do. But I urge you to entertain the thought and make a mental leap to a world where software engineers are capable adults who can build a great product, prioritize their work, and ship with confidence without a person with a BA degree called Josh who is "overseeing" their work.
- Scrum Master (that can be a full time job, apparently). Just don't use SCRUM as a whole, and if you have to, try to only incorporate some stuff from it if the engineers see as useful (like retros, or some form of daily sync). Anything else that stipulates also a role/position or some weird ritual with candles or cards, just throw it out of the window and thank me later.
- Product Owner/Manager. In corpo world, MITM is not a type of attack, but an actual job description, a well respected middle man who gets paid for repeating things (poorly) from one group to another and gets to, for unknown reasons, decide what is important and what's not. Just don't do this to yourselves and allow your developers to talk to "outside" people.
- Agile Coach (yes, that exists as a full time job as well) from the process of software development. Motivate the developers by spending the savings from not hiring these roles into the engineering team's next salary increase.
- Pillar 3: It's done when it's done
The more management types are sniffing around trying to pressure you into release or how to build whatever feature, the more they are slowing the process of a good, reliable software with well thought of features. So they just have to be patient or hire a new development team. It's done when it's done, deal with it.
Conclusion
I call this approach to change management: "Great Tactics For Owning Management", in short GTFOManagement, and I fully intend to write a book about it and then not release it.
Yep! Very pragmatic.
A few years ago I once ran a team without daily syncs etc. precisely to try to be remove all this stuff. Everyone still got their work done! But, an unintended side effect was that no body felt like they were on a team... which was a good learning that you still need to manufacture "together time" it just doesn't need to be in the form of status updates etc. Did you encounter something similar? or do you still have some sort of "sync" sessions.
A few years ago I once ran a team without daily syncs etc. precisely to try to be remove all this stuff. Everyone still got their work done! But, an unintended side effect was that no body felt like they were on a team... which was a good learning that you still need to manufacture "together time" it just doesn't need to be in the form of status updates etc. Did you encounter something similar? or do you still have some sort of "sync" sessions.
There can be sync sessions, of course, if people self organize and want that. My team particularly has a placeholder "sync" session every Tuesday, for example, and we might add more if we think it's needed. Other teams do their own thing, but very similar.
People also self organize in pairs or triplets or whatever they feel like on bigger tasks and everybody is encouraged to create issues and actively push for improvement of the software, even if they are huge refactorings or replacements of one system with another. Just ask the team for their opinion, support, and let's go! It just works, and it's super free format, not following any methodology. We also don't have a paternalistic figure from the business telling us what features to build or what is their priority, we decide that ourselves.
We do that based on frequent polls with internal company stakeholders, usage stats and feedbacks from clients, and what we ourselves think should be built.
Note that these dynamics were achieved and based on long, long working together and very high level of team members trust in each other and other dev teams. Note that most of us work remotely but there are also a couple of offices and sometimes some teams organize to meet in one of them for chat or whatever.
People also self organize in pairs or triplets or whatever they feel like on bigger tasks and everybody is encouraged to create issues and actively push for improvement of the software, even if they are huge refactorings or replacements of one system with another. Just ask the team for their opinion, support, and let's go! It just works, and it's super free format, not following any methodology. We also don't have a paternalistic figure from the business telling us what features to build or what is their priority, we decide that ourselves.
We do that based on frequent polls with internal company stakeholders, usage stats and feedbacks from clients, and what we ourselves think should be built.
Note that these dynamics were achieved and based on long, long working together and very high level of team members trust in each other and other dev teams. Note that most of us work remotely but there are also a couple of offices and sometimes some teams organize to meet in one of them for chat or whatever.
The arrogance of it! Without mentioning “overcoming resistance to change”, this smacks to me of that 1990’s kind of thinking. Try starting with what people actually want and what gets in the way of that – you might be surprised.
Edit: Be aware that the organisational development (OD) community has undergone significant change of its own since then. Check out dialogic OD, generative change etc (Bushe, Marshak), also anthro-complexity (Snowdon).
Traditional methods have their place (“technical challenges” in the jargon – Heifetz) but for anything interesting, their track record is woeful.