อย่าขอ “ใช่” แต่ให้ขอ “ไม่” (2022)
(mooreds.com)- เมื่อผลักดันงานที่อยู่ในขอบเขตหน้าที่ของตนเองในบริษัทขนาดเล็ก การให้ โอกาสและกำหนดเวลาในการปฏิเสธ แทนการรออนุญาต อาจช่วยเพิ่มความเร็วในการลงมือทำได้
- คำขออนุมัติ อย่าง “ขอติดตั้ง action X ได้ไหม?” อาจโยนภาระให้หัวหน้าต้องตรวจสอบปัญหา ตัดสินวิธีแก้ และปรับลำดับความสำคัญ จนทำให้คำตอบล่าช้า
- หากพูดว่า “ผม/ฉันจะติดตั้ง action X ในวันจันทร์ หากคิดต่างออกไปโปรดแจ้งให้ทราบ” จะเป็นการแสดงเจตนาว่าจะลงมือทำ ขณะเดียวกันก็ยังเปิดช่องให้หัวหน้าเข้ามาแทรกแซงได้
- วิธีนี้เหมาะเมื่อเรื่องนั้นอยู่ใน ขอบเขตบทบาท ของตนเอง ยินดีรับฟีดแบ็ก แต่มั่นใจในทิศทางมากพอที่จะเดินหน้าต่อแม้ไม่มีคำตอบ
- การระบุกำหนดเวลาอันใกล้ควบคู่ไปด้วยจะเพิ่มโอกาสให้คนที่จำเป็นต้องตอบสนองเร็วขึ้น และยังทำให้ผู้เกี่ยวข้องรับรู้อยู่เสมอโดยไม่หยุดการลงมือทำ
ให้โอกาสปฏิเสธแทนการรออนุญาต
- อคติเอนเอียงไปทางการลงมือทำ แม้จะเป็นก้าวเล็กมาก ก็ช่วยทำลายภาวะหยุดนิ่งได้
- นิสัยหลักคือไม่ขอ “ใช่” แต่ใช้วิธี ขอ “ไม่”
- ประสบการณ์นี้มาจากบริษัทขนาดเล็กที่มีพนักงานน้อยกว่า 200 คน
- ยังไม่แน่ชัดว่าวิธีเดียวกันนี้จะใช้ได้กับบริษัทขนาดใหญ่ องค์กรไม่แสวงกำไร หรือหน่วยงานรัฐหรือไม่
- เมื่อพยายามทำงานที่รู้สึกว่าอยู่ในขอบเขตหน้าที่ของตนเอง แต่ต้องการความสบายใจหรือต้องการแจ้งให้หัวหน้าทราบ ปกติแล้วมักจะขออนุญาตก่อน
- แทนที่จะทำเช่นนั้น ให้หัวหน้ามี โอกาสปฏิเสธ พร้อมระบุ กำหนดเวลาที่ชัดเจน สำหรับการตัดสินใจนั้น
ความแตกต่างจากตัวอย่าง GitHub Action
- ตัวอย่างคือสถานการณ์ที่ต้องการติดตั้ง GitHub Action ใหม่ลงใน repository เพราะเห็นว่าจะช่วยปรับปรุงคุณภาพซอฟต์แวร์ได้
- ไม่ใช่ความคิดชั่ววูบ แต่ผ่านการค้นคว้าและทดสอบในเครื่องแล้ว
- อาจเคยถามอดีตเพื่อนร่วมงานเกี่ยวกับประสบการณ์การใช้ GitHub Action นั้นแล้วด้วย
- วิธีถามว่า “ขอติดตั้ง action X ได้ไหม? มันช่วยแก้ปัญหา XYZ ที่เรากำลังเจออยู่” ทำให้หัวหน้าต้องทำงานเพิ่มเติมก่อนจะตอบว่า “ใช่”
- ต้องตรวจสอบปัญหา XYZ อีกครั้ง
- ต้องตัดสินว่า X จะแก้ปัญหาอย่างไร
- อาจต้องเทียบลำดับความสำคัญกับงานอื่น หรืออาจอยากให้ผู้รับผิดชอบแชร์สิ่งที่รู้ก่อน
- สำหรับหัวหน้าที่งานยุ่ง เรื่องนี้อาจถูกเลื่อนออกไป และอาจต้องเตือนซ้ำหลายครั้ง
- ทางเลือกคือพูดว่า “ผม/ฉันจะติดตั้ง action X เพื่อแก้ปัญหา XYZ หากคิดต่างออกไปโปรดแจ้งให้ทราบ มิฉะนั้นจะดำเนินการในวันจันทร์”
- เป็นสัญญาณว่าผู้รับผิดชอบจะจัดการปัญหานั้นเอง
- หัวหน้าสามารถเข้ามาเกี่ยวข้องได้หากต้องการ แต่ภาระที่ต้องตอบกลับก็ลดลง
- แม้หัวหน้าจะลืมหรือมีงานอื่นเข้ามา การดำเนินงานก็ไม่หยุดชะงัก
- วิธีนี้ใช้ได้ไม่เพียงกับบุคคลเดียว แต่ยังใช้กับ กลุ่มที่ประกอบด้วยหลายคน ได้ด้วย
แรงกดดันให้ตอบสนองที่กำหนดเวลาสร้างขึ้น
- กำหนดเวลาเป็นองค์ประกอบสำคัญของแนวทางนี้
- หากอ้างอิงวันที่ 15 มกราคม ประโยค “ผม/ฉันจะทำ task X” อาจกระตุ้นการตอบสนองได้ช้ากว่า “ผม/ฉันจะทำ task X ในวันที่ 17 มกราคม”
- กำหนดเวลาที่อยู่ในอนาคตอันใกล้มีแนวโน้มจะดึงการตอบสนองทันทีได้มากกว่ากำหนดเวลาที่ไกลออกไป เช่น “ผม/ฉันจะทำ task X ในวันที่ 15 กุมภาพันธ์”
- แนวทางนี้เหมาะที่สุดเมื่อเปิดโอกาสให้ฟีดแบ็กไว้ แต่มั่นใจในทิศทางมากพอที่จะลงมือทำแม้ไม่มีฟีดแบ็ก
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ใน บริษัทขนาดใหญ่ ที่ทุกคนยุ่งและงานมักถูกกลบหาย นี่คือความสามารถหลักอย่างหนึ่ง
หลังจากอธิบายปัญหาในอีเมลแล้ว ให้เขียนว่า “ถ้าไม่มีคำตอบภายใน [N] วัน ผม/ฉันจะทำ XYZ ในวันที่ [วันที่ครบ N วัน]” แทนที่จะขออนุมัติแล้วรออย่างไร้เรี่ยวแรงหรือคอยเร่ง ก็เป็นการแจ้งให้ทราบว่า หากอยู่นิ่ง ๆ XYZ จะดำเนินต่อไป
บางครั้งหลายสัปดาห์ต่อมาก็มีคนโกรธว่าทำไมทำไปโดยไม่บอก แต่ทุกครั้งก็สามารถเอาบันทึกที่อีกฝ่ายพลาดไปให้ดูได้
พูดแบบ “ด้วยเหตุผลเหล่านี้ ผม/ฉันตั้งใจจะทำ XYZ และจะดำเนินการใน [วันที่] ถ้ามีข้อคัดค้านหรือข้อกังวล โปรดแจ้งให้ทราบ” ก็เพียงพอแล้ว
วิธีนี้บังคับให้เราต้องเสนอเหตุผลที่หนักแน่นล่วงหน้า และยังทำให้ได้รับฟีดแบ็กเพื่อหลีกเลี่ยงข้อจำกัดหรือความผิดพลาดที่ตัวเองไม่รู้ได้ด้วย
การทำตามหลักการผู้นำของ Amazon เหมือนเป็นทางออกของปัญหาแบบ ลัทธิบูชาสินค้า ก็ดูแปลก ๆ เหมือนกัน ที่ “bias for action” ใช้ได้ผลใน Amazon ก็เพราะคนที่เดินหน้าโดยพลการแล้วล้มเหลวจะกลายเป็นแพะรับบาปและถูกไล่ออก และคนเหล่านั้นก็ไม่ได้เขียนบล็อกสรรเสริญคุณงามความดีของ bias for action
ประมาณว่า “ผม/ฉันมีกำหนดจะ defrag thingamajig ในวันที่ 1 มีนาคม ติดต่อมาล่วงหน้าถึงผู้ที่งานนี้อาจก่อปัญหาให้ หากมีข้อกังวลโปรดแจ้งให้ทราบ หากไม่มีคำตอบภายในวันที่ 1 มีนาคม thingamajig จะถูก defrag” แบบนี้หรือเปล่า
การพูดว่า “ถ้าไม่มีคำตอบภายใน 5 วัน ผม/ฉันจะทำ X” ไม่ได้เป็นเกราะป้องกันอะไรเลยหากคุณทำสิ่งที่อาจถูกลงโทษทางวินัย
ที่ใช้ได้อย่างมากก็แค่กรณีละเมิดการตัดสินใจด้านการออกแบบภายในที่ไม่เกี่ยวกับธุรกิจ
คนที่บอกว่าทำแบบนี้ “เสมอ” แล้วเขียนประโยควิเศษเป็นเทมเพลตนี่เป็นประสบการณ์จริงของตัวเองหรือเปล่า หรือเป็นการฉายภาพว่าตัวเองอยากทำงานแบบในบทความกันแน่
พอนึกภาพฉากที่เอา บันทึกให้เพื่อนร่วมงานที่โกรธดูแล้วชนะ เครื่องจับเรื่องเหลวไหลก็พุ่งขึ้นไปถึงสีแดง
ผม/ฉันเรียกสิ่งนี้ว่า “อย่าถาม แต่ให้บอก” และมันมีประโยชน์มากทั้งในและนอกบริษัท
เป็น ทักษะการสื่อสาร ขั้นพื้นฐาน และทำให้ผลลัพธ์กระชับและเด็ดขาด
ผม/ฉันคุยกับภรรยาแบบนี้บ่อย ๆ ภรรยามักส่งคำถามปลายเปิดไปในแชตกลุ่ม 8 คน เช่น “จะถึงกี่โมง?” เรารู้อยู่แล้วว่าเราจะไปถึงก่อนหนึ่งชั่วโมงเพราะมีตารางต้องฝากลูกไว้ จึงบอกเธอว่าให้แจ้งไปเลยว่า “เราจะถึงเวลานี้ และใครอยากดื่มก่อนก็ไปอยู่ที่บาร์นะ”
ไม่จำเป็นต้องเรียกร้องให้ใครตอบ ทุกคนมาก่อนเวลา และทุกอย่างก็ราบรื่นด้วยการสื่อสารน้อยที่สุด
มันเกี่ยวข้องกับ “ขออภัยง่ายกว่าขออนุญาต” อยู่บ้าง แต่พื้นที่อย่าง GitHub repository ที่หลายคนร่วมงานกัน ไม่ใช่ที่เหมาะจะโยนการเปลี่ยนแปลงใหญ่ ๆ ที่ส่งผลต่อคนอื่นเข้าไปอย่างไม่คิด
ไม่ใช่สภาพที่เราจะสนุกได้ก็ต่อเมื่อคนอื่นต้องช่วยประสานงานให้ แต่เป็นการเริ่มทำสิ่งที่เราอยากทำ แล้วบอกคนอื่นว่าสามารถมาร่วมได้
เวลาที่เพื่อนร่วมงานถามว่าจะทำให้ข้อเสนอของตัวเองได้รับการอนุมัติอย่างไร ผม/ฉันก็แนะนำคล้าย ๆ กันว่า “ทำให้ให้อีกฝ่าย พูดว่าใช่ได้ง่ายที่สุด”
อย่าโยนข้อความ 14 ย่อหน้าให้ใครสักคน แล้วคาดหวังว่าเขาจะตามทันในทันทีถึงระดับที่เราขุดคุ้ยปัญหามาหลายชั่วโมง
ถ้ามั่นใจในแนวทางของตัวเอง ก็อธิบายอย่างกระชับว่าปัญหาและทางแก้สอดคล้องกันอย่างไร แล้วแนบลิงก์เอกสารสำหรับคนที่อยากเจาะลึกเพิ่มเติม ควรขอความเห็นชอบจากสมาชิกทีมและ product owner ไว้ก่อนแล้วด้วย
ตัวอย่าง: “เราตั้งใจจะแก้ X ด้วย Y ทีมเห็นด้วยทั้งหมดแล้ว เอกสารข้อเสนอโดยละเอียดอยู่ที่ [link] หากไม่มีฟีดแบ็กเพิ่มเติมที่ต้องจัดการ เราจะเริ่มในวันอังคาร”
ผู้จัดการไม่มีเวลาดูทุกรายละเอียด และถ้าคุณจัดระเบียบงานไว้พร้อมทั้งแสดงการสนับสนุนจากทีมวงกว้าง เขาก็แค่ต้องอนุมัติ จึงรู้สึกขอบคุณ
ถ้าโอกาสสำเร็จ 10% แต่มีเหตุผลให้ลอง ก็จะพูดแบบนั้น ไม่ใช่ห่อมันเป็นการนำเสนอไร้สาระว่ามั่นใจว่าจะสำเร็จ ถ้าโอกาสสำเร็จ 80% ก็จะไม่ซ่อนอีก 20% และถ้าบอกว่า 98% ก็หมายความว่าจริง ๆ แล้วใกล้เคียงระดับนั้น
งานของผู้จัดการคือจัดการสถิติแบบนี้และ hedge ความเสี่ยง กองทุน hedge fund ทำด้วยเงิน ส่วนผู้จัดการทำด้วยคนและทรัพยากร
น่าเสียดายที่ผู้จัดการองค์กรทั่วไปมักชอบคนที่พูดว่าสำเร็จ 100% แต่ในความเป็นจริงล้มเหลว 50% มากกว่า
ผม/ฉันชอบสำนวนที่คล้ายกันคือ การกระจายเจตนา (radiating intent)
คือการแจ้งให้ทราบอย่างกว้างขวางว่าตั้งใจจะทำอะไรเมื่อไร ให้พื้นที่แก่ผู้มีส่วนได้ส่วนเสียในการคัดค้านอย่างชัดเจน แต่ไม่ไล่ตามฉันทามติ การจัดแนว หรือการอนุมัติทีละอย่าง
ใช้ได้ดีในบางสถานการณ์ และโดยทั่วไปต้องได้รับความไว้วางใจพื้นฐานก่อน
https://medium.com/@ElizAyer/dont-ask-forgiveness-radiate-in...
ผม/ฉันก็ชอบนัยที่ Eliz Ayer เสริมไว้ด้วยว่า “ถ้าพูดอย่างเป็นธรรม การกระจายเจตนาอาจทำให้งานสำเร็จน้อยลงก็ได้ เพราะมันเปิดช่องให้คนที่ขัดขวางหรือชอบแทรกแซงเข้ามายุ่งได้ อีกทั้งคำแนะนำแบบนี้ยังขึ้นกับสถานการณ์และองค์กรอย่างมาก จึงไม่เหมาะเสมอไป”
วิธีสื่อสารแบบนี้น่าจะทำให้อีกฝ่ายมองเราเป็น บุคคลอันตราย ในทันที
ภายนอกอาจดูเหมือนช่วยประหยัดเวลาให้ แต่จริง ๆ แล้วเป็นวิธีบอกว่าถ้าผู้จัดการไม่คอยตามดูอยู่เสมอว่าพนักงานคนนั้นกำลังทำอะไรอยู่ เขาอาจทำสิ่งที่ไม่พึงประสงค์ได้
บทความพูดถึงเรื่องนี้เหมือนเป็นการแจ้งเตือน แต่ไม่ว่าจะมีเจตนาดีและความเข้าใจมากแค่ไหน การแจ้งเตือนก็ถูกกลบได้ง่ายท่ามกลางเสียงรบกวนของสัญญาณ และการไม่มีคำตอบไม่ได้แปลว่ายินยอม อาจแปลว่าไม่ได้รับข้อความก็ได้
ถ้าพนักงานกับผู้จัดการได้คุยปัญหากันแล้ว และตอนนี้อยู่ในสถานการณ์ที่กำลังลงมือทำทางออก ก็อาจไม่เป็นไร แต่ถ้าเป็นการหยิบยกปัญหาที่อีกฝ่ายยังไม่ได้แม้แต่จะพิจารณามาก่อนเป็นครั้งแรก นี่แย่มาก เห็นแก่ตัวและตรงข้ามกับ teamwork อย่างสิ้นเชิง
ให้ความรู้สึกเหมือนเห็น วิศวกร 10x Rockstar ระดับตำนานทำแบบนี้แล้วก็ทำตาม วิศวกรคนนั้นทำงานดีเสมอ รู้ว่าควรทำอะไร และมีความเข้าใจรวมถึงความเคารพซึ่งกันและกันกับฝ่ายบริหาร จึงมีพื้นที่ให้มอบหมายการจัดการตนเองได้ คนที่เห็นแบบนั้นคงคิดว่าสิ่งเดียวกันใช้กับตัวเองได้ โดยไม่เข้าใจว่าทำไมคนนั้นถึงได้รับการปฏิบัติแบบนั้น และตัวเองควรต้องทำอย่างไรถึงจะได้มันมา
ถ้าทำแบบนี้ติดกันสามครั้งแล้วได้รับคำตอบว่า “ช่วยหยุดที” แปลว่ามีบางอย่างผิดทางแล้ว ถ้าได้รับคำชมติดกันสามครั้ง ก็ทำต่อไปได้
คนที่อันตรายจริง ๆ คือคนที่ได้ยินว่าไม่อนุญาตแล้วก็ยังหาทางทำเกือบทั้งหมดให้ได้ จากนั้นค่อยไปหา yes ทีหลัง งานถัดไปก็ทำแบบเดิม และไม่ตอบสนองต่อ feedback
ดังนั้นแก่นสำคัญไม่ใช่วิธีการเองเท่าไร แต่เป็นความสัมพันธ์ในการทำงาน ถ้ามีความเชื่อใจสูงและทุกคนยุ่งกันหมด ก็น่าลอง
แต่ถ้าเคยทำงานด้วยกัน มีความเชื่อใจ และฉันรู้ว่าเขาทำเพราะเคารพเวลาของฉัน นั่นก็เป็นอีกเรื่องโดยสิ้นเชิง
ทันทีที่ทำอะไรพังเป็นครั้งแรก มันจะกลายเป็น สูตรหายนะ
การได้รับ yes หรือ no หมายความว่าเจ้านายรับรู้แล้ว เมื่อเกิดเรื่องแล้วถูกถามว่า “ใครอนุมัติ?” คำตอบที่จริงใจคือไม่มีใครอนุมัติเลย
ถ้าในองค์กรไม่มีใครเลยที่สามารถทำแบบนี้ได้ นั่นเป็นสัญญาณว่าทีมผู้นำกำลัง ล้มเหลวในการมอบหมายงาน
เช่นกรณีที่ X จากทีม Y คัดค้านอะไรบางอย่าง
ถ้าเจ้านาย 1) บอกว่าต้องทำอะไรบางอย่าง และ 2) ไม่อนุมัติแผนใด ๆ ก็แค่ไม่ต้องทำ ในกรณีนั้นความรับผิดชอบในการสั่งให้เรื่องเดินหน้าเป็นของเจ้านาย
การบอกว่า “จะทำสิ่งนี้” นั้นโอเค แต่ไม่ควรถูกปล่อยขึ้น production โดยไม่มีขั้นตอนอย่างการ review และ automated test
แน่นอนว่าถ้าเป็นแบบนั้นก็จะเกิดคอขวด ส่ง merge request ไปแล้วถ้าไม่มีใคร review ทันเวลา ก็จะไม่มีอะไรเกิดขึ้น ในกรณีแบบนี้ควรกำหนดข้อตกลงในระดับ team lead ว่าจะตรวจสอบและ review ภายในเวลาที่กำหนด
แนวทางแบบนี้ดูเหมือนจะใช้ได้เฉพาะกับเจ้านายที่คุ้นเคยกับบริษัทอเมริกันหรือ วัฒนธรรมธุรกิจแบบอเมริกัน เท่านั้น
ถ้าเจ้านายไม่ชอบ อาจส่งผลย้อนกลับอย่างหนัก ตอนประเมินผลงาน เจ้านายอาจติดป้ายว่าไม่เชื่อฟังได้ง่าย ๆ และเท่ากับเป็นการยื่นหลักฐานที่จำเป็นใส่ถาดให้เอง
บางครั้งแม้แต่ในอเมริกา การขออนุญาตก็เป็นทางเลือกที่ดีที่สุดจริง ๆ โดยเฉพาะเรื่องที่เกี่ยวข้องกับทรัพยากร
เช่นใน วัฒนธรรมแถบสแกนดิเนเวีย การจัดการมักปล่อยมือค่อนข้างมาก และมักคาดหวังให้พนักงานตัดสินใจหลายอย่างอย่างอิสระหรือปรึกษากันเอง
แต่เจ้านายเหล่านั้นล้วนซึมซับ วัฒนธรรมอเมริกัน อย่างลึกซึ้ง
แม้แต่การตัดสินใจทางทหารที่มีประสิทธิภาพ ก็ยังพึ่งพาอย่างมากกับการที่หน่วยภาคสนามต้องสามารถปรับตัวได้โดยไม่ต้องโทรกลับไปสำนักงานใหญ่ทุกครั้ง
เรียกสิ่งนี้ว่า การสร้างค่าเริ่มต้นที่สมเหตุสมผล
แทนที่จะเรียกร้องให้คนอื่นตัดสินใจในทุกรายละเอียด ก็คือการกำหนดชุดค่าเริ่มต้นที่สมเหตุสมผลซึ่งแสดงให้เห็นว่าเราเข้าใจสถานการณ์ แล้วแจ้งว่าจะดำเนินการตามนั้น
วิธีนี้ช่วยสร้างความเชื่อใจ และเมื่อถึงเวลาที่ต้องการความใส่ใจจริง ๆ คนอื่นก็จะช่วยดูให้มากขึ้น เพราะรู้ว่าโดยปกติเราไม่ทำให้พวกเขาเสียเวลา
วิธีสื่อสารแบบนี้ดี แต่ส่วนของ กำหนดเส้นตาย ไม่ค่อยดี
ถ้าลูกน้องกำลังทำอะไรที่ฉันอาจใช้สิทธิยับยั้งได้ แค่แจ้งให้ฉันรู้ก็พอ เพราะฉันอาจมีบริบทมากกว่าและตัดสินได้ว่างานนั้นเสียเวลา หรือไม่ใช่ priority
การกำหนดเส้นตายให้ผู้จัดการเป็นเรื่องแปลก และฟังดูเหมือนการข่มขู่ที่น่ารำคาญอยู่ลึก ๆ
เรื่องเล็ก ๆ อย่าง GitHub Action ฉันอยากคิดว่าได้ให้อิสระกับทีมมากพอให้ตัดสินใจกันเองได้
แต่ถ้าเติมว่า “ผมจะทำในวันที่นี้ ถ้าไม่มีความเห็นอื่น” จะรู้สึกก้าวร้าวเล็กน้อย
แค่พูดถึงช่วงเวลาที่จะทำงานและทิ้งไว้ประมาณว่า “น่าจะเสร็จราว ๆ ตอนนั้น” ก็ยังเปิดช่องให้判断ได้ว่าไม่ควรเดินหน้าต่อ
ถึงอย่างนั้น เป้าหมายมานานแล้วก็คือการแน่วแน่มากขึ้น การหดตัวอยู่เฉย ๆ มีขีดจำกัด
ถ้าคิดว่าวันเดียวก็พอแล้วเลยเดินหน้าต่อ แต่อีกฝ่ายตอบกลับในอีกสองวันให้หลัง ก็เท่ากับได้ทำสิ่งที่ขัดกับคำสั่งไปแล้ว
ใส่วันที่ลงไปก็หลีกเลี่ยงได้: “ผมจะ migrate build system ในวันพุธ (วันที่ 26) หากมีข้อกังวลโปรดแจ้งให้ทราบ”
อ่านตัวอย่างแล้วถึงเข้าใจว่า จริง ๆ มันใกล้เคียงกับ วันที่วางแผนจะลงมือทำ มากกว่า ไม่ใช่กำหนดเส้นตาย
เพราะเป็นการบอก ระยะเวลาแจ้งล่วงหน้า ให้อีกฝ่าย และช่วยให้คนที่มาอ่านอีเมลเก่าภายหลังตัดสินได้ว่ายังเกี่ยวข้องอยู่หรือไม่
โดยปกติกำหนดเส้นตายใช้ในความหมายว่า “ตัดสินใจจะทำแล้ว และได้รับการอนุมัติหรือข้อตกลงแล้ว ตอนนี้จึงแจ้งข้อเท็จจริงว่าจะลงมือทำ”
เคล็ดลับส่วนหนึ่งของแนวทาง “ถ้าไม่ได้แจ้งเป็นอย่างอื่น ผมจะทำสิ่งนี้” คือการไม่เขียนให้ดูเหมือนคำถาม เพื่อลดต้นทุนในการสื่อสาร
แบบนั้นผู้รับก็ไม่จำเป็นต้องตอบกลับ และทั้งตัวผมเองหรือคนที่ถูกใส่ไว้ในสำเนาก็ไม่ต้องอ่านอีเมลเพิ่มเติม
ในความหมายนี้ ฟีเจอร์ที่ให้กดนิ้วโป้งเพื่อบอกว่าอ่านแล้วและเห็นด้วย เช่น reaction แบบอีโมจิใน GitHub หรือ Google Docs จึงดี แม้ในบางส่วนของ HN จะไม่ค่อยเป็นที่นิยมอย่างน่าประหลาด แต่มันเป็นวิธีสื่อสารแบบเบา ๆ ที่ไม่ต้องผ่านขั้นตอนเขียนคอมเมนต์อย่าง “ดีครับ ฟังดูสมเหตุสมผล!” ทุกครั้ง คล้ายกับการ upvote