Những lỗi thường gặp khi lần đầu làm manager (phần 1)

Manager là công việc rất đặc biệt. Ít có trường lớp nào dạy chúng ta sau này ra sẽ làm manager như thế nào.

Thường thì bạn phải học làm kỹ thuật cho giỏi, tạo được sự tin tưởng của team và của ban lãnh đạo, sau đó mới được cất nhắc vào vị trí manager.

Đa số các bạn mới làm manager đều phải tự học, tự thử sai để tìm ra phương pháp tối ưu cho team của mình.

Đây là một quá trình chông gai đòi hỏi sự kiên nhẫn, sáng tạo, tư duy giải quyết vấn đề và quan trọng nhất là phải biết nhận ra lỗi của mình và sửa lỗi nhanh nhất có thể. Bởi vì mỗi lỗi lầm đều phải trả giá rất đắt và sẽ làm ảnh hưởng đến cả team.

Hôm nay, mình sẽ trình bày những lỗi mình từng mắc phải, hoặc những vấn đề quan sát được từ các manager mà mình từng có dịp làm việc chung.

Trước tiên, hãy cùng thống nhất một số thuật ngữ dùng trong bài.

Giải thích thuật ngữ

• IC (Individual Contributor): người làm chuyên môn, kỹ thuật. Ví dụ: kỹ sư, người thiết kế, người làm product/marketing, nhân viên chăm sóc khách hàng,…
• Manager: làm quản lý, lãnh đạo, trưởng nhóm/phòng, chịu trách nhiệm quản lý một hoặc nhiều IC, hoặc cấp cao hơn là quản lý nhiều manager.
• Họp 1on1: họp riêng giữa 2 người. Đủ riêng tư để bàn về các vấn đề nhạy cảm, khó nói với đám đông.

Giờ hãy bắt đầu nào.

Lỗi #1: Không tìm hiểu kỳ vọng của sếp

Với guồng quay công việc hằng ngày: xử lý các vấn đề phát sinh trong team, lên kế hoạch, họp hành, báo cáo, … bạn rất dễ rơi vào lầm tưởng rằng mình đang kiểm soát tình hình, rằng mình đang làm tốt, bởi vì mình bận thế này cơ mà.

Tuy nhiên, những việc bận rộn đó có khả năng chưa phải là vấn đề lớn mà sếp muốn bạn giải quyết.

Như hồi mình mới tiếp quản team đầu tiên với vai trò manager, mình cứ nghĩ chỉ cần giữ được nhịp độ làm việc hiện tại là được, bao gồm phát triển tính năng mới, code review, hỗ trợ IC giải quyết trục trặc trong dự án,…

Nhưng khi nói chuyện với sếp mình mới biết như vậy là chưa đủ. Sếp còn muốn mình:

• Lên kế hoạch giải quyết những món nợ kỹ thuật lớn (technical debt) trong hệ thống.
• Đồng bộ cách xử lý logic giữa 2 team iOS & Android (hồi đó mình quản lý team iOS).
• Rút ngắn chu kỳ release ứng dụng từ 2 tuần xuống còn 1 tuần, …

Từ đó, mình phân bổ thời gian lại để vừa xử lý việc phát sinh trong ngày, vừa chủ động giải quyết các vấn đề lớn mà sếp giao phó. Nhờ đó mới đạt được kết quả tốt, được sếp và đồng nghiệp công nhận.

Nếu trước đó mình cứ ngầm định mà không hỏi rõ kỳ vọng của sếp thì có lẽ đã bị khiển trách vì mặc dù team hoạt động trơn tru nhưng không có cải tiến gì nổi bật cả.

Rút kinh nghiệm

• Nên chủ động họp bàn với sếp nhiều trong giai đoạn đầu để xác định xem:
  • Sếp kỳ vọng gì ở team này, ở mình với vai trò manager?
  • Kết quả công việc sẽ được đánh giá ra sao?
  • Như thế nào gọi là thành công?
• Sếp là người rất bận rộn, nên đôi khi họ cũng chưa có hình dung cụ thể những kỳ vọng cho team này.
  • Bạn nên tạo một vài buổi họp từ 1-2 tiếng với lịch trình rõ ràng để bàn với sếp, thay vì chỉ dùng thời lượng 1on1 ngắn ngủi hằng tuần.
  • Mỗi lần 1on1 với sếp, cập nhật kết quả công việc và so sánh với kế hoạch đã bàn trước đó xem có cần điều chỉnh gì không.
• Thường thì lúc nào sếp cũng sẽ muốn mình giải quyết một số vấn đề cụ thể, chứ không chỉ là “đảm bảo cho team chạy ổn định”. Ví dụ:
  • Sản phẩm team làm hay bị lỗi, ảnh hưởng đến kế hoạch mở rộng thị trường.
  • Mỗi lần làm tính năng mới hay bị trễ tiến độ.
  • Khảo sát độ hài lòng của các thành viên trong team đang ở mức thấp.
• Đôi khi định hướng công ty thay đổi, hoặc có những yêu cầu mới từ sếp thì bạn cũng phải điều chỉnh team để thích ứng nhanh với công việc.

Lỗi #2: Không tìm hiểu mong muốn, nguyện vọng của các thành viên trong team

Mỗi bạn IC trong team thường sẽ có mong muốn khác nhau:

• Có bạn thích làm hệ thống bên dưới thay vì giao diện tính năng phía trên.
• Có bạn thích làm dự án một mình.
• Có bạn thích phải có một IC nữa làm chung trong dự án.
• Có bạn luôn khao khát thăng tiến.
• Có bạn hài lòng với vị trí hiện tại.
• Có bạn bị lấn cấn về lương…

Nếu những mong muốn này không được đáp ứng thì người đó sẽ mất động lực, rồi lâu dần sẽ cân nhắc chuyển team, hoặc thậm chí nghỉ việc.

Bởi vậy, manager phải là người hiểu rất rõ những nhu cầu này. Ví dụ:

• Mình từng thấy có manager khi vừa nhận một yêu cầu công việc từ phía product hoặc từ sếp thì liền giao cho một bạn IC bất kỳ hiện đang rãnh ở trong team mà không cân nhắc xem:
  • Yêu cầu này có hợp lý không, có nhất thiết phải làm không.
  • Nếu cần thì ai sẽ là người phù hợp nhất để giao việc và bạn đó sẽ cần thêm hỗ trợ gì.
• Rốt cuộc bạn IC đó cảm thấy mình toàn được giao những việc ngẫu nhiên, đột xuất và ít có liên quan tới mục tiêu mà bạn đó đang hướng tới.

Rút kinh nghiệm

• Nên có những buổi họp 1on1 riêng với từng bạn IC trong team để lắng nghe mong muốn, nguyện vọng của họ.
• Thiết lập kế hoạch để giúp họ đạt được mục tiêu đó. Ví dụ:
  • Nếu bạn đó muốn được thăng chức thì manager phải:
    • Giải thích được yêu cầu kỹ thuật của cấp bậc tiếp theo.
    • Giúp bạn đó thấy mình đang ở đâu, còn thiếu những gì, cần đạt được những gì.
    • Từ đó viết ra được một bản kế hoạch với những cột mốc cụ thể.
  • Dù cho bạn IC không có trực tiếp nói muốn được thăng tiến, manager vẫn nên lập kế hoạch phát triển sự nghiệp cho bạn đó.
    • Mỗi ngày, mỗi thành viên đều phải có tiến bộ.
    • Nếu không sẽ bị tụt lại phía sau.
  • Nếu bạn đó cảm thấy không hòa nhập được trong team thì manager cần:
    • Tìm hiểu xem vấn đề cốt lõi là gì: do quy trình, do dự án được giao, hay do xích mích với 1 bạn nào khác trong team, …
    • Rồi từ đó bàn cách giải quyết.
• Ở những lần 1on1 tiếp theo, manager nên đối chiếu với kế hoạch để đưa ra nhận xét, góp ý để giúp bạn IC đó điều chỉnh.
• Ngoài ra, manager cũng nên chủ động tìm kiếm những cơ hội để phát triển khả năng của các IC trong team. Ví dụ:
  • Trong buổi họp với các phòng ban khác, nhận thấy có một vấn đề mà team bạn có thể giúp giải quyết, thế là xung phong nhận việc về.
  • Hoặc đơn giản là khi có một yêu cầu mới giao xuống team, thì manager nên cân nhắc kỹ lưỡng để giao cho bạn IC phù hợp nhất.

Lỗi #3: Không đặt ra kỳ vọng rõ ràng cho từng thành viên trong team

Ngoài việc chăm sóc, phục vụ cho các thành viên trong team, manager còn phải thực hiện vai trò là “người huấn luyện viên nghiêm khắc”.

Bạn cần đánh giá được chất lượng làm việc của từng IC ở từng cấp bậc và đưa ra góp ý kịp thời.

• Nếu senior IC mà không làm tròn trách nhiệm thì không thể độc lập gánh vác các dự án lớn, không đảm bảo chất lượng kỹ thuật, và không làm gương được cho những bạn junior khác.
• Còn junior IC mà làm không tốt thì ảnh hưởng đến tiến độ dự án, hoặc tính năng khi ra mắt thì gặp nhiều lỗi, có thể gây ra nhiều đánh giá tiêu cực từ người dùng.
• Ngoài ra, IC không biết cách giao tiếp với các phòng ban khác (product manager, designer, marketing, QA…) thì khi làm việc chung lúc nào cũng phát sinh mâu thuẫn, phải dành nhiều thời gian tranh luận, cãi vã, thay vì tập trung xây dựng sản phẩm.

Rút kinh nghiệm

• Ứng với mỗi cấp bậc IC, cần viết ra các yêu cầu kỹ thuật và kỳ vọng một cách rõ ràng. Ví dụ:
  • Với junior software engineer: (đây là bản rút gọn. Khi làm thực tế thì nên viết cụ thể hơn nhiều)
    • Hiểu những module chính trong codebase.
    • Có thể phát triển một tính năng vừa & nhỏ.
    • Code cần phải có test.
    • Trình bày rõ ràng khi đưa code lên review.
    • Làm việc độc lập với product manager/designer/QA.
    • Chịu trách nhiệm khi có lỗi production ở tính năng mình làm.
  • Với senior software engineer: giống junior, nhưng được giao những dự án lớn hơn, ít mắc lỗi và có thể đào tạo junior engineer.
  • Với lead software engineer: giống senior, nhưng có thêm một số trách nhiệm khác nữa.
• Trong trường hợp công ty đã có những tiêu chuẩn này (thường gọi là career ladder guide), thì cũng nên chỉnh sửa để phù hợp với hoàn cảnh & phạm vi của team bạn.
• Mỗi lần họp 1on1, góp ý kín với các bạn IC khi họ làm chưa tốt. Nếu đó là lỗi thường gặp thì nên chia sẻ trong team để mọi người cùng học hỏi.
• Tuy nhiên, bạn cần tìm hiểu rõ đầu đuôi câu chuyện trước khi góp ý với IC. Ví dụ:
  • Bạn nghe product manager phàn nàn về một bạn IC làm trễ tiến độ dự án. Bạn nên tìm hiểu kỹ nguyên nhân trước khi đưa ra kết luận:
    • Có thể dự án trễ là vì product manager đưa deadline quá sát.
    • Hoặc thông tin dự án chưa rõ ràng, thường hay có thay đổi nên ảnh hưởng tiến độ…

Lỗi #4: Không thiết lập văn hóa trong team

Văn hóa là một trong những yếu tố cốt lõi quyết định thành công của team.

Mỗi khi có hành vi xấu đến từ bạn hoặc ai đó trong team, nếu bạn không ý kiến, thì nó sẽ trở thành văn hóa xấu.

• Nếu trong team lúc nào cũng có người trễ họp, thì team bạn sẽ có văn hóa trễ họp.
• Mỗi khi có sự cố, nếu bạn toàn đổ lỗi cho IC, thì team bạn sẽ có văn hóa đổ lỗi.
• Nếu bạn không review, đánh giá công việc cho IC, thì team bạn sẽ có văn hóa không review lẫn nhau, không chia sẻ, học hỏi gì.

Tương tự, mỗi khi có hành vi đẹp, nếu bạn biết khởi xướng hoặc chủ động biểu dương, thì nó sẽ tạo nên văn hóa tốt.

• Khi bạn làm việc chăm chỉ, team sẽ noi theo bạn và tạo nên văn hóa chăm chỉ.
• Khi IC đưa ra ý tưởng hay để cải tiến hệ thống, nếu bạn biết khen ngợi, thì sẽ tạo ra văn hóa luôn sáng tạo, đổi mới.
• Khi IC hoàn thành dự án với chất lượng cao, nếu bạn biết tuyên dương và giải thích rõ phương pháp làm việc của bạn đó cho mọi người, thì team sẽ có văn hóa nâng cao chất lượng.

Rút kinh nghiệm

• Vì văn hóa là điều rất khó thay đổi nên bạn cần thiết lập càng sớm càng tốt, lý tưởng nhất là trong những tháng đầu sau khi vừa tiếp nhận team.
• Trong công việc hằng ngày, luôn để ý những việc xảy ra trong team, những cử chỉ, hành vi, và đặt câu hỏi xem đây có phải là văn hóa tốt không. Ví dụ:
  • Thấy 2 bạn IC đang tranh luận với nhau mà hơi to tiếng và có xu hướng chê bai nhau. Bạn có nên can thiệp không?
  • Thấy trong các cuộc họp team, chủ yếu là bạn nói, còn mọi người thì không có ý kiến gì. Vậy có ổn không?
• Ngoài việc quan sát hằng ngày, cần chủ động suy nghĩ xem mình muốn tạo văn hóa như nào trong team, hiện tại đã có những văn hóa tốt/xấu gì và còn thiếu những gì. Sau đó lên kế hoạch thực hiện. Ví dụ:
  • Sau khi đánh giá, bạn nhận ra team mình hiện có 2 văn hóa xấu (trễ họp, hay đỗ lỗi) và có 3 văn hóa tốt bạn muốn triển khai (sáng tạo, chất lượng, chăm chỉ).
    • Trong đó, văn hóa “tập trung vào chất lượng” là quan trong nhất trong thời điểm hiện tại.
    • Vì thế bạn ưu tiên đưa ra những quy định về chất lượng và chủ động khen thưởng các bạn IC khi họ thể hiện được những điều đó.

[Đón xem phần 2]