Tư duy (Mindset) khi làm Leader Bài 2: Kỹ năng Giao tiếp - Lãnh đạo không cần chức danh.
Có một sai lầm phổ biến là đợi đến khi có chức danh "Leader" thì mới bắt đầu lãnh đạo. Thực tế, chức danh chỉ là hệ quả của việc bạn đã lãnh đạo thành công từ trước đó. Lãnh đạo không cần chức danh chính là việc dùng sự ảnh hưởng (Influence) thay vì quyền lực (Authority). Và công cụ mạnh mẽ nhất để tạo ra sức ảnh hưởng chính là Kỹ năng Giao tiếp.
Dưới đây là 3 góc độ giao tiếp bạn cần nâng cấp:
1. Nói ngôn ngữ của "Business" (Giao tiếp phi kỹ thuật)
Các Developer thường mắc bệnh "nói tiếng ngoài hành tinh" (dùng quá nhiều thuật ngữ kỹ thuật) khi giao tiếp với Product Owner (PO), Business Analyst (BA) hoặc khách hàng. Một Leader xuất sắc là một "thông dịch viên" tài ba giữa đội Tech và đội Business.
Kinh doanh không quan tâm bạn dùng React hay Vue, PostgreSQL hay MongoDB. Họ quan tâm đến 3 thứ: Thời gian (Time), Tiền bạc/Chi phí (Cost), và Rủi ro (Risk).
| Tình huống | Cách nói của Developer bình thường | Cách nói của Leader tiềm năng |
|---|---|---|
| Gặp bug khó, trễ tiến độ | "Thư viện này bị conflict dependency, em phải refactor lại core module nên chậm." | "Có một vấn đề kỹ thuật phát sinh. Để giải quyết triệt để sẽ cần thêm 1 ngày, nếu không hệ thống sẽ rất chậm khi có nhiều user. Em sẽ ưu tiên làm xong phần này trước." |
| Từ chối yêu cầu vô lý | "Cái này vô lý quá, làm sao mà code được!" | "Tính năng này tính khả thi không cao vì A và B. Tuy nhiên, nếu mục đích của anh/chị là X, em đề xuất phương án C sẽ nhanh và hiệu quả hơn." |
| Đề xuất công nghệ mới | "Mình chuyển sang dùng GraphQL đi, cái này đang hot và viết sướng lắm." | "Mình nên thử GraphQL. Nó sẽ giúp giảm 30% thời gian tải trang cho user, đồng thời giúp Frontend và Backend làm việc độc lập, tăng tốc độ ra mắt tính năng mới." |
2. Nghệ thuật Review Code: Phê bình Code, không phê bình Người
Code Review (Đánh giá mã nguồn) là nơi diễn ra nhiều giao tiếp nhất giữa các lập trình viên. Đây cũng là nơi thể hiện rõ nhất tố chất lãnh đạo của bạn.
- Không ra lệnh, hãy gợi ý: Thay vì nói "Đoạn này viết tệ quá, sửa lại dùng hàm map đi", hãy nói "Nếu chúng ta dùng map ở đây, code trông sẽ gọn và dễ đọc hơn đấy. Bạn thấy sao?"
- Khen ngợi công khai: Khi thấy một đồng nghiệp (đặc biệt là người mới) viết một đoạn code hay, xử lý một thuật toán thông minh, hãy thả tim hoặc comment khen ngợi ngay trên Pull Request. Lãnh đạo là biết công nhận thành quả của người khác.
- Dùng từ "Chúng ta" thay vì "Bạn/Tôi": Khi có lỗi sập server do đồng nghiệp gây ra, đừng nói "Bạn làm sập server rồi". Hãy nói "Hệ thống đang có sự cố do đoạn code X, chúng ta cùng xem cách fix nhanh nhất nhé."
3. Lắng nghe chủ động và Trở thành "Cái mỏ neo" trong cuộc họp
Trong các buổi họp (Daily Scrum, Retrospective), nhiều Developer chỉ quan tâm đến phần báo cáo của mình rồi "tắt não".
Để nổi bật như một Leader, hãy làm 2 việc:
- Ghi chép và Tóm tắt: Khi mọi người tranh luận miên man và mất trọng tâm, hãy là người lên tiếng chốt lại: "Tóm lại nãy giờ chúng ta đang kẹt ở 2 vấn đề A và B. Vấn đề A thì anh X sẽ giải quyết. Vấn đề B chúng ta cần chốt phương án...".
- Nhường sân khấu: Nếu bạn thấy một thành viên ít nói hoặc bị ngắt lời, hãy chủ động mời họ: "Mình thấy bạn Y nãy giờ chưa có ý kiến. Y ơi, góc nhìn của bạn về phần Frontend này thế nào?"
📝 Bài tập thực hành cho Bài 2 (Trong tuần này)
- Dịch thuật thuật ngữ: Lần tới khi bạn phải báo cáo một vấn đề kỹ thuật (bug, tech debt) cho sếp hoặc PO, tuyệt đối không dùng từ chuyên ngành. Hãy thử giải thích nó bằng ngôn ngữ đời thường (ví dụ: ví von như việc xây nhà, làm đường...) để tập trung vào hệ quả (chậm tiến độ, rủi ro lỗi data...).
- Review Code có tâm: Thực hiện ít nhất 2 lượt review code cho đồng nghiệp trong tuần này. Áp dụng quy tắc: Khen 1 điểm tốt trước, sau đó mới góp ý cải thiện (dưới dạng câu hỏi gợi mở, không áp đặt).
Bí quyết: Sức ảnh hưởng không sinh ra từ chức danh, nó sinh ra từ sự tin tưởng mà đồng nghiệp dành cho bạn qua những lần giao tiếp nhỏ nhặt như vậy.
All rights reserved
