Đây là một kỹ năng quan trọng ở các tập đoàn lớn. Nó hữu ích trong bối cảnh ai cũng bận và công việc dễ bị quên. Hãy giải thích vấn đề qua email và nói rằng "nếu không có phản hồi trong vòng [N] ngày, tôi sẽ làm XYZ vào [NGÀY N]". Đây là cách thông báo cho đối phương thay vì chờ phê duyệt
Thỉnh thoảng vài tuần sau có người nổi giận vì ai đó đã làm XYZ, nhưng có hồ sơ cho thấy đó là lỗi của họ
Tôi gọi đây là "đừng hỏi, hãy thông báo", và có thể dùng cho nhiều mục đích cả trong lẫn ngoài công việc. Nó dẫn đến kết quả rõ ràng và dứt khoát
Tôi cũng thường có những cuộc trao đổi kiểu này với vợ. Vợ tôi có phong cách hay hỏi. Trong một buổi gặp mặt buổi tối, cô ấy hỏi "mấy giờ anh sẽ đến?", nhưng tôi chỉ nói cho cô ấy biết khi nào chúng tôi sẽ đến và rằng tôi sẽ đợi ở quán bar. Kết quả là mọi người đều đến sớm và mọi thứ hoàn hảo với mức giao tiếp tối thiểu
Nó có liên quan đến ý tưởng "xin tha thứ, đừng xin phép". Điều này có thể rủi ro, và về bản chất tôi khá nổi loạn. Tuy nhiên, trong môi trường cộng tác như GitHub thì không nên liều lĩnh thử những thay đổi lớn
Khi đưa lời khuyên cho đồng nghiệp về cách xin phê duyệt đề xuất, tôi cũng nói điều tương tự
"Hãy làm cho việc phê duyệt trở nên dễ dàng"
Giải thích ngắn gọn vấn đề và lý do giải pháp là đúng. Nếu ai đó muốn tìm hiểu sâu hơn thì cung cấp liên kết đến tài liệu. Hãy đảm bảo rằng bạn đã nhận được sự đồng ý từ các thành viên trong nhóm hoặc product owner
"Chúng ta sẽ làm Y để giải quyết X. Cả nhóm đều đã đồng ý. Chi tiết ở [liên kết]. Nếu không cần thêm phản hồi, chúng tôi sẽ bắt đầu vào thứ Ba"
Các quản lý không thể dành thời gian cho mọi chi tiết, vì vậy nếu bạn đã có được sự ủng hộ của nhóm thì họ có thể phê duyệt dễ dàng
Cũng có cách tiếp cận "phát đi ý định". Bạn cho biết mình muốn làm gì và kế hoạch là gì, rồi trao cho các bên liên quan cơ hội phản đối một cách rõ ràng. Cách này hiệu quả trong một số tình huống và đòi hỏi mức độ tin cậy cơ bản
Nếu lần đầu bạn làm hỏng thứ gì đó thì có thể là thảm họa. Việc nhận được câu trả lời có hoặc không có nghĩa là sếp biết chuyện
Với câu hỏi "ai đã phê duyệt?" thì có thể trả lời rằng không ai phê duyệt cả
Cách tiếp cận này có thể chỉ hiệu quả ở công ty Mỹ hoặc với những người quản lý quen phong cách kinh doanh kiểu Mỹ. Nếu sếp không thích, nó có thể phản tác dụng. Trong đánh giá hiệu suất, sếp có thể đóng khung đó là hành vi bất tuân. Đôi khi xin phép vẫn là lựa chọn tốt nhất
Một phần của mẹo "tôi sẽ làm việc này" là 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 thư trả lời và cũng không cần đọc thêm email nào khác
Tôi thích tính năng phản ứng bằng emoji trên GitHub và Google Docs. Đó là cách đơn giản để cho biết mình đồng ý. Trên HN nó không được ưa chuộng, nhưng phản ứng emoji là một cách giao tiếp đơn giản
Tôi hiểu quan điểm của OP, nhưng việc ưu tiên "xin tha thứ" còn tùy tình huống. Trên một website mạng xã hội, bạn có thể di chuyển nhanh và mắc sai lầm, nhưng với hệ thống điều khiển phóng hạt nhân thì cần cơ chế "không phóng cho đến khi được cho phép"
Tôi dùng kỹ thuật này trong các dự án cộng tác lớn. Tôi nói "nếu chúng ta không đạt được đồng thuận, tôi sẽ theo lựa chọn mặc định". Khi còn trẻ tôi từng nghĩ cần một mặc định tệ hại, nhưng điều đó chỉ hiệu quả được vài lần
Tôi gọi đó là "tạo ra một mặc định hợp lý". Thay vì yêu cầu quyết định cho mọi chi tiết, hãy chọn một phương án mặc định cho thấy bạn hiểu tình hình và thông báo rằng bạn sẽ thực hiện nó. Điều này giúp xây dựng lòng tin và khiến mọi người chú ý khi thực sự cần
Tôi thích kiểu giao tiếp này, nhưng không thích phần "hạn chót". Tôi muốn báo cáo cho tôi biết nếu họ đang làm việc mà tôi có thể phản đối. Việc đưa hạn chót cho quản lý nghe như một lời đe dọa kỳ lạ và gây khó chịu. Tôi muốn trao quyền tự chủ cho các thành viên trong nhóm
1 bình luận
Ý kiến trên Hacker News