- “วิศวกร 10x” ฟังดูเข้าท่าในเชิงสัญชาตญาณ แต่ในความเป็นจริงการวัด ประสิทธิภาพการทำงาน อย่างเป็นกลางนั้นยากมาก และการมองมันเป็น คุณลักษณะส่วนบุคคลที่คงที่ไม่เปลี่ยนแปลง ก็เป็นแนวทางที่ผิด
- ความเป็นเจ้าของและผลลัพธ์ที่แท้จริง ของซอฟต์แวร์ถูกกำหนดโดยความร่วมมือและความสามารถในระดับ ทีมวิศวกรรม
- องค์กรที่ ยอดเยี่ยมจริงๆ ไม่ใช่แค่มีคนที่โดดเด่นเป็นพิเศษเท่านั้น แต่คือที่ที่สร้างสภาพแวดล้อมให้ วิศวกรธรรมดา สร้างผลลัพธ์ที่ดีได้อย่างสม่ำเสมอ
- ระบบควรถูกออกแบบโดยคำนึงว่าคน ธรรมดา อาจทำผิดพลาดหรือเหนื่อยล้าได้ และควรโฟกัสกับการสร้าง “ทีม 10x”
- การออกแบบระบบซอฟต์แวร์และวัฒนธรรมควรตั้งอยู่บนพื้นฐานของคุณลักษณะ ความหลากหลาย และศักยภาพในการเติบโตของ “คนธรรมดา”
- ท้ายที่สุด ตัวชี้วัดหลักของประสิทธิภาพการทำงานคือผลกระทบต่อธุรกิจ และสิ่งสำคัญคือการจ้างและจัดทีมด้วย “คนที่เหมาะสม” ไม่ใช่ “คนเก่งที่สุด”
ยกย่องวิศวกร “ธรรมดา”
- บทความนี้วิจารณ์แนวคิดเรื่อง “วิศวกร 10x” และอธิบายความสำคัญขององค์กรที่ทำให้วิศวกรธรรมดาสร้างผลงานระดับทีมที่ยอดเยี่ยมได้
ตำนาน “วิศวกร 10x” และข้อจำกัดของมัน
- ทุกคนล้วนเคยพบ วิศวกรที่ไม่ธรรมดา ราวกับพ่อมดในช่วงหนึ่งของเส้นทางอาชีพ
- จากสิ่งนี้จึงเกิดแนวคิดเรื่อง “วิศวกร 10x” ขึ้นมา แต่แนวคิดนี้มีหลักฐานรองรับน้อย และยังอาจตอกย้ำ อคติ ด้วย
- แทบเป็นไปไม่ได้เลยที่จะกำหนด มาตรวัดเดียว สำหรับประสิทธิภาพการทำงาน
- มีการผสมกันอย่างไร้ขีดจำกัดของตัวแปรอย่าง tech stack, โดเมน, ระยะของการพัฒนา, สถานการณ์ตลาด, ประสบการณ์ และอื่นๆ
- คนคนหนึ่งอาจเป็นวิศวกร 10x ในบางด้าน แต่ในพื้นที่ส่วนใหญ่ก็อาจ ธรรมดา หรือแม้แต่ต่ำกว่าค่าเฉลี่ยได้
- แม้ครั้งหนึ่งเคยเป็น DBRE ที่ยอดเยี่ยม แต่เมื่อเวลาผ่านไปก็อาจกลายเป็นคนระดับ ธรรมดา ในด้านนั้นได้
- สุดท้ายแล้ว ไม่มีใครเก่งกว่าคนอื่น 10 เท่าได้ตลอดเวลาในทุกด้าน
ความเป็นเจ้าของซอฟต์แวร์ที่ยึดทีมเป็นศูนย์กลาง
- ซอฟต์แวร์เป็นสิ่งที่ ทีม เป็นเจ้าของและดูแล ไม่ใช่ความรับผิดชอบของคนคนเดียว
- กระบวนการทั้งหมดตั้งแต่การส่งมอบ การบำรุงรักษา การปรับปรุง การขยายระบบ ไปจนถึงการรีแฟกเตอร์ ล้วนเกิดขึ้นในระดับ ทีม
- ระบบที่มีคนคนเดียวเป็นเจ้าของจะกลายเป็น จุดล้มเหลวเพียงจุดเดียว (SPOF) หากคนนั้นลาพักหรือย้ายงาน และกลายเป็นจุดอ่อนขององค์กร
- ในสตาร์ตอัปช่วงแรก ความเป็นเจ้าของโดยบุคคลอาจหลีกเลี่ยงไม่ได้ แต่เมื่อองค์กรเติบโต ก็ต้องเปลี่ยนไปสู่ ความเป็นเจ้าของโดยทีม ให้ได้
- ภารกิจหลักของผู้นำสายวิศวกรรมคือต้องโฟกัสกับการสร้าง ทีมประสิทธิภาพสูง และการสร้าง ทีม 10x สำคัญกว่าการมี “วิศวกร 10x”
เงื่อนไขขององค์กรที่มีผลงานสูงอย่างแท้จริง
- หลายบริษัทชอบสร้างทีมจากคนที่มาจาก FAANG มหาวิทยาลัยชั้นนำ หรือ Staff Engineer เป็นหลัก
- แต่องค์กรที่ดีจริงคือที่ที่ วิศวกรธรรมดา สามารถสร้างผลกระทบที่มีความหมายได้อย่างมั่นคง
- ความได้เปรียบในการแข่งขันที่แท้จริงไม่ใช่องค์กรที่มีแต่ “คนเก่งที่สุด” จึงจะทำผลงานได้ แต่คือการสร้าง ระบบที่ทำให้นักพัฒนาทั่วไปเติบโตอย่างมีเจ้าของงาน และส่งผลเชิงบวกต่อผลิตภัณฑ์และธุรกิจได้
- กลับกัน องค์กรแบบนี้ต่างหากที่สร้าง วิศวกรระดับเวิลด์คลาส ได้มากกว่า
นิยามใหม่ของความ “ธรรมดา”
- วงการซอฟต์แวร์เต็มไปด้วยแนวคิดแบบชนชั้นนำ เช่น “10% แรก”, “top .1%”
- แต่สิ่งสำคัญคือการยอมรับว่าวิศวกรส่วนใหญ่คือ คนธรรมดา ที่เติบโตผ่านประสบการณ์และการฝึกฝนที่หลากหลาย
- ไม่มีใครเกิดมาเป็น “วิศวกรที่ยอดเยี่ยม” โดยกำเนิด
- วิศวกรที่ยิ่งใหญ่ถูกสร้างขึ้น - ทุกคนสามารถเก่งได้ผ่านการเรียนรู้และประสบการณ์
การออกแบบระบบเพื่อคนธรรมดา
- ในการจ้างงาน การมองหา จุดแข็งที่โดดเด่น เป็นเรื่องถูกต้อง แต่เมื่อต้องออกแบบระบบ เราต้องคำนึงถึงความจริงที่ว่าผู้คน ธรรมดาๆ สามารถทำผิด เหนื่อยล้า และยึดติดกับความคุ้นชินได้
- วิศวกรทั่วไปได้รับผลกระทบจาก อคติทางความคิด ความเหนื่อยล้า และความแปรปรวนทางอารมณ์
- หากระบบถูกออกแบบมาให้เหมาะกับมุมมองของ วิศวกรธรรมดา ไม่ใช่คนฉลาดเพียงหยิบมือ ความสามารถเชิงสร้างสรรค์ของคนเก่งก็จะไปโฟกัสที่ ตัวผลิตภัณฑ์เอง ได้มากขึ้น
วิธีสร้าง “ทีม 10x”
- ลดระยะห่างระหว่างการเขียนโค้ดกับการ deploy ให้มากที่สุด
- วงจร deploy ที่รวดเร็วช่วยลดภาระทางความคิด และทำให้ทดลองและรับ feedback ได้เร็วขึ้น
- ยิ่ง deploy ช้า การเปลี่ยนแปลงหลายอย่างก็ยิ่งถูกรวมเข้าด้วยกัน ทำให้ติดตามปัญหาและ rollback ได้ยาก
- ทำให้การกู้คืนจากความผิดพลาดและการ rollback เป็นเรื่องง่าย
- นักพัฒนาควร deploy โค้ดเองได้ และเมื่อพบปัญหาก็ควรกู้คืนได้อย่างรวดเร็ว
- ทำให้พฤติกรรมที่ถูกต้องทำได้ง่าย และพฤติกรรมที่ผิดทำได้ยาก
- ร่วมมือกับดีไซเนอร์และวิศวกรแพลตฟอร์ม เพื่อสร้าง guardrail และระบบ self-service
- ลงทุนอย่างจริงจังกับ observability และเครื่องมือวัดผล
- ทำให้การทำงานจริงของโค้ดมองเห็นได้ เพื่อช่วยให้วิศวกรทุกคนเข้าใจระบบและ debug ได้ง่าย
- ลงทุนทรัพยากรวิศวกรรมกับเครื่องมือภายในและการเพิ่มผลิตภาพ
- ระบบเหล่านี้ต้องการ ownership แยกต่างหาก และควรเป็นลำดับความสำคัญระดับทั้งองค์กร
- สร้างวัฒนธรรมที่เปิดกว้างและครอบคลุม
- เป็นสภาพแวดล้อมที่ทุกคนสามารถถาม ทำผิดพลาด และสำรวจได้
- ทีมที่มีความหลากหลายทั้งด้านภูมิหลัง ทักษะ และประสบการณ์ จะมี ความยืดหยุ่นฟื้นตัว มากกว่า และรับมือกับการเปลี่ยนแปลงได้ดีกว่า
- จัดทีมที่ผสมวิศวกรทุกระดับเข้าด้วยกัน
- ตั้งแต่ junior ถึง senior ได้เรียนรู้และสอนกันไป พร้อมเติบโตไปด้วยกัน
- ระบบแบบนี้ยังนำกลับมาใช้ได้กับการ onboard พนักงานใหม่ หรือการย้ายข้ามทีม
มาตรวัดที่แท้จริงของประสิทธิภาพการทำงาน: “ผลกระทบต่อธุรกิจ”
- ท้ายที่สุดแล้ว มาตรวัดประสิทธิภาพการทำงานของวิศวกรรมซอฟต์แวร์คือผลกระทบต่อธุรกิจ
- แก่นแท้ไม่ใช่การเขียนโค้ดให้มาก แต่คือ การแก้ปัญหาและสร้างคุณค่า
- ในความเป็นจริง คนที่ขับเคลื่อนอุตสาหกรรมไม่ใช่วิศวกรระดับ Staff+ แต่คือ วิศวกรระดับ senior และ mid-level
- คนกลุ่มนี้เป็นฐานขององค์กร และขับเคลื่อนธุรกิจไปข้างหน้าอย่างต่อเนื่อง
- หากมีแต่ระดับ Staff+ เท่านั้นที่สร้าง impact ได้ นั่นคือสัญญาณว่าองค์กรมีปัญหา
องค์กรที่สร้างวิศวกรระดับเวิลด์คลาส
- องค์กรที่ดีจริงคือองค์กรที่แม้ไม่ใช่วิศวกรที่โดดเด่น ทุกคนก็ยังสร้าง impact ได้
- องค์กรที่ดีที่สุด ไม่จำเป็นต้องคัดเลือกแต่คนระดับโลกเป็นพิเศษ แต่กลับสร้าง วิศวกรระดับเวิลด์คลาส ได้มากที่สุดอย่างเป็นธรรมชาติ
- คนเก่งจะมารวมตัวกันในที่ที่วิศวกรสามารถทุ่มเทให้กับ การแก้ปัญหา การเติบโต และ impact และ “ประสบการณ์ของการทำงานอย่างมีความสุขและเติบโต” เองก็สร้างวงจรเชิงบวก
- ผู้นำต้องไม่พึ่งพา ความสามารถเฉพาะตัว ของคนเก่ง แต่ต้องเชื่อมมันเข้ากับการเติบโตของทั้งองค์กรและคุณค่าที่ส่งมอบให้ลูกค้า
จ้าง “คนที่เหมาะสม” มากกว่า “คนเก่งที่สุด”
- วงการมักพยายามมองหาแต่ “ที่สุด” แต่สิ่งที่สำคัญจริงๆ คือ ระบบและสภาพแวดล้อม
- มากกว่า “คนเก่งที่สุด” การหา คนที่เหมาะกับทีมและองค์กร คือความได้เปรียบในการแข่งขันที่สำคัญกว่า
- แทนที่จะมองหาคนที่ไร้จุดอ่อน การสร้างทีมจาก “คนที่เหมาะสม” ซึ่งมีจุดแข็งเฉพาะตัวและช่วยเสริมความหลากหลายกับความกลมกลืนขององค์กร มีประสิทธิภาพมากกว่า
- ทีมที่เปิดกว้างและหลากหลายสามารถขับเคลื่อน ผลงาน การเติบโต และความสำเร็จระยะยาว ได้จริง
- ที่ที่ทุกคน สนุกกับงาน เติบโต และสร้างผลลัพธ์ที่มีความหมาย คือองค์กรระดับโลกที่แท้จริง และในวัฒนธรรมที่แม้แต่ความล้มเหลวหรือความผิดพลาดก็ยังเรียนรู้ได้ ทั้งวิศวกรและองค์กรจะเติบโตไปพร้อมกัน
- องค์กรแบบนี้เองที่ดึงดูด วิศวกรรุ่นถัดไป และเป็นสภาพแวดล้อมที่คนเก่งที่มีอยู่แล้วก็อยากอยู่ต่อ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ผมเห็นด้วยกับแนวคิดที่บอกว่าหน่วยขั้นต่ำของการเป็นเจ้าของซอฟต์แวร์และการส่งมอบคืองานของทีมวิศวกรรม แต่ก็รู้สึกเสียดายนิดหน่อย โครงสร้างแบบนี้เชื่อมโยงกับวัฒนธรรมที่ทำให้วิศวกรเป็นพลเมืองชั้นสองเมื่อเทียบกับผู้จัดการหรือฝ่ายโปรดักต์ เรามีหน้าที่รับผิดชอบแค่การส่งมอบเท่านั้น และไม่สามารถตัดสินใจเรื่องที่มีความหมายจริง ๆ ได้อย่างอิสระเกินขอบเขตเล็กมากของทีม ในทีมที่ดีที่สุด ระยะเวลาของดุลยพินิจอาจยาวหลายเดือนหรือแม้แต่หลายปี แต่ในทีมส่วนใหญ่กลับหดเหลือแค่ไม่กี่วันหรือไม่กี่สัปดาห์ ทั้งที่ในความเป็นจริง การจัดโครงสร้างให้วิศวกรมี ownership อย่างแท้จริงโดยที่ระบบไม่พังหรือเสี่ยงเกินไปในระยะยาวนั้นเป็นไปได้เต็มที่ เคล็ดลับคือการเผื่อ slack เอาไว้ สนับสนุนงานที่มีคุณภาพ และให้เสรีภาพมากพอจนใครก็ตามในทีมสามารถสลับงานกันได้อย่างยืดหยุ่น แต่ละคนมี ownership และตัดสินใจระยะยาวได้ ขณะเดียวกันก็ร่วมมือกันแบบ ad hoc และแชร์ความรู้ฝังลึก ทำให้เกิดสถานการณ์ที่ใครสักคนจะเข้ามาช่วยกะทันหันหรือรับช่วงต่อทั้งหมดก็เป็นเรื่องธรรมชาติ จากประสบการณ์จริง ทีมแบบนี้มี rewrite มากกว่าทีมทั่วไป แต่โดยรวมแล้ว productive กว่ามาก การ rewrite ระบบทีละส่วนเล็ก ๆ อย่างค่อยเป็นค่อยไปมีประสิทธิภาพมากทั้งต่อการวิวัฒน์ของดีไซน์และการสะสมความรู้กับความสามารถในองค์กร ภายนอกอาจดูเหมือนสิ้นเปลือง แต่จริง ๆ แล้วมันคือ slack ที่จำเป็นต่อการทำให้องค์กรทั้งหมดยืดหยุ่นและฟื้นตัวได้ดี ตรงกันข้าม ผมยิ่งมั่นใจขึ้นเรื่อย ๆ ว่าหลายกระบวนการแบบ top-down ที่พยายามลดสิ่งที่เรียกว่า waste นั้น จริง ๆ แล้วกำลังกำจัด ‘slack’ ที่สำคัญออกไป
คนที่อยู่นอกสายวิศวกรรมมักประเมินการตัดสินใจระยะยาวของวิศวกรในทันทีไม่ได้ และมักไม่รู้ว่าควรให้รางวัลแบบไหน เรื่องนี้แม้แต่ข้ามไปนอกทีมวิศวกรเดียวกันก็ยังเป็นเหมือนกัน เพราะพวกเขาไม่มีความสามารถจะประเมินได้โดยตรงว่างานระยะยาวที่มีคุณค่าภายในนั้นมีคุณค่าจริงหรือไม่ ถ้าคุณมั่นใจในความสามารถของตัวเองด้านการตัดสินใจระยะยาวและการใช้ slack time การได้รับรางวัลจากการส่งมอบก็ไม่ใช่ปัญหา เพราะวันหนึ่งงานระยะยาวเหล่านั้นจะกลับมาเป็นผลลัพธ์ที่ดีกว่าเอง
ผมคิดว่า software rewrite มีบทบาทสำคัญในกระบวนการพัฒนา ‘Agile’ ที่แท้จริงคือการไม่หมกมุ่นกับสถาปัตยกรรมแรกมากเกินไป แต่สร้าง prototype ให้เร็วเพื่อรับมือกับการเปลี่ยนแปลงของ requirement ได้อย่างยืดหยุ่น การเขียนโค้ดคล้ายกับการเขียนหนังสือ ร่างแรกอาจหยาบก็จริง แต่การเขียนออกไปก่อนแล้วค่อยปรับปรุงในเวอร์ชันที่สองมีประสิทธิภาพกว่ามาก จุดประสงค์ของร่างแรกไม่ใช่ให้ดี แต่คือการสร้างอะไรบางอย่างให้เร็ว เพื่อสำรวจ problem space และค้นหา edge case วิธีทำงานแบบนี้มักไม่เวิร์กกับผู้บริหาร พอเห็น prototype ที่ใช้งานได้ก็มักพูดว่า ‘งั้นปล่อยขึ้นโปรดักชันเลย’ และไม่ให้เวลา rewrite ทางออกคือน่าจะทำลำดับชั้นขององค์กรให้แบนลง และคืน ownership ของโค้ดให้วิศวกรอย่างแท้จริง โครงสร้างที่วิศวกรกับ product owner ตัดสินใจร่วมกันอย่างเป็นประชาธิปไตยน่าจะเหมาะสมกว่า
ครั้งหนึ่งผมก็เคยให้ความสำคัญกับ ‘ownership รายบุคคล’ และตอนนี้ก็ยังเชื่อว่าวิศวกรสามารถมี ownership ได้ แต่ก็ยอมรับว่าจริง ๆ แล้ววิศวกรจำนวนมากไม่ได้ต้องการสิ่งนั้น วิศวกรส่วนใหญ่โอเคถ้าเป็น ownership ระดับทีม แต่ไม่ค่อยสนใจ ownership ระดับบุคคล มันก็เป็นแค่งานหาเลี้ยงชีพเท่านั้น ถ้าปล่อยให้เป็นเรื่องของแต่ละคน มันมักก่อให้เกิดความไม่ไว้วางใจกันในทีม หรือทำให้สมาชิกที่ไม่มีนิสัยแบบผู้นำถูกกันออกไป สุดท้ายก็มักลงเอยด้วยการที่ไม่มีใครมีดุลยพินิจจริง ๆ โครงสร้างที่ให้ ownership และดุลยพินิจในระดับทีมนั้นง่ายกว่าและได้ผลกว่ามาก และยังเป็นพลวัตที่เกิดขึ้นได้เพราะมีหัวหน้าทีมหรือผู้จัดการด้วย ถ้าให้ ownership ซอฟต์แวร์แบบรายบุคคล ความเสี่ยงที่จะล้มเหลวจากการเปลี่ยนคน ความเสถียร และเรื่องอาชีพนั้นมีมากเกินไป ต่อให้องค์กรสุขภาพดีแค่ไหนก็ย่อมมีปัญหาเล็กใหญ่ และในโครงสร้างแบบนี้ เส้นทางไปสู่ความล้มเหลวจะสั้นที่สุด ลองนึกถึงกระปุกเกียร์ ถ้ามีเกียร์เดียวแล้วพัง ก็ไปต่อไม่ได้ แต่ถ้ามีหลายเกียร์ ถึงจะไม่สะดวกก็ยังพอไปต่อได้แม้จะมีตัวหนึ่งเสีย
ผมคิดว่าการมี ownership รายบุคคลอย่างแท้จริงนั้นเป็นไปได้จริง และอาจเป็นวิธีเดียวด้วยซ้ำที่จะ ‘productive’ ได้จริง แต่ประเด็นนี้ไม่ใช่แก่นแท้ของเรื่อง แต่ละคนไม่สามารถแทนกันได้ แต่สมาชิกทีมอาจแทนกันได้บ้างขึ้นอยู่กับโครงสร้าง ยิ่งองค์กรใหญ่ขึ้นก็ยิ่งต้องการความคาดเดาได้ในระดับทีม และเพื่อให้ได้แบบนั้นก็จำเป็นต้องมีความสามารถในการทดแทนสมาชิกกันได้อยู่บ้าง หรือก็คือ redundancy ในวิศวกรรมเองเราก็ใช้ redundancy เพื่อความน่าเชื่อถือและความทนทาน ดังนั้นประสิทธิภาพจึงเป็น trade-off กับการลด redundancy
เราทำงานอยู่ในโครงสร้างที่พูดเหมือนว่าเรารับผิดชอบแค่ 'delivery' เท่านั้น ซึ่งทำให้คำว่า ownership กลายเป็นแค่ภาระเพิ่มโดยไม่มีรางวัลจริง งานก็ถูกจำกัดเหลือเพียงการแปะฟีเจอร์ลงบนหน้าเพจ ถ้ามีความรับผิดชอบเพิ่มขึ้น ก็ควรมีค่าตอบแทนเพิ่มตามนั้น ผู้จัดการหรือผู้บริหารได้รับค่าตอบแทนมากขึ้นตามจำนวนคนที่รับผิดชอบ นักพัฒนาก็ควรเป็นแบบเดียวกัน
ผมเชื่อมั่นว่าทีมที่ดีที่สุดคือทีมที่มีวัฒนธรรมซึ่งทำให้วิศวกรธรรมดาสร้างผลงานมหาศาลได้ สิ่งที่สำคัญกว่าสิ่งที่คนชอบเรียกว่า ‘engineering quality’ หรือการจ้างคนเก่ง คือวัฒนธรรม ความไว้วางใจ ระบบ และกระบวนการ มีคำพูดว่า “ใคร ๆ ก็สร้างองค์กรที่มีวิศวกรระดับท็อปได้” แต่ในความเป็นจริง องค์กรที่สร้างทีมแบบนั้นได้มีน้อยมาก ส่วนใหญ่แทบจะเป็นบริษัทเทรดดิ้งหรือองค์กรเฉพาะทาง/วิจัย ผมสงสัยจริง ๆ ว่าทำไมคนอื่นถึงทำไม่ได้ สุดท้ายแล้วแม้แต่คำว่า "productivity" เองก็ยังไม่ชัดเจนว่าหมายถึงอะไร บางระบบประเมินดูแค่ว่าใครทนและฝ่าฟัน dysfunction ในองค์กรได้เก่ง แต่ผมไม่คิดว่านั่นคือความหมายที่แท้จริงของ ‘วิศวกรระดับท็อป’
อุปทานของวิศวกรที่เก่งจริงนั้นมีจำกัด สุดท้ายบริษัทที่ใหญ่กว่าก็มักดึงคนกลุ่มเดียวกันไปด้วยงานที่น่าสนใจกว่าหรือเงินเดือนที่สูงกว่า
เรื่องเงินอย่างที่คนอื่นพูดก็สำคัญมาก แต่ ‘เวลา’ ก็สำคัญมากเช่นกัน บริษัทไม่ได้มีเวลารอจนกว่าจะเจอคนเก่งระดับ “ยูนิคอร์น” ที่สมบูรณ์แบบ จึงจำเป็นต้องรีบเติมตำแหน่งด้วยคนที่พอจ้างได้ทันที ในบางบริษัท โดยเฉพาะสาย quant finance ซูเปอร์วิศวกรคนหนึ่งที่ครอบคลุมทั้ง system programmer, นักคณิตศาสตร์ และผู้เชี่ยวชาญตลาดการเงิน อาจสร้างมูลค่าได้มากกว่าทีมผู้เชี่ยวชาญสามคนรวมกัน แต่การหาคนแบบนั้นใช้เวลามากเกินไป แม้แต่งานเว็บดีเวลอปเมนต์เอง คนที่เป็น ‘full-stack’ จริง ๆ ซึ่งเข้าใจรอบด้านตั้งแต่ network protocol, system admin, distributed systems, database ไปจนถึง frontend นั้นมีน้อยมาก มีแค่องค์กรที่มีเวลาและงบประมาณเพียงพอเท่านั้นที่จะรวบรวมคนแบบนี้มาสร้างผลิตภัณฑ์ที่ดีที่สุดได้ แน่นอนว่าคำถามแยกต่างหากคือผลิตภัณฑ์นั้นจำเป็นต้องมีคุณภาพระดับนั้นจริงหรือไม่
โดยพื้นฐานแล้ว อุปทานของ “วิศวกรที่ดีที่สุด” ทั่วโลกมีจำกัดอย่างยิ่ง ถ้าคุณจ่ายได้ในระดับเงินเดือน top 10% และสามารถรวบรวมกับรักษาคนระดับนั้นไว้ได้ ก็นับว่าประสบความสำเร็จแล้ว ความจริงไม่ใช่ว่า ‘ใครก็ทำได้’ แต่ต้องมีภาวะผู้นำที่ออกแบบ sociotechnical system โดยมุ่งเน้นการเรียนรู้และการเติบโตของผู้คนอย่างแท้จริง ซึ่งแค่นั้นก็เป็นงานที่ยอดเยี่ยมมากแล้ว
ปัญหาใหญ่ที่สุดคือผู้บริหารระดับต้นถึงกลางส่วนใหญ่ไม่ได้เก่งขนาดนั้น พวกเขาขาดความสามารถในการสร้างและรักษาสภาพแวดล้อมที่ productive ทางแก้ในระดับรากฐานสุดท้ายก็คือ ‘จ่ายเงิน’ ให้มากพอ ถ้าเงินมากพอ คนส่วนใหญ่ก็พร้อมจะทนกับเงื่อนไขที่ยากลำบากได้
ต่อให้งบไม่ใช่ปัญหา วิศวกรที่เก่งมากจริง ๆ ก็อาจไม่เหมาะกับการเล่นเป็นทีมเสมอไป สมองที่ยอดเยี่ยมบางครั้งกลับกลายเป็นอุปสรรคต่อการประนีประนอมที่จำเป็น หรือกับงานน่าเบื่อแต่จำเป็น
ผมไม่ค่อยเห็นด้วยกับคำกล่าวที่ว่า “ผลกระทบทางธุรกิจคือมาตรวัด productivity เพียงหนึ่งเดียว” มุมมองแบบนี้ทำให้สายตาไปอยู่กับการเปลี่ยนแปลงที่วัดได้และผลระยะสั้น จนพลาดคุณค่าที่แท้จริงของวิศวกรที่มีประสบการณ์ คนที่เก่งจริงคือคนที่ป้องกัน landmine ที่อาจเกือบทำให้โปรเจกต์หรือบริษัทพังได้ล่วงหน้า แต่ ‘ความเสี่ยงที่หายไป’ แบบนี้วัดยากมาก และแทบเป็นไปไม่ได้เลยที่จะสื่อสารให้ฟังดูธรรมดา
“impact” ไม่จำเป็นต้องเป็นมุมมองระยะสั้น คนที่สร้าง impact สูงสุดต่อองค์กรคือคนที่เคลื่อนไหวจากมุมมองระยะยาว
ผมตั้งใจใช้คำอย่าง ‘productivity’ หรือ ‘impact’ ให้คลุมเครืออยู่บ้าง เช่นพูดว่า “โดยรวมแล้ว X ทำงานได้ดีมาก” มันเป็นสิ่งที่ทำให้เป็นตัวเลขหรือเขียนกฎให้ชัดเจนได้ยาก แต่ในองค์กรที่ซับซ้อนและสร้างสรรค์นั้น เดิมทีการหยั่งรู้และการตัดสินของมนุษย์สำคัญกว่าอยู่แล้ว การพยายามทำให้การบริหารเป็นตัวเลขไปหมดนั้นโดยพื้นฐานแล้วสายตาสั้น
ผมไม่เห็นด้วยกับการวัดคุณค่าวิศวกรแค่เรื่องการบริหารโปรเจกต์หรือการหลีกเลี่ยงความเสี่ยง แต่ก็อึดอัดกับการลดทอนทุกอย่างให้เหลือแค่ ‘business impact’ ในโลกนี้มีงานที่มีความหมายต่อปัจเจก มนุษยชาติ และโลกมากมายที่ไม่เกี่ยวกับเงิน วิศวกรที่ผมเคารพที่สุดไม่ใช่บุคคลระดับตำนานแห่ง Silicon Valley หลังปี 2001 แต่เป็น John von Neumann, Robert Oppenheimer, Nikola Tesla, Leonardo da Vinci, ใครก็ตามที่สร้างท่อส่งน้ำของโรมันและพีระมิดอียิปต์ รวมถึงนักดาราศาสตร์แห่งบาบิโลน-เมโสอเมริกา พวกเขาทิ้ง business impact ไว้หรือเปล่า? ต่อให้ Tesla เคยทำกำไรให้ Westinghouse อยู่ช่วงหนึ่ง นั่นก็ไม่ได้อธิบายความสำเร็จของเขา ที่จริงในเชิงธุรกิจเขาค่อนข้างธรรมดาด้วยซ้ำ บรรดายักษ์ใหญ่ของอุตสาหกรรมคอมพิวติ้งยุคใหม่ก็เช่นกัน ความสำเร็จมหาศาลของ Nvidia หรือ Geoff Hinton ก็มีส่วนจาก ‘โชค’ ที่อินเทอร์เน็ตถูกทำให้เป็นแพลตฟอร์มโฆษณาและข้อมูลเพิ่มขึ้นมหาศาลด้วย ยังมีอีกมากที่คนเก่งจริงถูกมองข้ามและหายไป เช่น Doug Lenat ผู้ยิ่งใหญ่ในวงการ AI ที่สุดท้ายก็ไม่ได้ถูกค้นพบเพราะกระแสประวัติศาสตร์ ความสำเร็จในหลายกรณีไม่ได้เกี่ยวกับความพยายามของปัจเจกมากนัก
ทางเลือกคือจะสร้างระบบที่มีประสิทธิภาพ หรือสร้างระบบที่ลดโอกาสเกิดหายนะให้ต่ำที่สุด การพิสูจน์ว่าหายนะไหนถูกป้องกันไว้จริงนั้นยากมาก และเพราะผลกระทบเชิงลบคือ ‘เหตุการณ์ที่ไม่ได้เกิดขึ้น’ จึงยิ่งแสดงเป็นผลลัพธ์ได้ยาก
บริษัทควรพยายามหาวิธีทำให้ความเสี่ยงของ ‘สิ่งที่ยังไม่รู้’ ถูกทำให้เป็นปริมาณได้ดีขึ้นไม่ทางใดก็ทางหนึ่ง
โชคดีที่จนถึงตอนนี้ผมได้ทำงานกับหลายทีมที่ยอดเยี่ยม และตอนนี้ก็กำลังนำทีมแบบนั้นอยู่ ตรงข้ามกับที่บทความว่าไว้ ยิ่งเป็นทีมแบบนี้ องค์กรมักยิ่งบริหารยาก องค์กรขนาดใหญ่มักโฟกัสกับการทำให้เป็นมาตรฐาน จนวิศวกรที่เก่งกลับแสดงศักยภาพไม่ได้และหมดแรงจูงใจ ผมไม่เห็นด้วยกับมุมมองในแง่ร้ายที่ว่าคนทุกคนไม่สามารถถูกพัฒนาให้เป็นวิศวกรที่ยอดเยี่ยมได้ จากประสบการณ์จริง ถ้าลงทุนอย่างต่อเนื่องก็สามารถพัฒนาให้เป็นวิศวกรที่ยอดเยี่ยมได้ และในระยะยาว ผลประโยชน์จากการมี talent pool ที่แข็งแกร่งขึ้นนั้นคุ้มค่าเกินต้นทุนการลงทุนมาก
แค่เพราะวัดได้อย่างมีประสิทธิภาพไม่ได้ ก็ไม่ได้แปลว่าสิ่งนั้นไม่มีอยู่จริง productivity รายบุคคล หรือก็คือผลงานการทำงานของแต่ละคนนั้นมีอยู่แน่นอน เพียงแต่ productivity ระดับกลุ่มอาจวัดได้ง่ายกว่า “business impact” กลับเป็นสิ่งที่ยิ่งตามอำเภอใจมากกว่าเสียอีก และถ้าใช้มาตรวัดแบบนั้น การรักษาคนที่ productive จริงไว้จะยากมาก การประเมินความรู้เฉพาะทางนั้นยากมากหากไม่มีประสบการณ์ในระดับเดียวกัน คุณอาจให้คำแนะนำได้ แต่คนฟังจะมีพื้นที่ทางปัญญาพอจะรับมันหรือไม่ก็เป็นอีกเรื่อง แล้วเราจะรู้ได้อย่างไรว่าผมเป็นอัจฉริยะ หรือเป็นแค่คนที่มั่นใจเกินเหตุ
ปัญหาไม่ใช่ว่าเรา ‘วัด’ productivity ไม่ได้ แต่คือเราอธิบายมันเป็นนามธรรมให้ ‘นิยาม’ ได้ด้วยซ้ำไม่ได้ ต่อให้วัดแค่ว่ามีส่วนเพิ่มเหนือ “replacement” เท่าไร ก็ไม่ได้อธิบายว่าผลลัพธ์นั้นเกิดขึ้นอย่างไรจริง ๆ ในความเป็นจริง อิทธิพลของปัจเจกถูกกำหนดโดยบริบทและทั้งองค์กร แม้จะพยายามให้นิยามที่ตรงกว่านี้ คำตอบก็แตกต่างกันสุดขั้วไปตามองค์กรและสถานการณ์ เรื่องนี้คุ้มค่าจะคิดต่อ แต่ตัวมาตรฐานอย่างวิศวกร ‘Top 1%’ เองมีความหมายจริงหรือไม่ก็ยังน่าสงสัย
อัจฉริยะที่แท้จริงสามารถอธิบายผลลัพธ์ของตัวเองได้อย่างเข้าใจง่ายและรักษามารยาท ดังนั้นผมคิดว่าความแตกต่างนั้นแยกออกได้ชัดพอสมควร
ผมชอบประโยคที่ว่า “องค์กรที่ดีที่สุดคือองค์กรที่ทำให้วิศวกรธรรมดาทำงานอันยิ่งใหญ่ได้” ไม่จำเป็นที่ทุกคนในทีมต้องเป็นซูเปอร์สตาร์ สิ่งที่สำคัญจริง ๆ คือการสนับสนุนให้คนพัฒนาระดับกลางสามารถแสดงความสามารถที่ดีและเชื่อถือได้ออกมาอย่างเต็มที่
หลักการที่ว่า “ทำให้สิ่งที่ถูกต้องเป็นเรื่องง่าย และทำให้สิ่งที่ผิดเป็นเรื่องยาก” เหมือนกับสโลแกนหลักของทุกทีมแพลตฟอร์มที่ผมเคยเจอ เป้าหมายคือออกแบบระบบให้ ‘คำตอบที่ถูกต้อง’ สำหรับปัญหาที่วิศวกรเจอนั้นเด่นชัดโดยอัตโนมัติและนำไปใช้ได้ง่าย เมื่อมีทั้งความน่าเชื่อถือและความง่ายต่อการดูแลรักษา จนค่อย ๆ สร้าง ‘กล้ามเนื้อ’ การพัฒนาไปในทิศทางนั้นเอง องค์กรทั้งระบบก็จะได้ประโยชน์ ความจริงข้อนี้จะยังใช้ได้ต่อไปอีกนาน
ทุกครั้งที่มีการพูดถึงภาษา/เฟรมเวิร์กหลากหลายอย่าง golang, python, COBOL, lisp, perl, React, brainfuck ผมรู้สึกมานานแล้วว่ามีแนวโน้มจะเข้าใจผิดว่า React คือระบบนิเวศ frontend ทั้งหมด ทั้งที่จริงแล้วนอกจาก React ก็ยังมีโลกของ frontend ที่หลากหลายอีกมาก แต่ดูเหมือนทุกคนคิดว่า React คือทั้งหมด
ที่บริษัทเรา เรามักชอบจ้างวิศวกรระดับกลางที่ทัศนคติดีมากกว่า คนที่คุณสมบัติยอดเยี่ยมแต่ทัศนคติแย่ มักเก่งเรื่องสร้างภาพลักษณ์จนได้รับความไว้วางใจจากผู้บริหารระดับบนได้ง่าย แล้วหลังจากนั้นก็กลายเป็นคนที่ไม่มีใครแตะต้องได้ เมื่อคนแบบนี้ปักหลักได้แล้ว คนรอบข้างถึงจะคับข้องใจก็ยากจะยกปัญหาขึ้นมา ผู้บริหารเองก็มักเมินข้อมูลที่ไม่ตรงกับภาพในหัวได้ง่าย เพราะการพึ่งพาการรับรู้ของตัวเองมันง่ายกว่าการดูข้อมูลเชิงวัตถุวิสัยมาก
ผมเห็นด้วยมากกับข้อเสนอที่ว่า “ใคร ๆ ก็สร้างองค์กรที่ได้ทำงานร่วมกับวิศวกรชั้นยอดได้ และการเน้นความสามารถรายบุคคลมากเกินไปทำให้บทบาทที่แท้จริงของผู้นำพร่าเลือน การสร้างระบบที่ทำให้วิศวกรที่มีทักษะน้อยกว่าสามารถทุ่มศักยภาพจนสร้างผลลัพธ์ได้คือความได้เปรียบในการแข่งขันมหาศาล” ผมไม่ใช่วิศวกร 10x แต่จากประสบการณ์ล่าสุด เมื่อทีมมีคนที่ประสบการณ์หรือฝีมือน้อยอยู่มาก สุดท้ายผมกลายเป็นคนเดียวที่ต้องรับตั๋วงานซับซ้อนทั้งหมด ถ้ารูปแบบนี้เกิดซ้ำไปเรื่อย ๆ ผมก็จะกลายเป็นคนที่ทำงานส่วนใหญ่เกือบทั้งหมด ซึ่งทั้งเหนื่อยและรู้สึกไม่ยุติธรรม พูดตรง ๆ ว่าถ้าเป็น SRE ที่ดี ผมคิดว่าควรมีความขี้เกียจอยู่บ้างเล็กน้อย เลยอยากให้เพื่อนร่วมทีมช่วยแบ่งงานกัน ผมจึงทุ่มทำงานหนักอยู่หลายสัปดาห์ เพื่อใส่ abstraction หลายชั้นลงไปในส่วนที่ซับซ้อนที่สุด (ผมทำ IAC เป็นหลัก; ในซอฟต์แวร์ก็มีรูปแบบคล้ายกัน) หลังจากนั้น วิศวกรที่มีทักษะหรือประสบการณ์น้อยกว่าก็เริ่มแบ่งรับงานบทบาทของผมได้ และเวลาของผมก็ถูกปล่อยไปให้กับปัญหาที่น่าสนใจกว่า นี่เป็นครั้งแรกที่ผมลองทำแบบนี้โดยไม่มีใครสั่ง ในทางกลับกัน ถ้าไม่มีโครงสร้างแบบนี้แล้วปล่อยให้ใครคนหนึ่งเล่นบทฮีโร่คนเดียว ทั้งทีมจะต้องตามเก็บความผิดพลาดอยู่ข้างหลังและปวดหัวไม่จบ สุดท้ายก็กลายเป็นทีมที่ไม่มีประสิทธิภาพอย่างมาก