Nghệ thuật giao việc: tech lead edition (phần 3-hết)
Khi team liên tục gặp lỗi và không đạt kỳ vọng, đó không phải là câu chuyện của lỗi cá nhân – mà là vấn đề trong leadership của bạn.
👋 Chào bạn, rất vui vì chúng ta lại được gặp nhau!
Tuần rồi của bạn thế nào? Mong rằng bạn vẫn khỏe mạnh và hạnh phúc bên những người thân yêu!🌟 Đây đã là phần ba của series về Delegation (giao việc). Nếu bạn chưa đọc phần một và hai thì có thể đọc lại tại đây:
Để hoàn thành series này, mình đã học được rất nhiều khi hệ thống lại những kinh nghiệm thực tế. Dù đã có thời gian thực hành delegation trong công việc, mình nhận ra rằng giải thích một cách rõ ràng và đầy đủ cho các bạn – đặc biệt là những ai mới làm quản lý – không phải chuyện dễ. Delegation trong thực tế không chỉ có một công thức chuẩn, mà còn bị ảnh hưởng bởi tình huống, con người, và vô vàn biến số khác.
Nhưng chính những thách thức đó lại khiến mình cảm thấy hứng thú. Viết đến phần ba này, mình cảm nhận được sự đồng cảm và ủng hộ của các bạn qua những phản hồi tích cực. Đây là động lực để mình hoàn thiện series với mong muốn giúp bạn áp dụng được các phương pháp giao việc hiệu quả nhất trong công việc.
Nếu như ở phần 1 và 2, chúng ta tập trung vào thinking process TRƯỚC khi giao việc – làm sao để hiểu đúng nhiệm vụ, chọn đúng người và chuẩn bị kỹ càng – thì phần 3 này sẽ đào sâu hơn vào cách thực hiện TRONG và SAU khi giao việc. Đây chính là giai đoạn bạn cần truyền cảm hứng, quản lý rủi ro, đồng hành cùng đội ngũ, và không quên kiểm tra, điều chỉnh để đạt kết quả tốt nhất.
🎯 Bạn sẵn sàng chưa? Cùng bắt đầu nhé! 🚀
🎓 Delegation 101 (tiếp tục)
5. Delegation
Giao việc, nhìn thì đơn giản, nhưng để làm tốt thì lại là một nghệ thuật. Nó không chỉ dừng ở việc phân công nhiệm vụ mà còn là cách bạn truyền cảm hứng, quản lý rủi ro, và đảm bảo mọi người đều hiểu và đồng thuận.
Để làm được điều đó, mình thường đi theo thứ tự:
👉 WHY→HOW→WHAT→DERISK→ALIGNMENT.
5.1. Why – Động lực là chìa khóa 🔑
Con người được thúc đẩy mạnh mẽ nhất bởi câu hỏi “Tại sao”. Khi giao việc, đừng chỉ nói: “Chúng ta cần upgrade version cho frontend và backend”. Thay vào đó, hãy giải thích rõ giá trị đằng sau nhiệm vụ:
“Chúng ta cần upgrade version cho cả frontend và backend lên phiên bản LTS1 mới nhất để tăng hiệu suất, bảo mật ổn định hơn và thuận tiện hơn trong việc bảo trì trong 5 năm tới.”
Việc làm rõ “Why” không chỉ giúp team nhận thức được giá trị công việc, mà còn khiến họ cảm thấy mình đang đóng góp vào bức tranh lớn hơn.Nếu có thể, hãy cá nhân hóa động lực. Ví dụ với một junior dev, bạn có thể nói:
“Đây là cơ hội để em thực hành thiết kế API với kiến trúc RESTful, rất cần cho lộ trình phát triển của em.”
5.2. How – Làm sao để làm tốt? 🤔
Sau khi đã hiểu mục đích, bước tiếp theo là hướng dẫn cách thực hiện. Hãy cung cấp những tài nguyên, công cụ hoặc kết nối cần thiết để công việc được bắt đầu thuận lợi nhất.
Mình thường hỏi:
“Em cần thêm thông tin hay tài liệu gì không? Nếu cần hỗ trợ từ ai, anh sẽ giúp kết nối.”
Nếu người nhận nhiệm vụ cảm thấy có đủ tài nguyên và sự hỗ trợ, họ sẽ tự tin hơn khi thực hiện.Đừng quên đặt giới hạn trách nhiệm để họ tập trung và không bị quá tải. Ví dụ:
“Em chỉ cần phân tích nghiệp vụ và trình bày giải pháp, còn việc báo cáo trước khách hàng sẽ do team Business Development đảm nhiệm.”
5.3 What – Kết quả mong đợi 🎯
Mọi người làm việc hiệu quả hơn khi biết rõ kết quả mình cần đạt được. Thay vì giao nhiệm vụ mơ hồ như “Build API cho module XYZ” hãy làm rõ đầu ra cụ thể:
Deadline: “API cần hoàn thành trước thứ Sáu để kịp tích hợp vào front-end.”
Chất lượng: “API phải bao gồm xử lý những bước A, B, C….”
Tiêu chuẩn: “Cần có test case với coverage tối thiểu 80%”
Những tiêu chí rõ ràng giúp cả hai bên có căn cứ đánh giá kết quả.5.4. Derisk – Phòng hơn chống ⚠️
Rủi ro là một phần không thể thiếu của mọi nhiệm vụ, nhất là những công việc phức tạp. Để giảm thiểu rủi ro, hãy giúp team member dự đoán những vấn đề có thể phát sinh.
“Task renew SSL này có thể bị chậm nếu team Cloud Ops không phản hồi kịp. Nếu đến hết tuần không thấy họ trả lời, em liên hệ anh ABC, cc anh vô để a dí phụ.”
Hoặc:
“Em nên setup một cuộc họp 30 phút với team DevOps để họ hỗ trợ trực tiếp. Làm vậy nhanh hơn là gửi email qua lại.”
Việc chia sẻ kinh nghiệm không chỉ giúp giảm sai sót mà còn xây dựng sự tin tưởng giữa bạn và team.5.5. Alignment – Đồng thuận giữa các bên 🤝
Đôi khi, nhiệm vụ không khó, nhưng việc đồng thuận giữa các bên liên quan lại là thử thách lớn nhất. Một bài học xương máu của mình là từng phải mất tới 70% thời gian, công sức chỉ để “thông não” và tìm hiểu khó khăn của các team liên quan, vì mỗi bên đều có KPIs, constraints, policies riêng nên việc họ hỗ trợ bạn có thể chỉ là “nice to have” chứ không phải “must to be”.
Trước khi bắt tay vào làm, hãy xác định rõ ai cần tham gia, và nếu cần, tổ chức một buổi họp nhanh để tất cả cùng hiểu rõ mục tiêu. Khuyến khích mọi người đặt câu hỏi để làm rõ mọi khúc mắc. Việc này không chỉ giúp tiết kiệm thời gian mà còn giảm thiểu nguy cơ phải sửa đổi sau này.
Hãy nhớ, sự đồng thuận là nền tảng để công việc diễn ra suôn sẻ.
6. Xác định mức độ giao việc
Không phải mọi nhiệm vụ đều giống nhau, và cách bạn giao việc cần được điều chỉnh để phù hợp với từng tình huống. Điều này không chỉ đảm bảo hiệu quả mà còn giúp tối ưu hóa năng lực của đội ngũ. Mình thường sử dụng mô hình 5 mức độ giao việc, tương tự như một công tắc chỉnh âm lượng – linh hoạt thay đổi để phù hợp với nhiệm vụ.
6.1. Do as I say – Làm đúng như hướng dẫn 📝
✅ Khi công việc đơn giản, rõ ràng, và không yêu cầu sáng tạo.
✅ Phù hợp với nhân sự mới, chưa quen với hệ thống hoặc công nghệ đang sử dụng.
🚫 Khi team member đã đủ kinh nghiệm hoặc nhiệm vụ yêu cầu tính sáng tạo. Áp dụng phương pháp này quá thường xuyên có thể khiến họ cảm thấy bị kiểm soát.
“Thay đoạn mã trong file
Navbar.jsđể logo hiển thị đúng trên màn hình 4K. Dùng cách đã ghi trong tài liệu nhé!”
6.2. Research and report back – Nghiên cứu và báo cáo 🔍
✅ Khi cần thông tin hoặc dữ liệu ban đầu để ra quyết định.
✅ Khi người thực hiện chưa đủ kinh nghiệm để tự đề xuất giải pháp cuối cùng.
🚫 Khi cần hành động ngay hoặc khi team member đã hiểu rõ vấn đề và có khả năng tự đưa ra đề xuất.
“Nghiên cứu các giải pháp khả thi cho app modernisation. Liệt kê ưu – nhược điểm và báo cáo lại để cả team thảo luận.”
6.3. Research and make a recommendation – Đưa ra đề xuất 💡
✅ Khi người thực hiện có kinh nghiệm trong lĩnh vực liên quan và đủ khả năng phân tích vấn đề.
✅ Khi bạn cần một đề xuất từ góc nhìn chuyên môn trước khi ra quyết định cuối cùng.
🚫 Khi vấn đề vượt quá phạm vi hiểu biết của cá nhân hoặc đòi hỏi sự phối hợp của nhiều team.
“Tìm hiểu cách cải thiện performance cho MongoDB. Đưa ra đề xuất giải pháp phù hợp và lý do lựa chọn.”
6.4. Decide and inform – Tự quyết định và thông báo lại 📢
✅ Khi người thực hiện đã hiểu rõ hệ thống và công việc liên quan.
✅ Khi nhiệm vụ không đòi hỏi phải kiểm duyệt hoặc phê duyệt từ cấp trên.
🚫 Khi nhiệm vụ có tác động lớn, ví dụ như thay đổi kiến trúc hệ thống hoặc quyết định tài chính. Trong trường hợp này, bạn cần phối hợp hoặc tham khảo ý kiến của các bên liên quan.
“Chọn giải pháp CI/CD2 phù hợp và triển khai. Chỉ cần thông báo lại khi hoàn thành.”
6.5. Act independently – Tự chủ hoàn toàn 🏋️
✅ Khi bạn hoàn toàn tin tưởng vào năng lực và kinh nghiệm của người thực hiện.
✅ Khi nhiệm vụ yêu cầu sáng tạo hoặc đòi hỏi một người có khả năng ra quyết định độc lập.
🚫 Khi nhiệm vụ có nhiều rủi ro hoặc cần sự giám sát chặt chẽ.
“Triển khai tính năng theo cách bạn thấy phù hợp. Cứ tự chủ hoàn toàn, chỉ cần báo cáo lại khi cần hỗ trợ.”
Việc chọn đúng mức độ giao việc không chỉ dựa vào bản thân nhiệm vụ, mà còn phụ thuộc vào:
Mức độ tin tưởng giữa bạn và họ.
Mỗi mức độ đều có ưu và nhược điểm riêng, và đôi khi bạn sẽ cần điều chỉnh linh hoạt giữa các mức này trong cùng một nhiệm vụ để đạt hiệu quả tối đa.7. Vòng lặp phản hồi-điều chỉnh
Giao việc không có nghĩa là bạn “ném việc rồi mặc kệ.” Sau khi giao nhiệm vụ, bạn cần theo sát để đảm bảo mọi thứ diễn ra đúng hướng. Tuy nhiên, việc theo dõi không phải là kiểm soát vi mô (micro-managing), mà là một vòng lặp phản hồi và điều chỉnh hợp lý. Điều này giúp bạn hỗ trợ team hiệu quả, xây dựng sự tin cậy, và cải thiện kết quả công việc.
7.1. Check-in thường xuyên 📅
Hãy thiết lập các checkpoint để kiểm tra tiến độ công việc. Ở giai đoạn đầu, có thể bạn cần over-communication (trao đổi thường xuyên hơn bình thường) để tránh hiểu nhầm và giúp đội ngũ bắt đúng nhịp.
Ví dụ:
“Hãy gửi bản nháp đầu tiên vào thứ Tư để chúng ta review sớm.”
“Sau khi xử lý được phần API, cứ báo lại để team test thử trên môi trường staging.”
Khi team dần làm quen với cách làm việc, bạn có thể giảm tần suất check-in để tránh làm phiền. Nhưng hãy nhớ, đừng bỏ qua bất kỳ dấu hiệu nào cho thấy họ đang bị “ngợp.” Hãy luôn chủ động hỏi:
“Công việc vẫn ổn chứ? Có chỗ nào cần hỗ trợ không?”
7.2. Phản hồi mang tính xây dựng 🛠️
Phản hồi không phải là chỉ trích sai sót, mà là cơ hội để bạn mentor hoặc coach đội ngũ.
Mentor: chia sẻ kinh nghiệm của bạn để họ học hỏi nhanh hơn.
“Khi trước mình làm REST API, từng gặp lỗi tương tự. Sau đó mình dùng caching và nó cải thiện hiệu suất rõ rệt.”
Coach: đặt câu hỏi để khơi gợi cách giải quyết.
“Em nghĩ nếu thử cách tiếp cận khác, như xử lý trước dữ liệu trên server, thì hiệu quả sẽ thế nào?”
Hãy giữ tinh thần khích lệ. Nếu kết quả chưa đạt kỳ vọng, thay vì nói “Sao làm chậm thế?”, bạn có thể dùng:
“Phần này chắc cần thêm thời gian để tối ưu. Em đang gặp khó khăn ở đâu?”
7.3. Chấp nhận rủi ro như cơ hội để học hỏi 🌟
Không phải nhiệm vụ nào cũng hoàn hảo ngay từ đầu. Sai lầm là cơ hội để cả bạn và cả team cùng học hỏi và trưởng thành.
Ví dụ, sau một sprint với tỷ lệ bug cao, bạn có thể tổ chức buổi retrospective3:
“Sprint4 vừa rồi trước có nhiều lỗi, nhưng team đã rút ra bài học và cải thiện quy trình. Điều đó giá trị hơn cả kết quả ban đầu.”
Đừng quên nhấn mạnh bài học thay vì đổ lỗi. Điều này không chỉ giúp đội ngũ học hỏi mà còn tăng tính đoàn kết và khả năng thích nghi.
Tóm lại:
Hãy chắc rằng bạn có mặt lúc họ cần và đưa ra phản hồi kịp thời trong suốt quá trình làm việc. Đó là trách nhiệm và bổn phận của người làm lead/manager.Nhưng nếu tôi không có ai để giao việc thì sao? 🤷♂️
Có thể bạn đang nghĩ: “Tôi chỉ là một thành viên trong team, không phải leader, hoặc team tôi quá nhỏ, làm gì có ai để giao việc?” Đây là một tình huống khá phổ biến, đặc biệt nếu bạn đang làm việc trong một startup nhỏ hoặc chỉ mới ở vị trí junior/mid-level.
Delegation không chỉ đơn thuần là giao việc cho người khác. Bản chất của delegation là tối ưu hóa thời gian và năng lượng của chính bạn để làm những việc quan trọng hơn.Một số cách mà bạn có thể thực hành từ hôm nay để tối ưu hóa bản thân:
Tự động hóa quy trình lặp đi lặp lại. Vd: dùng ChatGPT, Claude….
Rèn luyện kĩ năng tự quản lý.
Tuy nhiên, nếu bạn thích làm IC5 thì cũng không cần chú trọng nhiều tới delegation. Hoặc khi là bạn fresher, junior, tỉ lệ giữa học technical và non-technical nên là 80/20 hoặc 90/10, dần dần lên đến intermediate sẽ là 70/30 rồi lên đến senior sẽ là 50/50. Càng lên cao thì ưu tiên phát triển những thứ non-technical như soft skill, communication, delegation skill sẽ càng giúp bạn đi xa.
Nếu hôm nay bạn làm tốt việc tự quản lý, ngày mai bạn sẽ biết cách quản lý đội ngũ. Hãy bắt đầu từ những điều nhỏ nhất và luôn giữ tinh thần phát triển. 🌱
TL;DR: delegation thinking process 🌟
Giao việc gì?
Hiểu rõ nhiệm vụ cần làm và giá trị nó mang lại. Phân loại theo phễu giao việc.Xác định độ phức tạp.
Đánh giá xem nhiệm vụ thuộc loại nào: đơn giản, phức tạp hay cần sáng tạo.Phân loại độ ưu tiên.
Sử dụng các công cụ như ma trận Eisenhower hoặc Impact/Effort để xác định việc cần làm ngay.Chọn người để giao việc.
Sử dụng công cụ như ma trận Will/Skill để tìm người phù hợp.Delegation (giao việc).
Áp dụng theo thứ tự WHY→HOW→WHAT→DERISK→ALIGNMENT.Xác định mức độ giao việc (5 mức độ).
Linh hoạt điều chỉnh qua lại giữa các mức độ khi cần thiết.Vòng lặp phản hồi-điều chỉnh.
Check-in thường xuyên. Đưa feedback. Chấp nhận sai sót để học hỏi.
Bạn sẽ bắt đầu delegate những gì sau khi đọc bài viết này? Bạn đã sử dụng những phương pháp hoặc công cụ nào trong công việc hiện tại? Có mẹo nào khác không? Cùng chia sẻ nhé!
✌️ Bài hôm nay chỉ có thế
Như thường lệ, đừng ngần ngại thả ❤️ hay để lại comment cho newsletter tuần này nếu như bạn đã học được một điều gì đó mới mẻ, hay có một suy nghĩ nào đó từ lá thư này. Mình rất mong nhận được ý kiến từ độc giả của mình (và nếu bạn đã làm được đến mức này thì mình rất trân trọng)🙏🏻. Đó chính là nguồn cảm hứng để mình cải thiện và tiếp tục những bài viết tiếp theo!
See ya 🤖!
Bryant!
LTS: long-term support.
CI/CD: continuous integration and continuous delivery.
Buổi tổng kết để chia sẻ bài học và kinh nghiệm sau một sprint
Sprint: một khoảng thời gian ngắn trong mo hình Agile, thường là 2-3 tuần để cả team cùng phát triển hoàn thành một chức năng.
IC: Individual contributor
Hay quá anh Dũng ạ ❤️ đúng nội dung em cần