kiến thức Team leader - Team manager: Làm sao để build được một team hiệu quả.

hoctrokha

Member
Nhiều nhà quản lý có suy nghĩ: nếu tuyển dụng được những người thông minh, hăng hái, muốn thể hiện bản thân, thì dĩ nhiên những người đó khi gộp lại một team sẽ sáng tạo, chăm chỉ, qua đó tạo nên sự hiệu quả.
Nhưng liệu điều đó có đúng?
Mình đã từng ở trong những team có nhiều người giỏi, nhưng cuối cùng họ dành phần lớn thời gian để tranh luận về những vấn đề không có hồi kết. Và có những team khác nơi mọi người không phải thiên tài, nhưng lại làm việc cực kì hiệu quả.

Rõ ràng sự hiệu quả không chỉ đến từ những cá nhân đơn lẻ, sự thành công của một team không bằng tổng IQ của các thành viên.
Do đó, đơn vị nhỏ nhất để đo performance phải là team, không phải một cá nhân.

Vào năm 2012, Google triển khai một dự án nghiên cứu tên Aristotle. Mục tiêu của dự án là trả lời câu hỏi: điều gì tạo nên một team hiệu quả?
Nghiên cứu đưa ra định nghĩa về hiệu quả thông qua cả định tính (theo cảm tính của từng cá nhân) và định lượng (theo các con số trên thực tế).
Kết quả của nghiên cứu khá bất ngờ khi nó chứng minh một nghiên cứu trước đây 40 năm của Raymond Belbin (1981) là đúng.

Belbin nhận thấy: “The lack of coherence teamwork, nullified the gain of individual effort or brilliance”.
Có nghĩa: Team không gắn kết thì mỗi cá nhân có hăng hái và thông minh cũng như không.
Điểm thú vị ở đây là: những người thông minh và muốn thể hiện bản thân thường khó gắn kết. Có nghĩa, một team toàn thiên tài thì sẽ khó đem lại hiệu quả.
Ai cũng nghĩ họ quan trọng nhất và muốn trở thành người hùng của dự án, và thường nghĩ những người khác không quan trọng bằng.

Belbin đưa ra một mô hình có 9 role trong 1 team. Mỗi role sẽ có điểm mạnh, điểm yếu có thể chấp nhận được và những xu hướng hành vi của mỗi role đó. Mình lấy ví dụ 3 role:

Resource Investigator: Người tìm kiếm ý tưởng
  • điểm mạnh: Hướng ngoại, nhiệt tình. Khám phá các cơ hội và phát triển các mối quan hệ.
  • điểm yếu chấp nhận được: Có thể quá lạc quan và mất hứng thú khi sự nhiệt tình ban đầu đã qua.
  • hành vi: Họ có thể quên follow up những ý tưởng tiềm năng.

Co-ordinator: Người này giỏi việc nắm bắt mục tiêu của nhóm và chia việc cho mọi người.
  • điểm mạnh: Trưởng thành, tự tin, biết nhìn người, mục tiêu rõ ràng.
  • điểm yếu chấp nhận được: Thường thao túng và giảm tải công việc của họ
  • hành vi: giao việc không công bằng, giao cho người khác nhiều việc, để chính họ phải làm ít hơn.

Implementer: người này biến ý tưởng thành hiện thực
  • điểm mạnh: Thực tế, đáng tin cậy, hiệu quả
  • điểm yếu chấp nhận được: Có thể hơi thiếu linh hoạt và phản ứng chậm với những khả năng mới
  • hành vi: chậm từ bỏ kế hoạch của mình để ủng hộ những thay đổi tích cực

Tất nhiên tính cách của một người thường sẽ trải rộng ra nhiều role trong số 9 role này, nhưng bên cạnh đó, ai cũng có điểm mạnh và điểm yếu.
Ý tưởng ở đây là thay vì cố gắng khắc phục điểm yếu của mỗi người, ta nên xác định và tận dụng tối đa điểm mạnh của họ, những thành viên khác sẽ bù đắp vào những điểm yếu kia.
Nếu các member trong team hình thành đủ 9 role thì team sẽ có đủ các nhân cách giúp bù đắp vào những khuyết điểm của người khác, qua đó giúp team hiệu quả.

Gallup - một công ty tư vấn và phân tích của Mỹ đã chỉ ra rằng: Những nhân viên được sử dụng điểm mạnh của họ có khả năng nhập tâm vào công việc cao hơn 6 lần.

Trước đây mình có nói chuyện với một người anh về việc quản lý team, mình nói: Em cố gắng truyền cảm hứng cho team, giúp khắc phục điểm yếu của mỗi người.
Anh ý bảo: em dùng điểm mạnh của một người sẽ dễ và hiệu quả hơn rất nhiều việc cố gắng cải thiện điểm yếu của họ. Việc cải thiện điểm yếu chỉ có thể thực hiện nếu như người đó thực sự muốn cải thiện.
Mình nghĩ kết luận của anh ý quá đúng. Nếu mình tạo điều kiện cho điểm mạnh của họ được toả sáng, họ sẽ không cần ai truyền cảm hứng cả. Mình nên nhìn cả team là một cá thể để đánh giá thay vì nhìn mỗi cá nhân trong team, khắc phục điểm yếu của team chứ không khắc phục điểm yếu của từng cá nhân.
Việc đánh giá mỗi cá nhân giống như việc nhìn vào một đội bóng rồi hỏi tại sao ông tiền đạo lại không chặn được bóng khi đối phương tấn công vậy.

Qua mô hình 9 role của Belbin, người quản lý có thể thông qua nhiều phương thức để biết được tổ chức của họ cần những người với nhân cách như thế nào, qua đó tuyển dụng đúng người cũng như dùng người hợp lý.

Quay lại với dự án Aristotle của Google, cho dù nó phản chiếu lại nghiên cứu của Belbin ở nhiều khía cạnh, dự án của Google đưa ra một quan điểm thú vị:
“Who is on the team matter less than how team member interact, structure their work, and view their contributions”
Dịch: Cách các cá nhân tương tác, làm việc và hiểu được ý nghĩa của những đóng góp cho dự án quan trọng hơn họ là ai.

Có thể hiểu, cho dù ta tuyển đúng người, mỗi người bù đắp những yếu điểm của người kia nhưng như vậy thôi chưa đủ. Cách làm việc, tương tác giữa họ quan trọng hơn nhiều.
Leader sẽ là người đảm bảo sự tương tác này diễn ra thuận lợi.

Cách làm việc/tương tác được chia làm 5 phần:
  • 1, Psychological safety: Cho phép nhân viên mắc sai lầm
    • Không remote-control programing: Cho phép nhân viên tự do khám phá vấn đề và tự tìm ra giải pháp kể cả khi bạn đã có giải pháp.
    • Thực hành pair programming: Cho phép nhân viên phạm sai lầm khi giải quyết vấn đề và được những người có kinh nghiệm giúp đỡ ngay trong khi làm, không cần đợi review mới biết sai.
    • Cho mọi người hiểu chính lead cũng có thể sai: Điều này sẽ khuyến khích mọi người đặt câu hỏi và đưa ra những ý tưởng mới
  • 2, Dependability: công việc hoàn thành đúng hạn và chất lượng cao
    • Phản hồi về tình hình công việc của nhân viên sớm nhất có thể, giúp nhân viên hiểu được vấn đề
    • Lưu ý chỉ nói lên sự thực khách quan, không nói về cảm xúc của mình với nhân viên
    • Đưa ra mọi sự giúp đỡ cần thiết để giúp đỡ nhân viênn vượt qua khó khăn/trở ngại
  • 3, Structure and clarity: Đặt ra sự mong đợi rõ ràng và trách nhiệm đối với mỗi vị trí trong team
    • Mong đợi cần rõ ràng, cụ thể, thử thách và có thể đạt được
  • 4, Meaning: Mỗi người cần cảm nhận được sự quan trọng của công việc đối với bản thân họ
    • Cho phép cá nhân sử dụng điểm mạnh của họ trong công việc: điều này sẽ giúp họ nhập tâm vào công việc và cảm thấy nó có ý nghĩa với bản thân cá nhân đó hơn.
  • 5, Impact: Cá nhân cần hiểu được những điều họ làm là quan trọng trên một bức tranh lớn hơn của cả dự án.
Rồi, kiến thức của mình chỉ có vậy. Các bạn có thể lên google để tìm hiểu thêm về Belbin team role và Google Aristotle.
Mình sẽ không đi vào chi tiết làm sao để dùng được đóng kiến thức này, tại mỗi người, mỗi dự án sẽ có cách áp dụng khác nhau.
Nếu bạn là leader, bạn có thể dùng kiến thức này để giúp team thành công. Nếu bạn là nhân viên, kiến thức này sẽ giúp bạn hoàn thiện bản thân theo hướng có ích cho team hơn.
 
zFNuZTA.png
 
Team e làm theo kiểu hiểu ngầm, tự giác cao, nếu có quyết định từ ngoài vào sẽ gây xáo trộn, tâm lý chống lại. là hỏng bét.
 
Cảm ơn thớt, sẽ tìm hiểu thêm về cái này.
Cá nhân mình sau khoảng 3 năm lead 1 team 20 người cũng rút được một vài kinh nghiệm như thớt nói. Vừa từ bản thân, vừa quan sát.
  • Thành viên trong team cần được trao quyền nhiều hơn, được phép thử - sai
  • Lead không phải luôn đúng, cần phải biết lắng nghe, vì đôi khi cách của thành viên hay hơn của lead
  • Lead cần làm được những gì thành viên có thể làm, như mình có thể làm thay thế bất kì vị trí nào trong team nếu vị trí đó cần support
  • Chỉ giúp đỡ khi được thành viên yêu cầu, mình muốn thành viên trong team cần giúp thì phải lên tiếng, dù mình có thấy họ cần giúp, nhưng hãy lên tiếng
  • Tốt khen, cần cải thiện phải nhắc nhở ngay lập tức, không để đến cuộc họp chung rồi lôi ra bàn luận, đấu tố. Việc đấu tố mình cấm tuyệt đối, mình cần team rõ ràng, thẳng thắn với nhau trong mọi vấn đề.
Còn nữa nhưng tạm thời không nhớ hoặc mình không đủ trình để viết ra, chỉ có thể hiểu chút chút rồi dùng trực giác.
 
Thực tế kiếm được team mà build khó lắm. HR nó vứt cho thằng nào thì nhận thằng đó (Trừ trường hợp làm riêng hoặc startup thôi)
Kiến thức này không chỉ áp dụng cho build team mới bạn ơi. Cái này sẽ giúp bạn hiểu rõ team bạn, biết nó đã cân bằng chưa, qua đó phỏng vấn đúng người hoặc cân bằng lại giữa các team.
Bên cạnh đó bạn cũng sẽ hiểu tại sao trong team lại có xung đột, tại sao lại không deliver được, tại sao sản phẩm ra chất lượng kém ...
Nói chung bạn có thể áp dụng vào rất nhiều khía cạnh khác nhau.
 
Kiến thức này không chỉ áp dụng cho build team mới bạn ơi. Cái này sẽ giúp bạn hiểu rõ team bạn, biết nó đã cân bằng chưa, qua đó phỏng vấn đúng người hoặc cân bằng lại giữa các team.
Bên cạnh đó bạn cũng sẽ hiểu tại sao trong team lại có xung đột, tại sao lại không deliver được, tại sao sản phẩm ra chất lượng kém ...
Nói chung bạn có thể áp dụng vào rất nhiều khía cạnh khác nhau.
Hoặc có thể chọn ra đi, ko cay cú, ko nói xấu manager. Vui vẻ mà nghỉ
 
Viết rõ ra bạn ơi, chả hiểu bạn đang nói đến cái gì nữa.
Hiểu team, thấy cái dở của team mà mình ko làm gì đc thì té gấp, té trước khi cáu giận.

Tôi là team member thôi, tôi thấy vấn đề mà dạy lại manager thì mệt quá nên té.

Ko chỉ leader là có khả năng nghĩ như bài viết của fen đâu.
 
Điểm thú vị ở đây là: những người thông minh và muốn thể hiện bản thân thường khó gắn kết. Có nghĩa, một team toàn thiên tài thì sẽ khó đem lại hiệu quả.

Mình nghĩ cái này không đúng, việc team có gắn kết hay không phụ thuộc rất nhiều vào leader và culture chứ không phải vì member "thông minh", "muốn thể hiện bản thân". Ví dụ đơn giản là Google, không ai có thể nói Google kém hiệu quả cả, nhưng Google nổi tiếng với yêu cầu tuyển dụng cao, hay như cách google nói là Google chỉ tuyển "smart creative". Nhưng "smart creative" sẽ không hợp với leader có phong cách nghĩ mình phải "lead" (Authoritative) chứ không phải servant/coaching leaders. Nó tuỳ thuộc rất nhiều vào phong cách team leader có phù hợp với cách làm việc của team members hay không.
 
Mình nghĩ cái này không đúng, việc team có gắn kết hay không phụ thuộc rất nhiều vào leader và culture chứ không phải vì member "thông minh", "muốn thể hiện bản thân". Ví dụ đơn giản là Google, không ai có thể nói Google kém hiệu quả cả, nhưng Google nổi tiếng với yêu cầu tuyển dụng cao, hay như cách google nói là Google chỉ tuyển "smart creative". Nhưng "smart creative" sẽ không hợp với leader có phong cách nghĩ mình phải "lead" (Authoritative) chứ không phải servant/coaching leaders. Nó tuỳ thuộc rất nhiều vào phong cách team leader có phù hợp với cách làm việc của team members hay không.
Google nó chơi chiêu mất dạy đó bạn chứ hay ho mẹ gì, nó tuyển người giỏi nhất vào còn cho người ta làm không thì nó dell quan tâm. Lý do duy nhất là nó dell muốn nhả người giỏi cho các đối thủ cạnh tranh của nó, hoặc các startup có thể làm hại hệ sinh thái của nó
Nó cho bọn giỏi tự làm sản phẩm, cái nào ngon nó kéo về Mỹ cha con nó làm kiếm tiền, không thì nó giết cái sản phẩm đó.
 
Hiểu team, thấy cái dở của team mà mình ko làm gì đc thì té gấp, té trước khi cáu giận.

Tôi là team member thôi, tôi thấy vấn đề mà dạy lại manager thì mệt quá nên té.

Ko chỉ leader là có khả năng nghĩ như bài viết của fen đâu.
Nếu bạn xác định mình là member thì bạn té thoải mái thôi, ở lại làm gì cho mệt.
Nhưng nếu đã tự xưng mình có tố chất leader thì phải khắc phục, té mãi thì chỉ là con bạc, đánh cược hên xui giữa các lần chuyển team thôi.
Nếu bạn là leader mà ko khắc phục được, mình nghĩ không phải là hiếm. Chính mình đã gặp những lúc như vậy, nhưng khi nhìn lại thì lý do thường bởi mình thiếu 1 soft skill nào đó. Nếu bây giờ mình quay lại thì có lẽ mọi thứ đã khác.
Mình nhìn khó khăn như 1 cơ hội, ko phải là thách thức.
 
Mình có case này: team mình có 1 tên khá già (tầm 40+ rồi, bên sing). Làm thì đã ít, contributions cũng ko có, làm ở team nào cũng than rồi complains thiếu docs, ko thì cũng thiếu này hay kia,… rồi tự tạo conflict với tùm lum người. Không hề muốn take ownership cái gì cả, kể cả feature nó làm cũng đi hỏi ng khác cách debug (???), code thì ko thèm đọc, đi đâu cũng hỏi mấy câu rất junior, cái gì cũng nghĩ khó khăn r làm mọi thứ cực complex (cho tới code)

Ngoài ra nó còn hay khoe các ideas trên trời, ideas mà nó ko làm dc, chỉ muốn chém gió r đưa ng khác làm (???)

Mà dc cái nó có cái tật là nói rất nhiều, managers thì cứ nghĩ nó xịn chứ ae tech thì ngán tận cổ. Bad feedback thì đầy mà vẫn còn muốn promote nó.

Case này bác có lời khuyên gì không ạ?
 
Mình có case này: team mình có 1 tên khá già (tầm 40+ rồi, bên sing). Làm thì đã ít, contributions cũng ko có, làm ở team nào cũng than rồi complains thiếu docs, ko thì cũng thiếu này hay kia,… rồi tự tạo conflict với tùm lum người. Không hề muốn take ownership cái gì cả, kể cả feature nó làm cũng đi hỏi ng khác cách debug (???), code thì ko thèm đọc, đi đâu cũng hỏi mấy câu rất junior, cái gì cũng nghĩ khó khăn r làm mọi thứ cực complex (cho tới code)

Ngoài ra nó còn hay khoe các ideas trên trời, ideas mà nó ko làm dc, chỉ muốn chém gió r đưa ng khác làm (???)

Mà dc cái nó có cái tật là nói rất nhiều, managers thì cứ nghĩ nó xịn chứ ae tech thì ngán tận cổ. Bad feedback thì đầy mà vẫn còn muốn promote nó.

Case này bác có lời khuyên gì không ạ?
Thì nó có tài thế còn gì, cho nó làm BA tự viết doc, giao tiếp với khách hàng, làm việc với designer ...
Đây là kiểu người thinking-oriented, ông này ko nên làm lead, chỉ nên làm các việc ở những giai đoạn khơi mào ý tưởng.
Về phần code thì cũng nên cho code, nhưng nên có 1 người pair với ông ý, giúp ông ý trả lời các câu hỏi ngay trong lúc code, đỡ tốn thời gian chat qua lại.
 
Mấy bác cho em hỏi, nếu member của mình kém, dù k phải là fresher nhưng task nào cũng cần hỏi soluttion, nếu k đi hỏi thì ngâm task đến 2-3 ngày nên xử lý ra sao ạ?
 
Mấy bác cho em hỏi, nếu member của mình kém, dù k phải là fresher nhưng task nào cũng cần hỏi soluttion, nếu k đi hỏi thì ngâm task đến 2-3 ngày nên xử lý ra sao ạ?
Feedback với member, nói rõ nếu ko giải quyết được thì phải raise lên trong vòng 1 buổi.
Điều quan trọng là ông ý có ý thức học hỏi, cải thiện sau mỗi lần được member khác giúp đỡ là đc.
Nếu cứ tiếp tục vậy mãi thì nên xem lại tại sao, đôi khi lỗi do bạn ý không nắm được meaning và impact, bạn cần nói chuyện lại với member về meaning và impact của dự án.
Nếu thực sự ko có meaning thì có lẽ k hợp career path rồi, nên tìm hướng mới cho bạn ý.
Mình nghĩ khi member hiểu đc meaning và có tôn trọng impact thì việc bạn ý tốt lên sẽ là chuyện hiển nhiên thôi, ko phải lo.
 
Thì nó có tài thế còn gì, cho nó làm BA tự viết doc, giao tiếp với khách hàng, làm việc với designer ...
Đây là kiểu người thinking-oriented, ông này ko nên làm lead, chỉ nên làm các việc ở những giai đoạn khơi mào ý tưởng.
Về phần code thì cũng nên cho code, nhưng nên có 1 người pair với ông ý, giúp ông ý trả lời các câu hỏi ngay trong lúc code, đỡ tốn thời gian chat qua lại.
noted, đúng là mình đã từng nghĩ nên đề xuất cho nó làm ở bên product hơn là bên tech. Để nó tránh xa code thì ae đỡ khổ hơn.

Sắp tới mình đề xuất thử. Cám ơn bác
 
Nhiều nhà quản lý có suy nghĩ: nếu tuyển dụng được những người thông minh, hăng hái, muốn thể hiện bản thân, thì dĩ nhiên những người đó khi gộp lại một team sẽ sáng tạo, chăm chỉ, qua đó tạo nên sự hiệu quả.
Nhưng liệu điều đó có đúng?
Mình đã từng ở trong những team có nhiều người giỏi, nhưng cuối cùng họ dành phần lớn thời gian để tranh luận về những vấn đề không có hồi kết. Và có những team khác nơi mọi người không phải thiên tài, nhưng lại làm việc cực kì hiệu quả.

Rõ ràng sự hiệu quả không chỉ đến từ những cá nhân đơn lẻ, sự thành công của một team không bằng tổng IQ của các thành viên.
Do đó, đơn vị nhỏ nhất để đo performance phải là team, không phải một cá nhân.

Vào năm 2012, Google triển khai một dự án nghiên cứu tên Aristotle. Mục tiêu của dự án là trả lời câu hỏi: điều gì tạo nên một team hiệu quả?
Nghiên cứu đưa ra định nghĩa về hiệu quả thông qua cả định tính (theo cảm tính của từng cá nhân) và định lượng (theo các con số trên thực tế).
Kết quả của nghiên cứu khá bất ngờ khi nó chứng minh một nghiên cứu trước đây 40 năm của Raymond Belbin (1981) là đúng.

Belbin nhận thấy: “The lack of coherence teamwork, nullified the gain of individual effort or brilliance”.
Có nghĩa: Team không gắn kết thì mỗi cá nhân có hăng hái và thông minh cũng như không.
Điểm thú vị ở đây là: những người thông minh và muốn thể hiện bản thân thường khó gắn kết. Có nghĩa, một team toàn thiên tài thì sẽ khó đem lại hiệu quả.
Ai cũng nghĩ họ quan trọng nhất và muốn trở thành người hùng của dự án, và thường nghĩ những người khác không quan trọng bằng.

Belbin đưa ra một mô hình có 9 role trong 1 team. Mỗi role sẽ có điểm mạnh, điểm yếu có thể chấp nhận được và những xu hướng hành vi của mỗi role đó. Mình lấy ví dụ 3 role:

Resource Investigator: Người tìm kiếm ý tưởng
  • điểm mạnh: Hướng ngoại, nhiệt tình. Khám phá các cơ hội và phát triển các mối quan hệ.
  • điểm yếu chấp nhận được: Có thể quá lạc quan và mất hứng thú khi sự nhiệt tình ban đầu đã qua.
  • hành vi: Họ có thể quên follow up những ý tưởng tiềm năng.

Co-ordinator: Người này giỏi việc nắm bắt mục tiêu của nhóm và chia việc cho mọi người.
  • điểm mạnh: Trưởng thành, tự tin, biết nhìn người, mục tiêu rõ ràng.
  • điểm yếu chấp nhận được: Thường thao túng và giảm tải công việc của họ
  • hành vi: giao việc không công bằng, giao cho người khác nhiều việc, để chính họ phải làm ít hơn.

Implementer: người này biến ý tưởng thành hiện thực
  • điểm mạnh: Thực tế, đáng tin cậy, hiệu quả
  • điểm yếu chấp nhận được: Có thể hơi thiếu linh hoạt và phản ứng chậm với những khả năng mới
  • hành vi: chậm từ bỏ kế hoạch của mình để ủng hộ những thay đổi tích cực

Tất nhiên tính cách của một người thường sẽ trải rộng ra nhiều role trong số 9 role này, nhưng bên cạnh đó, ai cũng có điểm mạnh và điểm yếu.
Ý tưởng ở đây là thay vì cố gắng khắc phục điểm yếu của mỗi người, ta nên xác định và tận dụng tối đa điểm mạnh của họ, những thành viên khác sẽ bù đắp vào những điểm yếu kia.
Nếu các member trong team hình thành đủ 9 role thì team sẽ có đủ các nhân cách giúp bù đắp vào những khuyết điểm của người khác, qua đó giúp team hiệu quả.

Gallup - một công ty tư vấn và phân tích của Mỹ đã chỉ ra rằng: Những nhân viên được sử dụng điểm mạnh của họ có khả năng nhập tâm vào công việc cao hơn 6 lần.

Trước đây mình có nói chuyện với một người anh về việc quản lý team, mình nói: Em cố gắng truyền cảm hứng cho team, giúp khắc phục điểm yếu của mỗi người.
Anh ý bảo: em dùng điểm mạnh của một người sẽ dễ và hiệu quả hơn rất nhiều việc cố gắng cải thiện điểm yếu của họ. Việc cải thiện điểm yếu chỉ có thể thực hiện nếu như người đó thực sự muốn cải thiện.
Mình nghĩ kết luận của anh ý quá đúng. Nếu mình tạo điều kiện cho điểm mạnh của họ được toả sáng, họ sẽ không cần ai truyền cảm hứng cả. Mình nên nhìn cả team là một cá thể để đánh giá thay vì nhìn mỗi cá nhân trong team, khắc phục điểm yếu của team chứ không khắc phục điểm yếu của từng cá nhân.
Việc đánh giá mỗi cá nhân giống như việc nhìn vào một đội bóng rồi hỏi tại sao ông tiền đạo lại không chặn được bóng khi đối phương tấn công vậy.

Qua mô hình 9 role của Belbin, người quản lý có thể thông qua nhiều phương thức để biết được tổ chức của họ cần những người với nhân cách như thế nào, qua đó tuyển dụng đúng người cũng như dùng người hợp lý.

Quay lại với dự án Aristotle của Google, cho dù nó phản chiếu lại nghiên cứu của Belbin ở nhiều khía cạnh, dự án của Google đưa ra một quan điểm thú vị:
“Who is on the team matter less than how team member interact, structure their work, and view their contributions”
Dịch: Cách các cá nhân tương tác, làm việc và hiểu được ý nghĩa của những đóng góp cho dự án quan trọng hơn họ là ai.

Có thể hiểu, cho dù ta tuyển đúng người, mỗi người bù đắp những yếu điểm của người kia nhưng như vậy thôi chưa đủ. Cách làm việc, tương tác giữa họ quan trọng hơn nhiều.
Leader sẽ là người đảm bảo sự tương tác này diễn ra thuận lợi.

Cách làm việc/tương tác được chia làm 5 phần:
  • 1, Psychological safety: Cho phép nhân viên mắc sai lầm
    • Không remote-control programing: Cho phép nhân viên tự do khám phá vấn đề và tự tìm ra giải pháp kể cả khi bạn đã có giải pháp.
    • Thực hành pair programming: Cho phép nhân viên phạm sai lầm khi giải quyết vấn đề và được những người có kinh nghiệm giúp đỡ ngay trong khi làm, không cần đợi review mới biết sai.
    • Cho mọi người hiểu chính lead cũng có thể sai: Điều này sẽ khuyến khích mọi người đặt câu hỏi và đưa ra những ý tưởng mới
  • 2, Dependability: công việc hoàn thành đúng hạn và chất lượng cao
    • Phản hồi về tình hình công việc của nhân viên sớm nhất có thể, giúp nhân viên hiểu được vấn đề
    • Lưu ý chỉ nói lên sự thực khách quan, không nói về cảm xúc của mình với nhân viên
    • Đưa ra mọi sự giúp đỡ cần thiết để giúp đỡ nhân viênn vượt qua khó khăn/trở ngại
  • 3, Structure and clarity: Đặt ra sự mong đợi rõ ràng và trách nhiệm đối với mỗi vị trí trong team
    • Mong đợi cần rõ ràng, cụ thể, thử thách và có thể đạt được
  • 4, Meaning: Mỗi người cần cảm nhận được sự quan trọng của công việc đối với bản thân họ
    • Cho phép cá nhân sử dụng điểm mạnh của họ trong công việc: điều này sẽ giúp họ nhập tâm vào công việc và cảm thấy nó có ý nghĩa với bản thân cá nhân đó hơn.
  • 5, Impact: Cá nhân cần hiểu được những điều họ làm là quan trọng trên một bức tranh lớn hơn của cả dự án.
Rồi, kiến thức của mình chỉ có vậy. Các bạn có thể lên google để tìm hiểu thêm về Belbin team role và Google Aristotle.
Mình sẽ không đi vào chi tiết làm sao để dùng được đóng kiến thức này, tại mỗi người, mỗi dự án sẽ có cách áp dụng khác nhau.
Nếu bạn là leader, bạn có thể dùng kiến thức này để giúp team thành công. Nếu bạn là nhân viên, kiến thức này sẽ giúp bạn hoàn thiện bản thân theo hướng có ích cho team hơn.
Mình từng 1 lần fail trong vai trò team lead, và từ đó chưa nhận lại role này bao giờ. Cơ bản cũng nhận ra cái sai của bản thân. Nhưng ở cty cũ cái role đó thật sự là ôm rơm nặng bụng và phải đi đấu đá vs team khác nên mình từ sau vụ đó cũng tập trung cho kỹ thuật hơn là quản lý.
Bài viết rất hay mình sẽ đọc để 1 ngày nào đó lại phải vào role leader thì chiến đúng chức năng
4ri4S5u.png
 
Cái đầu tiên nên xác định team sẽ đi với nhau bao lâu.
Có project ngắn hạn co khi 2 tuần - vài tháng.
Có project dài hạn 1 năm - vài năm.
Mỗi loại project sẽ có chiến lược khác nhau để build team.

Các project ngắn hạn (kiểu những người thoáng chốc đi ngang đời nhau thôi) thì thường sẽ định hướng theo kiểu ae hay gọi là "chộp giựt" tức là delivery là được xong rồi ai về nhà nấy. Những team này thiên hướng tận dụng "sức chịu đựng" của mỗi cá nhân. Các mâu thuẫn thường sẽ được giải quyết theo kiểu "cho qua tính sau" (thực tế là ko cần phải tính luôn vì sau đó end rồi). Thế mạnh nổi trội của mỗi người sẽ được tận dụng để nhằm mục đích đem lại kết quả tốt nhất trong thời gian nhanh nhất. Tính ownership sẽ cực cao ở vài member và thường team se co 1 vài MVP đê gánh team.

Các project dài hạn sẽ đòi hỏi tính ổn định cao hơn. Do đó môi trường của team này đòi hỏi sự minh bạch rõ ràng, văn hóa đóng góp, thẳng thắn và chấp nhận lẫn nhau. Các mâu thuẫn, gút mắt trong lòng mỗi thành viên sẽ được giải quyết triệt để. Thế mạnh và mong muốn của mỗi người sẽ được balance và có lô trình phù hợp (ví du a giỏi cái này nhưng a lại thích làm cái kia) để chuyển dịch. Ngoài ra, các project này đòi hỏi 1 sự chấp nhận của việc đào thải tức là thành viên ko hợp với văn hóa đại đa số số đông sẽ được cách ly và thải loại khỏi team. Member 1 là chấp nhận thay đổi, 2 là out. Cac project dài hạn cũng sẽ đòi hỏi tính ownership đồng đều hơn của mọi member (tùy vào team size - Team size lớn thì sẽ là ownership của phần cviec của sub-team mình).
Nói chung chủ đề này dài lắm, mỗi người co 1 trải nghiệm nữa.
Và ta thường nghe, đời ko như người ta thường mong. a nào mà làm Lead, PM lần đầu, học PMP xong vô làm thực tế sẽ vỡ mộng khá nhiều. Nhất là khi a làm các dự án outsource vi du dự án embedded mà 80% resource là dân làm web sang or ngược lại.
 
Back
Top