Đừng xin “có”, hãy yêu cầu “không” (2022)
(mooreds.com)- Khi thúc đẩy công việc trong phạm vi trách nhiệm của mình ở một công ty nhỏ, việc đưa ra cơ hội và thời hạn để từ chối thay vì chờ được cho phép có thể giúp tăng tốc độ thực thi
- Những yêu cầu phê duyệt như “Tôi có thể cài action X không?” có thể đẩy sang cho cấp trên việc xem xét vấn đề, đánh giá cách giải quyết và điều chỉnh ưu tiên, khiến câu trả lời bị chậm
- Nếu nói “Tôi sẽ cài action X vào thứ Hai. Nếu anh/chị nghĩ khác, hãy cho tôi biết”, bạn vừa thể hiện ý định hành động, vừa để lại khoảng trống cho cấp trên can thiệp
- Cách này phù hợp khi việc đó nằm trong phạm vi vai trò của bạn, bạn hoan nghênh phản hồi nhưng đủ tự tin về hướng đi để vẫn tiến hành nếu không có câu trả lời
- Khi đưa kèm một thời hạn gần, những người cần lên tiếng có khả năng phản hồi nhanh hơn; đồng thời bạn vẫn có thể tiếp tục thông báo cho các bên liên quan mà không làm chậm việc thực thi
Không chờ được cho phép, mà trao cơ hội từ chối
- Thiên hướng hành động tiến lên dù chỉ một bước rất nhỏ cũng giúp phá vỡ trạng thái trì trệ
- Thói quen cốt lõi là không xin “có”, mà yêu cầu “không”
- Cơ sở kinh nghiệm là các công ty nhỏ có dưới 200 nhân viên
- Không chắc cách này có hiệu quả tương tự ở các công ty lớn, tổ chức phi lợi nhuận hay cơ quan chính phủ hay không
- Khi muốn làm một việc mà bạn cảm thấy nằm trong phạm vi công việc của mình, nhưng cần sự yên tâm hoặc muốn báo cho cấp trên biết, thông thường bạn sẽ xin phép trước
- Thay vào đó, hãy trao cho cấp trên cơ hội từ chối, đồng thời đưa kèm một thời hạn rõ ràng để họ có thể đưa ra phán đoán đó
Khác biệt qua ví dụ GitHub Action
- Ví dụ là tình huống cài một GitHub Action mới vào repository vì bạn cho rằng nó sẽ giúp cải thiện chất lượng phần mềm
- Đây không phải ý thích nhất thời, mà là trạng thái đã qua tìm hiểu và thử nghiệm local
- Bạn cũng có thể đã hỏi đồng nghiệp cũ về kinh nghiệm sử dụng GitHub Action đó
- Cách hỏi “Tôi có thể cài action X không? Nó giúp giải quyết vấn đề XYZ mà chúng ta đang gặp” buộc cấp trên phải làm thêm việc trước khi nói “có”
- Phải xem xét lại vấn đề XYZ
- Phải đánh giá X sẽ giải quyết vấn đề như thế nào
- Có thể phải cân nhắc ưu tiên so với các công việc khác, hoặc muốn người phụ trách chia sẻ trước những điều họ biết
- Với một cấp trên bận rộn, việc này có thể bị đẩy lùi và bạn có thể phải nhắc lại nhiều lần
- Phương án thay thế là nói: “Tôi sẽ cài action X để giải quyết vấn đề XYZ. Nếu anh/chị nghĩ khác, hãy cho tôi biết; nếu không, tôi sẽ xử lý vào thứ Hai”
- Đây là tín hiệu rằng người phụ trách sẽ trực tiếp xử lý vấn đề
- Cấp trên vẫn có thể can thiệp nếu muốn, nhưng giảm bớt gánh nặng phải trả lời
- Ngay cả khi cấp trên quên hoặc có việc khác phát sinh, tiến độ cũng không bị dừng lại
- Cách này có thể áp dụng không chỉ cho cá nhân mà cả nhóm gồm nhiều người
Áp lực phản hồi do thời hạn tạo ra
- Thời hạn là yếu tố then chốt của cách tiếp cận này
- Nếu đang là ngày 15/1, “Tôi sẽ làm task X” có thể kém hiệu quả hơn “Tôi sẽ làm task X vào ngày 17/1” trong việc thúc đẩy phản hồi nhanh
- Một thời hạn trong tương lai gần có khả năng kéo theo phản hồi tức thì hơn so với thời hạn xa như “Tôi sẽ làm task X vào ngày 15/2”
- Cách này phù hợp nhất khi bạn vẫn mở cơ hội phản hồi, nhưng đủ tự tin về hướng đi để thực thi ngay cả khi không có phản hồi
1 bình luận
Các ý kiến trên Hacker News
Đây là năng lực cốt lõi ở các công ty lớn, nơi ai cũng bận và công việc rất dễ bị chìm đi
Sau khi giải thích vấn đề trong email, hãy viết “Nếu không nhận được phản hồi trong vòng [N] ngày, tôi sẽ làm XYZ vào [ngày thứ N]”. Thay vì gửi yêu cầu phê duyệt rồi bất lực chờ đợi hoặc thúc giục, đây là cách để lại thông báo rằng nếu không ai lên tiếng thì XYZ sẽ được tiến hành
Thỉnh thoảng vài tuần sau sẽ có người nổi giận hỏi sao làm mà không nói gì, nhưng mỗi lần như vậy bạn có thể cho họ xem bản ghi mà họ đã bỏ lỡ
Chỉ cần nói kiểu “Vì những lý do này, tôi dự định làm XYZ và sẽ tiến hành vào [ngày]. Nếu có phản đối hoặc lo ngại, vui lòng cho tôi biết” là đủ
Cách này buộc bạn phải đưa ra cơ sở vững chắc từ trước, đồng thời cũng giúp nhận phản hồi để tránh các ràng buộc hoặc sai sót mà bản thân chưa biết
Việc bắt chước các nguyên tắc lãnh đạo của Amazon như thể đó là lời giải cho mọi vấn đề, theo kiểu sùng bái hàng hóa, cũng khá kỳ lạ. “Thiên hướng hành động” hiệu quả ở Amazon là vì những người tự ý làm rồi thất bại sẽ trở thành vật tế thần và bị sa thải, và những người như vậy không viết blog ca ngợi đức tính thiên hướng hành động
Có phải kiểu “Tôi dự định chống phân mảnh thingamajig vào ngày 1/3. Tôi liên hệ trước với những ai việc này có thể gây vấn đề. Nếu có lo ngại, hãy cho tôi biết. Nếu không có phản hồi trước ngày 1/3, thingamajig sẽ được chống phân mảnh” không
Câu “nếu không có phản hồi trong 5 ngày thì tôi sẽ làm X” không phải là lá chắn nào cả nếu bạn đã làm việc có thể bị kỷ luật
Nơi nó có tác dụng cùng lắm là khi vi phạm một quyết định thiết kế nội bộ không liên quan đến kinh doanh
Nói rằng mình “luôn làm thế” rồi viết một câu thần chú như mẫu có sẵn, tôi nghi không biết đó có thật là trải nghiệm của người đó không, hay chỉ là sự phóng chiếu về cách họ muốn làm việc như trong bài
Nghĩ đến cảnh đem bản ghi ra cho đồng nghiệp đang tức giận xem rồi chiến thắng là máy dò nhảm nhí của tôi leo lên mức đỏ
Tôi gọi cách này là “đừng hỏi, hãy thông báo”, và nó hữu ích cả trong lẫn ngoài công ty
Đây là kỹ năng giao tiếp cơ bản, giúp kết quả ngắn gọn và dứt khoát
Tôi thường có những cuộc trao đổi kiểu này với vợ. Cô ấy hay gửi câu hỏi mở vào nhóm chat 8 người như “Mấy giờ mọi người đến?”. Vì chúng tôi biết mình sẽ đến sớm hơn một tiếng do lịch gửi con, tôi bảo cô ấy cứ thông báo “Chúng tôi sẽ đến lúc này, ai muốn uống trước thì chúng tôi sẽ ở quầy bar”
Không cần yêu cầu ai trả lời, mọi người đều đến sớm và mọi chuyện suôn sẻ với mức giao tiếp tối thiểu
Nó cũng hơi liên quan đến câu “xin tha thứ thay vì xin phép”, nhưng những nơi nhiều người cùng cộng tác như kho GitHub không phải chỗ phù hợp để ném ra những thay đổi lớn ảnh hưởng đến người khác
Thay vì ở trong trạng thái chỉ có thể tận hưởng khi người khác phối hợp giúp, tôi bắt đầu làm điều mình muốn và cho người khác biết rằng họ có thể tham gia
Khi đồng nghiệp hỏi làm sao để đề xuất của họ được phê duyệt, tôi cũng khuyên tương tự: “hãy làm sao để đối phương dễ nói có nhất có thể”
Đừng ném cho ai đó 14 đoạn văn rồi kỳ vọng họ lập tức bắt kịp tới mức bạn đã đào sâu vấn đề suốt nhiều giờ
Nếu bạn tự tin với cách tiếp cận, hãy giải thích ngắn gọn vấn đề và giải pháp vì sao đúng, rồi gắn link tài liệu cho người muốn xem sâu hơn. Tốt nhất là đã có sự đồng thuận trước từ thành viên nhóm hoặc người phụ trách sản phẩm
Ví dụ: “Chúng tôi định giải quyết X bằng Y. Cả nhóm đều đồng ý. Tài liệu đề xuất chi tiết ở [link]. Nếu không có phản hồi nào cần xử lý thêm, chúng tôi sẽ bắt đầu vào thứ Ba”
Quản lý không có thời gian xem từng chi tiết, và nếu bạn đã sắp xếp công việc gọn gàng, bao gồm cả sự ủng hộ của nhóm rộng hơn, họ chỉ cần phê duyệt nên sẽ rất cảm kích
Nếu xác suất thành công là 10% nhưng vẫn có lý do để thử, tôi sẽ nói như vậy, chứ không bọc nó thành một bài trình bày nhảm nhí kiểu chắc chắn sẽ thành công. Nếu xác suất thành công là 80%, tôi cũng không giấu 20% còn lại; nếu tôi nói 98% thì nghĩa là nó thật sự gần mức đó
Công việc của quản lý là xử lý các thống kê kiểu này và phòng hộ rủi ro. Quỹ phòng hộ làm việc đó bằng tiền, còn quản lý làm bằng con người và tài nguyên
Đáng tiếc là kiểu quản lý doanh nghiệp điển hình lại thích người nói chắc 100% sẽ thành công nhưng thực tế thất bại 50% hơn
Tôi thích một cách diễn đạt tương tự là phát tỏa ý định (radiating intent)
Đó là cách thông báo rộng rãi bạn định làm gì và khi nào, cho các bên liên quan không gian phản đối rõ ràng, nhưng không đi đuổi theo từng người để xin đồng thuận, căn chỉnh hay phê duyệt
Nó hiệu quả trong một số tình huống, và nhìn chung trước hết cần có sự tin cậy cơ bản
https://medium.com/@ElizAyer/dont-ask-forgiveness-radiate-in...
Sắc thái mà Eliz Ayer bổ sung cũng hay: “Nói cho công bằng, phát tỏa ý định cũng có thể khiến bạn làm được ít việc hơn, vì nó tạo lối cho những người cản trở hoặc thích xen vào chen ngang. Ngoài ra, lời khuyên này phụ thuộc rất nhiều vào tình huống và tổ chức, nên không phải lúc nào cũng phù hợp”
Cách giao tiếp này có vẻ sẽ khiến người đối diện lập tức bị xem là nhân vật nguy hiểm
Bề ngoài thì có vẻ như giúp tiết kiệm thời gian cho họ, nhưng thực ra đó là cách báo cho quản lý rằng nếu không luôn theo sát nhân viên đó đang làm gì, họ có thể làm những việc không mong muốn
Bài viết xử lý chuyện này như một thông báo, nhưng dù có thiện chí và sự thấu hiểu đến đâu, thông báo cũng dễ bị chìm trong nhiễu của tín hiệu, và không có phản hồi không có nghĩa là đồng ý. Nó cũng có thể có nghĩa là người đó chưa nhận được tin nhắn
Nếu nhân viên và quản lý đã thảo luận vấn đề rồi và giờ đang ở giai đoạn triển khai giải pháp thì có thể ổn, nhưng khi lần đầu nêu ra một vấn đề mà đối phương còn chưa hề cân nhắc thì đây là cách tệ nhất. Nó ích kỷ và hoàn toàn trái ngược với tinh thần teamwork
Cũng có cảm giác như thấy một kỹ sư 10x Rockstar huyền thoại làm vậy rồi bắt chước. Kỹ sư đó luôn làm tốt công việc, biết cần làm gì, có sự thấu hiểu và tôn trọng lẫn nhau với cấp quản lý, nên có chỗ để giao quyền tự quản. Có vẻ ai đó nhìn thấy điều đó rồi nghĩ nó cũng áp dụng cho mình, mà không hiểu vì sao người kia được đối xử như vậy, hay bản thân phải làm gì để có được điều đó
Nếu làm như vậy ba lần liên tiếp mà nhận được câu trả lời “hãy dừng lại”, thì có gì đó không ổn. Nếu ba lần liên tiếp được khen, thì cứ tiếp tục
Người thực sự nguy hiểm là người dù đã nghe nói không được, vẫn tìm cách làm hầu hết mọi thứ, rồi sau đó mới đi tìm lời đồng ý. Việc tiếp theo cũng làm theo cùng kiểu và không phản ứng với feedback
Vì vậy trọng tâm không nằm ở bản thân phương thức, mà ở quan hệ công việc. Trong môi trường có mức độ tin cậy cao và ai cũng bận, đây là cách đáng thử
Nếu đó là người tôi từng làm việc cùng, có sự tin cậy, và tôi biết họ làm vậy vì tôn trọng thời gian của tôi, thì câu chuyện hoàn toàn khác
Khoảnh khắc lần đầu tiên làm hỏng thứ gì đó, nó sẽ trở thành công thức cho thảm họa
Việc nhận được câu trả lời có hoặc không nghĩa là sếp đã biết. Khi xảy ra chuyện và có câu hỏi “ai đã phê duyệt?”, câu trả lời trung thực là không ai phê duyệt cả
Nếu trong tổ chức không có ai có thể hành động theo cách này, đó là dấu hiệu cho thấy đội ngũ lãnh đạo đang thất bại trong việc ủy quyền
Ví dụ như trường hợp X ở team Y phản đối một việc nào đó
Nếu sếp 1) nói rằng cần làm điều gì đó và 2) không phê duyệt bất kỳ kế hoạch nào, thì cứ không làm là được. Trong trường hợp đó, trách nhiệm chỉ đạo để công việc được thực hiện thuộc về sếp
Nói “tôi sẽ làm việc này” thì ổn, nhưng không được đưa lên production nếu không có các quy trình như review và kiểm thử tự động
Tất nhiên như vậy sẽ tạo ra nút thắt. Nếu bạn mở merge request mà không ai review kịp thời, thì sẽ chẳng có gì xảy ra. Khi đó cần có thỏa thuận ở cấp team lead rằng mọi người sẽ kiểm tra và review trong một khoảng thời gian nhất định
Cách tiếp cận này có vẻ chỉ hiệu quả với sếp ở công ty Mỹ hoặc quen với văn hóa kinh doanh kiểu Mỹ
Nếu sếp không thích, nó có thể phản tác dụng nghiêm trọng. Khi đánh giá nhân sự, sếp rất dễ gắn nhãn là bất phục tùng, và bạn đã tự dâng bằng chứng cần thiết lên khay cho họ
Đôi khi ngay cả ở Mỹ, xin phép thật sự là lựa chọn tốt nhất, nhất là khi liên quan đến tài nguyên
Ví dụ trong các nền văn hóa Scandinavia, quản lý thường khá buông tay, và nhân viên thường được kỳ vọng tự đưa ra nhiều quyết định một cách độc lập hoặc sau khi trao đổi với nhau
Tuy vậy, tất cả các sếp đó đều thấm rất sâu văn hóa Mỹ
Ngay cả việc ra quyết định quân sự hiệu quả cũng phụ thuộc rất nhiều vào việc các đơn vị tại hiện trường có thể thích nghi mà không phải lần nào cũng gọi về sở chỉ huy
Tôi gọi đây là tạo ra giá trị mặc định hợp lý
Thay vì yêu cầu mọi người quyết định về từng chi tiết, đây là cách đặt ra một nhóm mặc định hợp lý cho thấy bạn hiểu tình huống, rồi thông báo rằng bạn sẽ tiến hành theo đó
Làm như vậy sẽ xây dựng niềm tin, và khi thật sự cần chú ý, mọi người sẽ xem kỹ hơn. Vì họ biết bình thường bạn không lãng phí thời gian của họ
Cách giao tiếp này thì tốt, nhưng phần thời hạn thì tôi không thích lắm
Nếu cấp dưới đang làm một việc mà tôi có thể phủ quyết, thì chỉ cần báo cho tôi là được. Vì có thể tôi biết thêm bối cảnh và đánh giá rằng việc đó là lãng phí thời gian hoặc không phải ưu tiên
Đặt thời hạn cho quản lý thì kỳ lạ, và nghe như một lời đe dọa khó chịu một cách tinh vi
Với những việc nhỏ như GitHub Action, tôi muốn nghĩ rằng mình đã trao đủ quyền tự chủ để thành viên trong team tự quyết định
Nhưng nếu thêm “tôi sẽ làm vào ngày này, nếu không có ý kiến khác” thì cảm giác hơi gây hấn
Chỉ cần nhắc đến thời điểm làm việc và để ở mức “tôi nghĩ sẽ hoàn thành vào khoảng lúc đó” cũng có thể chừa khoảng trống để người kia đánh giá rằng tốt hơn là không nên tiến hành
Dù vậy, từ lâu mục tiêu của tôi vẫn là trở nên quyết đoán hơn. Chỉ co mình lại thì cũng có giới hạn
Bạn nghĩ một ngày là đủ nên tiến hành, nhưng nếu hai ngày sau đối phương mới trả lời, thì bạn đã làm việc trái với chỉ đạo rồi
Thêm ngày vào có thể tránh được điều đó: “Tôi sẽ migration hệ thống build vào thứ Tư (ngày 26). Nếu có lo ngại, xin hãy cho tôi biết”
Đọc ví dụ xong tôi mới hiểu, thực ra nó gần với ngày dự kiến thực hiện hơn là thời hạn
Vì nó cho đối phương biết khoảng thời gian thông báo trước, và giúp người đọc một email cũ sau này đánh giá liệu nó còn liên quan hay không
Thông thường thời hạn mang nghĩa “đã quyết định làm rồi, cũng đã được phê duyệt hoặc đạt đồng thuận, nên giờ chỉ thông báo việc thực hiện”
Một phần của mẹo “nếu không được cho biết khác đi thì tôi sẽ làm việc này” là giảm chi phí giao tiếp bằng cách không diễn đạt nó như một câu hỏi
Như vậy người nhận không cần phải viết phản hồi, và cả tôi lẫn những người được cc cũng không cần đọc thêm email
Theo nghĩa đó, tôi thích tính năng có thể bấm biểu tượng ngón tay cái để cho biết đã đọc và đồng ý, giống như phản ứng emoji trên GitHub hay Google Docs. Không hiểu sao trong một số bộ phận của HN nó lại không được ưa chuộng, nhưng đây là một cách giao tiếp nhẹ nhàng giúp không phải lúc nào cũng trải qua thủ tục viết bình luận kiểu “Được, nghe hợp lý đấy!”. Nó giống upvote.