Coaching, Mentoring & Trí tuệ cảm xúcCoaching, Mentoring & Emotional Intelligence
Thuộc bộ kiến thức Engineering Manager Roadmap.
Tổng quan
Đa số manager mới mặc định “managing” trong mọi tình huống: tự chẩn đoán vấn đề, tự quyết cách fix, rồi bảo report phải làm gì. Cách này có vẻ hiệu quả và tận dụng đúng kỹ năng đã giúp họ được thăng chức — là người giải quyết vấn đề giỏi nhất phòng. Nhưng một manager chỉ biết managing sẽ giới hạn sự phát triển của cả team ở đúng năng lực của bản thân họ, vì không ai trong team từng phải tự rèn cơ bắp giải quyết vấn đề khó. Coaching, mentoring và trí tuệ cảm xúc (emotional intelligence) là ba năng lực giúp manager nhân bản (multiply) output của team thay vì chỉ điều khiển nó.
Bài viết này vạch ranh giới rõ ràng giữa coaching (khơi gợi câu trả lời của chính người đó), mentoring (chia sẻ kinh nghiệm và lời khuyên của manager) và directive management (tự quyết định và chịu trách nhiệm về kết quả), đồng thời đưa ra một mô hình thực dụng — GROW — để chạy một cuộc trò chuyện coaching. Bài viết cũng bàn về cách xây dựng mối quan hệ mentoring thực sự hiệu quả, cách delegation đúng “độ cao” theo năng lực (competence) và sự tự tin (confidence) của một người trên một task cụ thể, lý do trí tuệ cảm xúc trở nên quan trọng hơn kỹ năng kỹ thuật khi phạm vi quản lý mở rộng, cách unconscious bias bóp méo các quyết định về con người và cách giảm thiểu, cùng một framework đơn giản, lặp lại được để xử lý conflict trước khi nó đóng băng. Đây đều là những “soft skill” mà thực chất là kỹ năng khó và học được của nghề quản lý — xem thêm One-on-Ones, Feedback & Performance để biết nhịp độ (cadence) mà các cuộc trò chuyện này diễn ra, và Team Culture & Well-Being để thấy chúng cộng dồn thành niềm tin ở cấp độ team như thế nào.
Kiến thức nền tảng
Coaching vs. mentoring vs. managing
Ba khái niệm này thường xuyên bị lẫn lộn, nhưng chúng trả lời những câu hỏi khác nhau và đòi hỏi kỷ luật khác nhau từ manager.
- Coaching giả định người đó đã có, hoặc có thể tự tìm ra, câu trả lời — nhiệm vụ của manager là đặt câu hỏi giúp họ tự khám phá ra nó, chứ không phải cung cấp sẵn. Manager giữ vai trò trung lập về nội dung và chuyên gia về quy trình (đặt câu hỏi tốt, giữ im lặng đúng lúc, phản chiếu lại những gì nghe được).
- Mentoring giả định kinh nghiệm của chính manager có ích trực tiếp — manager chia sẻ “tôi từng làm gì trong tình huống tương tự” hoặc “đây là điều tôi sẽ lưu ý.” Manager là chuyên gia về nội dung, nhưng đưa ra như một góc nhìn tham khảo, không phải mệnh lệnh.
- Managing (directive) nghĩa là manager quyết định hướng đi và chịu trách nhiệm về kết quả — phù hợp khi có deadline, vấn đề an toàn, report thiếu context cần thiết, hoặc khi cái giá của một quyết định sai quá lớn để bỏ ngỏ.
| Khía cạnh | Coaching | Mentoring | Directive managing |
|---|---|---|---|
| Ai nắm câu trả lời | Người được coach | Manager, đưa ra như gợi ý | Manager, đưa ra như chỉ thị |
| Kỹ năng cốt lõi của manager | Đặt câu hỏi, active listening | Chia sẻ kinh nghiệm liên quan | Quyết định và truyền đạt rõ ràng |
| Tình huống điển hình | Người đó có kỹ năng/context nhưng đang bế tắc hoặc thiếu tự tin | Người đó chưa từng tiếp xúc với con đường mà manager đã đi qua | Áp lực thời gian, rủi ro cao, hoặc khoảng cách kỹ năng quá lớn để lấp ngay lúc đó |
| Rủi ro nếu lạm dụng | Cảm giác né tránh khi người đó thực sự thiếu thông tin | Tạo phụ thuộc; report không bao giờ xây được judgment riêng | Report không phát triển; manager trở thành bottleneck |
| Phù hợp nhất cho | Các quyết định đòi hỏi judgment lặp lại, quyết định sự nghiệp, thay đổi hành vi | Xử lý chính trị nội bộ (org politics), đánh đổi kỹ thuật manager từng gặp | Sự cố (incident), onboarding cơ bản, chuẩn mực không thể thương lượng |
Kỹ năng thực sự không phải là chọn một chế độ mãi mãi — mà là chẩn đoán, ngay tại thời điểm đó, tình huống đang đòi hỏi chế độ nào, và thành thật với bản thân về việc mình đang thực sự mặc định dùng chế độ nào chỉ vì thói quen chứ không phải vì đó là lựa chọn đúng.
Mô hình coaching GROW
GROW là một cấu trúc đơn giản cho cuộc trò chuyện coaching, được phổ biến ban đầu trong lĩnh vực executive coaching (Whitmore, Coaching for Performance). Nó không giải quyết vấn đề thay người khác; nó dẫn dắt họ qua một chuỗi câu hỏi khiến bước tiếp theo trở nên rõ ràng với chính họ.
| Giai đoạn | Mục đích | Câu hỏi ví dụ |
|---|---|---|
| Goal (Mục tiêu) | Xác định kết quả tốt cho cuộc trò chuyện này và vấn đề nền tảng | ”Bạn muốn đạt được điều gì sau buổi nói chuyện hôm nay?” “Thành công ở đây trông như thế nào?” |
| Reality (Thực tế) | Phơi bày tình huống hiện tại mà không phán xét | ”Chuyện gì đang xảy ra?” “Bạn đã thử gì rồi?” “Điều gì đang cản trở bạn?” |
| Options (Lựa chọn) | Tạo ra các phương án khả thi, cố tình bao gồm cả những lựa chọn người đó chưa nghĩ tới | ”Bạn có những lựa chọn nào?” “Nếu không bị giới hạn nguồn lực, bạn sẽ làm gì?” “Bạn chưa thử cách nào?” |
| Will (Cam kết, hoặc Way forward) | Cam kết một hành động tiếp theo cụ thể và một điểm check-in | ”Bạn sẽ chọn phương án nào?” “Bước đầu tiên là gì, và khi nào?” “Làm sao bạn biết nó có hiệu quả?” |
Đoạn hội thoại mẫu — một kỹ sư đang phân vân giữa hai hướng kiến trúc:
Manager (Goal): “Bạn muốn cuộc nói chuyện này giúp được gì cho bạn?” Kỹ sư: “Tôi muốn quyết định nên dùng hướng event-driven hay chỉ mở rộng service hiện tại.” Manager (Reality): “Điều gì khiến quyết định này khó khăn lúc này?” Kỹ sư: “Hướng event-driven đúng đắn hơn về lâu dài, nhưng tôi lo về timeline, và tôi chưa từng xây hệ thống kiểu này bao giờ.” Manager (Reality): “Bạn đã tìm hiểu được gì rồi?” Kỹ sư: “Tôi đã phác thảo cả hai thiết kế và ước lượng thời gian sơ bộ. Event-driven có thể chậm hơn khoảng hai tuần.” Manager (Options): “Ngoài việc chọn một trong hai, bạn còn thấy lựa chọn nào khác không?” Kỹ sư: “Tôi nghĩ có thể làm một phiên bản event-driven thu gọn — chỉ phần cần dùng ngay — và để chỗ mở rộng sau. Hoặc tôi có thể nhờ [senior engineer] pair cùng để giảm rủi ro về timeline.” Manager (Options): “Còn gì nữa không? Nếu deadline không cố định, bạn sẽ làm gì?” Kỹ sư: “Thật ra thì tôi sẽ làm cho đúng hẳn. Vậy có lẽ câu hỏi thật sự là deadline có thực sự cố định hay không.” Manager (Will): “Bước tiếp theo là gì, và khi nào bạn sẽ làm?” Kỹ sư: “Tôi sẽ viết thiết kế event-driven thu gọn hôm nay, và xin [senior engineer] một giờ ngày mai để kiểm tra lại ước lượng. Tôi cũng sẽ báo với anh nếu cần trao đổi về timeline với PM.” Manager: “Tốt — thứ Năm mình check-in xem ước lượng thế nào.”
Chú ý manager không hề nói nên chọn kiến trúc nào. Kỹ sư tự đi đến kế hoạch của riêng mình, thậm chí còn tự phát hiện ra một giả định (deadline) đáng để đặt câu hỏi lại — một khám phá mà các câu hỏi coaching tạo ra thường xuyên hơn nhiều so với lời khuyên trực tiếp.
Mối quan hệ mentoring
Mentoring chỉ hiệu quả khi được xây dựng quanh một nhu cầu cụ thể, không phải một bài tập ghép cặp mơ hồ. Hai cấu trúc thường gặp trong thực tế:
- Formal mentoring (mentoring chính thức) — tổ chức chủ động ghép cặp người (thường như một phần của onboarding, chương trình phát triển sự nghiệp, hoặc leadership pipeline), thiết lập nhịp độ kỳ vọng, và đôi khi cung cấp cấu trúc nhẹ (một buổi kickoff, gợi ý chủ đề, ngày kết thúc xác định). Chương trình chính thức giúp mentoring tiếp cận được những người sẽ không tự tìm được mentor một cách tự nhiên — đặc biệt là người junior hơn và người thuộc nhóm underrepresented, thường ít có khả năng tiếp cận mạng lưới sponsor không chính thức.
- Informal mentoring (mentoring không chính thức) — nảy sinh tự nhiên, thường vì ai đó chủ động tìm đến một người có kinh nghiệm hoặc con đường mà họ ngưỡng mộ. Thường có mức độ gắn kết cao hơn mỗi buổi nhưng phân bố không đều trong tổ chức.
Điều gì khiến việc ghép cặp hiệu quả, bất kể nguồn gốc chính thức hay không chính thức:
- Nhu cầu đủ cụ thể từ phía mentee — “giúp tôi vượt qua giai đoạn chuyển từ IC sang manager” hiệu quả hơn nhiều so với “giúp tôi phát triển.” Mục tiêu mơ hồ tạo ra những cuộc trò chuyện mơ hồ, thiếu năng lượng.
- Đủ context chung để kinh nghiệm của mentor thực sự chuyển giao được — một mentor cao hơn hai cấp nhưng ở domain khác vẫn có thể giúp về judgment và chính trị nội bộ, nhưng không thể giúp về phát triển kỹ thuật chuyên sâu theo domain.
- Đủ psychological safety để thừa nhận điều gì đó không hiệu quả — một mentee không thể nói với mentor “lời khuyên đó không đúng với tôi” thì không nhận được mentoring thực sự, chỉ là một bài độc thoại.
- Phạm vi và thời hạn đủ rõ ràng để cả hai bên có thể kết thúc mà không gượng gạo — quan hệ “mentor mãi mãi” không giới hạn thường sẽ nguội dần và biến thành nợ lịch hẹn.
Công việc của manager không nhất thiết là tự mình làm mentor cho từng report (một manager trực tiếp mentor report của mình về con đường sự nghiệp có xung đột lợi ích cố hữu, vì manager cũng là người kiểm soát promotion và lương). Thường giá trị hơn là chủ động môi giới (broker) các mối quan hệ mentoring ở nơi khác trong tổ chức — giới thiệu một report với người đã đi qua con đường họ muốn đi, và theo dõi xem mối quan hệ đó có thực sự hiệu quả không.
Delegation và phổ delegation
Delegation không phải là nhị phân (tự làm hay giao hết) — nó là một phổ (spectrum), và chọn sai điểm trên phổ này là một trong những nguyên nhân phổ biến nhất gây kiệt sức cho manager lẫn trì trệ cho team.
| Mức | Mô tả | Manager nói gì |
|---|---|---|
| 1. Tell | Manager quyết định, report thực thi đúng như được chỉ định | ”Làm theo cách này, đây là các bước.” |
| 2. Sell | Manager quyết định nhưng giải thích lý do để tạo sự đồng thuận | ”Đây là việc chúng ta sẽ làm và lý do tại sao.” |
| 3. Consult | Manager thu thập ý kiến của report trước khi quyết định | ”Bạn nghĩ nên làm gì? Tôi sẽ quyết định sau khi nghe bạn.” |
| 4. Agree | Manager và report cùng quyết định, ngang hàng ở quyết định này | ”Cùng thống nhất một hướng nhé.” |
| 5. Advise | Report quyết định; manager đưa ý kiến nếu được hỏi | ”Việc này bạn quyết — sẵn sàng góp ý nếu bạn cần.” |
| 6. Inquire | Report quyết định và hành động; manager chỉ cần được báo lại sau đó | ”Cứ làm đi — báo tôi kết quả nhé.” |
| 7. Delegate | Toàn quyền tự chủ; manager không can thiệp | ”Việc này là của bạn. Tôi tin vào judgment của bạn.” |
Bảng này được điều chỉnh từ các framework về mức độ delegation dùng trong agile và đào tạo lãnh đạo (liên quan chặt tới cái đôi khi gọi là thang “delegation poker”). Mức độ này không phải là một đặc điểm tính cách cố định của report — nó là thuộc tính của task cụ thể và của competence, confidence của report trên chính task đó, đó là lý do cùng một người có thể ở mức 2 với một phần codebase xa lạ và mức 7 với phần họ đã sở hữu hai năm.
Khớp đúng mức với người đòi hỏi đọc hai biến độc lập:
- Competence (năng lực) — người này đã thực sự làm thành công loại task này trước đây chưa, và họ có kỹ năng task này đòi hỏi không?
- Confidence (sự tự tin) — bất kể competence, họ có tin mình làm được không, và họ có thoải mái hành động mà không cần giám sát chặt không?
Một kỹ sư có kỹ năng nhưng hay lo lắng (competence cao, confidence thấp) thường cần mức 4–5 với việc xây dựng niềm tin rõ ràng chứ không phải mức 2 — họ không cần thêm chỉ dẫn, họ cần sự trấn an và một track record chứng minh mình đúng. Một kỹ sư nhiệt tình nhưng chưa được kiểm chứng (competence thấp, confidence cao) là sự lệch pha nguy hiểm hơn — họ sẽ vui vẻ nhận delegation mức 6–7 và tạo ra kết quả sai một cách tự tin, nên họ cần mức 2–3 với các checkpoint rõ ràng, được đóng khung sao cho không giống như một cuộc bỏ phiếu bất tín nhiệm.
Các lỗi delegation thường gặp:
- Under-delegating vì nhu cầu kiểm soát — manager tự nhủ việc này “quá quan trọng để giao” hoặc “tự làm nhanh hơn,” điều này thường đúng ngay lúc đó nhưng sai trên một chân trời thời gian dài hơn. Điều này giới hạn sự phát triển của team lẫn năng lực của chính manager, và thường là vấn đề lo âu của manager hơn là một quyết định quản lý rủi ro thực sự.
- Over-delegating mà không có hỗ trợ — giao một task mức 6–7 cho người thực chất chỉ đang ở competence mức 2–3, rồi coi thất bại xảy ra sau đó là vấn đề performance thay vì lỗi hiệu chỉnh (calibration) delegation. Chính sự hiệu chỉnh sai của manager đã gây ra thất bại đó.
- Giao kết quả nhưng không giao thẩm quyền — nói với ai đó “việc này là của bạn” (ngôn ngữ mức 7) trong khi vẫn nghi ngờ từng quyết định (hành vi mức 1). Điều này còn tệ hơn việc chọn dứt khoát một mức nào đó, vì nó phá vỡ niềm tin ở cả hai chiều.
- Không bao giờ đàm phán lại mức delegation khi competence tăng lên — để một report ở mức 2 cho một task họ đã thành thạo từ một năm trước, điều này bị hiểu là thiếu tin tưởng và dẫn đến disengagement.
Khái niệm chính
Trí tuệ cảm xúc (Emotional Intelligence) cho manager
Sự xuất sắc về kỹ thuật là điều giúp hầu hết kỹ sư được thăng chức lên quản lý. Nhưng đó không phải là điều giúp họ hiệu quả sau khi đã ở vị trí đó. Khi phạm vi quản lý mở rộng — từ vài report lên cả một team rồi nhóm nhiều team — đòn bẩy của manager ngày càng nằm ở các quyết định về con người, các cuộc trò chuyện khó khăn, và khả năng đọc tình huống trong phòng, chứ không phải ở việc viết code tốt hơn ai đó. Bạn không thể dùng kỹ thuật để giải quyết một report cảm thấy bị thiếu tôn trọng, một team đã ngừng tin tưởng lẫn nhau, hay một mối quan hệ với stakeholder đang âm thầm rạn nứt.
Framework của Daniel Goleman (Emotional Intelligence, 1995; Working with Emotional Intelligence, 1998) chia EQ thành bốn domain, xây dựng lên nhau:
| Domain | Là gì | Ví dụ với manager |
|---|---|---|
| Self-awareness (tự nhận thức) | Nhận ra cảm xúc của chính mình và tác động của chúng lên judgment, hành vi ngay lúc đó | Nhận ra mình đang bực bội trước khi vào 1:1 và gọi tên nó trong đầu trước khi nó rò rỉ vào cuộc trò chuyện |
| Self-regulation (tự điều tiết) | Quản lý cảm xúc và xung động gây rối thay vì bị chúng điều khiển | Không gửi câu trả lời gay gắt cho một tin nhắn Slack gây bực mình; dừng lại trước khi phản hồi trong một cuộc họp căng thẳng |
| Empathy (đồng cảm) | Cảm nhận cảm xúc và góc nhìn của người khác, kể cả những gì họ không nói ra trực tiếp | Nhận ra một kỹ sư thường xuyên phát biểu đã trở nên im lặng trong standup và hỏi thăm riêng |
| Social skill (kỹ năng xã hội) | Quản lý các mối quan hệ và xây dựng mạng lưới; dẫn dắt mọi người hướng tới kết quả mong muốn | Xử lý một bất đồng giữa hai senior engineer mà không ai cảm thấy bị bỏ qua |
Self-awareness và self-regulation là điều kiện tiên quyết cho hai domain còn lại — một manager không nhận ra hoặc không quản lý được phản ứng của chính mình sẽ khó đọc đúng người khác, vì trạng thái cảm xúc của chính họ liên tục làm nhiễu việc đọc đó. Về mặt thực hành, EQ được xây dựng giống mọi kỹ năng khác: gọi tên trạng thái cảm xúc của bản thân trước các cuộc trò chuyện quan trọng, chủ động xin feedback về điểm mù (self-perception của manager nổi tiếng không đáng tin ở khía cạnh này — 360 feedback tồn tại chính vì lý do đó), và coi mỗi tương tác khó khăn là dữ liệu về một pattern chứ không phải một sự cố đơn lẻ.
Nhận diện và giảm thiểu bias
Mọi quyết định về con người mà manager đưa ra — ai được giao stretch project, ai được xây dựng promotion case, ai được cho benefit of the doubt trong một buổi retro sự cố — đều dễ bị bóp méo một cách có hệ thống và phần lớn vô thức. Gọi tên đúng loại bias khiến việc bắt lỗi ngay tại thời điểm đó dễ hơn nhiều so với chỉ quyết tâm chung chung “phải công bằng.”
| Bias | Biểu hiện | Cách giảm thiểu |
|---|---|---|
| Affinity bias | Thiên vị những người giống mình (background, phong cách giao tiếp, trường học) trong staffing, tuyển dụng, cơ hội không chính thức | Phỏng vấn có cấu trúc với rubric cố định; chủ động đa dạng hóa ai được tiếp cận cơ hội không chính thức |
| Recency bias | Đánh giá hiệu suất bị chi phối bởi vài tuần gần nhất thay vì toàn bộ chu kỳ | Duy trì log ghi nhận công việc nổi bật xuyên suốt chu kỳ, không chỉ trước mùa review |
| Halo/horn effect | Một đặc điểm nổi bật (mạnh hoặc yếu) — thường là thâm niên, sự tự tin, hoặc một thành công/thất bại lớn — chi phối đánh giá về mọi thứ khác ở người đó | Đánh giá từng năng lực cụ thể riêng biệt thay vì một điểm tổng thể theo cảm tính; hỏi “bằng chứng cụ thể cho claim này là gì?” |
| Confirmation bias | Khi đã hình thành quan điểm về ai đó, ta chú ý tới bằng chứng xác nhận nó và bỏ qua bằng chứng phản bác | Chủ động tìm ví dụ phản bác trước khi chốt một review hay promotion case; hỏi một đồng nghiệp có góc nhìn khác về người đó |
Các biện pháp giảm thiểu mang tính cấu trúc thường hiệu quả hơn ý chí đơn thuần: các buổi calibration nơi nhiều manager so sánh đánh giá và phải chứng minh bằng bằng chứng sẽ phơi bày bias mà một manager làm việc đơn độc sẽ không bao giờ nhận ra; blind review hoặc partially blinded review (ví dụ bỏ tên hoặc tín hiệu thâm niên khỏi mẫu viết trong một promo packet) giảm affinity và halo effect ở những nơi khả thi; và yêu cầu bằng chứng viết cho mỗi đánh giá, thay vì một con số lấy từ trí nhớ, buộc recency và confirmation bias phải lộ ra để bị chất vấn.
Xử lý conflict
Đa số conflict trong team không phải là xung đột tính cách — mà thường là hai người có bất đồng thực sự, mang tính cấu trúc (về priority, cách tiếp cận, hoặc ownership) chưa được cho một cách giải quyết có cấu trúc. Một framework đơn giản, điều chỉnh từ nguyên tắc negotiation (Fisher & Ury, Getting to Yes):
- Tách con người khỏi vấn đề. Giải quyết bất đồng về kế hoạch mà không để nó biến thành đánh giá về tính cách hay năng lực của người đó. “Tôi nghĩ hướng caching này có rủi ro” là một cuộc trò chuyện khác với “anh lúc nào cũng overengineer.”
- Hiểu interest (lợi ích), không chỉ position (lập trường). Position là điều ai đó đang yêu cầu (“chúng ta nên dùng Postgres”); interest là lý do vì sao (“tôi cần đảm bảo strong consistency và chưa tin tưởng độ trưởng thành vận hành của mình với một datastore mới”). Hai người có thể giữ position không tương thích trong khi chia sẻ cùng một interest — và đó thường là nơi giải pháp thực sự nằm ở.
- Tìm mục tiêu chung phía trên bất đồng. Cả hai kỹ sư trong một cuộc tranh luận kiến trúc thường đều muốn hệ thống đáng tin cậy và team ship đúng hạn — gọi tên mục tiêu chung đó thành lời sẽ đưa cuộc trò chuyện từ “ai thắng” sang “điều gì phục vụ mục tiêu mà cả hai đều có.”
Khi nào nên mediate (hòa giải) và khi nào để mọi người tự giải quyết: Đa số bất đồng giữa những người trưởng thành có năng lực nên để họ tự xử lý — can thiệp quá sớm gửi tín hiệu rằng manager không tin tưởng team có thể xử lý ma sát, và tước đi cơ hội để họ tự rèn kỹ năng giải quyết conflict. Hãy trực tiếp mediate khi:
- Bất đồng đã bế tắc hơn một hoặc hai chu kỳ mà không có tiến triển và đang chặn tiến độ giao việc.
- Có sự mất cân bằng quyền lực hoặc thâm niên thực sự khiến một bên khó phản biện một cách an toàn.
- Conflict đã trở nên mang tính cá nhân (xem các tín hiệu leo thang bên dưới) thay vì giữ ở phạm vi nội dung.
- Một trong hai bên đã chủ động yêu cầu giúp đỡ.
Các tín hiệu leo thang đáng chú ý: ngôn ngữ chuyển từ “kế hoạch” sang “anh/chị” hoặc “họ”; một người ngừng tham gia vào các kênh hoặc cuộc họp chung; các phàn nàn bắt đầu đến từ bên thứ ba thay vì trực tiếp từ người liên quan; cùng một bất đồng lặp lại dưới hình thức khác mỗi vài tuần mà không được giải quyết; sự bực bội thể hiện rõ trong giao tiếp bằng văn bản (trả lời cộc lốc, CC rộng rãi như một chiến thuật gây áp lực). Bắt được những tín hiệu này sớm và có một cuộc trò chuyện trực tiếp với từng bên — riêng lẻ trước tiên, lý tưởng là gặp trực tiếp hoặc qua video — rẻ hơn nhiều so với để nó đi đến mức ai đó âm thầm disengage hoặc team chia phe.
Coaching vs. mentoring vs. directive management — khi nào dùng cái nào
| Tình huống | Chế độ phù hợp nhất | Vì sao |
|---|---|---|
| Report có đủ kỹ năng và context nhưng đang bế tắc khi quyết định | Coaching | Họ có thể tự tìm ra câu trả lời; mục tiêu là xây dựng judgment của họ, không phải giải quyết thay |
| Report đang đối mặt với điều manager đã có kinh nghiệm trực tiếp (một quyết định sự nghiệp tương tự, một tình huống chính trị nội bộ tương tự) | Mentoring | Kinh nghiệm cụ thể của manager là một đường tắt thực sự đáng chia sẻ |
| Sự cố production đang diễn ra | Directive | Không có thời gian để khám phá; cần ai đó chịu trách nhiệm quyết định |
| Report mới vào team hoặc mới nhận vai trò | Kết hợp directive (về những điều không thể thương lượng) và mentoring (về cách mọi thứ vận hành ở đây) | Họ chưa có context mà coaching giả định phải có |
| Pattern hiệu suất hoặc hành vi lặp lại | Coaching, leo thang lên directive nếu không thay đổi | Quyền sở hữu sự thay đổi phải thuộc về người đó, nhưng manager không thể để một vấn đề thực sự tồn tại vô thời hạn |
| Trò chuyện về sự nghiệp và phát triển | Chủ yếu là coaching, mentoring khi được hỏi trực tiếp về con đường của chính manager | Con đường của manager không nhất thiết là con đường của report |
Best Practices
- Mặc định ưu tiên coaching trước mentoring, và mentoring trước directing — chỉ dùng directive management cho những tình huống thực sự đòi hỏi (áp lực thời gian, an toàn, các chuẩn mực không thể thương lượng), và coi việc thường xuyên dựa vào nó là tín hiệu cần xem lại lý do.
- Xin phép trước khi mentor mà không được yêu cầu — “Tôi có thể chia sẻ một điều từ kinh nghiệm của mình không?” giúp mentoring không biến thành lời khuyên không được yêu cầu lấn át tư duy của chính người đó.
- Xem lại mức delegation một cách rõ ràng và định kỳ thay vì để nó đóng băng ở điểm khởi đầu — competence thay đổi, và mức delegation nên thay đổi theo.
- Khi delegate, nói rõ bạn đang dùng mức nào (“việc này bạn quyết, cứ báo tôi biết” khác với “cùng quyết định việc này nhé”) — sự mơ hồ về mức độ tự nó là nguyên nhân phổ biến gây lỗi delegation.
- Chủ động xây vòng phản hồi cho trí tuệ cảm xúc của chính mình: nhờ một đồng nghiệp tin cậy hoặc manager của bạn cho feedback thẳng thắn về cách bạn thể hiện dưới áp lực, vì tự đánh giá EQ vốn không đáng tin cậy.
- Gọi tên bias bạn đang lo ngại, thành lời, trong các cuộc calibration và tuyển dụng — “tôi muốn kiểm tra xem mình có đang bị halo effect vì đợt launch lớn vừa rồi không” mời người khác cùng kiểm tra điểm mù của bạn thay vì chỉ dựa vào sự tự cảnh giác của riêng bạn.
- Yêu cầu bằng chứng viết, cụ thể cho các đánh giá hiệu suất và promotion case thay vì điểm số cảm tính tổng thể — điều này phơi bày recency và confirmation bias để bị chất vấn.
- Để những người trưởng thành có năng lực tự giải quyết các bất đồng ít rủi ro; dành việc mediate trực tiếp cho các conflict bế tắc, mất cân bằng, hoặc mang tính cá nhân, và hành động theo các tín hiệu leo thang sớm thay vì chờ đến khi bùng nổ.
- Kết hợp mô hình GROW với sự tò mò thực sự — hỏi một cách máy móc, câu hỏi GROW nghe như một kịch bản thẩm vấn; hỏi với sự quan tâm thực sự tới suy nghĩ của người đó, chúng trở thành sự hỗ trợ thực sự.
- Coi coaching, mentoring, delegation, EQ và nhận thức về bias là một hệ thống liên kết, không phải các kỹ năng riêng lẻ — xem One-on-Ones, Feedback & Performance để biết những cuộc trò chuyện này diễn ra ở đâu trong nhịp độ hàng tuần, và Team Culture & Well-Being để thấy việc áp dụng nhất quán chúng xây dựng (hoặc bào mòn) niềm tin ở cấp độ team theo thời gian như thế nào.
Tài liệu tham khảo
- Whitmore, J. — Coaching for Performance (tài liệu gốc về mô hình GROW)
- Goleman, D. — Emotional Intelligence (1995) và Working with Emotional Intelligence (1998)
- Fisher, R. & Ury, W. — Getting to Yes: Negotiating Agreement Without Giving In
- Oncken, W. & Wass, D. — “Management Time: Who’s Got the Monkey?”, Harvard Business Review — https://hbr.org/1999/11/management-time-who-has-the-monkey
- Project Oxygen — các phát hiện về hành vi coaching của manager, Google re:Work — https://rework.withgoogle.com/en/subjects/managers
- CIPD — hướng dẫn “Coaching and mentoring” — https://www.cipd.org/en/knowledge/factsheets/coaching-mentoring-factsheet/
- roadmap.sh — Engineering Manager Roadmap — https://roadmap.sh/engineering-manager
Part of the Engineering Manager Roadmap knowledge base.
Overview
Most new engineering managers default to “managing” every interaction: they diagnose the problem, decide the fix, and tell the report what to do. It feels efficient and it draws on the exact skill that got them promoted — being the best problem-solver in the room. But a manager who only ever manages caps their team’s growth at their own capacity, because nobody on the team ever has to build the muscle of solving hard problems themselves. Coaching, mentoring, and emotional intelligence are the three capabilities that let a manager multiply their team’s output instead of just directing it.
This note draws a hard line between coaching (drawing out the person’s own answer), mentoring (sharing the manager’s own experience and advice), and directive management (deciding and being accountable for the outcome), and gives a practical model — GROW — for running a coaching conversation. It covers how to build mentoring relationships that actually work, how to delegate work at the right altitude for a person’s competence and confidence on that specific task, why emotional intelligence becomes more important than technical skill as scope grows, how unconscious bias distorts people decisions and what mitigates it, and a simple, repeatable framework for resolving conflict before it calcifies. Together these are the “soft skills” that are actually the hard, learnable skills of the job — see also One-on-Ones, Feedback & Performance for the cadence these conversations live in, and Team Culture & Well-Being for how they compound into team-level trust.
Fundamentals
Coaching vs. mentoring vs. managing
These three modes get conflated constantly, but they answer different questions and require different discipline from the manager.
- Coaching assumes the person already has, or can find, the answer — the manager’s job is to ask questions that help them discover it, not to supply it. The manager stays neutral on the content and expert on the process (asking good questions, holding silence, reflecting back what they hear).
- Mentoring assumes the manager’s own experience is directly useful — the manager shares “here’s what I did in a similar situation” or “here’s what I’d watch out for.” The manager is an expert on the content, offered as one input, not a mandate.
- Managing (directive) means the manager decides the direction and owns accountability for the outcome — appropriate when there’s a deadline, a safety issue, insufficient context on the report’s side, or when the cost of a wrong decision is too high to leave open.
| Dimension | Coaching | Mentoring | Directive managing |
|---|---|---|---|
| Who holds the answer | The person being coached | The manager, offered as guidance | The manager, given as instruction |
| Manager’s core skill | Asking questions, active listening | Sharing relevant experience | Deciding and communicating clearly |
| Typical trigger | Person has the skill/context but is stuck or lacks confidence | Person lacks exposure to a path the manager has walked | Time pressure, high stakes, or skill gap too large to close in the moment |
| Risk if overused | Feels evasive when person genuinely lacks information | Creates dependency; report never builds own judgment | Report never grows; manager becomes a bottleneck |
| Best for | Recurring judgment calls, career decisions, behaviour change | Navigating org politics, technical trade-offs the manager has faced before | Incidents, onboarding basics, non-negotiable standards |
The skill isn’t picking one mode forever — it’s diagnosing, in the moment, which mode the situation calls for, and being honest with yourself about which one you’re actually defaulting to out of habit rather than judgment.
The GROW coaching model
GROW is a simple structure for a coaching conversation, originally popularized in executive coaching (Whitmore, Coaching for Performance). It doesn’t fix problems for people; it walks them through a sequence that makes the next step obvious to them.
| Stage | Purpose | Example questions |
|---|---|---|
| Goal | Define what a good outcome looks like for this conversation and the underlying issue | ”What would you like to walk away with today?” “What does success look like here?” |
| Reality | Surface the current situation without judgment | ”What’s happening right now?” “What have you already tried?” “What’s getting in the way?” |
| Options | Generate possible paths, deliberately including options the person hasn’t considered | ”What are your options?” “What would you do if resources weren’t a constraint?” “What haven’t you tried yet?” |
| Will (or Way forward) | Commit to a specific next action and a check-in point | ”Which option will you take?” “What’s the first step, and by when?” “How will you know it worked?” |
Worked mini-dialogue — an engineer who feels stuck between two architecture approaches:
Manager (Goal): “What would be useful to get out of this conversation?” Engineer: “I want to figure out whether to use the event-driven approach or just extend the existing service.” Manager (Reality): “What’s making this a hard call right now?” Engineer: “The event-driven version is more correct long-term, but I’m worried about the timeline, and I haven’t built a system like this before.” Manager (Reality): “What have you already looked into?” Engineer: “I sketched both designs and did a rough time estimate. Event-driven is maybe two weeks slower.” Manager (Options): “What options do you see, beyond a straight either/or?” Engineer: “I guess I could do a scoped version of the event-driven approach — just the piece we need now — and leave room to expand it later. Or I could ask [senior engineer] to pair with me on the event-driven build to de-risk the timeline.” Manager (Options): “What else? What would you do if the deadline weren’t fixed?” Engineer: “Honestly, I’d just do it properly. So maybe the real question is whether the deadline is actually fixed.” Manager (Will): “What’s the next step, and when will you take it?” Engineer: “I’ll write up the scoped event-driven design today, and ask [senior engineer] for an hour tomorrow to sanity-check the estimate. I’ll also flag to you if the timeline conversation needs to happen with the PM.” Manager: “Good — let’s check in Thursday on how the estimate looks.”
Notice the manager never says which architecture to pick. The engineer arrives at their own plan, including surfacing an assumption (the deadline) that turned out to be worth questioning — a discovery coaching questions produce far more often than direct advice does.
Mentoring relationships
Mentoring works when it’s built around a specific need, not a vague pairing exercise. Two structures show up in practice:
- Formal mentoring — the organization pairs people deliberately (often as part of onboarding, a career-development program, or a leadership pipeline), sets an expected cadence, and sometimes provides light structure (a kickoff conversation, suggested topics, a defined end date). Formal programs help mentoring reach people who wouldn’t otherwise find a mentor organically — notably, more junior people and people from underrepresented groups, who often have less access to informal sponsor networks.
- Informal mentoring — arises organically, usually because someone sought out a person whose experience or path they admired. It tends to have higher engagement per session but is unevenly distributed across an organization.
What makes pairing work, regardless of formal or informal origin:
- A specific enough need on the mentee’s side — “help me navigate a return to IC-to-manager transition” works better than “help me grow.” Vague goals produce vague, low-energy conversations.
- Enough shared context that the mentor’s experience actually transfers — a mentor two levels up in a different domain can still help with judgment and politics, but can’t help with domain-specific technical growth.
- Psychological safety to admit what’s not working — a mentee who can’t tell their mentor “that advice didn’t land” isn’t getting real mentoring, just a monologue.
- A defined enough scope and duration that either side can end it without awkwardness — open-ended “let’s mentor forever” relationships tend to fizzle into calendar debt.
The manager’s job isn’t necessarily to be every report’s mentor personally (a direct manager mentoring their own report on career moves has an inherent conflict of interest, since the manager also controls promotion and pay). It’s often more valuable to actively broker mentoring relationships elsewhere in the org — introducing a report to someone who’s walked a path they want to walk, and following up on whether it’s actually working.
Delegation and the delegation spectrum
Delegation is not binary (do it yourself vs. hand it off completely) — it’s a spectrum, and picking the wrong point on it is one of the most common causes of both manager burnout and team stagnation.
| Level | Description | What the manager says |
|---|---|---|
| 1. Tell | Manager decides, report executes exactly as specified | ”Do it this way, here are the steps.” |
| 2. Sell | Manager decides but explains the reasoning to build buy-in | ”Here’s what we’re doing and why.” |
| 3. Consult | Manager gathers the report’s input before deciding | ”What do you think we should do? I’ll decide after hearing you out.” |
| 4. Agree | Manager and report decide together, as equals on this decision | ”Let’s agree on an approach together.” |
| 5. Advise | Report decides; manager offers an opinion if asked | ”It’s your call — happy to share a view if useful.” |
| 6. Inquire | Report decides and acts; manager asks to be told after the fact | ”Go ahead — let me know how it goes.” |
| 7. Delegate | Full autonomy; manager stays out of it entirely | ”This is yours. I trust your judgment.” |
This is adapted from delegation-level frameworks used in agile and leadership training (closely related to what’s sometimes called the “delegation poker” scale). The level isn’t a personality trait of the report — it’s a property of the specific task and the report’s competence and confidence on that specific task, which is why the same person might sit at level 2 for an unfamiliar area of the codebase and level 7 for the area they’ve owned for two years.
Matching level to person requires reading two independent variables:
- Competence — has this person actually done this kind of task successfully before, and do they have the skills the task requires?
- Confidence — regardless of competence, do they believe they can do it, and are they comfortable acting without close supervision?
A skilled-but-nervous engineer (high competence, low confidence) often needs level 4–5 with visible trust-building rather than level 2 — they don’t need more instruction, they need reassurance and a track record of being right. An eager-but-unproven engineer (low competence, high confidence) is the more dangerous mismatch — they’ll happily accept level 6–7 delegation and produce a confidently wrong result, so they need level 2–3 with explicit checkpoints, framed in a way that doesn’t read as a vote of no confidence.
Common delegation failures:
- Under-delegating out of a need for control — the manager tells themselves the work is “too important to hand off” or “faster to just do myself,” which is often true in the moment and false over any longer horizon. This caps the team’s growth and the manager’s own capacity, and it’s usually a manager anxiety problem more than a real risk-management decision.
- Over-delegating without support — handing someone a level 6–7 task while they’re actually at level 2–3 competence, then treating the resulting failure as a performance problem rather than a delegation-calibration failure. The manager’s own miscalibration caused the miss.
- Delegating the outcome but not the authority — telling someone “this is yours” (level 7 language) while still second-guessing every decision (level 1 behavior). This is worse than picking either level cleanly, because it destroys trust in both directions.
- Never renegotiating the level as competence grows — leaving a report at level 2 for a task they mastered a year ago, which reads as a lack of trust and drives disengagement.
Key Concepts
Emotional intelligence for managers
Technical excellence is what gets most engineers promoted into management. It is not what makes them effective once there. As scope grows — from a few reports to a whole team to a group of teams — a manager’s leverage increasingly runs through people decisions, difficult conversations, and reading a room, not through writing better code than anyone else. You cannot out-technical your way out of a report who feels disrespected, a team that’s stopped trusting each other, or a stakeholder relationship that’s quietly souring.
Daniel Goleman’s framework (Emotional Intelligence, 1995; Working with Emotional Intelligence, 1998) breaks EQ into four domains that build on each other:
| Domain | What it is | Manager example |
|---|---|---|
| Self-awareness | Recognizing your own emotions and their effect on your judgment and behavior in the moment | Noticing you’re irritated going into a 1:1 and naming it internally before it leaks into the conversation |
| Self-regulation | Managing disruptive emotions and impulses rather than being run by them | Not sending the sharp reply to a frustrating Slack message; pausing before responding in a tense meeting |
| Empathy | Sensing others’ emotions and perspectives, including ones they haven’t stated directly | Noticing a normally vocal engineer has gone quiet in standups and following up privately |
| Social skill | Managing relationships and building networks; moving people toward desired outcomes | Navigating a disagreement between two senior engineers without either feeling unheard |
Self-awareness and self-regulation are prerequisites for the other two — a manager who can’t notice or manage their own reactions will struggle to read others accurately, because their own emotional state keeps contaminating the read. Practically, EQ is built the same way any skill is: naming your own emotional state before high-stakes conversations, seeking feedback on blind spots (a manager’s self-perception is notoriously unreliable here — 360 feedback exists precisely because of this), and treating every difficult interaction as data about a pattern rather than a one-off.
Bias recognition and mitigation
Every people decision a manager makes — who gets the stretch project, whose promotion case gets built, who gets the benefit of the doubt in an incident retro — is vulnerable to systematic, mostly unconscious distortion. Naming the specific bias makes it far easier to catch in the moment than a general resolve to “be fair.”
| Bias | What it looks like | Mitigation |
|---|---|---|
| Affinity bias | Favoring people who remind you of yourself (background, communication style, alma mater) in staffing, hiring, and informal opportunity | Structured interviews with a fixed rubric; deliberately diversify who gets access to informal opportunities |
| Recency bias | A performance review dominated by the last few weeks rather than the full period | Keep a running log of notable work throughout the cycle, not just before review season |
| Halo/horn effect | One strong (or weak) trait — often seniority, confidence, or a single big win/failure — colors judgment of everything else about that person | Evaluate specific competencies separately rather than one holistic gut score; ask “what’s the evidence for this specific claim?” |
| Confirmation bias | Once you’ve formed an opinion about someone, you notice evidence that confirms it and discount evidence that doesn’t | Actively seek disconfirming examples before finalizing a review or a promotion case; ask a peer who has a different view of the person |
Structural mitigations tend to outperform willpower: calibration sessions where multiple managers compare ratings and justify them with evidence surface bias that a single manager working alone would never catch; blind or partially blinded review (removing names or seniority signals from writing samples in a promo packet, for instance) reduces affinity and halo effects where it’s feasible; and requiring written evidence for every rating, rather than a number pulled from memory, forces the recency and confirmation biases into the open where they can be challenged.
Conflict resolution
Most team conflict is not a personality clash — it’s usually two people with a real, structural disagreement (about priority, approach, or ownership) that hasn’t been given a structured way to resolve. A simple framework, adapted from principled-negotiation work (Fisher & Ury, Getting to Yes):
- Separate the person from the problem. Address the disagreement about the plan without letting it become a judgment about the person’s character or competence. “I think the caching approach has a risk” is a different conversation than “you always overengineer things.”
- Understand interests, not just positions. A position is what someone is asking for (“we should use Postgres”); an interest is why (“I need strong consistency guarantees and I don’t trust our ops maturity with a new datastore yet”). Two people can hold incompatible positions while sharing an interest, which is where a real resolution usually lives.
- Look for a shared goal above the disagreement. Both engineers in an architecture debate usually want the system to be reliable and the team to ship on time — naming that shared goal out loud reframes the conversation from “who wins” to “what serves the goal we both have.”
When to mediate vs. when to let people work it out: Most disagreements between capable adults should be left to them — stepping in too early signals the manager doesn’t trust the team to handle friction, and it deprives people of the chance to build their own conflict-resolution skill. Mediate directly when:
- The disagreement has stalled for more than a cycle or two with no progress and is blocking delivery.
- There’s a real power or seniority imbalance that makes it hard for one side to push back safely.
- The conflict has become personal (see the escalation signals below) rather than staying on the substance.
- Either party has asked for help.
Escalation signals worth watching for: language shifting from “the plan” to “you” or “they”; one person stops engaging in shared channels or meetings; complaints start arriving from third parties rather than the people involved; the same disagreement resurfaces in a different guise every few weeks without resolution; visible frustration in written communication (terse replies, CC-ing widely as a pressure tactic). Catching these early and having a direct conversation with each party — separately at first, ideally in person or over video — is far cheaper than letting it reach the point where someone quietly disengages or a team splits into camps.
Coaching vs. mentoring vs. directive management — when to use each
| Situation | Best mode | Why |
|---|---|---|
| Report has the skills and context but is stuck deciding | Coaching | They can find the answer; the goal is building their judgment, not solving it for them |
| Report is navigating something the manager has direct experience with (a similar career move, a similar org-politics situation) | Mentoring | The manager’s specific experience is a genuine shortcut worth sharing |
| Production incident in progress | Directive | No time for discovery; someone needs to own the call |
| Report is new to the team or role | Mix of directive (on non-negotiables) and mentoring (on how things work here) | They lack the context coaching assumes |
| Recurring performance or behavior pattern | Coaching, escalating to directive if it doesn’t shift | Ownership of the change has to sit with the person, but the manager can’t leave a real problem unaddressed indefinitely |
| Career and growth conversations | Coaching primarily, mentoring when asked directly for the manager’s own path | The manager’s path isn’t necessarily the report’s path |
Best Practices
- Default to coaching before mentoring, and mentoring before directing — reserve directive management for situations that genuinely require it (time pressure, safety, non-negotiables), and treat frequent reliance on it as a signal to examine why.
- Ask permission before mentoring uninvited — “Can I share something from my own experience?” keeps mentoring from turning into unsolicited advice that overrides the person’s own thinking.
- Revisit delegation levels explicitly and periodically rather than letting them freeze at wherever they started — competence changes, and the delegation level should change with it.
- When delegating, be explicit about which level you’re using (“this one’s your call, just keep me posted” vs. “let’s decide this together”) — ambiguity about the level is itself a common cause of delegation failure.
- Build your own emotional-intelligence feedback loop deliberately: ask a trusted peer or your own manager for candid feedback on how you show up under pressure, since self-assessment of EQ is unreliable by nature.
- Name the bias you’re worried about, out loud, in calibration and hiring conversations — “I want to check I’m not halo-effecting this because of the big launch” invites others to check your blind spot rather than relying on your own vigilance alone.
- Require written, specific evidence for performance ratings and promotion cases rather than holistic gut scores — it exposes recency and confirmation bias to scrutiny.
- Let capable adults resolve their own low-stakes disagreements; save direct mediation for stalled, imbalanced, or personal conflicts, and act on escalation signals early rather than waiting for a blowup.
- Pair the GROW model with real curiosity — asked mechanically, GROW questions feel like an interrogation script; asked with genuine interest in the person’s thinking, they feel like real support.
- Treat coaching, mentoring, delegation, EQ, and bias-awareness as a connected system, not separate skills — see One-on-Ones, Feedback & Performance for where these conversations happen in the weekly rhythm, and Team Culture & Well-Being for how consistently applying them builds (or erodes) team-level trust over time.
References
- Whitmore, J. — Coaching for Performance (the original GROW model text)
- Goleman, D. — Emotional Intelligence (1995) and Working with Emotional Intelligence (1998)
- Fisher, R. & Ury, W. — Getting to Yes: Negotiating Agreement Without Giving In
- Oncken, W. & Wass, D. — “Management Time: Who’s Got the Monkey?”, Harvard Business Review — https://hbr.org/1999/11/management-time-who-has-the-monkey
- Project Oxygen findings on manager coaching behaviors, Google re:Work — https://rework.withgoogle.com/en/subjects/managers
- CIPD — “Coaching and mentoring” guidance — https://www.cipd.org/en/knowledge/factsheets/coaching-mentoring-factsheet/
- roadmap.sh — Engineering Manager Roadmap — https://roadmap.sh/engineering-manager