[HN Gopher] Winning over hearts and minds work: ADKAR my favorit...
___________________________________________________________________
Winning over hearts and minds work: ADKAR my favorite change
management approach
Author : krawczstef
Score : 50 points
Date : 2023-12-19 20:28 UTC (2 days ago)
(HTM) web link (blog.dagworks.io)
(TXT) w3m dump (blog.dagworks.io)
| krawczstef wrote:
| 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 wrote:
| What does "Awanesss", "Kaniolige" and "an Refovation" mean on
| the first image?
| krawczstef wrote:
| 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 wrote:
| "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 wrote:
| "What Is LLMOps?" https://www.databricks.com/glossary/llmops
| cloakedcode wrote:
| 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 wrote:
| 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.
| asplake wrote:
| > 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.
| krawczstef wrote:
| > 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 wrote:
| 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 wrote:
| Fair enough! Thanks for explaining.
| jph wrote:
| ^ @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.
| koliber wrote:
| 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 wrote:
| 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 wrote:
| 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.
| gfysfm wrote:
| 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 wrote:
| 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.
| slingnow wrote:
| 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 wrote:
| > 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.
___________________________________________________________________
(page generated 2023-12-21 23:01 UTC)