Mở đầu — vì sao bài này quan trọng
Có một sự thật mà rất nhiều Scrum Master nhận ra hơi muộn trong sự nghiệp: bạn có thể coach một team xuất sắc đến mức nào đi nữa, nhưng nếu lãnh đạo phía trên vẫn vận hành theo tư duy command-and-control (ra lệnh và kiểm soát), thì mọi nỗ lực của bạn rồi cũng bị bào mòn. Team vừa học được cách tự quản, một manager xuống "giao việc trực tiếp cho từng người" là đổ sông đổ bể. Team vừa dám nói thật trong Retrospective, một VP buông câu "sao Sprint vừa rồi chậm thế" là cả phòng im bặt suốt ba tháng sau.
Đó là lý do ở cấp độ PSM II, công việc coaching không dừng lại ở team. Một Scrum Master trưởng thành phải biết coach lên trên — coach chính những người đang trả lương cho mình, những người có quyền lực, có cái tôi, có lịch họp dày đặc và thường nghĩ rằng "Agile là việc của team, không phải của tôi". Đây là phần khó nhất và cũng giá trị nhất của nghề.
Bài này tập trung riêng vào coaching leadership — coaching ở ba tầng lãnh đạo khác nhau, từ team lead đến C-suite. Chúng ta sẽ không bàn lại kỹ thuật coaching cá nhân nói chung (đã có ở Bài 8) hay tư duy hệ thống cấp tổ chức (Bài 10). Ở đây, trọng tâm là: lãnh đạo ở mỗi tầng có mối bận tâm gì, bạn tiếp cận họ thế nào, và làm sao để coaching một người có quyền lực hơn bạn mà không bị "đá ra khỏi phòng".
Khái niệm cốt lõi
Vì sao coach lãnh đạo lại khác coach team
Khi coach một thành viên trong team, bạn và họ ít nhiều ngang hàng về quyền lực, và mục tiêu chung khá rõ. Khi coach lãnh đạo, ba điều thay đổi căn bản:
- Bất đối xứng quyền lực: họ có thể sa thải bạn; bạn không thể làm gì họ. Điều này khiến nhiều SM rụt rè, nói vòng vo, hoặc tệ hơn là chỉ biết "vâng dạ". Coaching thật sự đòi hỏi bạn phải dám nói điều khó nghe — nhưng nói theo cách họ nghe được.
- Mối bận tâm khác nhau: team quan tâm tới công việc hằng ngày, lãnh đạo quan tâm tới ngân sách, rủi ro, mục tiêu kinh doanh, và hình ảnh của họ trước cấp trên. Nếu bạn nói chuyện "Scrum thuần túy" với một CTO, họ sẽ thấy bạn ngây thơ.
- Tầm ảnh hưởng đòn bẩy: thay đổi được một hành vi của lãnh đạo có thể tháo gỡ impediment cho cả chục team. Một câu nói đúng lúc với một VP có sức nặng hơn cả tháng coaching team.
Ba tầng lãnh đạo mà Scrum Master coach
Tầng 1 — Team leads / Engineering Managers. Đây là tầng gần bạn nhất và cũng dễ va chạm nhất, vì họ thường là người trực tiếp "mất việc" khi Scrum hoạt động đúng. Trước đây họ phân công công việc, theo dõi tiến độ, quyết định ai làm gì. Bây giờ Scrum bảo team tự quản. Nỗi sợ ngầm của họ là: "Nếu team tự quản hết thì vai trò tôi còn gì?" Coaching tầng này xoay quanh việc tái định nghĩa vai trò của họ: từ người giao việc thành người phát triển con người, gỡ rào cản, xây dựng năng lực dài hạn.
Tầng 2 — Department heads / VP Engineering. Tầng này không quản lý công việc hằng ngày mà quản lý hệ thống: cấu trúc phòng ban, ngân sách headcount, KPI, quy trình giữa các bộ phận. Đây là nơi sinh ra phần lớn impediment cấp tổ chức — ví dụ chính sách "mỗi kỹ sư phải đạt 90% utilization" trực tiếp giết chết khả năng cải tiến của team. Coaching tầng này thường mang hình thức đối thoại về đánh đổi (trade-off): bạn không bảo họ "bỏ KPI utilization đi", bạn giúp họ thấy KPI đó đang đánh đổi điều gì.
Tầng 3 — C-suite (CTO, CPO, CEO). Tầng cao nhất, ít thời gian nhất, tư duy ở mức chiến lược và kết quả kinh doanh. Họ không quan tâm Scrum có làm đúng "by the book" không; họ quan tâm: sản phẩm có ra thị trường nhanh hơn không, rủi ro có giảm không, tiền có được chi hiệu quả không. Coaching tầng này gần như không bao giờ dùng từ "Scrum". Bạn nói ngôn ngữ của họ: time-to-market, predictability, risk, ROI. Công cụ mạnh nhất ở đây là bằng chứng và dữ liệu, không phải lý thuyết.
Nguyên tắc xuyên suốt: meet them where they are
Quy tắc vàng khi coach lãnh đạo là gặp họ ở nơi họ đang đứng — nói về điều họ quan tâm, bằng ngôn ngữ họ dùng, gắn với nỗi đau họ đang có. Một SM giỏi không "dạy Agile" cho lãnh đạo. Anh ta lắng nghe để hiểu lãnh đạo đang lo gì, rồi cho thấy một cách làm việc mới giải quyết được nỗi lo đó. Agile chỉ là phương tiện, không bao giờ là đích đến trong cuộc trò chuyện.
Một nguyên tắc thứ hai cũng quan trọng không kém: coaching theo lời mời (invitation), không áp đặt. Bạn không thể ép một CTO thay đổi. Bạn chỉ có thể tạo ra những khoảnh khắc khiến họ tự muốn thay đổi — bằng câu hỏi, bằng dữ liệu, bằng việc đặt một tấm gương trước mặt họ.
Tình huống thực tế
Tình huống 1 — Engineering Manager không chịu buông tay (Tiki, TP.HCM)
Tại một bộ phận sản phẩm của một sàn thương mại điện tử lớn ở TP.HCM (gọi là bối cảnh kiểu Tiki), có một Engineering Manager tên Hùng, quản lý 14 kỹ sư chia thành hai Scrum team. Hùng là kỹ sư giỏi đi lên, quen tay vào từng việc. Mỗi sáng anh nhắn riêng từng dev "task này xong chưa", và trong Sprint Planning anh thường tự quyết team commit bao nhiêu story.
Velocity hai team dao động thất thường, dev phàn nàn ngầm rằng "Planning chỉ là hình thức". Scrum Master Linh nhận ra gốc rễ không nằm ở team mà ở Hùng. Thay vì phê phán, Linh mời Hùng cà phê và hỏi: "Anh đang dành bao nhiêu phần trăm thời gian để theo dõi task hằng ngày?" Hùng tính ra khoảng 60%. Linh hỏi tiếp: "Nếu phần đó giảm còn 10%, anh sẽ dùng thời gian còn lại làm gì để tạo giá trị lớn hơn?"
Câu hỏi đó mở ra một cuộc đối thoại thật. Hùng thừa nhận anh không có thời gian làm việc anh thực sự muốn: định hướng kiến trúc, phát triển con người, làm việc với các bộ phận khác. Linh đề xuất một thử nghiệm 4 Sprint: Hùng ngừng giao task trực tiếp, để team tự kéo việc trong Daily Scrum; đổi lại Hùng dùng thời gian rảnh để mentor hai junior và đàm phán với team Data về một dependency kéo dài.
Bài học rút ra: coaching team lead không phải là tước quyền của họ mà là chỉ cho họ một vai trò có giá trị hơn. Câu hỏi "nếu giảm việc này, anh sẽ làm gì giá trị hơn" hiệu quả hơn nhiều so với câu khẳng định "anh đừng micromanage nữa". Sau 4 Sprint, velocity ổn định hơn và Hùng tự nói rằng anh "không ngờ buông tay lại nhẹ nhõm đến vậy".
Tình huống 2 — VP Engineering và cái KPI giết chết cải tiến (công ty fintech ~300 người, Hà Nội)
Một công ty fintech khoảng 300 nhân sự ở Hà Nội đặt KPI cho toàn bộ kỹ sư: utilization phải đạt tối thiểu 85%, nghĩa là 85% thời gian phải gắn với một task có trong hệ thống. VP Engineering, anh Tâm, tự hào về con số này vì nó "chứng minh đội ngũ làm việc hết công suất".
Hệ quả ngầm: không team nào dám dành thời gian cho refactoring, cải tiến quy trình, hay học hỏi, vì những việc đó không "tính utilization". Technical debt chồng chất, mỗi lần release lại có sự cố. Scrum Master Phong biết nếu nói thẳng "KPI của anh sai" thì sẽ bị phản ứng. Thay vào đó, anh chuẩn bị dữ liệu: trong 6 tháng, số sự cố production tăng 40%, thời gian sửa lỗi chiếm trung bình 30% mỗi Sprint, và mỗi sự cố lớn tốn khoảng 200 triệu đồng chi phí gián đoạn.
Phong xin gặp Tâm 30 phút và đặt một câu hỏi duy nhất: "Anh muốn đội ngũ bận 85%, hay anh muốn sản phẩm ổn định và ra tính năng đều đặn?" Rồi anh đặt dữ liệu lên bàn. Tâm im lặng một lúc và hỏi lại: "Vậy theo cậu, đo cái gì thì đúng hơn?" Phong đề xuất chuyển từ đo utilization sang đo flow — cụ thể là lead time (thời gian từ lúc nhận yêu cầu đến lúc lên production) và tỉ lệ Sprint đạt Sprint Goal. Họ chạy thử trên một tribe gồm 4 team trong 2 quý.
Bài học rút ra: với VP, đừng tấn công vào niềm tin của họ — hãy cho họ thấy cái họ đang đo lường đang dẫn tới hành vi ngược với mục tiêu họ muốn. Câu hỏi đặt ra hai lựa chọn (bận rộn vs. kết quả) buộc lãnh đạo phải tự đối diện với đánh đổi. Dữ liệu quy ra tiền (200 triệu/sự cố) có sức nặng hơn mọi lý thuyết Agile.
Tình huống 3 — Coach CTO bằng ngôn ngữ rủi ro, không phải Scrum (startup SaaS ~50 người, Singapore)
Một startup SaaS khoảng 50 người ở Singapore phục vụ thị trường Đông Nam Á. CTO, anh Raj, vốn xuất thân từ một big tech, tin vào kế hoạch dài hạn: mỗi năm anh chốt một roadmap cố định 12 tháng và cam kết với nhà đầu tư. Vấn đề là thị trường biến động nhanh, và nửa số tính năng trong roadmap khi làm xong thì khách hàng không còn cần nữa.
Scrum Master Mai biết rằng nói "Scrum thì làm việc theo Sprint, roadmap cố định 12 tháng là phản Agile" sẽ chẳng đi tới đâu với một CTO bận rộn. Thay vào đó, Mai dùng ngôn ngữ Raj quan tâm nhất: rủi ro vốn và niềm tin nhà đầu tư. Cô trình bày: "Mỗi tính năng ta xây mà không kiểm chứng nhu cầu là một khoản đặt cược. Năm ngoái ta đặt cược 12 tháng vốn vào một roadmap, và khoảng 50% trượt. Nếu ta chia thành các đặt cược nhỏ, mỗi quý kiểm chứng một lần, ta giảm rủi ro mất vốn và có dữ liệu thật để báo cáo investor."
Mai không đề nghị bỏ roadmap. Cô đề nghị giữ tầm nhìn 12 tháng nhưng chỉ cam kết chi tiết cho 1 quý, mỗi quý xem lại dựa trên dữ liệu sử dụng thực tế. Với Raj, đây không phải "làm Agile" — đây là quản trị rủi ro danh mục đầu tư, điều anh hiểu rất rõ. Anh đồng ý thử.
Bài học rút ra: coach C-suite gần như không bao giờ dùng từ vựng Scrum. Bạn dịch nguyên lý Agile sang ngôn ngữ chiến lược của họ — ở đây là rủi ro, vốn, và niềm tin nhà đầu tư. Cùng một ý tưởng (làm nhỏ, kiểm chứng sớm) nhưng đóng gói đúng cách thì lãnh đạo gật đầu.
Hướng dẫn từng bước
Dưới đây là một quy trình bạn có thể áp dụng cho bất kỳ tầng lãnh đạo nào, điều chỉnh độ sâu theo cấp:
- Hiểu thế giới của họ trước khi mở miệng. Trước cuộc gặp, trả lời ba câu: Người này chịu trách nhiệm về cái gì? Họ đang bị áp lực gì từ cấp trên? Thành công với họ được đo bằng gì? Đừng đến với agenda của bạn — đến với mối bận tâm của họ.
- Xây dựng quan hệ và sự tin cậy. Coaching lãnh đạo chỉ xảy ra khi có lòng tin. Trước khi đưa ra bất kỳ thách thức nào, hãy có vài lần tương tác nhỏ chứng minh bạn hiểu việc của họ và đứng về phía mục tiêu của họ.
- Bắt đầu bằng câu hỏi, không bằng kết luận. Powerful question (xem Bài 7) là vũ khí chính. "Điều gì khiến anh lo nhất về quý này?" mở ra nhiều hơn "Em nghĩ anh nên thay đổi cách này." Câu hỏi giúp lãnh đạo tự đi đến nhận thức, và nhận thức tự tìm ra thì mới bền.
- Đưa dữ liệu và bằng chứng đúng tầng. Team lead cần ví dụ cụ thể về team. VP cần xu hướng và số liệu hệ thống. C-suite cần con số quy ra tiền, rủi ro, time-to-market. Luôn quy nỗi đau thành thứ họ đo lường.
- Đề xuất một thử nghiệm nhỏ, có thời hạn. Đừng đòi hỏi cam kết vĩnh viễn. "Ta thử trong 4 Sprint rồi cùng nhìn lại" dễ được chấp nhận hơn nhiều vì rủi ro thấp và giữ thể diện nếu phải đổi hướng.
- Định nghĩa rõ thành công sẽ trông như thế nào. Trước khi chạy thử, thống nhất với lãnh đạo: nếu thử nghiệm này thành công, ta sẽ thấy điều gì thay đổi? Điều này biến một ý tưởng mơ hồ thành một cam kết đo được.
- Theo sát và phản chiếu kết quả. Sau thử nghiệm, đưa kết quả về cho lãnh đạo, để chính họ kết luận. Khi lãnh đạo tự nói "cách này tốt hơn", bạn đã thắng — và thay đổi sẽ tự lan.
Lỗi thường gặp & mẹo
Lỗi 1 — Coach lãnh đạo bằng ngôn ngữ Scrum. Nói "theo Scrum Guide thì..." với một CTO là cách nhanh nhất để mất họ. Mẹo: trước mỗi cuộc gặp, dịch điều bạn muốn nói sang ngôn ngữ của họ (tiền, rủi ro, thời gian, con người), bỏ hết thuật ngữ.
Lỗi 2 — Sợ quyền lực nên nói vòng vo. Vì lãnh đạo cao hơn mình, nhiều SM không dám nói điều khó nghe, kết quả là coaching trở nên vô hại và vô dụng. Mẹo: dùng kỹ thuật "nói thật một cách tôn trọng" — đặt sự thật dưới dạng câu hỏi hoặc quan sát trung lập ("Em nhận thấy mỗi lần anh phát biểu trong Retro thì sau đó team ít chia sẻ hơn — anh có để ý điều này không?").
Lỗi 3 — Coach một lãnh đạo chưa hề mời. Lao vào "chấn chỉnh" một VP chưa sẵn sàng nghe sẽ phản tác dụng. Mẹo: tạo điều kiện để họ mời bạn — bằng cách làm họ tò mò, đưa ra một quan sát hấp dẫn rồi dừng lại, để họ hỏi "thế theo cậu nên làm gì".
Lỗi 4 — Bỏ qua tầng giữa (VP / department head). Nhiều SM chỉ nhắm hoặc team lead hoặc C-suite, bỏ qua tầng giữa — nơi sinh ra nhiều impediment hệ thống nhất (KPI, ngân sách, cấu trúc phòng ban). Mẹo: lập bản đồ ai có quyền tháo gỡ impediment nào, và đầu tư quan hệ với tầng giữa.
Lỗi 5 — Coaching mà không thay đổi hệ thống. Bạn có thể coach một manager đổi hành vi, nhưng nếu hệ thống tưởng thưởng (lương, thăng tiến) vẫn dựa trên hành vi cũ, họ sẽ quay lại. Mẹo: khi coach lãnh đạo, luôn hỏi "hệ thống nào đang khuyến khích hành vi này" và giúp họ thấy chính họ có quyền sửa hệ thống đó.
Mẹo bổ sung — dùng tấm gương, không dùng cây gậy. Vai trò mạnh nhất của bạn không phải người phán xét mà là tấm gương phản chiếu. Cho lãnh đạo thấy hệ quả hành vi của họ một cách trung lập, rồi để họ tự quyết. Người tự nhận ra mới thay đổi thật.
Bài tập thực hành
- Lập bản đồ lãnh đạo. Vẽ ba tầng (team lead, VP/department head, C-suite) trong tổ chức bạn. Với mỗi người, ghi: họ chịu trách nhiệm gì, thành công đo bằng gì, họ đang lo gì nhất. Đây là nền tảng cho mọi cuộc coaching.
- Dịch ngôn ngữ. Lấy một thông điệp Agile bạn muốn truyền (ví dụ "team cần thời gian cho technical excellence"). Viết lại ba phiên bản: một cho team lead, một cho VP, một cho CTO — mỗi phiên bản dùng đúng mối bận tâm và ngôn ngữ của tầng đó, không dùng từ Scrum.
- Chuẩn bị một cuộc đối thoại khó. Chọn một hành vi của một lãnh đạo đang cản trở team. Soạn ba powerful question để mở đầu cuộc trò chuyện mà không khiến họ phòng thủ. Soạn thêm một mẩu dữ liệu/bằng chứng phù hợp với tầng của họ.
- Thiết kế một thử nghiệm. Cho impediment ở bài tập 3, viết một đề xuất thử nghiệm có thời hạn (ví dụ 4 Sprint), nêu rõ "thành công trông như thế nào" để lãnh đạo dễ gật đầu.
Tóm tắt
Ở cấp PSM II, coaching không dừng ở team — sức bật lớn nhất đến từ việc coach lên trên, vào chính hàng ngũ lãnh đạo. Có ba tầng cần coach, mỗi tầng có mối bận tâm và ngôn ngữ riêng: team lead lo về vai trò của mình (coach họ tái định nghĩa giá trị bản thân từ giao việc sang phát triển con người); VP / department head kiểm soát hệ thống và KPI (coach họ thấy đánh đổi mà các thước đo hiện tại đang gây ra); và C-suite tư duy chiến lược (coach họ bằng ngôn ngữ rủi ro, vốn, time-to-market — gần như không nhắc đến Scrum).
Xuyên suốt ba tầng là vài nguyên tắc bất biến: gặp họ ở nơi họ đang đứng, coaching theo lời mời chứ không áp đặt, mở đầu bằng câu hỏi, đưa dữ liệu đúng tầng, đề xuất thử nghiệm nhỏ có thời hạn, và làm tấm gương thay vì cây gậy. Khi bạn thay đổi được một hành vi của lãnh đạo, bạn không chỉ giúp một người — bạn tháo gỡ rào cản cho cả tổ chức. Đó chính là đòn bẩy lớn nhất mà một Scrum Master trưởng thành có thể tạo ra.