แอนติแพตเทิร์นสำหรับผู้นำสายวิศวกรรม (Anti-patterns)

• เมื่อได้พบกับ CTO หรือผู้นำฝ่ายวิศวกรรม หัวข้อสนทนาที่พบได้บ่อยที่สุดคือแรงกดดันจาก CEO ที่บอกให้ “เพิ่มความเร็วของงานวิศวกรรม”
• ต่างจากงานขายหรือการจ้างงาน งานวิศวกรรมไม่มีตัวชี้วัดผลงานที่ชัดเจน
• ในมุมของผู้นำวิศวกรรม การจะบอก CEO ว่า “วิศวกรรมเป็นศิลปะ จึงคาดการณ์ผลงานได้ยาก” เป็นเรื่องลำบาก
• สาเหตุของความเห็นต่างระหว่างผู้นำวิศวกรรมกับผู้บริหาร
  • ผู้นำวิศวกรรมมีแนวโน้มจะยึดตามคำแนะนำด้านภาวะผู้นำแบบสำเร็จรูปอย่างแข็งทื่อเกินไป
  • เมื่อเหมารวมว่าบางแนวปฏิบัติใช้ได้หรือใช้ไม่ได้เสมอ ก็จะยิ่งนำไปปรับใช้ให้เหมาะกับบริบทขององค์กรได้ยาก
  • แก่นของภาวะผู้นำวิศวกรรมที่มีประสิทธิภาพคือการตัดสินใจตามสถานการณ์ว่าจะยึดแนวปฏิบัติเดิมหรือทดลองแนวทางใหม่
• บทความนี้สรุปสิ่งที่ Will Larson, CTO ของ Carta พูดไว้ในพอดแคสต์

3 แอนติแพตเทิร์นของภาวะผู้นำวิศวกรรม

1. การหลีกเลี่ยง micro-management
2. การหลีกเลี่ยงการวัดด้วยตัวชี้วัดที่ไม่สมบูรณ์
3. การที่ผู้นำทำตัวเป็นร่มให้ทีม

[แอนติแพตเทิร์น #1: การหลีกเลี่ยง micro-management]

3 บทบาทที่ขัดแย้งกันในการเป็นผู้บริหารวิศวกรรมชั้นยอด

• ผู้บริหารวิศวกรรมต้องทำหน้าที่ 3 บทบาทที่สวนทางกัน และผู้บริหารที่ยอดเยี่ยมจะสลับไปมาระหว่างบทบาทเหล่านี้ได้อย่างคล่องแคล่ว
  • บทบาทในฐานะหนึ่งในทีมผู้บริหาร: มองหาวิธีผลักดันธุรกิจให้ก้าวหน้า
    • บางครั้งอาจต้องตัดสินใจที่ “ไม่ดีต่อวิศวกรรมโดยรวม” เช่น การตัดงบฝ่ายวิศวกรรม
    • อาจรวมถึงการย้ายไปสู่โมเดลหน่วยธุรกิจที่ทำให้เสียงของวิศวกรรมต่อบางประเด็นลดลง
  • บทบาทในฐานะผู้จัดการฝ่ายวิศวกรรม
    • ทำความเข้าใจโครงสร้างของนโยบายที่จำเป็นต่อการบริหารองค์กรวิศวกรรม และมองหาวิธีเป็นผู้นำด้านบุคลากรที่มีประสิทธิภาพ
  • บทบาทในฐานะวิศวกร
    • รับผิดชอบต่อความเป็นเลิศทางเทคนิคและการลงมือทำด้านวิศวกรรม แม้จะมีแรงกดดันจากภายนอก
    • ต้องรักษามาตรฐานความเป็นเลิศทางเทคนิคไว้ในระดับสูง
• ผู้บริหารจำนวนมากมักเอนเอียงไปทางหนึ่งในสามบทบาทนี้มากเกินไป
• ไม่ว่าจะทำบทบาทใด ผู้นำมักพลาดเมื่อยังยึดติดกับแนวปฏิบัติการจัดการที่ไม่ช่วยอะไรแล้ว
• เมื่อกลายมาเป็นผู้จัดการทีมอย่างกะทันหัน คุณยังมีบริบททางเทคนิคเกี่ยวกับทุกอย่างที่ทีมทำมากที่สุด แต่ในเวลาเดียวกันก็กลายเป็นผู้จัดการคนด้วย
• ในช่วงนี้คนมักได้รับคำแนะนำให้ออกห่างจากรายละเอียดอยู่เรื่อย ๆ
• ผู้จัดการวิศวกรรมมือใหม่มักได้ยินคำแนะนำว่า “ออกจากโค้ดให้ได้”
• ยอมรับว่าคำแนะนำแบบนี้อาจมีประโยชน์สำหรับบางคน
• แต่ผู้บริหารที่มีความสามารถสูงจะยังคงมีความเข้าใจในระดับรายละเอียดเกี่ยวกับโดเมนที่ตนดูแลอยู่พอสมควร
• ถ้าออกห่างจากรายละเอียดมากเกินไป ก็จะกลายเป็นเพียงข้าราชการ และนี่คือเหตุผลที่ผู้จัดการวิศวกรรมจำนวนมากลงเอยเช่นนั้น

การบ่มเพาะสไตล์ภาวะผู้นำ

• Larson แนะนำให้ผู้บริหารวิศวกรรมลืมคำว่า micro-management ไปเสีย และหันไปโฟกัสที่การบ่มเพาะสไตล์ภาวะผู้นำหลายแบบให้เลือกใช้
• เมื่อยังไม่มีเส้นทางข้างหน้าที่ชัดเจน หรือคนที่มีบริบทเกี่ยวกับหนทางข้างหน้ามีความเห็นไม่ตรงกันอย่างรุนแรง การลงไปดูรายละเอียดและตัดสินใจด้วยตัวเองจะช่วยได้
• สิ่งนี้ช่วยให้เข้าใจคันโยกที่เปลี่ยนธุรกิจได้จริง ผลลัพธ์ที่ทีมต้องทำให้ได้ ระยะเวลาที่ต้องใช้ และวิธีให้บริการผู้ใช้ได้ดีขึ้น
• การพัฒนาความมั่นใจที่หนักแน่นขึ้นในการตัดสินใจเป็นสิ่งที่ต้องฝึกฝนตลอดชีวิต และ Larson เองก็ยังคงฝึกอยู่
• การตั้งคำถามอย่าง “เรากำลังทำอะไรอยู่? ทำไมเราถึงทำแบบนั้น? ข้อมูลคืออะไร? แหล่งข้อมูลจริงอยู่ที่ไหน?” ทุกเดือนหรือทุกไตรมาส จะช่วยให้ลงลึกในรายละเอียดได้มากขึ้น

2 ยุทธวิธีในการเข้าใกล้รายละเอียด

1. ทำความเข้าใจบริบทผ่าน “การขุดความขัดแย้ง”

   • ในสภาพแวดล้อมใหม่ การพลาดความต่างของบริบทเพียงเล็กน้อยก็อาจทำลายความสำเร็จในการดำเนินงานได้
   • แม้จะใช้เวลานาน การพูดคุยกับคนที่มีมุมมองตรงข้ามเพื่อค้นหา “เมล็ดพันธุ์แห่งความขัดแย้ง” ก็เป็นกระบวนการสำคัญ
   • ผู้นำที่ประสบความสำเร็จจะถามว่า “ฉันควรเปลี่ยนอย่างไรให้เหมาะกับองค์กรนี้?” ไม่ใช่ “ฉันจะเปลี่ยนองค์กรอย่างไรให้เข้ากับวิธีของฉัน?”

2. ทำเอกสารรายละเอียด

   • กลยุทธ์มีอยู่ทุกที่ แต่แทบไม่ถูกบันทึกเป็นเอกสาร
   • หลายครั้งเหตุผลเบื้องหลังการตัดสินใจสำคัญไม่ได้ถูกบันทึกไว้
   • การสร้างวัฒนธรรมการจัดทำเอกสารคือกุญแจขององค์กรวิศวกรรมที่เคลื่อนไหวรวดเร็ว
   • ผู้นำใหม่ควรสำรวจทุกสิ่งที่มีอยู่ก่อน และใช้กรณีความสำเร็จของบริษัทอื่นเป็น benchmark ก่อนจะสร้างกลยุทธ์ด้วยตัวเอง
   • เมื่อต้องเขียนเอกสารกลยุทธ์ แนะนำให้ใช้กรอบคิด “Good Strategy, Bad Strategy” ของ Richard Rumelt
   • ต่อให้เขียนกลยุทธ์ออกมาแย่แค่ไหน แค่ทำเป็นเอกสาร กลยุทธ์ก็อาจดีขึ้นอย่างรวดเร็วได้ในชั่วข้ามคืน

[แอนติแพตเทิร์น #2: การหลีกเลี่ยงการวัดด้วยตัวชี้วัดที่ไม่สมบูรณ์]

• แอนติแพตเทิร์นด้านการวัดมีอยู่ทั่วไป
• ในอุดมคติอาจอยากพูดแบบบริสุทธิ์ใจว่า “เราไม่ควรวัดสิ่งนี้” แต่ถ้าทำเช่นนั้น ก็มีแต่จะทำให้การเรียนรู้ขององค์กรรอบข้างช้าลง
• งานที่มีคุณค่ามากที่สุดของผู้บริหารวิศวกรรมคือการให้ความรู้แก่ผู้บริหารคนอื่น ๆ ว่าวิศวกรรมทำงานอย่างไร

โฟกัสที่การปรับปรุง mental model

• เราอยากให้ตัวชี้วัดสะท้อนความเป็นจริง แต่ตัวชี้วัดไม่ได้มีไว้เพื่อบอกความจริงเท่านั้น มันยังมีไว้เพื่อให้ความรู้กับผู้คนด้วย
• คุณควรกังวลกับการทำให้คณะกรรมการหรือ CEO เข้าใจ mental model มากกว่าการรู้สึกว่ามันกระทบ mental model ของตัวเอง

ดึง CEO เข้ามาสู่รายละเอียด

• แทนที่จะพูดว่า “นี่เป็นวิธีวัดที่แย่มาก” ควรพูดว่า “มาเริ่มจากตรงนี้ แล้วค่อยขุดลงไปจนเราเข้าใจข้อจำกัดของการวัดแบบนี้กัน”
• การบังคับให้คนออกห่างจากรายละเอียดไม่เคยเป็นวิธีที่ดี ควรดึงพวกเขาเข้ามาในรายละเอียดและให้ความรู้จากตรงนั้น

[แอนติแพตเทิร์น #3: การทำตัวเป็นร่มให้ทีม]

• ในอดีตเคยเชื่อว่าผู้จัดการควรทำตัวเป็น “ร่ม” เพื่อปกป้องทีม
• แต่การปกป้องทีมจากความเป็นจริงจะทำร้ายทีมในระยะยาว
• ควรทำให้ทั้งผู้จัดการและวิศวกรสามารถเข้าร่วมบทสนทนาที่สำคัญได้

ต้องการมุมมองใหม่ต่อการตัดสินใจเชิงกลยุทธ์

1. กลยุทธ์ Bottom-Up
   • ข้อดี: ช่วยให้ทีมเคลื่อนที่ได้เร็วและควบคุมเครื่องมือของตนเองได้
   • ข้อเสีย: ไม่มีความสามารถในการลงทุนทางเทคนิคอย่างมีจุดรวมศูนย์ และมักได้รับข้อมูลช้ากว่าเล็กน้อย
2. กลยุทธ์ Top-Down
   • ข้อเสีย: การให้ CTO หรือกลุ่มสถาปัตยกรรมตัดสินใจทุกอย่างนั้นไม่มีประสิทธิภาพ
   • แทบไม่มีกรณีที่คณะกรรมการจะตัดสินใจได้ดีที่สุด

ใช้ “Navigator” เพื่อเร่งการตัดสินใจ

• เพิ่มความเร็วในการตัดสินใจด้วยการมี “Navigator” ที่ทำหน้าที่เป็น “mini CTO” ประจำแต่ละ business unit
• ทำให้คนที่มีบริบทหน้างานมากที่สุดสามารถตัดสินใจเรื่อง tech stack ที่เหมาะสมที่สุดได้
• บทเรียนสู่ความสำเร็จ:
  1. อย่าละเลยการจัดทำเอกสาร
  2. ทำ postmortem
  3. จงระมัดระวังอย่างมากในการเลือกคนที่คุณจะมอบความไว้วางใจให้
• องค์กรคือผลรวมของวิจารณญาณที่สะสมจากคนเพียงไม่กี่คน และไม่อาจหลีกหนีความจริงนั้นได้

สรุป

• ความเสี่ยงของการยึดกฎอย่างเคร่งครัดเกินไป
  • เมื่อทีมวิศวกรรมเริ่มเติบโตไปพร้อมกับบริษัท ผู้นำต้องไม่ลืมสิ่งที่เคยทำให้ผู้บริหารที่มีเจตนาดีมากมายตกอยู่ในสถานการณ์ยากลำบากมาก่อน
  • เป้าหมายสูงสุดคือการสร้างกลไกคุณภาพสูงที่ทำให้ผู้คนรักษาความอยากรู้อยากเห็นและมองหาข้อยกเว้น
• วงเรียนรู้ (Learning Circle)
  • Larson จัด “วงเรียนรู้” ทุกสองสัปดาห์มาตลอด 3 ปีครึ่งที่ผ่านมา
    • CTO, VP of Engineering หรือผู้บริหารวิศวกรรมอาวุโสอื่น ๆ จากบริษัทเทคโนโลยี 6–10 คน มารวมตัวกันเพื่ออัปเดตความคืบหน้า และแลกเปลี่ยนปัญหาด้านยุทธวิธีและกระบวนการ
    • แต่ละการประชุมเริ่มด้วยการให้ทุกคนใช้เวลาคนละ 1 นาทีพูดถึงสิ่งที่กำลังโฟกัสในสัปดาห์นี้และหัวข้อที่อยากคุย
    • หลังจากคุยหัวข้อประมาณ 5 นาที กลุ่มจะเลือกหนึ่งหัวข้อและลงลึกกับมันต่ออีกประมาณ 20 นาที
    • หัวข้อมีตั้งแต่ “ฉันกำลังมีปัญหาเพราะโปรเจกต์นี้” ไปจนถึง “เราเพิ่งจ้างคนที่ยอดเยี่ยมมากคนหนึ่งเข้ามาและรู้สึกตื่นเต้นมาก”
• การเรียนรู้ผ่านการลงมือทำ
  • คนที่เรียนรู้ผ่านการปฏิบัติสามารถอาศัยการทบทวนอย่างสม่ำเสมอ เช่น วงเรียนรู้หรือการสะท้อนคิดส่วนตัว เพื่อบังคับให้เกิดการใคร่ครวญตนเองที่จำเป็นต่อการปรับกฎอย่างละเอียดอ่อน
  • Larson กล่าวว่า “ผมได้กลายเป็นผู้นำที่ดีขึ้นด้วยการเรียนรู้จากบทเรียนของคนอื่นที่เคยทำผิดพลาดคล้าย ๆ กับผม”

[geniuskey]

ผมรู้สึกเขินนิดหน่อยตรงช่วงท้ายที่ว่า "Larson บอกว่า 'ฉัน...กลายเป็นผู้นำที่ดีขึ้น'" นะครับ ถ้าเปลี่ยนเป็นประมาณว่า "ผู้นำควรพยายามอย่างต่อเนื่องเพื่อ... ผมเองก็ยังไม่ดีพอ และกำลังพยายามพัฒนาตัวเองให้ดีขึ้นอยู่" แบบนี้น่าจะอ่านได้สบายใจกว่านิดหน่อย ไม่แน่ใจว่านี่เป็นมุมมองแบบเกาหลีเกินไปหรือเปล่านะครับ ^^;;

[savvykang]

เห็นจากที่คุณถามว่าเป็นมุมมองแบบเกาหลีหรือเปล่า ก็ดูเหมือนว่าคุณจะเข้าใจเรื่องนี้ดีอยู่แล้ว ในมุมมองของผม ผู้พูดก็ไม่ได้แสดงอาการหลงตัวเองอะไร แต่ปฏิกิริยาแบบนี้ก็ค่อนข้างทำให้งงอยู่เหมือนกัน

[tofumaker]

การที่ไปโฟกัสที่ท่าทีของผู้พูด แทนที่จะดูแก่นหรือเนื้อหาของบทความนั้น เป็นอะไรที่เกาหลีมากเลยนะ

[savvykang]

แม้จะเป็น 'แอนตี้แพตเทิร์น #1: การหลีกเลี่ยงไมโครแมเนจเมนต์' แต่กลับบอกให้ลืมไมโครแมเนจเมนต์ไปเสีย ทำให้การดำเนินเนื้อหาดูแปลกๆ นะครับ

[frog08]

การมองว่าไมโครแมเนจเมนต์เป็นสิ่งไม่ดี เป็นสิ่งที่ไม่ควรทำ และจึงหลีกเลี่ยงมันแบบไม่มีเงื่อนไขนั้นต่างหากที่เป็น anti-pattern ประเด็นคือไม่ควรตัดสินว่าใช่หรือไม่ใช่ไมโครแมเนจเมนต์ แต่ควรใส่ใจรายละเอียดตามความจำเป็น

[savvykang]

อย่างน้อยถ้าเขียนว่า 'แอนติแพตเทิร์น: การมองว่าไมโครแมเนจเป็นทางเลือก' หรือไม่ก็ 'การคิดว่าการใส่ใจรายละเอียดกับการไมโครแมเนจเป็นเรื่องเดียวกัน' บริบทก็น่าจะลื่นไหลกว่านี้ ผมเข้าใจเจตนาของบทความนะ แต่สุดท้ายสารที่ต้องการสื่อก็คือ ให้บริหารแบบใส่ใจรายละเอียดแทนการ 'ไมโคร'แมเนจ ใช่ไหม

[kandk]

เวลาได้พบ CTO หรือผู้นำฝ่ายวิศวกรรม หัวข้อสนทนาที่คุยกันบ่อยที่สุดคือแรงกดดันจาก CEO ที่ให้ “เร่งความเร็วของงานวิศวกรรม”
ต่างจากงานขายหรือการสรรหาบุคลากร งานวิศวกรรมไม่มีตัวชี้วัดผลงานที่ชัดเจน
ในมุมของผู้นำฝ่ายวิศวกรรม ก็ลำบากที่จะบอก CEO ว่า “วิศวกรรมเป็นศิลปะ จึงคาดการณ์ผลงานได้ยาก”

[xguru]

ดูความคิดเห็นใน Hacker News เกี่ยวกับบทความนี้ด้วย

• มีความเห็นว่าวิธีการของ Will Larson ที่เคยนำไปใช้ในหลายองค์กรนั้นไม่ได้ผลนัก และวิธีการของเขาก่อให้เกิดความขัดแย้งระหว่างวิศวกรกับธุรกิจ
• มีการแนะนำหนังสือของ Ron Jeffries: "The Nature of Software Development" โดยเน้นคุณค่าที่ค่อย ๆ เพิ่มขึ้น การขับเคลื่อนโดยวิศวกร ฟีดแบ็กอย่างต่อเนื่อง และความยืดหยุ่น
• มองในแง่บวกที่ Larson มีความสามารถในการทบทวนตนเองและรับคำวิจารณ์ได้ งานเขียนของเขาไม่ได้ถูกหรือผิดเสมอไป แต่เขาทุ่มเทอย่างลึกซึ้งกับการแก้ปัญหา
• ด้วยลักษณะของผลิตภัณฑ์บนเว็บ ความผิดพลาดจึงไม่ถึงขั้นร้ายแรง และการเปลี่ยนแปลงที่เกิดขึ้นบ่อยมักมาจากเหตุผลด้านการตลาด จึงเกิดวัฒนธรรมที่เคลื่อนไหวเร็วและยอมรับความผิดพลาดได้
• แง่บวกของ micro-management: ผู้นำด้านวิศวกรรมที่ดีจะเข้าใจรายละเอียดได้ดีและมีความสามารถในการสื่อสารกับทีม ซึ่งแตกต่างจาก micro-management
• การมีบุคลากรสายเทคนิคมากเกินไปทำให้เกิดปัญหา หากมีการพัฒนาเครื่องมือที่ดีกว่าเดิม ทีมขนาดเล็กก็น่าจะทำงานได้เพียงพอ
• ปัญหาไม่ใช่การวัดผลเอง แต่เป็นการตัดสินใจที่ผิดจากผลการวัดนั้น ตัวชี้วัดควรถูกใช้เป็นเครื่องมือในการตั้งคำถาม
• การพัฒนาซอฟต์แวร์ขนาดใหญ่มีหัวใจสำคัญคือการทำงานร่วมกัน การล่มสลายของชุมชนคือสาเหตุหลักที่ทำให้โครงการช้าลง
• หากบทบาทและความคาดหวังของแต่ละคนใน pipeline การพัฒนาไม่ชัดเจน ก็จะเกิดปัญหา ผู้จัดการควรแก้ไขสถานการณ์นี้
• มีความเห็นว่าเป็นบทความที่ดี แต่ถ้าลดความยาวลง 25% จะยิ่งดีขึ้น