คู่มือ CTO สำหรับสตาร์ทอัพ
(github.com/ZachGoldberg)คู่มือ CTO สำหรับสตาร์ทอัพ
ทักษะสำคัญและแนวปฏิบัติที่ดีที่สุดสำหรับทีมวิศวกรรมสมรรถนะสูง
บทนำ
- เรียนรู้อยู่เสมอ: ผู้เขียนมีความหลงใหลในคอมพิวเตอร์และการเขียนโปรแกรมซอฟต์แวร์มาตั้งแต่วัยเด็ก และจากสิ่งนี้ทำให้ตระหนักถึงความสำคัญของการเรียนรู้อย่างต่อเนื่อง เพื่อประสบความสำเร็จในฐานะผู้นำทางเทคนิค จำเป็นต้องเรียนรู้และเติบโตอย่างไม่หยุดยั้ง
- ภาวะกลืนไม่เข้าคายไม่ออกของผู้นำเทคนิคในสตาร์ทอัพ: สตาร์ทอัพส่วนใหญ่มักมีผู้ร่วมก่อตั้งสายเทคนิค ซึ่งเป็นผู้เขียนโค้ดเบสช่วงแรกและจ้างวิศวกรชุดแรก แต่เมื่อทีมเติบโตขึ้น ผู้นำทางเทคนิคจำเป็นต้องเปลี่ยนบทบาทไปสู่การบริหาร และในกระบวนการนี้อาจขาดทักษะความเป็นผู้นำ
เกี่ยวกับผู้เขียน
- ผู้เขียนได้สั่งสมประสบการณ์จากสตาร์ทอัพหลายแห่ง และทำหน้าที่ในบทบาทผู้นำทางเทคนิคมาอย่างต่อเนื่อง จากประสบการณ์ในสตาร์ทอัพหลากหลายรูปแบบ ทำให้เข้าใจทักษะและความท้าทายหลายด้านที่จำเป็นต่อการเป็นผู้นำทางเทคนิค
วิธีใช้หนังสือเล่มนี้
- หนังสือเล่มนี้เป็นหนังสืออ้างอิงสำหรับผู้นำที่ดูแลทีมวิศวกรรมซอฟต์แวร์ โดยครอบคลุมหัวข้อต่าง ๆ ในรูปแบบบทที่แยกอ่านได้อย่างอิสระ แต่ละบทจะเกริ่นนำหัวข้อ ให้ภาพรวม และนำเสนอแนวปฏิบัติที่ดีที่สุด
กระบวนการทางธุรกิจ
- อธิบายกระบวนการทางธุรกิจเพื่อเป็นจุดเริ่มต้นของการแก้ปัญหา โดยจำเป็นต้องปรับและขยายกระบวนการให้เหมาะกับขนาดของทีมและบริษัท
ผู้คนและวัฒนธรรม
หลักการพื้นฐานของการบริหาร
- กฎทองของการบริหาร: ผลงานของทีมคือเกณฑ์ที่ใช้วัดผลงานของผู้จัดการ จึงต้องสนับสนุนให้สมาชิกทีมสามารถทำผลงานได้ดีที่สุด
- ต้นไม้ทักษะวิชาชีพ: สำหรับภาวะผู้นำทางเทคนิค ไม่เพียงต้องลงทุนกับทักษะด้านเทคนิคเท่านั้น แต่ยังต้องลงทุนกับทักษะการบริหารด้วย
การปรับปรุงอย่างต่อเนื่อง
- ไคเซ็น: ทั้งทีมและแต่ละบุคคลควรมุ่งสู่การปรับปรุงอย่างต่อเนื่อง และควรมองความผิดพลาดเป็นโอกาสในการพัฒนา
การโค้ช
- ผู้จัดการควรทำหน้าที่เป็นโค้ชที่ช่วยให้สมาชิกทีมสามารถแสดงศักยภาพได้อย่างเต็มที่
การหาที่ปรึกษาด้านการบริหาร
- การหาที่ปรึกษาด้านการบริหารมีความสำคัญต่อการเปลี่ยนผ่านสู่บทบาทผู้นำ โดยสามารถพัฒนาทักษะความเป็นผู้นำได้ผ่านเมนเทอร์ที่เหมาะสม
การประชุม 1:1
- การประชุม 1:1 เป็นโอกาสในการสร้างความสัมพันธ์กับสมาชิกทีม ทำความเข้าใจจุดแข็งและจุดอ่อนของพวกเขา และช่วยให้พวกเขาทำผลงานได้ดีที่สุด
การประชุมแบบ skip-level
- การประชุมกับผู้ใต้บังคับบัญชาตรงของผู้จัดการอย่างสม่ำเสมอช่วยให้รวบรวมมุมมองที่หลากหลาย และนำไปสู่การปรับปรุงธุรกิจได้
การโค้ชสำหรับผู้จัดการ
- ผลงานของผู้จัดการระดับกลางมีความสำคัญต่อผลงานขององค์กร จึงต้องพัฒนาผู้จัดการผ่านการฝึกฝนและการสนับสนุนอย่างต่อเนื่อง
การประชุม 1:1 กับวิศวกร
- การประชุม 1:1 กับวิศวกรเป็นโอกาสในการรับฟังปัญหาที่พวกเขากำลังเผชิญ และช่วยให้พวกเขาค้นหาแนวทางแก้ไข ต้องกำหนดเป้าหมายของการประชุมให้ชัดเจนและนำการสนทนาไปอย่างมีประสิทธิภาพ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เวลาดูเอกสารแบบนี้ ผมมักจะไปดูส่วนที่ตัวเองรู้ลึกก่อนว่าเขาพูดไว้อย่างไร ในที่นี้เขาบอกว่าการเตรียมและดำเนินการ การตรวจสอบ PCI DSS หรือ SOC 2 โดยทั่วไปใช้เวลา 6–12 เดือน จึงไม่ควรพยายามขอการรับรองในนาทีสุดท้าย แต่สำหรับสตาร์ทอัพ ผมแทบอยากแนะนำตรงกันข้าม
โดยเฉพาะ การรับรอง SOC 2 นั้นทำได้ค่อนข้างง่าย และการใช้เงินเชิงรุกตั้งแต่ก่อนจะมีใบสั่งซื้อเข้ามาถือว่าเป็นการสิ้นเปลือง แน่นอนว่าสิ่งที่จะเป็นพื้นฐานของการรับรองในภายหลัง เช่น การตั้งค่า single sign-on หรือ Git branch ที่มีการป้องกัน ควรทำไว้แต่เนิ่น ๆ แต่สิ่งเหล่านี้ก็ใกล้เคียงกับ best practices พื้นฐานที่ควรทำอยู่แล้ว แม้จะไม่ได้มีแผนจะทำ SOC 2 ก็ตาม ถ้าลูกค้ารายใหญ่ไม่ได้เรียกร้อง ผมมองว่าไม่จำเป็นต้องทำ SOC 2 อยากให้มีคนลองตรวจสอบส่วนอื่น ๆ ของเอกสารนี้ด้วย
ถ้าเพิ่ม read replica สำหรับ BI กับเครื่องมือ visualization ที่ใช้ได้ ก็อยู่ได้อีกนานพอสมควร และเพียงพอก่อนจะต้องไปจ่ายเงินระดับห้าถึงหกหลักให้ของอย่าง Snowflake
แล้วแต่สถานะเงินทุน ค่าใช้จ่ายสำหรับบริการ checklist อัตโนมัติด้านการปฏิบัติตาม SOC 2 อย่าง Secureframe อาจอยู่ที่ระดับไม่กี่พันดอลลาร์ และไม่เพียงช่วยให้ทำตาม best practices แต่ยังจัดระเบียบในรูปแบบเฉพาะที่เหมาะกับ SOC 2 ทำให้ตรวจสอบได้ง่ายขึ้นด้วย เมื่อเทียบกับเวลาในการพัฒนาและบริหารโครงการที่ต้องใช้เพื่อพาองค์กรที่มีกระบวนการไม่สอดคล้องฝังลึกอยู่แล้วเข้าสู่เส้นทาง SOC 2 นี่ไม่ใช่การลงทุนที่ใหญ่อะไร
คำพูดที่ว่าการรับรอง SOC 2 ทำได้ง่ายก็ตรงข้ามกับที่ผมได้ยินจากคนอื่น ๆ เกี่ยวกับหัวข้อนี้โดยสิ้นเชิง ปกติผมได้ยินว่ามันยากและกินเวลามาก เลยสงสัยว่าผมพลาดอะไรไป ถ้ามันง่ายจริง ๆ ก็หวังว่าผมจะเข้าใจผิด
มักเห็นคนพูดกันว่าพอเป็น VP หรือ CTO แล้วจะหยุดเขียนโค้ด ผมเข้าใจว่าทักษะการจัดการไม่ใช่ทักษะการเขียนโค้ด แต่ก็ยากจะเข้าใจว่าทำไมผู้คนถึงวางคีย์บอร์ดลงและปล่อยให้ซูเปอร์พาวเวอร์แรกของตัวเองสูญเปล่า
คุณสามารถเป็น CTO สายเทคนิค ตั้งแต่ต้นจนจบได้ ปฏิบัติต่อทีมและบริษัทเหมือนบริการที่ต้องการการมีส่วนร่วมเชิงรุก การบำรุงรักษา และการ support on-call พร้อมกันนั้นก็ต้องลงมือทำจริง ทั้งด้วยตัวเองและร่วมกับทีม
ปัญหาจริง ๆ คือการรับบทบาทที่ไม่มีเวลาให้เขียนโค้ดตั้งแต่ช่วงต้นอาชีพ เช่น บทบาท architect ที่เอาแต่วาดกล่องบน whiteboard แล้วย้ายไปมาระหว่างประชุม หรือรับบทบาทที่โดยแท้จริงเป็นสายบริหารแต่ติดป้ายว่า “tech lead” พอชินกับการไม่เขียนโค้ด และผ่านไปหลายปีจนต้องหางานใหม่ ก็ต้องไปสัมภาษณ์ตำแหน่งเขียนโค้ดพร้อมเผชิญความจริงว่าใช้ส่วนสำคัญของอาชีพโปรแกรมมิงไปโดยไม่ได้เขียนโค้ด สำหรับหลายคน ความรู้สึกคุ้นมือไม่ได้กลับมาเร็ว
การใช้เวลาของผมไปแก้ปัญหาที่คนอื่นแก้ไม่ได้คุ้มค่ากว่ามาก บางครั้งผมรับงานแก้ไขที่ง่ายมาก ๆ เพื่อผ่านกระบวนการของเราเองและดูว่าตรงไหนปรับปรุงได้บ้าง ตอนกลางคืนหรือสุดสัปดาห์ก็ยังเขียนโค้ดต่อ แต่ความรู้สึกไม่เหมือนเดิม และพอเวลาผ่านไปก็เลี่ยงไม่ได้ที่จะเริ่มสนิมขึ้นบ้าง ถึงอย่างนั้น ช่วงพักงานที่ได้ลงมือเขียนโค้ดทั้งวันก็สนุกมากจริง ๆ
การ review หรือประชุมออกแบบยังทำได้ แต่ถ้ารับงานหลัก สุดท้ายก็จะเกิดปัญหา
โค้ดที่ VP/CTO เขียนได้ คนอื่นในทีมก็น่าจะเขียนได้ และบางทีอาจเขียนได้ดีกว่าด้วย ในทางกลับกัน งานอื่น ๆ ที่ยกมานั้นมีโอกาสสูงที่ VP/CTO จะเป็นคนทำได้ดีที่สุดในบริษัท การวางงานเทคนิคเชิงปฏิบัติส่วนใหญ่ลงเพื่อไปทำสิ่งที่สำคัญกว่าต่อทีมและบริษัท จึงเป็นการตัดสินใจที่สมเหตุสมผลทีเดียว
แนวคิดที่จะเขียนโค้ดต่อไปนั้นดี แต่โดยปกตินั่นไม่ใช่เหตุผลที่คุณได้รับค่าตอบแทน ผมมองว่าตัวเองเป็นนักพัฒนาที่แข็งแกร่งมาก แต่สามารถหานักพัฒนาแบบนั้นได้ในต้นทุนต่ำกว่าเงินเดือนระดับ CTO การให้ CTO ที่แพงกว่ามาทำงานนั้นจึงไม่มีประสิทธิภาพ อ้างอิงว่าอีกไม่กี่ปีต่อมาผมกลับไปเป็น individual contributor และตั้งใจจะเดินเส้นทางนั้นไปตลอดอาชีพที่เหลือ
อยากบอกว่าไม่มีสิ่งที่เรียกว่า แชตแบบ synchronous
ถ้าต้องเป็น synchronous ก็ไม่ควรทำในหน้าต่างแชต อย่างน้อยก็เว้นแต่จะตกลงกันว่า “มาจดจ่อกับการแชตแบบเรียลไทม์สักไม่กี่นาที” ถ้ารีโมตก็โทรคุย ถ้าอยู่หน้างานก็พูดคุยกันต่อหน้า ไม่ควรโยนข้อความไว้ในแชตแล้วคาดหวังคำตอบทันที
สงสัยว่ามีกรณีไหนบ้างที่ระบบ “สองทีม” ไม่ก่อให้เกิดความขุ่นเคือง ไม่แน่ใจเหมือนกันว่ามีกรณีที่ผู้คนไม่ได้อยากย้ายไปอยู่ ทีมอนาคต โดยธรรมชาติหรือไม่
บนกระดาษดูเหมือนเป็นไอเดียที่ดี แต่ยากจะเชื่อว่าจะทำงานได้ดีจริง รูปแบบที่ใกล้เคียงที่สุดที่เคยเห็นคือทีมไลบรารีที่สร้างบริการอย่าง design system และคอมโพเนนต์ให้ทีมอื่นใช้
ตราบใดที่ยังรับผิดชอบเรื่องนั้นได้ เวลาที่เหลือก็ทำอะไรก็ได้อย่างอิสระที่เห็นว่ามีคุณค่าต่อบริษัท เป็นข้อตกลงที่ค่อนข้างดี คนอื่นๆ ขอบคุณที่ทีมเล็กๆ นั้นรับงานสกปรกไปทำ ส่วนทีม maintenance ก็ชอบที่มีเวลาที่เหลือไปแก้สิ่งที่คาใจมาตลอดหรือทำวิจัยได้ จำรายละเอียดไม่ได้แล้ว แต่จำได้ว่ามี improvement และผลการวิจัยที่ค่อนข้างเจ๋งออกมา การที่คนในทีมนั้นเก่งมากและขับเคลื่อนตัวเองได้ดีก็ช่วยให้สำเร็จ แต่ก็มีต้นทุนสูงขึ้นด้วย
เคยผ่านมาหลายที่ที่ทีมที่แยกกันชัดเจนทำงานได้ดีจริงๆ ในวงการเกมให้นึกถึงทีมเอนจินกับทีมเกม ในบทบาทหนึ่งในอดีต แม้แต่ภายในทีมเกมเอง เราก็รับฟีเจอร์ที่ใช้เวลา 6–12 สัปดาห์ไปทำและปล่อย จากนั้นจัดการ maintenance, updates และ technical debt สิ่งที่เพิ่งปล่อยเป็นโฟกัสหลัก แต่ก็ยังมีเวลากลับไปดูงานก่อนหน้า และทีมอื่นก็อยู่ในวงจรเดียวกัน แล้วอีก 6–8 สัปดาห์ค่อย onboard เข้าฟีเจอร์ใหม่ วนแบบนี้ไปเรื่อยๆ
ไม่ได้มองเป็นทีมถาวร แต่ถือเป็น กระแสงาน ที่ผู้คนย้ายไปมาทุก sprint คือทุก 2 สัปดาห์ ช่วงประมาณ 3 เดือนแรกไปได้ดี แต่หลังจากนั้นก็เริ่มไม่เข้ากัน และช่วงนั้นองค์กรก็ใหญ่ขึ้นจนปรับโครงสร้างทีมใหม่ตาม business capability หรือ domain
เอกสารแบบนี้ดีตรงที่ไม่ได้มีไว้ใช้เหมือนคัมภีร์ แต่ช่วยกวาดตามองความรับผิดชอบและประเด็นที่ต้องใส่ใจในภาพกว้าง
ถ้าไม่ได้มีที่ปรึกษาที่ยอดเยี่ยม หรือไม่เคยทำงานใต้คนที่เก่งจริงๆ เมื่อมาถึงตำแหน่งนี้ก็ไม่มีใครมานั่งข้างๆ แล้วบอกลิสต์สิ่งที่ต้องดูแลให้ แต่ละ section ช่วยให้ถามได้ว่า “คำตอบของเราคืออะไร?”, “เราเห็นด้วยไหม?”, “process ของเราดีกว่าไหม?”, “ฉันพลาดอะไรไป?” ซึ่งมีประโยชน์
นึกไม่ถึงว่าเรื่องการแยก “สองทีม” จะถูกเขียนไว้ชัดเจนขนาดนี้ เป็นวิธีที่ยอดเยี่ยมในการทำให้ทีมปล่อยของต่อไปเรื่อยๆ จนกว่าต้นทุนของการปล่อยสิ่งที่พอใช้ได้จะสูงเกินไป
ถ้าตัด feedback loop ที่ย้อนกลับไปหาคนที่สร้างซอฟต์แวร์ขึ้นมา คนเหล่านั้นจะมีความสุขขึ้นชั่วคราว และคนอื่นๆ จะทุกข์ขึ้นชั่วคราว จากนั้นทีมฟีเจอร์ก็จะไม่อยากถูกขัดจังหวะอีกเลย ส่วนทีมลูกค้าก็จะไม่ได้รับทรัพยากรพอที่จะซ่อมอะไรให้ถูกต้อง
ที่แย่กว่านั้นคือทีมฟีเจอร์จะไม่ได้เรียนรู้อะไรเลยนอกจากวิธีปล่อยของออกไปเป็นสาย เหตุผลที่เมื่อเวลาผ่านไปมันช้าลงและแพงขึ้น ก็เพราะได้เอา fitness function เดียวของการพัฒนาซอฟต์แวร์ที่ดีออกไป นั่นคือกระบวนการรวม feedback เชิงลบกลับเข้าไปเป็นแหล่งกำเนิดของการพัฒนา ถ้านี่เป็นคู่มือ leadership สำหรับ CTO จริงๆ ก็ควรพูดให้ชัดว่า “การช่วยให้นักพัฒนาดีขึ้นแม้ในระหว่างที่พวกเขากำลังปล่อยงาน เป็นความรับผิดชอบของคุณ และนักพัฒนาไม่ได้ชอบสิ่งนั้นเสมอไป”
ยังจะเกิด merge conflict ระหว่างทีมฟีเจอร์ที่ฝ่ายขายผลักดัน กับทีม maintenance ที่ฝ่ายดูแลลูกค้าผลักดันด้วย ตราบใดที่ “ทีมลูกค้า” ถูกอธิบายเหมือนเป็นขั้นที่วันหนึ่งจะหลุดพ้นออกมาได้ ก็เดาได้ไม่ยากว่าฝ่ายไหนจะชนะในการแย่ง priority คำว่า “อีกเส้นทางหนึ่งให้วิศวกรแต่ละคน โดยเฉพาะ junior ได้เรียนรู้และเติบโต” สุดท้ายฟังเหมือน “senior ไม่อยากเก็บกวาดขี้ เลยให้ junior ทำ”
ทีมแบบนี้มักดึงดูดคนที่ดูถูกงาน deploy ฟีเจอร์และแก้บั๊ก และอยาก abstract ปัญหามากเกินไป แทนที่จะแก้บั๊ก ก็สร้าง abstraction ที่ซับซ้อนขึ้นเรื่อยๆ โดยอ้างว่าจะทำให้บั๊กไม่เกิดตั้งแต่แรก และผลลัพธ์ก็เดาได้อยู่แล้ว
ลูกค้า โดยเฉพาะลูกค้าที่ไม่ใช่สายเทคนิค มักไม่มีวิสัยทัศน์ผลิตภัณฑ์ที่สอดคล้องกัน และหลายครั้งต้องการแค่การแก้ไขเฉพาะหน้าตอนนี้โดยไม่สนแผนอื่นๆ ลูกค้าแต่ละรายก็ไม่ได้สื่อสารกันเอง ทำให้ feedback ขัดแย้งกันได้ ถ้าเอาภาระนี้ไปวางบน developer นอกจาก developer ต้องมีทักษะทางเทคนิคในการรู้จัก codebase และดูแลมันให้ดีแล้ว ยังต้องจัดการการสื่อสารทั้งหมดด้วย และ developer ทุกคนต้องมีวิสัยทัศน์ที่สอดคล้องกันแบบเดียวกันจึงจะตัดสินใจอย่างรอบคอบได้ ในยุคนี้ที่ developer ยังต้องจัดการ infrastructure ด้วย ก็เท่ากับคนคนเดียวทำงานสองสามอย่างไปแล้ว
ดูเหมือนผู้คนจะชอบวิธีนี้มากกว่าเยอะ เพราะไม่เหนื่อยกับการแก้แต่บั๊กตลอดเวลา และยังหลีกเลี่ยงการตัดขาด feedback ที่คุณพูดไว้อย่างเฉียบแหลมได้ด้วย
ณ จุดนี้ผมสัมภาษณ์มาหลายครั้งจนแทบนับไม่ถ้วนแล้ว เลยค่อนข้างเห็นด้วยได้ยากอยู่บ้าง ความยากอย่างหนึ่งคือ ในขั้นตอนรับใบสมัคร อาจมีผู้สมัครจำนวนมากหรืออาจมากเกินไป และในขั้นตอนนี้โดยปกติทีมสรรหาจะเป็นฝ่ายมีปฏิสัมพันธ์กับผู้สมัคร
การใส่คำถามแบบในตัวอย่างนั้นไม่เป็นไร แต่ถ้าต้องการคัดผู้สมัครที่ไม่มีคุณสมบัติออก จำเป็นต้องมีคำถามที่ไม่ใช่แบบใช่/ไม่ใช่หรือแบบให้คะแนน ผมชอบคำถามที่ง่ายมากและมีคำตอบชัดเจน มีคนจำนวนมากจนน่าตกใจที่ตอบว่า “ถนัดมาก” กับ JavaScript แต่กลับไม่รู้ว่า
===คืออะไร ดังนั้นผมจึงถามคำถามอย่าง “ตัวดำเนินการเท่ากันแบบเข้มงวดของ JavaScript คืออะไร” โปรแกรมเมอร์ JavaScript ทุกคนควรรู้ แต่คำถามเดียวแบบนี้ก็ช่วยคัดผู้สมัครออกไปได้ 50% และประหยัดเวลาขององค์กรได้มหาศาลมีการพูดถึง ความเหมาะสมทางวัฒนธรรม กันมาก แต่ส่วนใหญ่ดูเหมือนเป็นการดึงชั้นของการเลือกปฏิบัติแฝงที่เป็นอันตรายต่อบริษัทขึ้นมา ผมมองว่าความเปิดกว้างทางวัฒนธรรมเป็นปัจจัยแห่งความสำเร็จ ส่วนการเลือกปฏิบัติพาไปในทิศทางตรงกันข้าม
เมื่อเห็นประโยคที่ว่า “ผู้นำที่ดีที่สุดติดตามอัตราความสำเร็จ ไม่กลัวที่จะยอมรับความผิดพลาดในการจ้างงาน และจ้างช้า ไล่ออกเร็ว” ก็ทำให้อยากโพสต์ภาพที่ JWZ (Jamie Zawinski) แสดงเมื่อเขาตรวจพบ referrer header ที่ชี้มายังไซต์นี้ ลองค้นใน Google ดูว่า Jamie Zawinski พูดถึง Y Combinator ว่าอย่างไรได้ เขายังเป็นบุคคลที่มีผลงานสำคัญต่อการตัดสินใจของ Netscape ในการเปิดซอร์ส Netscape Navigator และงานส่วนใหญ่ที่นำไปสู่เอนจินเรนเดอร์ของเบราว์เซอร์นั้นด้วย จึงมี Firefox ในวันนี้
ในที่ทำงานช่วงแรก ๆ แห่งหนึ่ง เราพยายามห้ามทุกอย่างในเกณฑ์การจ้างงานที่อาจเรียกได้ว่าเป็นความเหมาะสมทางวัฒนธรรม ผลคือมีบางคนเข้ามาแล้วเกลียดบริษัททันที และลาออกภายในไม่กี่สัปดาห์หรือไม่กี่เดือน ผู้สมัครคนหนึ่งเน้นเรื่องการวางแผนและความคาดการณ์ได้ และบ่นว่าบริษัทก่อน ๆ เคลื่อนไหวเร็วเกินไป เราเป็นสตาร์ทอัพ และก็เป็นไปตามคาด เขาเกลียดบริษัท แต่ในกระบวนการตัดสินใจจ้างงาน เราไม่สามารถพูดถึงความกังวลนั้นได้ เพราะมองว่าเป็น “ความเหมาะสมทางวัฒนธรรม” และอาจนำไปสู่การเลือกปฏิบัติ หลังจากเกิดเรื่องคล้ายกันอีกสองสามครั้ง นโยบายนั้นก็หายไปอย่างเงียบ ๆ และเราก็กลับมาประเมินความเข้ากันได้กับวัฒนธรรมด้านวิศวกรรมได้อีกครั้ง
“ความเหมาะสมทางวัฒนธรรม” โดยมากคือการแลกเปลี่ยนที่ยอมเสียความหลากหลายทางความคิดไปบางส่วน เพื่อให้ได้ ประสิทธิภาพในการสื่อสารและความไว้วางใจสูง เพราะผู้คนรู้อยู่แล้วว่าควรประพฤติอย่างไร และควรคาดหวังอะไรจากกัน จึงไม่จำเป็นต้องตั้งแนวทางไว้มากนัก แต่ก็จะเปราะบางต่อ groupthink และอคติทางปัญญาที่เกี่ยวข้องมากขึ้น ประมาณว่า “เรือลำนี้มีสีรุ้งครบทุกสี แต่แม้แต่ชาว Klingon ของเราก็ยังคิดว่า Klingon เป็นฝ่ายชั่วร้าย”
ไม่ค่อยแน่ใจว่าคำแนะนำให้ “สร้างคลังวิดีโออธิบาย” เป็นคำแนะนำที่ดีหรือไม่ มันอาจสมเหตุสมผลกับบางอย่างเฉพาะเจาะจง เช่น UI หรือแอนิเมชัน
แต่โดยทั่วไปแล้ว การอ่านข้อความ มีประสิทธิภาพกว่าการดูวิดีโอ เมื่อรีบ การเลื่อนไปยังส่วนสำคัญในข้อความก็ทำได้ง่ายกว่าวิดีโอมาก