Winning over hearts and minds work: ADKAR my favorite change management approach
blog.dagworks.io
blog.dagworks.io
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.
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 :)
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.