Change ManagementChange Management
Thuộc bộ kiến thức Engineering Manager Roadmap.
Tổng quan
Mọi note trong bộ kiến thức này tính đến giờ đều xoay quanh việc quyết định thay đổi cái gì: tái cấu trúc team trong Hiring & Organization Design, áp dụng một process mới trong Agile, Process & Delivery, khai tử một hệ thống legacy trong Technical Roadmap, Debt & Risk, hay dịch chuyển norms trong Organizational Culture & Learning. Note này nói về một trục hoàn toàn khác, và trên thực tế còn mang tính quyết định hơn: cách bạn triển khai bất kỳ thay đổi nào trong số đó. Một quy luật đáng chú ý trong nghiên cứu về tổ chức là phần lớn các sáng kiến change management thất bại không phải vì ý tưởng thay đổi sai — process mới thực sự tốt hơn, reorg thực sự khớp với chiến lược mới, tool mới thực sự vượt trội — mà thất bại vì cách thay đổi được đưa vào tổ chức: quá nhanh, quá mơ hồ, thiếu đúng người ủng hộ, không có cách đo xem nó có hiệu quả không, hoặc không bảo vệ thành quả sau khi động lực ban đầu nguội đi.
Đây là lý do change management được coi là một discipline riêng chứ không phải một bước phụ đính kèm vào bất cứ thứ gì đang được thay đổi. Một engineering manager giỏi ra quyết định kỹ thuật, giỏi thiết kế tổ chức, nhưng không có mô hình lặp lại được để triển khai thay đổi sẽ liên tục phải học lại cùng một bài học đau đớn — reorg về mặt logic hợp lý nhưng phá vỡ morale, việc chuyển tool khách quan tốt hơn nhưng âm thầm bị bỏ rơi sau sáu tháng, process mới được leadership công bố một lần rồi không bao giờ theo dõi tiếp. Note này cung cấp cho bạn hai mô hình bổ sung cho nhau để tư duy về thay đổi (Kotter’s 8-step model ở cấp tổ chức, ADKAR ở cấp cá nhân), một khung để chọn chiến lược thay đổi, một cách nhìn có căn cứ về resistance, và một checklist đánh giá mức độ sẵn sàng trước khi bạn tung ra bất kỳ thay đổi đáng kể nào.
Kiến thức nền tảng
Vì sao change management là một discipline riêng
Sẽ hữu ích nếu tách hai câu hỏi dễ bị nhầm lẫn với nhau: “đây có phải thay đổi đúng không?” và “thay đổi này có thực sự diễn ra như dự định không?” Câu hỏi thứ nhất là câu hỏi về chiến lược, kiến trúc, hoặc thiết kế tổ chức, và các note trước trong bộ kiến thức này phần lớn nói về việc trả lời câu hỏi đó cho tốt. Câu hỏi thứ hai là câu hỏi change management, và nó không tự động được trả lời chỉ vì câu hỏi thứ nhất đã đúng. Một quyết định hoàn toàn hợp lý — gộp ba team thành một, chuyển từ Jira sang Linear, áp dụng trunk-based development — vẫn có thể thất bại khi thực thi nếu người ta không hiểu tại sao nó xảy ra, không tin nó sẽ bền vững, hoặc chủ động lách qua vì không ai giải quyết mối lo của họ.
Hệ quả khó chịu cho một manager là: đúng là điều kiện cần chứ không phải điều kiện đủ. Change management là tập hợp các thực hành biến một quyết định đúng thành một kết quả bền vững: tạo đủ sự hiểu biết và động lực chung để mọi người di chuyển cùng hướng, sắp xếp trình tự rollout sao cho trải nghiệm ban đầu củng cố niềm tin thay vì củng cố sự nghi ngờ, và củng cố trạng thái mới đủ lâu để nó sống sót qua cả sự ra đi của người đã khởi xướng nó. Không có gì trong đây là “bán hàng” người khác một cách thiếu trung thực — đây là việc thừa nhận rằng thay đổi tổ chức là một quá trình xã hội và tâm lý, không chỉ là một vấn đề kỹ thuật hay cấu trúc, và quá trình đó có những failure mode riêng, độc lập với việc quyết định nền tảng có đúng đắn hay không.
Kotter’s 8-step model
Mô hình của John Kotter, được đúc kết từ việc nghiên cứu hàng chục cuộc chuyển đổi doanh nghiệp, mô tả thay đổi tổ chức như một chuỗi các bước, mỗi bước giải quyết một cách cụ thể mà các nỗ lực thay đổi thường bị mắc kẹt. Các bước này không đơn thuần là một checklist để tích theo thứ tự — mỗi bước tạo ra một điều kiện tiên quyết mà bước tiếp theo phụ thuộc vào, và bỏ qua một bước thường lộ ra thành một failure cụ thể, có thể dự đoán được, ở giai đoạn sau.
| Bước | Ý nghĩa | Điều gì xảy ra nếu bỏ qua |
|---|---|---|
| 1. Tạo urgency | Đưa ra luận điểm rằng hiện trạng thực sự tốn kém và chờ đợi còn tệ hơn hành động — không phải hoảng loạn giả tạo, mà là một bức tranh trung thực, cụ thể về vấn đề | Người ta coi thay đổi là tùy chọn hoặc là “sáng kiến của quý này” và âm thầm chờ nó qua đi |
| 2. Xây dựng guiding coalition | Tập hợp một nhóm đủ uy tín, đủ cấp bậc, đủ tầm ảnh hưởng liên phòng ban để dẫn dắt thay đổi — không chỉ người sponsor, mà cả những đồng nghiệp và influencer được kính trọng | Thay đổi bị coi là dự án cá nhân của một người, không có trọng lượng tổ chức đứng sau |
| 3. Hình thành strategic vision | Vẽ ra một bức tranh rõ ràng, đơn giản về trạng thái tương lai và nó khác hiện tại ra sao, đủ sắc nét để người ta có thể diễn đạt trong một câu | Nỗ lực bị phân mảnh thành các cách diễn giải cục bộ, không nhất quán về mục đích của thay đổi |
| 4. Truyền thông vision | Lặp lại vision liên tục, qua mọi kênh và mọi cấp lãnh đạo, và — quan trọng nhất — thể hiện nó qua hành động chứ không chỉ lời nói | Người ta nghe thông điệp một lần, quên nó, rồi quay lại hành vi cũ vì hành động của lãnh đạo không củng cố nó |
| 5. Empower broad-based action | Loại bỏ các rào cản cấu trúc — process lỗi thời, incentive lệch hướng, hệ thống vẫn thưởng cho cách làm cũ — thứ nếu không loại bỏ sẽ trừng phạt người áp dụng hành vi mới | Người ta muốn thay đổi nhưng bị chặn về mặt cấu trúc hoặc bị phạt khi cố thử, dẫn đến sự hoài nghi |
| 6. Tạo short-term wins | Chủ động thiết kế và quảng bá những thành công sớm, rõ ràng, không thể chối cãi trong vài tuần hoặc vài tháng đầu | Động lực chết trước khi những người hoài nghi có bằng chứng rằng thay đổi đang hiệu quả, và sự nghi ngờ cứng lại thành phản đối |
| 7. Consolidate gains và tạo thêm thay đổi | Dùng uy tín từ các win sớm để giải quyết những phần lớn hơn, khó hơn của thay đổi thay vì tuyên bố chiến thắng quá sớm | Thay đổi mắc kẹt ở 60% vì mọi người thư giãn sau win đầu tiên |
| 8. Anchor changes in culture | Biến cách làm việc mới thành bình thường mới — phản ánh trong tiêu chí tuyển dụng, onboarding, tiêu chí thăng tiến, và cách các câu chuyện thành công được kể lại — để nó sống sót qua cả sự thay đổi lãnh đạo | Thay đổi âm thầm đảo ngược trong vòng một hai năm khi những người khởi xướng ban đầu rời đi |
Lý do trình tự này quan trọng, không chỉ nội dung từng bước, là các bước sau phụ thuộc vào social capital được xây dựng bởi các bước trước. Bạn không thể tạo ra một short-term win đáng tin (bước 6) nếu chưa từng xây coalition đủ mạnh để mang lại nó (bước 2); bạn không thể anchor thay đổi vào culture (bước 8) nếu vision chưa bao giờ được truyền thông rõ ràng (bước 4), khiến phần lớn mọi người không thực sự hiểu họ được cho là đang áp dụng cái gì. Phát hiện nghiên cứu của chính Kotter là: failure phổ biến nhất không phải làm tệ một bước cụ thể, mà là nhảy thẳng vào giữa — công bố vision và kỳ vọng sự tuân thủ — mà không xây urgency và coalition trước, rồi tự hỏi tại sao thay đổi không bám rễ.
ADKAR: góc nhìn thay đổi ở cấp cá nhân
Mô hình Kotter mô tả thay đổi ở cấp tổ chức: những gì lãnh đạo cần điều phối trên toàn bộ nhóm. Mô hình ADKAR của Prosci đặt ra một câu hỏi bổ sung, và với một line manager thường thực dụng hơn ngay lập tức: một cá nhân cần gì, về mặt tâm lý và thực tiễn, để thay đổi hành vi của chính họ? ADKAR là viết tắt của năm khối xây dựng tuần tự mà một cá nhân cần, theo thứ tự, để duy trì một thay đổi cá nhân:
| Yếu tố | Ý nghĩa | Can thiệp điển hình của manager |
|---|---|---|
| Awareness | Người đó hiểu tại sao thay đổi là cần thiết | Giải thích lý do kinh doanh/kỹ thuật, không chỉ cơ chế của cái gì đang thay đổi |
| Desire | Người đó sẵn lòng cá nhân ủng hộ và tham gia thay đổi | Giải quyết “tôi được gì từ việc này,” thừa nhận mất mát, kết nối thay đổi với thứ họ đã coi trọng |
| Knowledge | Người đó biết cách thay đổi — kỹ năng, process, hoặc tool mới | Đào tạo, tài liệu, pairing, runbook |
| Ability | Người đó thực sự có thể thể hiện kỹ năng/hành vi mới trong thực tế, không chỉ lý thuyết | Thời gian luyện tập, môi trường rủi ro thấp để thử cách mới, coaching qua các sai lầm ban đầu |
| Reinforcement | Có gì đó duy trì hành vi mới sau đợt push ban đầu, để nó không suy thoái ngược về cách cũ | Ghi nhận, cập nhật metric/incentive, loại bỏ đường quay lại tool hoặc process cũ |
ADKAR chứng minh giá trị như một công cụ chẩn đoán: khi một thay đổi bị mắc kẹt với một người hoặc một nhóm cụ thể, ADKAR cho bạn một câu hỏi rất cụ thể để hỏi — yếu tố nào trong năm yếu tố đang thực sự thiếu? Một kỹ sư senior đồng ý về lý trí rằng kiến trúc mới tốt hơn (Awareness đã có) nhưng vẫn âm thầm quay về pattern cũ khi áp lực deadline có thể đang thiếu Ability (chưa đủ thời gian luyện tập để nhanh với cách mới) chứ không phải thiếu Desire — và can thiệp cho một khoảng trống Ability (nhiều pairing hơn, nhiều thời gian luyện tập rủi ro thấp hơn) hoàn toàn khác với can thiệp cho khoảng trống Desire (giải quyết một mối lo về status hoặc khối lượng công việc). Áp dụng can thiệp sửa Desire (nhiều thuyết phục hơn, nhiều thông điệp “tại sao điều này quan trọng” hơn) cho một khoảng trống Ability là lãng phí công sức, thậm chí có thể bị coi là vô cảm, vì người đó đã đồng ý rồi — họ chỉ chưa có đủ “reps.”
Dùng Kotter khi bạn đang điều phối thay đổi trên một team, một phòng ban, hoặc cả công ty và cần sắp xếp trình tự các động thái tổ chức — xây coalition, truyền thông vision, thay đổi cấu trúc incentive. Dùng ADKAR khi một cá nhân hoặc nhóm nhỏ cụ thể không áp dụng một thay đổi vốn dĩ đang ổn ở cấp tổ chức, hoặc khi bạn đang coach cá nhân qua một transition (tool mới, vai trò mới, process mới) và cần chẩn đoán chính xác họ đang vướng ở đâu. Trong thực tế, hai mô hình vận hành ở hai tầm cao khác nhau đồng thời: một reorg được thực hiện tốt cần trình tự kiểu Kotter ở cấp tổ chức, trong khi manager chạy một kiểu chẩn đoán ADKAR trong các buổi 1:1 với những cá nhân đang vật lộn để thích nghi.
Khái niệm chính
Chọn chiến lược thay đổi: sequencing và pacing
Không phải thay đổi nào cũng nên được triển khai theo cùng một cách, và hai lựa chọn chiến lược quan trọng nhất là triển khai rộng đến đâu và nỗ lực nên dồn vào communication hay process design.
Pilot với một team sẵn lòng trước, hay mandate toàn công ty. Một pilot — chạy thay đổi với một hoặc hai team sẵn lòng, có vị thế tương đối tốt trước khi yêu cầu bất kỳ ai khác áp dụng — có những lợi ích thực sự: nó tạo ra bằng chứng cụ thể (một short-term win, theo cách nói của Kotter) giúp giảm rủi ro cho phần rollout còn lại, nó phát hiện các vấn đề thực tiễn của chính thay đổi khi phạm vi ảnh hưởng còn nhỏ, và nó cho bạn những champion nội bộ có thể nói chuyện đáng tin cậy với các đồng nghiệp hoài nghi vì họ thực sự đã trải qua nó, không chỉ nghe về nó qua một slide deck. Cái giá phải trả là thời gian — pilot kéo dài thêm vài tuần hoặc vài tháng trước khi thay đổi đến với mọi người, và nếu thay đổi giải quyết một vấn đề cấp bách, ai cũng cảm nhận được (một lỗ hổng bảo mật, một tool đang thực sự hỏng), độ trễ đó có chi phí riêng của nó. Một mandate toàn công ty — công bố thay đổi cho tất cả mọi người cùng lúc — nhanh hơn và thể hiện sự nghiêm túc, nhưng nghĩa là bất kỳ lỗ hổng nào trong thiết kế thay đổi cũng bị phát hiện ở quy mô đầy đủ, nó không cho người hoài nghi bằng chứng tích cực cụ thể nào để tham chiếu, và nó loại bỏ khả năng lặp lại (iterate) cách tiếp cận dựa trên trải nghiệm ban đầu. Quy tắc chung: pilot khi thay đổi thực sự chưa chắc chắn về thiết kế (bạn không chắc process mới có thực sự hoạt động như dự định) hoặc mức độ khẩn cấp có thể thương lượng; mandate khi thay đổi giải quyết một vấn đề đủ nghiêm trọng và nhạy cảm về thời gian đến mức chi phí trì hoãn vượt quá chi phí học công khai, hoặc khi thay đổi liên quan đến compliance/an toàn nơi không thể có lựa chọn opt-out hợp lý.
Cách tiếp cận thiên về communication so với thiên về process. Một số thay đổi chủ yếu là dịch chuyển cách người ta nghĩ và ưu tiên điều gì — một sự chuyển dịch văn hóa hướng tới blameless postmortem, một sự nhấn mạnh mới vào documentation, một sự thay đổi ý nghĩa của “quality” đối với team. Những thay đổi này sống chết ở bước 3 và 4 của mô hình Kotter (vision và communication): nếu vision không được lặp lại đủ nhiều và không được chính lãnh đạo thể hiện qua hành động, thay đổi đơn giản là không bám rễ, vì không có cách nào ép buộc cơ học — bạn không thể ép ai đó thực sự tin rằng đổ lỗi là phản tác dụng. Những thay đổi khác chủ yếu mang tính cơ học — một CI pipeline mới, một tool on-call rotation mới, một quy trình deploy mới — và dù communication vẫn quan trọng (người ta cần hiểu tại sao), phần lớn nỗ lực nên thuộc về bước 5 (empowering action): đảm bảo đường cũ thực sự bị loại bỏ hoặc khó hơn đường mới, tài liệu và đào tạo tồn tại, và bản thân tooling không âm thầm cho phép quay lại hành vi cũ. Một sai lầm phổ biến là áp dụng playbook thiên về communication cho một thay đổi thiên về process (nói rất nhiều về việc tại sao deploy tool mới tốt hơn trong khi để tool cũ vẫn hoạt động đầy đủ và tiện hơn một chút, khiến người ta trôi dạt về nó) hoặc áp dụng playbook thiên về process cho một thay đổi thiên về communication (bắt buộc blameless postmortem qua một template mà không đầu tư gì vào việc tại sao người ta nên thực sự tin vào triết lý bên dưới, tạo ra “compliance theater” chứ không phải thay đổi thực sự).
Resistance là tín hiệu, không phải lỗi cần vượt qua
Sự dịch chuyển tư duy quan trọng nhất đối với một manager dẫn dắt thay đổi là coi resistance là dữ liệu chứ không phải vấn đề kỷ luật. Resistance với thay đổi, trong đại đa số trường hợp, là một phản ứng hợp lý với một mối lo có thật chứ không phải sự cứng đầu hay chống đối vì lợi ích riêng của nó — và mối lo thường thuộc một vài dạng nhận diện được:
- Mất status hoặc quyền kiểm soát. Thay đổi lấy đi thứ mà người đó hiện đang sở hữu, được biết đến, hoặc lấy identity từ đó — là chuyên gia go-to về tool đang bị thay thế, sở hữu process đang được thiết kế lại, giữ một chức danh hoặc phạm vi mà một reorg sẽ giải thể. Mất mát này là có thật ngay cả khi thay đổi khách quan tốt cho tổ chức, và giả vờ như nó không phải là mất mát (thay vì thừa nhận trực tiếp) sẽ đọc như sự coi thường.
- Lợi ích không rõ ràng hoặc không thuyết phục. Người đó thực sự không thấy thay đổi làm gì tốt hơn — cho họ, cho team, hay cho khách hàng — hoặc vì luận điểm không được truyền thông tốt, hoặc vì khi soi kỹ, luận điểm thực sự yếu với tình huống cụ thể của họ. Điều này đáng được xem xét nghiêm túc thay vì giả định đó chỉ là vấn đề truyền thông; đôi khi một người hoài nghi đã phát hiện ra một lỗ hổng thực sự trong kế hoạch.
- Sự hoài nghi từ những thay đổi thất bại trong quá khứ. Một team đã trải qua vài sáng kiến được công bố rầm rộ rồi âm thầm bị bỏ rơi, hoặc vài reorg không giải quyết được gì, phát triển một prior hợp lý rằng “cái này rồi cũng sẽ qua” — và prior đó là có căn cứ, không phải phi lý. Phản ứng đúng không phải là tranh luận để bác bỏ prior đó bằng lời nói, mà là chứng minh, qua việc theo đuổi đến cùng lần này, rằng nó không áp dụng.
- Trở ngại thực tiễn có thật. Đôi khi thứ trông giống resistance thực ra là “tôi không có thời gian học cái này trong khi vẫn phải đạt deadline bạn cũng vừa giao” hoặc “tool mới thực sự không hỗ trợ một use case tôi đang phụ thuộc vào” — vấn đề logistics thực sự, không phải vấn đề thái độ.
Vì resistance thường mã hóa thông tin thật, các chiến thuật thực tiễn theo sau một cách trực tiếp:
- Lắng nghe trước, trước khi bảo vệ thay đổi. Hỏi cụ thể điều gì khiến ai đó lo lắng trước khi giải thích tại sao họ không nên lo lắng — bạn thường sẽ học được điều gì đó thay đổi cách bạn thực thi rollout, và ngay cả khi không, việc được lắng nghe thực sự tự nó đã giảm resistance.
- Đưa người hoài nghi vào sớm thay vì sau khi quyết định đã chốt. Một người hoài nghi đã giúp định hình kế hoạch (hoặc ít nhất có input thật được cân nhắc trước khi kế hoạch bị khóa) có cổ phần trong sự thành công của nó; một người hoài nghi bị đưa cho một fait accompli có mọi động lực để chứng minh nó sai.
- Cho thấy quick win đến đúng đối tượng hoài nghi cụ thể, không chỉ win nói chung — một win ở một phần của tổ chức mà người hoài nghi không thấy liên quan đến mình sẽ ít tác động; một win rõ ràng trong một bối cảnh họ nhận ra là tương tự bối cảnh của họ tác động nhiều hơn.
- Truyền thông “tại sao” nhiều hơn cả “cái gì.” Người ta sẽ tha thứ cho một thay đổi họ không đồng ý nếu họ hiểu và tin vào lý do; họ sẽ oán giận một thay đổi cảm giác tùy tiện hoặc không được giải thích ngay cả khi bản thân thay đổi là nhỏ. Lặp lại lý do nhiều hơn mức bạn cảm thấy cần thiết — vào lúc lãnh đạo phát chán vì phải lặp lại thông điệp, nó thường mới chỉ vừa chạm đến một phần tư cuối cùng của tổ chức.
- Phân biệt resistance đáng giải quyết với resistance chỉ đơn giản là cái giá phải trả của việc thay đổi. Không phải mọi phản đối đều có thể hoặc nên thay đổi kế hoạch — một số mối lo là thật nhưng bị vượt qua bởi lợi ích, và phản hồi trung thực là thừa nhận trade-off một cách rõ ràng (“đúng, điều này có nghĩa là X, và chúng tôi đã quyết định nó đáng giá vì Y”) thay vì giả vờ như downside không tồn tại.
Best Practices
Áp dụng change management vào các thay đổi đã được đề cập ở nơi khác trong bộ kiến thức này
Note này chủ ý là phần đồng hành “cách triển khai tốt” cho một vài chủ đề “thay đổi cái gì” đã đề cập trước đó, và đáng để nói rõ các mô hình ở đây map vào từng chủ đề như thế nào:
Reorgs (Hiring & Organization Design). Một reorg gần như là một bài tập thuần túy theo mô hình Kotter: urgency cần là thật và được giải thích rõ ràng (không phải “lãnh đạo mới muốn đóng dấu cá nhân lên tổ chức”), coalition cần bao gồm các manager sẽ hấp thụ sự xáo trộn và có thể bảo chứng cho lý do trước chính team của họ, và short-term win thường đơn giản chỉ là thực thi transition nhanh và gọn để người ta thấy cấu trúc mới hoạt động thay vì phải chứng kiến nó kéo dài trong mơ hồ suốt nhiều tháng. Resistance với một reorg rất thường là resistance mất status — người ta mất phạm vi, chức danh, hoặc identity của team — và giả vờ như không phải vậy, thay vì gọi tên nó trực tiếp, chắc chắn sẽ khiến nó âm ỉ.
Chuyển đổi tool và áp dụng công nghệ (Technical Roadmap, Debt & Risk). Việc di chuyển tool thường là thay đổi thiên về process, phù hợp nhất với một pilot: chạy tool mới với một team sẵn lòng, dùng trải nghiệm của họ để sửa các góc cạnh thô ráp và tạo ra một tài liệu tham chiếu nội bộ đáng tin, rồi mới mở rộng rollout. ADKAR thường hữu ích hơn Kotter ở đây khi xét cấp độ cá nhân, vì các thất bại trong việc áp dụng tool thường là khoảng trống Knowledge hoặc Ability (người ta ủng hộ về mặt lý trí việc migration nhưng chưa có đủ thời gian thực hành) chứ không phải khoảng trống Desire — nghĩa là thời gian đào tạo và pairing, chứ không phải thông điệp thuyết phục hơn, thường là cách sửa đúng.
Thay đổi process (Agile, Process & Delivery). Một thay đổi process (một sprint cadence mới, một definition of done mới, một format incident review mới) có xu hướng thất bại cụ thể ở bước 5 của Kotter (empower action) và bước 8 (anchor in culture): process cũ vẫn còn khả dụng về mặt kỹ thuật, thói quen cũ không bao giờ bị ngăn cản về mặt cấu trúc, và sáu tháng sau ai cũng âm thầm trôi ngược về cách cũ. Cách sửa thực tiễn là biến process mới thành con đường ít trở lực nhất — cập nhật template, dashboard, và tooling default để phản ánh nó — thay vì trông chờ người ta nhớ tuân theo một tập hướng dẫn mới vô thời hạn.
Sự tiến hóa văn hóa (Organizational Culture & Learning). Thay đổi văn hóa là trường hợp thiên về communication thuần túy nhất và phụ thuộc nhiều nhất vào việc bước 4 (communicate the vision) được hậu thuẫn bởi chính hành vi có thể quan sát được của lãnh đạo — một sự thúc đẩy hướng tới blameless postmortem chỉ sống sót qua sự cố có tính hiển thị cao đầu tiên nếu chính lãnh đạo thể hiện việc không đổ lỗi ngay tại khoảnh khắc đó. Thay đổi văn hóa cũng là chậm nhất trong bốn loại để anchor (bước 8), vì nó không có đường ép buộc cơ học nào; nó chỉ trở nên bền vững một khi nó được phản ánh trong việc ai được tuyển, được thăng chức, và được tôn vinh.
Một checklist đánh giá mức độ sẵn sàng cho thay đổi
Trước khi tung ra một thay đổi có ý nghĩa thực sự, đáng để kiểm tra rõ ràng sự hiện diện của một số ít điều kiện tiên quyết, vì sự vắng mặt của chúng dự đoán thất bại với độ tin cậy khó chịu:
| Mục checklist | Câu hỏi cần đặt | Failure mode nếu thiếu |
|---|---|---|
| Luận điểm rõ ràng cho thay đổi | Bạn có thể nói trong một hai câu tại sao hiện trạng là vấn đề thật và tại sao ngay bây giờ? | Người ta coi thay đổi là tùy tiện hoặc tùy chọn |
| Coalition ủng hộ | Có những người được kính trọng ngoài sponsor công khai ủng hộ, và họ có thể nói về nó đáng tin cậy với chính team của họ không? | Thay đổi bị coi là sáng kiến của một người, không có hậu thuẫn thật |
| Vision cụ thể | Mọi người bị ảnh hưởng có thể mô tả bằng lời của chính họ trạng thái cuối cùng trông như thế nào và nó khác hiện tại ra sao không? | Nỗ lực phân mảnh thành các cách diễn giải cục bộ không nhất quán |
| Kế hoạch truyền thông | Có kế hoạch lặp lại thông điệp nhiều lần, qua nhiều kênh, suốt toàn bộ giai đoạn rollout — không chỉ một thông báo duy nhất? | Thông điệp được nghe một lần rồi bị quên |
| Rào cản cấu trúc đã bị loại bỏ | Bạn đã kiểm tra xem có process, incentive, hay tool hiện tại nào vẫn thưởng hoặc đòi hỏi hành vi cũ không? | Người ta bị trừng phạt vì cố áp dụng hành vi mới |
| Win sớm đã xác định | Có một milestone cụ thể, hiển thị, gần hạn sẽ chứng minh thay đổi đang hiệu quả không? | Động lực chết trước khi người hoài nghi thấy bằng chứng nào |
| Resistance đã được map | Bạn đã nói chuyện với những người hoài nghi khả dĩ và xác định mối lo của họ là mất status, lợi ích không rõ, hoài nghi, hay trở ngại thực tiễn chưa? | Những phản đối có thể dự đoán được nổi lên muộn và làm chệch rollout |
| Cách đo thành công | Bạn có một metric cụ thể hoặc tín hiệu quan sát được, xác định trước khi launch, cho biết thay đổi có thực sự hiệu quả không? | Bạn không thể phân biệt thành công với thất bại, và không thể lập luận để duy trì hay đảo ngược thay đổi |
| Kế hoạch reinforcement | Có kế hoạch (cập nhật tiêu chí tuyển dụng, cập nhật dashboard, cập nhật incentive) để giữ trạng thái mới là mặc định sau khi đợt push ban đầu nguội đi không? | Thay đổi âm thầm đảo ngược trong vòng một năm |
Một thay đổi đạt điểm kém ở nhiều mục trong số này không nhất thiết là thay đổi sai — nhưng tung ra nó mà không giải quyết các khoảng trống trước là một lựa chọn chấp nhận rủi ro thất bại cao hơn đáng kể, và đáng để đưa ra lựa chọn đó một cách có ý thức thay vì mặc định.
So sánh Kotter vs. ADKAR
| Kotter’s 8-Step Model | ADKAR | |
|---|---|---|
| Cấp độ thay đổi | Tổ chức — cả team, phòng ban, hoặc công ty | Cá nhân — quá trình chuyển đổi của một người |
| Trọng tâm chính | Sắp xếp trình tự các hành động tổ chức: urgency, coalition, vision, communication, empowerment cấu trúc, wins, consolidation, culture | Sắp xếp trình tự các khối xây dựng tâm lý/thực tiễn: awareness, desire, knowledge, ability, reinforcement |
| Phù hợp nhất để | Thiết kế và dẫn dắt một chương trình thay đổi từ đầu đến cuối (reorg, sáng kiến lớn, chuyển hướng chiến lược) | Chẩn đoán tại sao một người hoặc nhóm nhỏ cụ thể không áp dụng thay đổi, hoặc coach một cá nhân qua nó |
| Failure điển hình nó chẩn đoán | Nhảy thẳng vào công bố vision mà không xây urgency hoặc coalition trước | Áp dụng sai cách sửa — ví dụ, thuyết phục nhiều hơn cho thứ thực ra là khoảng trống kỹ năng |
| Người sở hữu | Thường là lãnh đạo cấp cao cùng một guiding coalition | Thường là manager trực tiếp, qua các buổi 1:1 và coaching hàng ngày |
| Khung thời gian | Rollout dài, theo giai đoạn với các milestone tuần tự | Có thể áp dụng cho đường cong áp dụng của một cá nhân trong vài ngày hoặc vài tuần |
Tài liệu tham khảo
- Kotter, J. P. (1995), “Leading Change: Why Transformation Efforts Fail” — Harvard Business Review, bài viết gốc trình bày mô hình 8 bước
- Kotter Inc. — The 8-Step Process for Leading Change — tóm tắt hiện tại và hướng dẫn thực tiễn từ chính tổ chức của Kotter
- Prosci — ADKAR Model — mô hình thay đổi cấp cá nhân, năm giai đoạn của nó, và cách dùng để chẩn đoán
- Hiatt, J. (2006), ADKAR: A Model for Change in Business, Government and Our Community — Prosci, tài liệu nền tảng về mô hình này
- Prosci — Change Management Research — nghiên cứu benchmarking liên tục về lý do các sáng kiến thay đổi thành công hay thất bại
- Kotter, J. P. & Schlesinger, L. A. (1979/2008), “Choosing Strategies for Change” — Harvard Business Review, về việc khớp cách tiếp cận thay đổi (education, participation, negotiation, coercion) với nguồn gốc của resistance
- roadmap.sh — Engineering Manager — roadmap mà bộ kiến thức này theo sát
Part of the Engineering Manager Roadmap knowledge base.
Overview
Every note in this knowledge base up to this point has been about deciding what to change: reorganizing a team in Hiring & Organization Design, adopting a new process in Agile, Process & Delivery, retiring a legacy system in Technical Roadmap, Debt & Risk, or shifting norms in Organizational Culture & Learning. This note is about something orthogonal and, in practice, more decisive: how you roll any of those changes out. A striking regularity in organizational research is that most change initiatives that fail do not fail because the underlying idea was wrong — the new process really would have been better, the reorg really did match the new strategy, the tool really was superior — they fail because of how the change was introduced: too fast, too vague, without the right people on board, without a way to tell whether it worked, or without protecting the gains once the initial push faded.
This is why change management is treated as its own discipline rather than an afterthought bolted onto whatever is being changed. An engineering manager who is good at technical decision-making and organization design but has no repeatable model for introducing change will keep re-deriving the same painful lessons — the reorg that technically made sense but shattered morale, the tool migration that was objectively better but got quietly abandoned six months in, the new process that leadership announced once and never followed up on. This note gives you two complementary models for thinking about change (Kotter’s 8-step model for the organizational level, ADKAR for the individual level), a framework for choosing a change strategy, a grounded way to think about resistance, and a readiness checklist to run before you launch anything significant.
Fundamentals
Why change management is its own discipline
It helps to separate two questions that are easy to conflate: “is this the right change?” and “will this change actually happen the way we intend?” The first question is a strategy, architecture, or organization-design question, and the earlier notes in this knowledge base are largely about answering it well. The second question is a change management question, and it is not automatically answered just because the first one was answered correctly. A perfectly reasoned decision to consolidate three teams into one, or to move from Jira to Linear, or to adopt trunk-based development, can still fail in execution if people don’t understand why it’s happening, don’t believe it will stick, or actively work around it because no one addressed their concerns.
The uncomfortable implication for a manager is that being right is necessary but not sufficient. Change management is the set of practices that convert a correct decision into a durable outcome: creating enough shared understanding and motivation that people move in the same direction, sequencing the rollout so that early experience builds confidence rather than reinforcing doubt, and reinforcing the new state long enough that it survives the departure of whoever championed it. None of this is about “selling” people on something disingenuously — it is about recognizing that organizational change is a social and psychological process, not just a technical or structural one, and that process has its own failure modes independent of whether the underlying decision was sound.
Kotter’s 8-step model
John Kotter’s model, developed from studying dozens of corporate transformations, describes organizational change as a sequence of steps, each of which addresses a specific way change efforts stall. The steps are not merely a checklist to tick off in order — each step creates a precondition the next step depends on, and skipping one tends to surface as a specific, predictable failure later in the sequence.
| Step | What it means | What happens if you skip it |
|---|---|---|
| 1. Create urgency | Make the case that the status quo is genuinely costly and that waiting is worse than acting — not manufactured panic, but an honest, specific picture of the problem | People treat the change as optional or as “this quarter’s initiative” and quietly wait it out |
| 2. Build a guiding coalition | Assemble a group with enough credibility, seniority, and cross-functional reach to lead the change — not just the sponsor, but respected peers and influencers | The change is seen as one person’s pet project with no organizational weight behind it |
| 3. Form a strategic vision | Articulate a clear, simple picture of the future state and how it differs from today, sharp enough that people can explain it in a sentence | Effort splinters into inconsistent, locally-optimized interpretations of what the change is even for |
| 4. Communicate the vision | Repeat the vision constantly, through every channel and every level of leadership, and — critically — model it through actions, not just words | People hear the message once, forget it, and revert to old behavior because leadership’s own actions didn’t reinforce it |
| 5. Empower broad-based action | Remove structural obstacles — outdated processes, misaligned incentives, systems that still reward the old way — that would otherwise punish people for adopting the new behavior | People want to change but are structurally blocked or penalized for trying, which breeds cynicism |
| 6. Generate short-term wins | Deliberately engineer and publicize early, visible, unambiguous successes within the first weeks or months | Momentum dies before skeptics have any evidence the change is working, and doubt hardens into opposition |
| 7. Consolidate gains and produce more change | Use the credibility from early wins to tackle bigger, harder parts of the change instead of declaring victory prematurely | The change stalls at 60% complete because everyone relaxes after the first visible win |
| 8. Anchor changes in culture | Make the new way of working the new normal — reflected in hiring criteria, onboarding, promotion criteria, and how success stories get told — so it survives leadership turnover | The change quietly reverts within a year or two once the original champions move on |
The reason this sequencing matters, and not just the content of each step, is that later steps depend on the social capital built by earlier ones. You cannot generate a credible short-term win (step 6) if you never built a coalition capable of delivering one (step 2); you cannot anchor a change in culture (step 8) if the vision was never clearly communicated (step 4) and so most people never really understood what they were supposedly adopting. Kotter’s own research finding was that the most common failure is not doing any one step badly, but skipping straight to the middle — announcing a vision and expecting compliance — without first building urgency and a coalition, and then wondering why the change doesn’t take.
ADKAR: the individual-change lens
Kotter’s model describes change at the organizational level: what leadership needs to orchestrate across an entire group. Prosci’s ADKAR model asks a complementary and, for a line manager, often more immediately actionable question: what does one person need, psychologically and practically, to change their own behavior? ADKAR is an acronym for five sequential building blocks an individual needs, in order, to sustain a personal change:
| Element | What it means | Typical manager intervention |
|---|---|---|
| Awareness | The person understands why the change is needed | Explain the business/technical reason, not just the mechanics of what’s changing |
| Desire | The person is personally willing to support and participate in the change | Address “what’s in it for me,” acknowledge losses, connect the change to something they already value |
| Knowledge | The person knows how to change — the new skills, process, or tool | Training, documentation, pairing, runbooks |
| Ability | The person can actually demonstrate the new skill or behavior in practice, not just in theory | Practice time, low-stakes environments to try the new way, coaching through early mistakes |
| Reinforcement | Something sustains the new behavior after the initial push, so it doesn’t decay back to the old way | Recognition, updated metrics/incentives, removing easy paths back to the old tool or process |
ADKAR earns its keep as a diagnostic tool: when a change stalls with a particular person or subgroup, ADKAR gives you a specific question to ask — which of the five elements is actually missing? A senior engineer who intellectually agrees the new architecture is better (Awareness present) but keeps quietly reverting to old patterns under deadline pressure may be missing Ability (they haven’t had enough practice to be fast in the new way yet) rather than Desire — and the intervention for a missing Ability gap (more pairing, more low-stakes practice) is completely different from the intervention for missing Desire (addressing a status or workload concern). Applying a Desire-fixing intervention (more persuasion, more “why this matters” messaging) to an Ability gap wastes effort and can even read as tone-deaf, since the person already agrees — they just haven’t had the reps yet.
Use Kotter when you are orchestrating change across a team, department, or company and need to sequence organizational moves — coalition-building, vision communication, structural changes to incentives. Use ADKAR when a specific individual or small group isn’t adopting a change that’s otherwise going fine at the org level, or when you are personally coaching someone through a transition (a new tool, a new role, a new process) and need to diagnose exactly where they’re stuck. In practice the two operate at different altitudes simultaneously: a well-run reorg needs Kotter’s sequencing at the org level while a manager runs an ADKAR-style diagnosis in 1:1s with individuals who are struggling to adapt.
Key Concepts
Choosing a change strategy: sequencing and pacing
Not every change should be rolled out the same way, and the two most consequential strategic choices are how broadly to launch it and how much of the effort goes into communication versus process design.
Pilot with a willing team first, versus an org-wide mandate. A pilot — running the change with one or two willing, reasonably well-positioned teams before asking anyone else to adopt it — has real advantages: it produces concrete evidence (a short-term win, in Kotter’s terms) that de-risks the rollout for everyone else, it surfaces practical problems with the change itself while the blast radius is small, and it gives you internal champions who can speak credibly to skeptical peers because they’ve actually lived it, not just heard about it in a slide deck. The cost is time — a pilot adds weeks or months before the change reaches everyone, and if the change addresses an urgent, universally-felt problem (a security vulnerability, a tool that’s actively breaking), that delay has a real cost of its own. An org-wide mandate — announcing the change for everyone simultaneously — is faster and signals seriousness, but it means any flaw in the change design is discovered at full scale, it gives skeptics no positive local evidence to point to, and it removes the option of iterating on the approach based on early experience. As a rule of thumb: pilot when the change is genuinely uncertain in its design (you’re not sure the new process will actually work as intended) or discretionary in its urgency; mandate when the change addresses a problem severe and time-sensitive enough that the cost of delay outweighs the cost of learning in public, or when the change is a compliance/safety matter where opt-out isn’t a reasonable option.
Communication-heavy versus process-heavy approaches. Some changes are primarily about shifting how people think and what they prioritize — a cultural shift toward blameless postmortems, a new emphasis on documentation, a shift in what “quality” means for the team. These changes live or die on steps 3 and 4 of Kotter’s model (vision and communication): if the vision isn’t repeated often enough and modeled by leadership’s own behavior, the change simply doesn’t take, because there’s no mechanical enforcement possible — you can’t force someone to genuinely believe blame is unproductive. Other changes are primarily mechanical — a new CI pipeline, a new on-call rotation tool, a new deployment process — and while communication still matters (people need to understand why), the bulk of the effort belongs in step 5 (empowering action): making sure the old path is actually removed or made harder than the new one, that documentation and training exist, and that the tooling itself doesn’t quietly permit reverting to the old behavior. A common mistake is applying a communication-heavy playbook to a process-heavy change (talking extensively about why the new deployment tool is better while leaving the old one fully functional and slightly more convenient, so people drift back to it) or a process-heavy playbook to a communication-heavy change (mandating blameless postmortems via a template with no investment in why people should actually believe in the underlying philosophy, producing compliance theater rather than genuine change).
Resistance is signal, not a defect to override
The single most consequential mental shift for a manager driving change is treating resistance as data rather than as a discipline problem. Resistance to change is, in the great majority of cases, a rational response to a real concern rather than stubbornness or resistance for its own sake — and the concern is usually one of a few recognizable shapes:
- Loss of status or control. The change removes something the person currently owns, is known for, or derives identity from — being the go-to expert on the tool that’s being replaced, owning the process that’s being redesigned, holding a title or scope that a reorg dissolves. This loss is real even when the change is objectively good for the organization, and pretending it isn’t a loss (rather than acknowledging it directly) reads as dismissive.
- Unclear or unconvincing benefit. The person genuinely doesn’t see how the change makes anything better — for them, for the team, or for the customer — either because the case wasn’t well communicated or because, on inspection, the case really is weak for their specific situation. This is worth taking seriously rather than assuming it’s just a communication problem; sometimes a skeptic has spotted a real gap in the plan.
- Cynicism from past failed changes. A team that has been through several initiatives that were announced with fanfare and then quietly abandoned, or several reorgs that solved nothing, develops a rational prior that “this too shall pass” — and that prior is earned, not irrational. The correct response is not to argue the prior away rhetorically but to demonstrate, through follow-through this time, that it doesn’t apply.
- Genuine practical obstacles. Sometimes what looks like resistance is really “I don’t have time to learn this while also hitting the deadline you also gave me” or “the new tool doesn’t actually support a use case I depend on” — legitimate logistical problems, not attitude problems.
Given that resistance usually encodes real information, the practical tactics follow directly:
- Listen first, before defending the change. Ask what specifically concerns someone before explaining why they shouldn’t be concerned — you will frequently learn something that changes how you execute the rollout, and even when you don’t, being heard genuinely reduces resistance on its own.
- Involve skeptics early rather than after the decision is final. A skeptic who helped shape the plan (or who at least had real input considered before the plan was locked) has a stake in its success; a skeptic who is presented with a fait accompli has every incentive to prove it wrong.
- Show quick wins to the specific skeptical audience, not just wins in general — a win in a part of the org a skeptic doesn’t identify with does little to move them; a visible win in a context they recognize as similar to their own does much more.
- Over-communicate the “why,” not just the “what.” People will forgive a change they disagree with if they understand and believe the reasoning; they resent a change that feels arbitrary or unexplained even if the change itself is minor. Repeat the reasoning far more than feels necessary — by the time leadership is sick of repeating the message, it’s usually just landing with the last quarter of the organization.
- Distinguish resistance worth addressing from resistance that is simply the cost of doing the change. Not every objection can or should change the plan — some concerns are real but are outweighed by the benefit, and the honest response is to acknowledge the trade-off explicitly (“yes, this does mean X, and we’ve decided it’s worth it because Y”) rather than pretending the downside doesn’t exist.
Best Practices
Applying change management to the changes covered elsewhere in this knowledge base
This note is deliberately the “how to roll it out well” companion to several “what to change” topics covered earlier, and it’s worth being explicit about how the models here map onto each:
Reorgs (Hiring & Organization Design). A reorg is close to a pure Kotter-model exercise: urgency needs to be genuine and clearly explained (not “the new leader wanted a fresh org chart”), the coalition needs to include the managers who will absorb the disruption and can vouch for the rationale to their own teams, and the short-term win is often simply executing the transition quickly and cleanly so people can see the new structure functioning rather than watching it drag on in ambiguity for months. Resistance to a reorg is very often status-loss resistance — people losing scope, a title, or a team identity — and pretending otherwise, rather than naming it directly, guarantees it festers.
Tool transitions and technology adoption (Technical Roadmap, Debt & Risk). Tool migrations are usually process-heavy changes best served by a pilot: run the new tool with one willing team, use their experience to fix rough edges and produce a credible internal reference, and only then broaden the rollout. ADKAR is often more useful here than Kotter at the individual level, because tool adoption failures are frequently Knowledge or Ability gaps (people intellectually support the migration but haven’t had enough hands-on practice) rather than Desire gaps — which means training and pairing time, not more persuasive messaging, is usually the right fix.
Process changes (Agile, Process & Delivery). A process change (a new sprint cadence, a new definition of done, a new incident review format) tends to fail specifically at Kotter’s step 5 (empower action) and step 8 (anchor in culture): the old process remains technically available, old habits are never structurally discouraged, and six months later everyone has quietly drifted back. The practical fix is to make the new process the path of least resistance — update templates, dashboards, and tooling defaults to reflect it — rather than relying on people remembering to follow a new set of instructions indefinitely.
Culture evolution (Organizational Culture & Learning). Culture change is the purest communication-heavy case and the one most dependent on step 4 (communicate the vision) being backed by leadership’s own visible behavior — a push toward blameless postmortems that survives the first real high-visibility incident only if leadership itself models not assigning blame in that moment. Culture change is also the slowest of the four to anchor (step 8), because it has no mechanical enforcement path; it only becomes durable once it’s reflected in who gets hired, promoted, and celebrated.
A change readiness checklist
Before launching a change of any real significance, it is worth explicitly checking for the presence of a small number of preconditions, because their absence predicts failure with uncomfortable reliability:
| Checklist item | Question to ask | Failure mode if missing |
|---|---|---|
| Clear case for change | Can you state, in one or two sentences, why the status quo is a real problem and why now? | People treat the change as arbitrary or optional |
| Coalition of support | Do respected people beyond the sponsor visibly back this, and can they speak to it credibly with their own teams? | The change is seen as one person’s initiative with no real backing |
| Concrete vision | Can everyone affected describe, in their own words, what the end state looks like and how it differs from today? | Effort fragments into inconsistent local interpretations |
| Communication plan | Is there a plan for repeating the message multiple times, through multiple channels, over the full rollout period — not just a single announcement? | The message is heard once and forgotten |
| Removed structural obstacles | Have you checked whether any existing process, incentive, or tool still rewards or requires the old behavior? | People are punished for trying to adopt the new behavior |
| Early win identified | Is there a specific, visible, near-term milestone that will demonstrate the change is working? | Momentum dies before skeptics see any evidence |
| Resistance mapped | Have you talked to likely skeptics and identified whether their concern is status loss, unclear benefit, cynicism, or a practical obstacle? | Predictable objections surface late and derail the rollout |
| Way to measure success | Do you have a specific metric or observable signal, defined before launch, that tells you whether the change actually worked? | You cannot tell success from failure, and cannot make the case to sustain or reverse the change |
| Reinforcement plan | Is there a plan (updated hiring criteria, updated dashboards, updated incentives) to keep the new state the default after the initial push fades? | The change quietly reverts within a year |
A change that scores poorly on several of these items is not necessarily the wrong change — but launching it without addressing the gaps first is a choice to accept a materially higher risk of failure, and it’s worth making that choice consciously rather than by default.
Kotter vs. ADKAR at a glance
| Kotter’s 8-Step Model | ADKAR | |
|---|---|---|
| Level of change | Organizational — the whole team, department, or company | Individual — one person’s transition |
| Primary focus | Sequencing organizational actions: urgency, coalition, vision, communication, structural enablement, wins, consolidation, culture | Sequencing psychological/practical building blocks: awareness, desire, knowledge, ability, reinforcement |
| Best used for | Designing and leading a change program end to end (a reorg, a major initiative, a strategic pivot) | Diagnosing why a specific person or subgroup isn’t adopting a change, or coaching an individual through one |
| Typical failure it diagnoses | Skipping straight to announcing a vision without first building urgency or a coalition | Applying the wrong fix — e.g., more persuasion for what’s actually a skills gap |
| Owner | Usually senior leadership plus a guiding coalition | Usually the direct manager, in 1:1s and day-to-day coaching |
| Time horizon | Long, staged rollout with sequential milestones | Can apply to a single person’s adoption curve over days or weeks |
References
- Kotter, J. P. (1995), “Leading Change: Why Transformation Efforts Fail” — Harvard Business Review, the original articulation of the 8-step model
- Kotter Inc. — The 8-Step Process for Leading Change — current summary and practical guidance from Kotter’s own organization
- Prosci — ADKAR Model — the individual-change model, its five stages, and diagnostic use
- Hiatt, J. (2006), ADKAR: A Model for Change in Business, Government and Our Community — Prosci, the foundational text on the model
- Prosci — Change Management Research — ongoing benchmarking research on why change initiatives succeed or fail
- Kotter, J. P. & Schlesinger, L. A. (1979/2008), “Choosing Strategies for Change” — Harvard Business Review, on matching change approach (education, participation, negotiation, coercion) to the source of resistance
- roadmap.sh — Engineering Manager — the roadmap this knowledge base follows