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

Ở phần 1, mình đã trình bày về:

• Lỗi #1: Không tìm hiểu kỳ vọng của sếp
• 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
• Lỗi #3: Không đặt ra kỳ vọng rõ ràng cho từng thành viên trong team
• Lỗi #4: Không thiết lập văn hóa trong team

Giờ hãy cùng tìm hiểu những lỗi còn lại nhé.

Lỗi #5: Phân bổ thời gian chưa hợp lý

Nhớ hồi mới lên làm manager, mình cảm thấy công việc cũng không khác gì lắm so với lúc làm IC. Ngoài việc có thêm các buổi 1on1 mỗi 2 tuần với từng IC và họp hành với manager của các team khác, mình vẫn làm những công việc IC như thường: code tính năng, code review, sửa lỗi hệ thống, họp với product/design/QA,…

Mọi thứ vẫn ổn, cho đến khi mình phát hiện ra một số vấn đề lớn:

• Team mình không có kế hoạch gì khác trong tương lai ngoại trừ làm các tính năng mới mà bên product đưa qua.
• Mọi người trong team không hiểu làm các tính năng này có ý nghĩa gì và làm sao để được coi là một IC thành công.
• Một số bạn phàn nàn rằng quy trình làm việc còn lộn xộn, chủ yếu gặp chuyện đâu giải quyết đó chứ không rút kinh nghiệm gì.
• Có bạn cảm thấy việc thì nhiều nhưng đơn giản, không có nhiều vấn đề kỹ thuật phức tạp, không học hỏi được nhiều.

Từ đó, mình mới nhận ra rằng: “Làm manager không phải chỉ là làm người đại diện team đi họp, rồi quản thêm một vài IC là xong chuyện“.

Một manager tốt cần phải:

• Giúp team hiểu được tại sao công việc của họ quan trọng, như nào mới gọi là team thành công.
• Giúp từng thành viên hiểu điểm mạnh điểm yếu của họ, làm sao để phát triển bản thân và góp phần vào thành công của team.
• Giúp cải thiện quy trình làm việc giữa những IC với nhau, giữa IC với các phòng ban khác (product/design/marketing/QA…).
• Giúp team thấy được tương lai và có kế hoạch để đạt được nó.

Hiểu được như vậy thì mình mới biết cách phân bổ thời gian cho phù hợp, không còn quá tập trung vào công việc IC như trước nữa.

Rút kinh nghiệm

• Để ý xem thời gian của bạn trong một tuần được sử dụng như nào: bao nhiêu % là làm IC, bao nhiu % dành cho việc quản lý. Rồi với những việc quản lý đó, cụ thể là làm những gì, có đúng trọng tâm chưa?
• Nếu bạn ngày nào cũng làm thêm giờ mà không bao giờ thấy hết việc, thì nên tự hỏi:
  • Có phải mình đã dành quá nhiều thời gian cho việc IC không?
  • Khi hứa hẹn deadline với bên product hoặc khi lên kế hoạch công việc cho từng quý, có phải bạn tính cả phần làm IC của mình và luôn tính với trọng số rất cao hay không (90%, hay thậm chí 100% làm IC)?
• Đây là một ví dụ về việc phân chia thời gian mà mình từng áp dụng:
  • Đối với team nhỏ (từ 1-3 IC), manager vẫn nên dành nhiều thời gian làm IC hơn (vd: 60-70% IC, 30-40% manager).
  • Khi team bắt đầu lớn dần (4-8 IC), lui dần về phía sau và tập trung nhiều hơn tới khâu quản lý (20-50% IC, 50-80% manager).
• Các đầu việc về quản lý nên được lên kế hoạch cụ thể và nên xuất hiện trên calendar của bạn. Thay vì ngồi chờ vấn đề xảy đến rồi “tùy cơ ứng biến”.

Lỗi #6: Tư duy “chữa cháy”, thay vì quy trình hóa mọi thứ

Khi phải đối mặt với các vấn đề phát sinh hằng ngày trong team, manager rất dễ có thói quen “chữa cháy” tạm thời để gạt nó qua một bên và dành thời gian cho những việc khẩn cấp khác. Bởi vậy nên những vấn đề này cứ lặp đi lặp lại, gây thiệt hại lâu dài cho cả team. Ít người chịu ngồi lại đào sâu suy nghĩ xem vấn đề cốt lõi của nó là gì và liệu mình có cách nào giải quyết triệt để hay không.

Có lần lúc họp team, mình nghe một bạn IC nêu vấn đề là: mỗi khi bạn đó nhận được yêu cầu công việc (JIRA ticket) từ phía product, thường các thông tin ghi rất sơ sài, chỉ có vài dòng mô tả, không hình minh họa… Rồi bạn đó phải đi hỏi product manager, hỏi đi hỏi lại nhiều lần mới có đủ thông tin để bắt đầu code. Việc này không những làm chậm tiến độ dự án mà còn làm mất nhiều thời gian của bạn IC và product manager.

Mình có góp ý với product manager & designer rằng nên ghi thông tin đầy đủ hơn. Nhưng việc này vẫn tái diễn hết lần này đến lần khác. Bởi vậy, mình quyết định đầu tư nhiều thời gian để tìm hiểu sâu hơn. Hóa ra, product manager cũng muốn ghi nhiều thông tin lắm, chỉ là họ không biết bên phía kỹ sư cần thông tin gì.

Thế là mình nhóm họp các kỹ sư, product manager, designer để thống nhất những quy chuẩn thông tin khi viết JIRA ticket. Ví dụ: phải ghi yêu cầu này bắt nguồn từ đâu (context/why), mô tả kỳ vọng (gherkin user stories), có trường hợp ngách gì không (edge cases), có biến số nào cần tùy chỉnh không (frontend/backend configuration), có deadline gì cụ thể không và tại sao…

Ngoài ra, mình cũng đề xuất nên có buổi product grooming mỗi 2 tuần để team cùng xem xét các ticket sẽ làm cho sprint tiếp theo cùng với product manager. Tại đây, mọi người sẽ cùng thảo luận, bổ sung thông tin đầy đủ và thống nhất mục tiêu cho các ticket đó.

Kết quả là team vận hành trơn tru hơn, product manager biết phải cung cấp thông tin gì, kỹ sư hiểu lý do đằng sau yêu cầu và biết mình phải làm gì, dẫn tới mọi người phối hơn ăn ý hơn.

Rút kinh nghiệm

• Khi gặp vấn đề, nhận thức được những giải pháp mà bạn đưa ra là tạm thời hay mang tính lâu dài. Nếu là tạm thời thì tự hỏi xem:
  • Có cách nào để giải quyết triệt để vấn đề không?
  • Tại sao bây giờ không giải quyết luôn mà phải để sau này?
  • Team sẽ được lợi ích gì sau khi vấn đề được giải quyết?
• Tổ chức các buổi retro trong team để nhìn lại những vấn đề phát sinh trong sprint. Từ đó để mọi người cùng bàn bạc, đưa ra giải pháp tối ưu hơn.
• Đối với những sự cố nghiêm trọng gây thiệt hại doanh thu/danh tiếng công ty (vd: tính năng bị lỗi trên production làm cho một lượng lớn người dùng không sử dụng sản phẩm được), nên nghiêm túc kiểm điểm, phân tích nguyên nhân cốt lõi, chia sẻ bài học cho mọi người cả trong/ngoài team, và quan trọng là phải có kế hoạch cải thiện quy trình/hệ thống để tránh lặp lại lỗi tương tự.

Lỗi #7: Luôn là người quyết định mọi việc và hay micromanage

Lúc còn làm IC, mình đã quen với việc được toàn quyền quyết định trong dự án, từ việc đưa giải pháp, cấu trúc code, cách test, cho đến cách thảo luận và đi đến thống nhất với các team khác. Thói quen này vẫn đi theo mình khi trở thành manager.

Như khi mình giao việc cho IC, mình hay có xu hướng “micromanage”: đại khái là chỉ định luôn nên làm giải pháp nào, nên bàn thêm với ai, đôi khi còn tạo cả cuộc họp cho nhóm dự án. Rồi khi mọi người đã chốt giải pháp sau cùng, nếu nó khác với giải pháp mà mình đề xuất ban đầu thì mình hay gặng hỏi và tỏ vẻ không hài lòng.

Điều này làm cho bạn IC buồn vì không được tự do giải quyết vấn đề theo cách của bạn đó, cứ hay bị manager áp đặt, cảm thấy như ý kiến của bạn đó không được tôn trọng. Hơn nữa, nó cũng hạn chế sự phát triển tay nghề của IC.

Do đó, mình bắt đầu điều chỉnh cách làm việc, chuyển dần từ chế độ “một người quyết định tất cả” sang “không có mình, team vẫn chạy tốt“.

• Khi giao việc cho IC, mình chỉ nói yêu cầu và kết quả cần đạt được, chứ không bàn nhiều về giải pháp (trừ khi được hỏi).
• Đối với những quyết định lớn trong team, mình luôn nêu ra vấn đề trong các buổi họp team để mọi người đóng góp ý kiến, sau đó mới chốt phương án.
• Có một số khâu kỹ thuật mà mình vẫn phải tự tay làm (vd: những việc liên quan đến tài khoản business của công ty như app release, google services,…) thì nay mình hướng dẫn cho các bạn khác cùng làm. Tuy nhiên, vẫn phải đảm bảo tính bảo mật.

Nhờ vậy mà mọi người cảm thấy tự do, được sáng tạo, học hỏi nhiều hơn, có trách nhiệm hơn với các quyết định trong team, dẫn đến động lực cũng như năng suất làm việc được tăng cao.

Rút kinh nghiệm

• Tự đánh giá xem:
  • Bạn có hay micromanage không?
  • Giả sử có thang điểm từ 1 tới 10, trong đó 1 là “hoàn toàn không nhúng tay” và 10 là “can thiệp mọi quyết định”, thì bạn ở mức nào?
  • Mức độ đó có ổn không? Hay cần điều chỉnh lại?
• Ngoài ra, cũng tùy vào từng bạn IC mà manager có cách quản lý khác nhau. Ví dụ:
  • Junior IC ít kinh nghiệm nên họ cần nhiều sự hướng dẫn, trợ giúp hơn. Vì vậy manager cần theo sát 1 chút để đảm bảo dự án không trì trệ và bạn IC không bị nản lòng khi gặp vấn đề khó.
  • Senior IC đã từng trải qua nhiều dự án nên manager có thể yên tâm giao phó mà không cần theo quá sát, chỉ cần biết tiến độ hằng tuần và chỉ họp bàn khi có vấn đề quan trọng.
• Nhìn lại xem có việc gì trong team mà chỉ mỗi mình bạn làm được. Cân nhắc liệu có thể hướng dẫn những người khác cùng làm hay không? Bởi nếu chỉ mình bạn biết làm thì khi bạn nghỉ phép sẽ gây ảnh hưởng cho team, và cũng khiến bạn nghỉ phép không được yên tâm.

Lỗi #8: Không hỏi & tiếp nhận feedback của mọi người về mình

Manager là người đại diện của team, là người mà công ty có thể trông cậy để gánh vác trọng trách dẫn dắt team. Nhưng điều này đôi khi lại trở thành áp lực lớn với manager.

Để xứng đáng với trông đợi đó, manager thường phải gồng mình lên để tỏ ra là một người tự tin, hiểu biết và luôn kiểm soát được tình hình. Chính vì quá tự tin nên dễ dẫn đến suy nghĩ rằng:

• Cách làm của mình luôn đúng, ít chịu tiếp thu ý kiến/feedback của người khác.
• Ngầm định là mình đang làm tốt vai trò manager, ít dám hỏi sếp, đồng nghiệp, team xem họ có feedback gì cho mình không. Vì khi hỏi sợ bị người ta nghĩ là mình kém tự tin và không biết cách quản lý.

Thậm chí khi đã nghe được feedback, manager lại tỏ ra tự ái, thể hiện thái độ phản bác hoặc nghe cho qua rồi phớt lờ feedback, không tự nghiền ngẫm lại mà lên kế hoạch cải thiện bản thân.

Hậu quả là manager dễ dẫn dắt team đi sai đường, làm phật ý đồng nghiệp và nghiêm trọng nhất là không đạt được mục tiêu của công ty.

Rút kinh nghiệm

• Không phải ngẫu nhiên mà người ta tới feedback cho mình. Hãy mở lòng đón nhận, tự soi chiếu bản thân để rút ra bài học, như vậy mới mau tiến bộ.
• Chấp nhận mình có thể sai, thậm chí sai nhiều là đằng khác, đặc biệt là khi mới lần đầu làm manager.
• Tập thói quen chủ động hỏi feedback của người khác: ví dụ như khi 1on1 với sếp, 1on1 với từng IC, khi họp với các bạn ở phòng ban khác.
• Khi đã nhận được feedback, nên ghi chú tất cả lại, nhưng chỉ chọn ra 1-2 cái để tập trung cải thiện, tránh bị rối khi có quá nhiều feedback.

Lỗi #9: Không dành thời gian học thêm về kỹ năng quản lý, lãnh đạo

Thời gian đầu làm manager, mình cứ nghĩ rằng chắc cứ “thử sai” dần dần rồi mình cũng sẽ làm tốt thôi. Tuy nhiên, vấn đề của thử sai là “sai thường nhiều hơn đúng”, đặc biệt đối với người chưa có kinh nghiệm.

Một vấn đề nữa là công ty thường sẽ không cho bạn quá nhiều thời gian để thử sai. Mỗi lần sai thì phải khắc phục hậu quả. Nhiều lần sai quá sẽ dẫn đến việc ban điều hành cân nhắc thay manager.

Do đó, những lúc rãnh rỗi ngoài giờ làm, mình có tìm đọc nhiều sách về kỹ năng quản lý & lãnh đạo. Nhờ vậy mà mình hiểu hơn về công việc manager, phải vận hành team như nào và làm sao để trở thành manager giỏi, thay vì chỉ tà tà ở mức “cố gắng sinh tồn”.

Nhờ áp dụng những điều học được từ sách, mình nhận thấy công việc trở nên thuận lợi hơn, mình ít mắc sai lầm hơn, những quyết định của mình mang tính chiến lược và lâu dài hơn. Kết quả là đạt được nhiều đánh giá tốt từ mọi người trong team/công ty.

Rút kinh nghiệm

• Dành ra tầm 30-60 phút mỗi ngày để đọc sánh về kỹ năng quản lý & lãnh đạo. Nên xem đây là một phần của công việc chứ đừng chờ khi bạn có hứng rồi mới đọc.
• Chủ động hỏi sếp về những kinh nghiệm khi họ lần đầu làm manager. Sếp bạn là người từng trải nên khả năng cao sẽ cho bạn được lời khuyên phù hợp với hoàn cảnh team.
• Chủ động quan sát các manager khác trong công ty xem họ vận hành như nào, cách họ giao tiếp, ra quyết định. Học hỏi triết lý lãnh đạo từ họ.

Tổng kết

Lần đầu làm việc gì cũng đều sẽ gặp nhiều khó khăn. Làm manager thì lại càng khó nữa vì có nhiều trách nhiệm và áp lực hơn. Tuy nhiên, nếu bạn biết chủ động quan sát, nhìn ra được lỗi sai của mình mà cải sửa thì không có vấn đề gì không giải quyết được. Rồi bạn cũng sẽ làm được thôi.

Thực ra, manager còn rất dễ mắc nhiều lỗi khác nữa. Trong 2 bài viết này, mình chỉ nêu ra những lỗi quan trọng và thường gặp nhất. Nếu bạn thấy có lỗi gì khác đáng nêu lên thì hãy chia sẻ dưới phần bình luận nha.

Cám ơn các bạn đã theo dõi bài viết.