8 ms·

Winning over hearts and minds work: ADKAR my favorite change management approach

55 points by krawczstef 3y ago

gfysfm 3y ago
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.
- krawczstef 3y ago
  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.
  - paulryanrogers 3y ago
    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.
krawczstef 3y ago
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.
- rzzzt 3y ago
  What does "Awanesss", "Kaniolige" and "an Refovation" mean on the first image?
  - krawczstef 3y ago
    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 :)
skywhopper 3y ago
“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.
- CharlesW 3y ago
  “What Is LLMOps?” https://www.databricks.com/glossary/llmops https://www.databricks.com/glossary/llmops
  - cloakedcode 3y ago
    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.
- krawczstef 3y ago
  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-llmops/ 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.
deleted 3y ago
[deleted]
asplake 3y ago
> ADKAR, a mnemonic to help you run a change management process by modeling what needs to happen to get someone to “change”. 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.
- gklitz 3y ago
  [dead]
- krawczstef 3y ago
  > 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 :)
  - asplake 3y ago
    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!
    - krawczstef 3y ago
      Fair enough! Thanks for explaining.
- deleted 3y ago
  [deleted]
deleted 3y ago
[deleted]
koliber 3y ago
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.
xrd 3y ago
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.
- krawczstef 3y ago
  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.
- DonsDiscountGas 3y ago
  > 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.
- bomewish 3y ago
  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.
slingnow 3y ago
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.
jimnotgym 3y ago
> 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.
- krawczstef 3y ago
  Very true!
ath3nd 3y ago
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.

55 points by krawczstef 3y ago

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.

krawczstef 3y ago
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.
- paulryanrogers 3y ago
  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.

krawczstef 3y ago

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.

rzzzt 3y ago
What does "Awanesss", "Kaniolige" and "an Refovation" mean on the first image?
- krawczstef 3y ago
  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 :)

skywhopper 3y ago

“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.

CharlesW 3y ago
“What Is LLMOps?” https://www.databricks.com/glossary/llmops https://www.databricks.com/glossary/llmops
- cloakedcode 3y ago
  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.
krawczstef 3y ago
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-llmops/ 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.

deleted 3y ago

[deleted]

asplake 3y ago

> ADKAR, a mnemonic to help you run a change management process by modeling what needs to happen to get someone to “change”. 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.

gklitz 3y ago
[dead]
krawczstef 3y ago
> 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 :)
- asplake 3y ago
  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!
  - krawczstef 3y ago
    Fair enough! Thanks for explaining.
deleted 3y ago
[deleted]

deleted 3y ago

[deleted]

koliber 3y ago

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.

xrd 3y ago

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.

krawczstef 3y ago
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.
DonsDiscountGas 3y ago
> 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.
bomewish 3y ago
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.

slingnow 3y ago

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.

jimnotgym 3y ago

> 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.

krawczstef 3y ago
Very true!

ath3nd 3y ago

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.