- Michael Lopp ผู้นำฝ่ายวิศวกรรมของ Apple เน้นว่า ยิ่งเป็นยุคที่สร้างผลิตภัณฑ์ได้รวดเร็วเท่าไร การบริหารที่ยึดคนเป็นศูนย์กลางและวิจารณญาณในการตัดสินใจ ก็ยิ่งสำคัญมากขึ้น
- “ใครเป็นคนตัดสินใจ และตัดสินใจนั้นถูกนำไปปฏิบัติอย่างไร?” คือแก่นแท้ที่แท้จริงของงานวิศวกรรม
- มากกว่าความสามารถในการเขียนโค้ด องค์กรและภาวะผู้นำที่ยึดคนเป็นศูนย์กลาง ต่างหากที่กำหนดผลลัพธ์ขององค์กร
- จากประสบการณ์ในสภาพแวดล้อมที่หลากหลาย ทั้ง Borland, Netscape, Palantir และ Slack เขาเสนอภาพที่เป็นรูปธรรมของ โครงสร้างองค์กร วัฒนธรรมการทำงานร่วมกัน และความสามารถหลักของผู้นำ
- จุดเน้นไม่ได้อยู่ที่ภาวะผู้นำด้านเทคนิค แต่เป็น การบริหารองค์กร การทำงานร่วมกันของผู้คน และความเข้าใจในมนุษย์
- บทสัมภาษณ์นี้ไม่ได้เป็นเพียงการพูดคุยเรื่องเทคนิค แต่เน้นไปที่ การออกแบบองค์กรวิศวกรรมที่ยั่งยืนและมีประสิทธิภาพ พร้อมนำเสนอคำแนะนำเชิงปฏิบัติให้แก่ผู้ก่อตั้งและผู้นำด้านเทคโนโลยี ในเรื่องความสัมพันธ์กับทีมผลิตภัณฑ์ ความสามารถที่ยึดคนเป็นศูนย์กลาง และคุณสมบัติของผู้นำที่ดี
จะออกแบบโครงสร้างองค์กรวิศวกรอย่างไร
- แม้อยู่คนละอุตสาหกรรม แต่ปัจจัยความสำเร็จร่วมกันคือ ความเชื่อมั่นในงานวิศวกรรม การเติบโตอย่างรวดเร็ว และการดึงดูดคนเก่ง
- จากสิ่งนี้ เขาเสนอ 3 แนวทางปฏิบัติเพื่อออกแบบองค์กรวิศวกรรมที่ประสบความสำเร็จ
Tip #1: ส่งเสริม “Wolf Time”
- แบ่งเวลาของวิศวกรเป็น 71% สำหรับงานหลัก / 29% สำหรับเวลาสร้างสรรค์อย่างอิสระ
- 29% นี้คือ “เวลาที่วัดผลไม่ได้และไม่จำเป็นต้องอธิบาย” ซึ่งเป็นพื้นที่ให้ความคิดสร้างสรรค์และความริเริ่มเติบโต
- ความพยายามทำให้เป็นระบบอย่างเป็นทางการที่ Palantir ล้มเหลว → การสนับสนุนแบบไม่เป็นทางการและการสื่อสารมีประสิทธิภาพกว่าการทำให้เป็นพิธีการ
- ตัวอย่าง: เสนอช่วงเวลาแชร์ไอเดียแบบไม่เป็นทางการทุกวันศุกร์
> “ถ้าสมาชิกทีมไม่รับรู้ว่าเวลานี้ได้รับอนุญาต พวกเขาจะต้องแอบทำมันระหว่างการประชุม และสุดท้ายจะไม่มีอะไรเติบโตขึ้นมาเลย”
Tip #2: ยิ่งถกเถียงกันเป็นประจำยิ่งดี
- ผลิตภัณฑ์ที่ยอดเยี่ยมเกิดจากความร่วมมือของ 3 ด้าน คือ วิศวกรรม การออกแบบ และผลิตภัณฑ์
- ความร่วมมือนี้มักมาพร้อมความขัดแย้ง แต่การถกเถียงนั้นเองคือ หัวใจสำคัญที่ช่วยยกระดับคุณภาพของผลิตภัณฑ์
- ต้องมี การถกเถียงอย่างคึกคักภายในทีม ว่าเป็น “ปัญหาด้านดีไซน์ ปัญหาด้านผลิตภัณฑ์ หรือปัญหาความเข้าใจในฟีเจอร์”
- ผู้นำต้องส่งเสริมให้เกิดการท้าทายความคิดเห็น ไม่ใช่แค่จากล่างขึ้นบน แต่รวมถึงจากบนลงล่างด้วย
- หลายครั้งการถกเถียงระหว่างผู้ก่อตั้งกับพนักงานก็กลายเป็นจุดเปลี่ยนทิศทางของบริษัท
Tip #3: สร้างระบบปฏิบัติการที่ขยายได้
- วิจารณญาณที่ดี + ความสามารถในการปฏิบัติการ คือรากฐานของผลิตภัณฑ์ที่ขยายได้
- วิจารณญาณไม่ได้หมายถึงผลลัพธ์เพียงอย่างเดียว แต่คือ ความสามารถในการอธิบายว่า “ทำไมจึงตัดสินใจเช่นนั้น”
- ความหมายของความรับผิดชอบ (Accountability) คือ การมี “เรื่องราวที่สามารถรายงานได้”
- หากต้องการให้วิจารณญาณของคนเพียงไม่กี่คน ขยายไปเป็นทั้งระบบ ก็จำเป็นต้องมีกระบวนการที่ชัดเจน
- แค่ดูจากกระบวนการจ้างงานก็สะท้อนคุณภาพการปฏิบัติการได้แล้ว เช่น ความเร็วในการตอบกลับ ความชัดเจนของตารางเวลา ฯลฯ
- อย่าใช้ข้ออ้างว่าเป็นสตาร์ตอัปเพื่อมองข้ามกระบวนการ → การสร้างบริษัทก็คือการสร้างการปฏิบัติการ
จะเสริมความสัมพันธ์ระหว่างวิศวกรรมกับทีมผลิตภัณฑ์อย่างไร
- ความตึงเครียดและความเข้าใจผิด ระหว่างทีมผลิตภัณฑ์กับทีมวิศวกรรมเป็นเรื่องเก่าแก่ แต่
หากต้องการสร้างผลิตภัณฑ์คุณภาพสูงที่ขยายได้ ความสัมพันธ์นี้จำเป็นต้องได้รับการขัดเกลาอย่างดี
- PM ที่ไม่ดี ทำให้วิศวกรเพียงแค่ทำตามโดย ไม่มีความเป็นเจ้าของต่อผลิตภัณฑ์
- PM ที่ดี ช่วยให้วิศวกร เข้าใจอย่างเพียงพอว่า “ทำไมเราจึงสร้างสิ่งนี้”
- Lopp ให้นิยามว่าวิศวกรคือคนของ “how” และ PM คือคนของ “why”
- ทีมผลิตภัณฑ์ควร ถ่ายทอดเรื่องราวของลูกค้า และ มอบหมายเรื่องวิธีสร้างให้กับวิศวกรและนักออกแบบ
- หัวใจสำคัญคือการแบ่งปัน “why”
> อย่าถาม PM แต่ให้ถามวิศวกรโดยตรงว่า “ทำไมเราถึงสร้างฟีเจอร์นี้?”
- ถ้าคำตอบคือ “เพราะ PM สั่งมา” ก็ชวนให้เดือดดาล
- ปัญหาที่แท้จริงไม่ใช่ว่าการตัดสินใจของทีมผลิตภัณฑ์ผิด แต่คือ วิศวกรไม่เข้าใจบริบท
> “วิศวกรคือคนที่ลงมือสร้างผลิตภัณฑ์ด้วยมือของตนเอง องค์กรที่ให้พวกเขาทำงานโดยไม่เข้าใจว่า ‘ทำไมเราจึงสร้างสิ่งนี้’ ย่อมล้มเหลว”
- เมื่อถูกถามว่าทำไม Slack ไม่มีฟีเจอร์บล็อก Stewart อธิบายปรัชญาอย่างชัดเจนว่า “ข้อมูลควรมองเห็นได้สำหรับทุกคน”
- เป็นการแบ่งปันมุมมองว่า นี่คือ ประเด็นเรื่องวิสัยทัศน์ ไม่ใช่แค่ฟีเจอร์
- ผู้จัดการผลิตภัณฑ์ที่ดีต้องสามารถ วางแต่ละฟีเจอร์หรือไอเดียให้อยู่ในบริบทของวิสัยทัศน์ผลิตภัณฑ์โดยรวมแล้วสื่อสารออกมา
- นั่นคือส่วนหนึ่งของ ‘why’ ที่ทุกคนควรโฟกัส
ผู้นำที่ยอดเยี่ยมคือคนแบบไหน?
- ภาวะผู้นำด้านวิศวกรรมที่ทรงพลังอย่างแท้จริง ไม่ได้หยุดอยู่แค่ความสามารถทางเทคนิค
- “ท้ายที่สุดแล้ว ภาวะผู้นำคือทักษะในการรับมือกับผู้คน”
-
คุณลักษณะผู้นำ #1: มีความยืดหยุ่น (Malleability)
- ผู้นำต้องทำงานกับผู้คนที่มีลักษณะหลากหลาย และสามารถ ปรับสไตล์ของตัวเอง ให้เหมาะกับแต่ละคนได้
- เขายกประสบการณ์ของตนเองที่นำทีมด้วยวิธีต่างกันอย่างสิ้นเชิงที่ Pinterest และ Slack เพื่อเน้นประเด็นนี้
- คำถามเดิมที่เขาถามผู้จัดการมือใหม่เสมอคือ “หลังจากได้รับฟีดแบ็กแล้ว คุณเปลี่ยนอะไรไปบ้าง?”
- การจัดทีมเองก็ไม่ได้ยึดเกณฑ์ตายตัว แต่จะปรับโครงสร้างใหม่ตาม จุดแข็งและจุดอ่อนที่ปรากฏขึ้นจากการทำงานร่วมกันจริง
- เพื่อสิ่งนี้ เขาจึง reorganize ทุก 6 เดือน
-
คุณลักษณะผู้นำ #2: มีทักษะการเล่าเรื่องยอดเยี่ยม
- เขาแสดงจุดยืนไม่ชอบ micromanagement อย่างชัดเจน: "ไม่มีอะไรน่ารำคาญไปกว่าการคอยสั่งวิศวกร"
- แต่ผู้นำควรมอบ “Box” และ “Soup” แทน
- Box: พื้นที่ที่บรรจุไอเดียและบริบทไว้
- Soup: ฐานข้อมูลหรือสารสนเทศที่สมาชิกจะเลือกดื่มหรือผสมต่อเองได้อย่างอิสระ
- หากแทนที่จะสั่งการ แต่ให้ เรื่องเล่าที่สร้างแรงบันดาลใจ สมาชิกก็จะตัดสินใจและเติบโตได้ด้วยตนเอง
- สมาชิกบางคนอาจพูดว่า “บอกมาเลยว่าต้องทำอะไร” แต่สุดท้ายพวกเขาก็ยัง ตีความในแบบของตัวเองอยู่ดี
> บทบาทของผู้นำคือการมอบซุป จะดื่มหรือจะใส่อะไรเพิ่ม เป็นทางเลือกของพวกเขา
-
คุณลักษณะผู้นำ #3: เข้าใจแรงจูงใจและเป้าหมายของสมาชิก
- ผู้นำต้องรู้ว่าสมาชิกแต่ละคน เติบโตและมีแรงจูงใจจากอะไร
- ตัวอย่างหนึ่ง: สำหรับวิศวกรที่ความท้าทายทางเทคนิคคือพลังขับเคลื่อนของชีวิต ก็ควรมอบ โอกาสในการแก้ปัญหาอย่างต่อเนื่อง
- อีกตัวอย่าง: ผู้ช่วยใน Palantir ระบุอย่างชัดเจนว่า มีแรงจูงใจด้านผลตอบแทน → จึงบริหารจัดการได้ชัดเจน
- หัวใจคือการค้นหา “แรงจูงใจหลักเพียงหนึ่งเดียว” ของแต่ละคน แล้วลงทุนกับสิ่งนั้นอย่างต่อเนื่อง
- และสิ่งนี้ต้องอาศัย ความอยากรู้อยากเห็น (curiosity) และการตั้งคำถาม “ทำไม?” อย่างไม่สิ้นสุด
> ผู้นำต้องค้นพบแรงจูงใจที่แม้แต่สมาชิกเองยังอาจไม่รู้ และสร้างโอกาสให้พวกเขาเติบโต
บทสรุป: แก่นแท้ของวิศวกรรมที่ประสบความสำเร็จคือความเข้าใจมนุษย์
- องค์กรวิศวกรรมที่ประสบความสำเร็จขึ้นอยู่กับพลวัตของมนุษย์ (Human Dynamics) ที่ทำงานได้อย่างราบรื่น
- ผลิตภัณฑ์ที่ยอดเยี่ยมไม่ได้เกิดจากคนเก่งเพียงรายบุคคล แต่เกิดจาก กลุ่มคนที่ทำงานร่วมกันได้ดี
- บทบาทของผู้นำเริ่มต้นจาก การเสริมพลังให้กับผู้คนที่ประกอบกันเป็นองค์กร
- “ทีมวิศวกรรมคือผืนทอขนาดใหญ่ของมนุษย์ที่ซับซ้อนและน่าทึ่ง (tapestry)”
- ความพยายามทำความเข้าใจโครงสร้างและการไหลของผืนทอนี้ คือ กุญแจที่ทำให้คุณค่าของผลิตภัณฑ์ถูกส่งต่ออย่างมีประสิทธิภาพผ่านทั้งองค์กร
> "เมื่อคุณมีแรงจูงใจที่จะเข้าใจว่าผู้คนมีปฏิสัมพันธ์กันอย่างไร บริษัทของคุณก็จะพร้อมส่งมอบคุณค่าของผลิตภัณฑ์ในระดับขนาดใหญ่"
6 ความคิดเห็น
มี Slack สำหรับผู้นำสายเทคที่ Michael Lopp เป็นผู้ดูแลอยู่ RLS - Rands Leadership Slack หากสนใจ ลองเข้าไปดูได้ ปัจจุบันเป็น Slack ขนาดใหญ่ที่มีผู้เข้าร่วมมากกว่า 36,000 คน หากต้องการสมัคร ให้เข้าไปอ่านรายละเอียดในลิงก์ด้านบนให้ดี แล้วส่งอีเมลถึง Lopp ชื่อ/อาชีพ/เหตุผลที่อยากเข้าร่วม/รู้จัก RLS มาจากที่ไหน/ลิงก์ไปยังบัญชี LinkedIn หรือ Twitter ของตัวเอง เป็นต้น
ถ้าซื้อตัววิศวกรราคาแพงมาแล้ว ก็อย่าไปสั่งจุกจิกแม้แต่เรื่องเล็กน้อยราวกับมองว่าวิศวกรเป็น LLM หรือเหมือนออกคำสั่งให้โดราเอมอนที่เสกของออกมาได้ทันทีเพียงเพราะแค่ขยับปากกาสั่งงาน แต่ให้แชร์แค่วิสัยทัศน์ของตัวเอง แล้วปล่อยให้เขาจัดการเอง เพราะแนวทางเชิงวิศวกรรมในการทำสิ่งนั้นให้เป็นจริงต่างหากคือความเชี่ยวชาญของเขา
พอนั่งฟังเงียบ ๆ แล้ว ทำไมภาพการโต้เถียงกันไปมาระหว่างคนที่อยากสร้างบ้านเดี่ยวในชนบทหรือรีโนเวตอพาร์ตเมนต์เก่าในบ้านเรา กับผู้รับเหมา บริษัทก่อสร้าง หรือสถาปนิก ถึงลอยขึ้นมาในหัวก็ไม่รู้
กรณีหลังนี้น่าจะอยู่ในบริบทที่ต่างออกไปนิดหน่อยใช่ไหมครับ?
การรีโนเวตบ้านเดี่ยวชานเมืองหรืออพาร์ตเมนต์เก่า
อย่างแรกเลยคือมันเป็นพื้นที่ที่ใกล้เคียงกับการทำฝันให้เป็นจริงมากกว่าธุรกิจอยู่แล้ว
แถมก็มีเรื่องที่ฝากให้บริษัทก่อสร้าง/รีโนเวตจัดการแล้วโดนหักหลังเกิดขึ้นบ่อยอย่างน่าประหลาดอีกด้วย...
ถ้าเจ้าของไม่ได้ทำเองแล้วไปสั่งให้คนอื่นทำ ก็น่าจะลงเอยเป็นสถานการณ์แบบเดียวกันครับ
ต่อให้อธิบายดีแค่ไหนก็ยังมีเรื่องเข้าใจคลาดเคลื่อน และต่อให้ตรวจละเอียดแค่ไหนก็ยังมีส่วนที่นึกไม่ถึงอยู่เสมอ
ถ้าจะคอยถามทีละจุดในส่วนที่เจ้าของไม่ได้บอกเพื่อทำงาน ก็ทั้งใช้เวลาและชวนอึดอัด เลยมีหลายส่วนที่ผู้เชี่ยวชาญจัดการกันไปเอง ซึ่งดูเหมือนว่านั่นแหละจะกลายเป็นประเด็นให้มีปากเสียงกัน
ว่าแต่ก็น่าอิจฉาที่ดูเหมือนคุณจะยังไม่ค่อยโดนบริษัท SI แทงข้างหลังมาเยอะเท่าไรนะครับ
ทำให้นึกถึงหนังสือ Modern Software Engineering ที่เพิ่งอ่านไปเหมือนกัน เพราะหนังสือเล่มนี้ก็พูดถึงทีมและองค์กรด้วย ไม่ได้พูดถึงแค่การพัฒนาเพียงอย่างเดียว
แม้ว่าจะมีความคิดเห็นและวิธีการเกี่ยวกับภาวะผู้นำด้านวิศวกรรมที่หลากหลาย แต่ดูเหมือนว่าสิ่งที่เหมือนกันในแก่นแท้คือทั้งหมดตั้งอยู่บนความเข้าใจต่อสมาชิกในทีม การจะเข้าใจสมาชิกในทีมนั้นพูดเหมือนง่าย แต่ดูเหมือนว่าเป็นส่วนที่ต้องค่อย ๆ สร้างความไว้วางใจผ่านความเห็นอกเห็นใจระหว่างผู้นำกับสมาชิก โดยอาศัยฟีดแบ็กซึ่งกันและกัน คงไม่ใช่สิ่งที่สร้างขึ้นได้ในครั้งเดียว ขอบคุณสำหรับเนื้อหาดี ๆ ที่ชวนให้ได้คิดครับ