Leading Effective Engineering Teams

What Makes a Software Engineering Team Effective?

1. ทีมที่เวิร์กคืออะไร? ทีมที่ประสบความสำเร็จไม่ใช่แค่กลุ่มคนที่ทำงานประสานกันเท่านั้น แต่คือกลุ่มคนที่ผูกพันกันด้วยความรับผิดชอบและเป้าหมายร่วมกัน (( Effective team - ทีมที่สามารถผลิตฟีเจอร์หรือผลิตภัณฑ์ที่มีประโยชน์ออกมาใช้งานได้จริงอย่างสม่ำเสมอ ตั้งแต่การเขียนโค้ด ทดสอบ ไปจนถึงปล่อยให้ผู้ใช้งานจริง ))

2. กุญแจสำคัญ 5 ประการจากงานวิจัย Project Aristotle Google ค้นพบว่า “วิธีที่คนในทีมปฏิสัมพันธ์และทำตัวต่อกัน” นั้นสำคัญกว่า “ทักษะของคนในทีม” เสียอีก โดยมีปัจจัยสำคัญ 5 ข้อเรียงตามลำดับดังนี้:

รู้สึกปลอดภัยทางจิตวิทยา (( Psychological safety - การที่คนในทีมกล้าแสดงความคิดเห็น หรือเสนอไอเดียโดยไม่กลัวว่าจะถูกตำหนิหรือถูกตัดสิน )) ซึ่งถือเป็นรากฐานที่สำคัญที่สุด
พึ่งพากันได้ (( Dependability - สมาชิกในทีมสามารถพึ่งพากันและกันในการทำงานให้เสร็จตรงตามเวลาและได้คุณภาพ ))
โครงสร้างและความชัดเจน (( Structure and clarity - ทุกคนเข้าใจเป้าหมายของโปรเจกต์และหน้าที่รับผิดชอบของตัวเองอย่างชัดเจน ))
ความหมายของงาน (( Meaning - การรู้สึกว่างานที่กำลังทำอยู่มีความหมายและมีจุดประสงค์ ))
ผลกระทบของงาน (( Impact - ความเชื่อมั่นว่างานที่ทำสามารถสร้างความเปลี่ยนแปลงที่ดีให้กับองค์กรหรือสังคมได้ ))

3. พลังของแรงจูงใจ (Motivation) งานที่ต้องใช้ความคิดสร้างสรรค์อย่างงานซอฟต์แวร์นั้น แรงจูงใจภายใน (( Intrinsic reward - ความรู้สึกเติมเต็มทางใจ เช่น ความภูมิใจในผลงาน หรือการได้เรียนรู้ทักษะใหม่ ๆ ซึ่งส่งผลดีระยะยาวมากกว่ารางวัลภายนอกอย่างโบนัส )) เป็นแรงขับเคลื่อนสำคัญที่สุด ประกอบด้วย 3 อย่าง ได้แก่:

ความเป็นอิสระ (( Autonomy - ความต้องการที่จะมีอิสระในการตัดสินใจ ควบคุมการทำงาน และเป็นเจ้าของผลงานของตัวเอง ))
ความเชี่ยวชาญ (( Mastery - ความต้องการพัฒนาทักษะและความสามารถของตัวเองให้เก่งขึ้นเรื่อย ๆ ))
จุดมุ่งหมาย (( Purpose - ความต้องการทำสิ่งที่มีความหมายและเห็นผลกระทบที่ชัดเจน ))

4. ขั้นตอนการสร้างทีม 4 สเต็ป (4-Step Team Building) การสร้างทีมให้ทำงานได้ดีมีขั้นตอนดังนี้:

ขั้นที่ 1: การรวมตัวคนที่ใช่ (Assemble the Right People): ขนาดทีมที่เหมาะสมมักอยู่ที่ 3–5 คน การมีคนมากเกินไปไม่ได้แปลว่าจะดีเสมอ เพราะอาจทำให้การสื่อสารยุ่งยาก การเลือกคนเข้าทีมจึงไม่ควรดูแค่ทักษะการเขียนโค้ด แต่ควรดูทัศนคติด้วย เช่น เป็นนักแก้ปัญหา ใส่ใจผู้ใช้งาน และไม่ทำเรื่องง่ายให้ซับซ้อนเกินจำเป็น (( Overengineering - การออกแบบระบบหรือเขียนโค้ดแก้ปัญหาที่ซับซ้อนเกินความจำเป็นสำหรับสิ่งที่ยังไม่เกิดขึ้นจริง )) หากทีมมีความหลากหลาย ก็ควรมีกระบวนการที่เปิดรับความแตกต่าง (( Inclusion - การสร้างสภาพแวดล้อมที่ปลอดภัยให้ทุกคนรู้สึกมีส่วนร่วม เช่น การให้ทุกคนสลับกันพูด หรือมีช่องทางรับฟังความเห็นแบบไม่ระบุตัวตน ))
ขั้นที่ 2: การสร้างสปิริตในทีม (Enable Team Spirit): แบ่งหน้าที่ให้ชัดเจนเพื่อไม่ให้งานทับซ้อน สร้างเป้าหมายร่วมกัน และสร้างความไว้ใจ ทีมที่เปิดกว้างและช่วยเหลือกัน (( Team Open-Door - ทีมที่สื่อสารกันอย่างเปิดเผยและพร้อมให้ความช่วยเหลือโดยไม่ตัดสิน )) จะแก้ปัญหาได้ดีกว่าทีมที่ต่างคนต่างทำ (( Team Silos - ทีมที่แต่ละคนสนใจแต่งานตัวเอง และปัดความรับผิดชอบเวลามีปัญหา ))
ขั้นที่ 3: การเป็นผู้นำที่ดี (Lead Effectively): ผู้นำต้องคอยชี้แนะและจัดหาเครื่องมือให้ทีม รวมถึงช่วยนำเสนอผลงานของทีมให้ผู้บริหารหรือแผนกอื่นรับรู้ (( Strategic visibility - การสื่อสารผลงานและผลกระทบที่ทีมสร้างขึ้นให้ผู้มีส่วนได้ส่วนเสียรับรู้ เพื่อให้ทีมได้รับความชื่นชม การยอมรับ และมองเห็นโอกาสเติบโต ))
ขั้นที่ 4: การรักษาประสิทธิภาพให้ยั่งยืน (Sustain Effectiveness): สนับสนุนวัฒนธรรมการเรียนรู้ ให้ทีมพัฒนาทักษะใหม่ ๆ และปรับกระบวนการทำงานให้ยืดหยุ่น (( Agility - ความสามารถในการปรับตัวรับมือกับการเปลี่ยนแปลงความต้องการของโปรเจกต์ได้อย่างรวดเร็ว โดยไม่ยึดติดกับวิธีเดิม ๆ มากเกินไป ))

Productivity vs Efficiency vs Effectiveness

1. 3 คำที่คล้ายกัน แต่ความหมายต่างกัน เพื่อให้เห็นภาพชัดเจน ลองเปรียบเทียบกับการ “ขับรถ”:

Productivity (( Productivity - ผลผลิตเทียบกับปัจจัยนำเข้า (Output over input) หรือการวัดว่าเราทำปริมาณงานออกมาได้มากแค่ไหน )) เปรียบเหมือน “ความเร็วของรถ” ว่าเราสามารถวิ่งได้เร็วแค่ไหน
Efficiency (( Efficiency - การทำสิ่งต่าง ๆ อย่างถูกวิธี (Doing things right) เพื่อลดความสูญเปล่าและใช้ทรัพยากรกับเวลาให้คุ้มค่าที่สุด )) เปรียบเหมือน “ความประหยัดน้ำมัน” คือการวิ่งให้เร็วโดยใช้ทรัพยากรน้อยที่สุด
Effectiveness (( Effectiveness - การทำสิ่งที่ถูกต้อง (Doing the right thing) โดยมุ่งไปที่การส่งมอบผลลัพธ์ที่มีคุณค่าต่อธุรกิจและลูกค้า )) เปรียบเหมือน “การขับรถไปถึงปลายทางที่ถูกต้อง”

รถที่วิ่งเร็วและประหยัดน้ำมัน (Productive และ Efficient) ก็ไม่มีประโยชน์ หากขับหลงทิศและมุ่งไปผิดทาง (ไม่ Effective) ผู้นำจึงต้องให้ความสำคัญกับการกำหนดปลายทางให้ถูกต้องเป็นอันดับแรก

2. เลิกหลงกลกับปริมาณงาน (Output) แต่ให้มองที่ผลลัพธ์ (Outcome) การวัดประสิทธิภาพของคนทำงานที่ใช้ความรู้ (( Knowledge work - งานที่ต้องใช้ความคิด การแก้ปัญหา และทักษะเฉพาะทาง มากกว่าการใช้แรงงานซ้ำ ๆ เช่น งานวิศวกรรมซอฟต์แวร์ )) ไม่สามารถวัดแค่ความเร็วหรือปริมาณเหมือนการวัดการทำงานของเครื่องจักรได้ เราต้องแยกให้ออกระหว่าง:

Output (สิ่งที่ทำเสร็จ): เช่น พัฒนาแอปพลิเคชันตัวใหม่เสร็จ, ออกแบบเอกสารเสร็จ
Outcome (ผลที่เกิดตามมา): เช่น แอปใหม่ช่วยให้เข้าถึงลูกค้ากลุ่มใหม่ได้, เอกสารช่วยให้กระบวนการทำงานง่ายขึ้น

การวัด Output เพียงเพราะวัดและนับเป็นตัวเลขได้ง่าย มักนำไปสู่กับดักที่เรียกว่า Watermelon effect (( Watermelon effect - ปรากฏการณ์แตงโม คือสถานการณ์ที่ตัวชี้วัดภายนอกดูสวยหรูเป็น “สีเขียว” เช่น ส่งมอบงานตรงเวลา แต่ความเป็นจริงข้างในกลับล้มเหลวเป็น “สีแดง” เช่น งานนั้นไม่มีคนใช้หรือไม่ได้สร้างคุณค่าใด ๆ ))

บางครั้งทีมอาจเก่งเทคนิคมาก ทำงานเร็วและโค้ดเนี้ยบ แต่หากไม่ได้ทำฟีเจอร์ที่ตรงความต้องการของเป้าหมายธุรกิจ งานเหล่านั้นก็ไร้ความหมาย (เหมือนกรณีศึกษาของวิศวกรที่โฟกัสแต่การเขียนโค้ดและทำระบบที่ซับซ้อน แต่ผลลัพธ์กลับไม่ตอบโจทย์ผู้ใช้งานเลย)

3. สู่จุดสูงสุด: Effective Efficiency เป้าหมายในอุดมคติที่ทุกคนควรมุ่งไปคือ Effective Efficiency (( Effective efficiency - การทำสิ่งที่ถูกต้องอย่างถูกวิธี (Do the right things right) )) หรือการทำงานที่ตอบโจทย์ให้ออกมาดีที่สุด นักพัฒนาสามารถเพิ่มประสิทธิภาพของตัวเองได้ผ่านเทคนิคเหล่านี้:

ถามคำถามเสมอ: ทำความเข้าใจภาพรวมและเป้าหมายของธุรกิจก่อนลงมือเขียนโค้ด
ทำงานร่วมกับผู้อื่น: สื่อสารกับคนในทีมหรือแผนกอื่นเสมอเพื่อลดความผิดพลาด
ใช้ กฎ 20 นาที (( 20-minute rule - กฎที่แนะนำให้ลองใช้เวลา 20 นาทีแรกเพื่อค้นคว้าหาทางแก้ปัญหาด้วยตัวเองก่อน หากยังติดขัด ค่อยทักไปถามเพื่อนร่วมทีม พร้อมกับอธิบายว่าตัวเองได้ลองหาข้อมูลอะไรไปแล้วบ้าง เพื่อช่วยให้การสนทนามีประสิทธิภาพขึ้น ))

นอกจากนี้ การหาจุดสมดุลที่ดีอาจต้องยอมแลก (Trade-off) เช่น ช่วงเริ่มต้นของ Airbnb ผู้ก่อตั้งมีงบและเวลาจำกัด จึงเลือกทำเฉพาะฟีเจอร์หลักที่จำเป็นและสำคัญที่สุดก่อน (Effective) และพักการสร้างฟีเจอร์หรูหราอย่างระบบค้นหาแบบพิเศษไว้ก่อน เพื่อประหยัดทรัพยากรและเพิ่ม Efficiency ของทีม

4. การตั้งเป้าหมายและการวัดผลยุคใหม่ ตัวชี้วัดแบบเก่าที่ใช้วัดปริมาณงาน เช่น การนับจำนวนบรรทัดของโค้ดนั้นล้าสมัยแล้ว การตั้งเป้าหมายยุคใหม่ควรช่วยให้ทีมโฟกัสที่ “ผลลัพธ์” (Outcome) โดยใช้เครื่องมือเหล่านี้:

ระดับบุคคล ใช้ SMART (( SMART goal - หลักการตั้งเป้าหมายที่ดี ต้องมีความเฉพาะเจาะจง (Specific), วัดผลได้ (Measurable), ทำได้จริง (Achievable), เกี่ยวข้องกับงาน (Relevant) และมีกรอบเวลาชัดเจน (Time-bound) ))
ระดับโปรเจกต์ ใช้ GQM (( GQM - Goal-Question-Metric เฟรมเวิร์กที่เริ่มจากการตั้งเป้าหมาย (Goal) แล้วตั้งคำถาม (Question) ว่าต้องทำอย่างไรถึงจะบรรลุเป้า จากนั้นจึงค่อยหาตัวชี้วัด (Metric) ที่เหมาะสมมาตอบคำถามนั้น ))
ระดับองค์กร ใช้ OKR (( OKR - Objectives and Key Results เฟรมเวิร์กการตั้งเป้าหมายที่เชื่อมโยงผลลัพธ์ของทีมให้สอดคล้องกับกลยุทธ์หลักขององค์กร ))

“จงระบุผลลัพธ์ที่ต้องการ (Outcome) ให้ชัดเจนก่อน แล้วค่อยเลือกวิธีวัดผล (Metrics/Output) ที่สำคัญจริง ๆ” อย่าพยายามวัดทุกอย่างเพียงเพราะว่าวัดได้ง่าย

The 3 E’s model

ขั้นที่ 1: Enable (ปูทางและตั้งเป้าหมาย) ก่อนจะไปถึงความสำเร็จ เราต้องรู้ก่อนว่าความสำเร็จมีหน้าตาอย่างไร การทำ Enable คือการกำหนดนิยามของประสิทธิผลให้ชัดเจน โดยไม่ใช้ (( Blanket definition - การใช้นิยามความสำเร็จแบบเหมารวมกับทุก ๆ ทีม ซึ่งมักไม่ได้ผลเพราะแต่ละองค์กรมีบริบทและเป้าหมายต่างกัน )) ตัวอย่างเช่น ทีมสตาร์ทอัพอาจนิยามความสำเร็จว่าเป็นการนำผลิตภัณฑ์ออกสู่ตลาดให้เร็วที่สุด ขณะที่ทีมรับทำซอฟต์แวร์ (Agency) อาจนิยามความสำเร็จว่าเป็นการส่งมอบงานคุณภาพตรงเวลาและอยู่ในงบประมาณ

เป้าหมายต้องชัดเจน: ควรกำหนดเป้าหมายโดยใช้เครื่องมืออย่าง OKR หรือ SMART ให้สอดคล้องกับเป้าหมายใหญ่ขององค์กร
สร้างความเข้าใจ: เมื่อได้นิยามแล้ว ต้องสื่อสาร ฝึกอบรม และให้ฟีดแบ็ก เพื่อให้ทุกคนในทีมเข้าใจตรงกันว่ากำลังวิ่งไปสู่เป้าหมายใด

ขั้นที่ 2: Empower (มอบอำนาจและสนับสนุน) เมื่อทีมรู้ทิศทางแล้ว ผู้นำต้องมอบความไว้วางใจ ทรัพยากร และอิสระในการตัดสินใจให้ทีม โดยมีแนวทางปฏิบัติที่สำคัญดังนี้:

ใช้หลักการ Feed opportunities, starve problems: คือการทำสองสิ่งควบคู่กันไป ได้แก่ (( Feed opportunities - การทุ่มเททรัพยากรไปที่โอกาสที่ทำให้คนหรือทีมเติบโต เช่น มอบหมายงานที่ตรงกับจุดแข็ง จัดหาเครื่องมือ หรือให้โอกาสฝึกอบรม )) และ (( Starve problems - การจัดการปัญหา คอขวด หรือความขัดแย้งให้เร็วที่สุดก่อนที่มันจะลุกลามจนเป็นอุปสรรคต่อการทำงาน ))
ผู้นำต้องจัดการตัวเองก่อน: ผู้นำต้องไม่ทำตัวเป็น (( Bottleneck - จุดคอขวด หรือการรวบการตัดสินใจทุกอย่างมากองไว้ที่ตัวเองคนเดียวจนงานของทีมเดินต่อไม่ได้ )) ต้องรู้จักกระจายงาน (Delegate) ให้ทีมดูแล
ทำตัวเป็น Multiplier: (( Multiplier - ผู้นำที่ช่วยขยายขีดความสามารถและดึงศักยภาพของคนรอบข้างออกมา ทำให้ทีมเก่งขึ้นและกล้าคิดกล้าทำ ต่างจากผู้นำแบบ Diminisher ที่ชอบรวบอำนาจและกดศักยภาพของทีม ))
เน้นทำสิ่งที่เป็น High-leverage activity: (( High-leverage activity - กิจกรรมที่ลงแรงทำเพียงครั้งเดียวแต่สร้างผลลัพธ์หรือส่งผลกระทบเชิงบวกต่อเนื่องไปอย่างมหาศาล เช่น การทำระบบทดสอบอัตโนมัติ หรือการสอนงานให้คนในทีมเก่งขึ้น ซึ่งจะช่วยทวีคูณผลลัพธ์ขององค์กร ))

ขั้นที่ 3: Expand (ขยายผลและสร้างความยั่งยืน) เมื่อทีมเก่งแล้ว ผู้นำต้องทำให้ทีมยืนหยัดและพึ่งพาตัวเองได้ (Self-sufficient) เพื่อสร้างผู้นำรุ่นใหม่และขยายรูปแบบความสำเร็จไปสู่ทีมอื่น ๆ ในขั้นนี้บทบาทของผู้นำจะเปลี่ยนจากผู้ลงมือทำงานเทคนิคไปเป็นผู้ดูแลเรื่องคนและกลยุทธ์ภาพรวม โดยยึดหลัก “3 เสมอ (The Three Always)”:

Always be deciding (ตัดสินใจอยู่เสมอ): ปัญหาของผู้นำระดับสูงมักไม่มีคำตอบที่ถูกหรือผิด 100% ผู้นำต้องชั่งน้ำหนักผลดีผลเสีย (Trade-offs) เมื่อตัดสินใจแล้วก็ต้องกล้าลงมือทำ แล้วค่อยปรับปรุงแก้ไข อย่ารอทางเลือกที่สมบูรณ์แบบจนเกิดอาการ (( Analysis paralysis - ภาวะคิดมากเกินไปหรือรอข้อมูลที่สมบูรณ์แบบจนไม่กล้าตัดสินใจทำอะไรเลย ))
Always be leaving (เตรียมตัวจากไปเสมอ): ไม่ได้แปลว่าจะลาออก แต่หมายถึงการสอนและโค้ชทีมให้ทำงานได้เองโดยไม่ต้องพึ่งพาเราทุกเรื่อง เพื่อลดความเสี่ยงจาก (( Bus factor - ตัวชี้วัดความเสี่ยง สมมติว่าคนสำคัญในทีมต้องหายไปกะทันหัน โปรเจกต์จะล่มทันที ยิ่งต้องใช้คนหายไปน้อยคนก็ยิ่งเสี่ยงสูง )) ผู้นำที่ดีจึงต้องป้องกันไม่ให้ตัวเองกลายเป็น (( SPOF (Single Point of Failure) - จุดศูนย์กลางหรือเสาหลักเพียงต้นเดียวที่หากพังลงจะทำให้ระบบทั้งหมดหรือทีมหยุดทำงาน ))
Always be scaling (ขยายขีดจำกัดเสมอ): เมื่อเติบโตขึ้น ปริมาณงานจะเยอะขึ้นในขณะที่ทรัพยากรเวลาเท่าเดิม ผู้นำจึงต้องรู้จักปกป้องเวลาและพลังงานของตัวเอง เลือกทำเฉพาะงานสำคัญที่สุด 20% ที่มีแต่คุณเท่านั้นที่ทำได้ และอย่าลืมใส่ใจการดูแลสุขภาพจิตของตนเอง

โมเดล 3 ขั้นตอนนี้ช่วยปรับโครงสร้างและเตรียมความพร้อมให้ผู้นำกับทีมรับมือกับการเติบโตได้อย่างมีประสิทธิภาพและยั่งยืน

Effective Management Behaviors: Research from Google

งานวิจัยสำคัญ 2 ชิ้นของ Google ได้แก่ Project Oxygen และ Project Aristotle “Manager ที่ดีควรมีพฤติกรรมอย่างไร” และ “จะนำพฤติกรรมเหล่านั้นไปสร้างสภาพแวดล้อมที่ดีให้ทีมได้อย่างไร”

ส่วนที่ 1: 10 พฤติกรรมของผู้จัดการที่ยอดเยี่ยม (จาก Project Oxygen) ในอดีต Google เคยคิดว่าผู้จัดการไม่จำเป็น จนถึงขั้นทดลองยกเลิกตำแหน่งนี้ทั้งหมด แต่ข้อมูลกลับพบว่า ทีมที่มีผู้จัดการเก่ง ๆ มีความสุขและทำงานได้ดีกว่ามาก Google จึงสกัดพฤติกรรมของผู้จัดการชั้นยอดออกมา 10 ข้อ ดังนี้:

เป็นโค้ชที่ดี: รับฟัง ให้คำติชมที่นำไปพัฒนาต่อได้ และทำตัวเป็นแบบอย่างที่ดี
ให้อำนาจทีมโดยไม่จู้จี้จุกจิก (Micromanage): ให้อิสระทีมในการตัดสินใจ อาจใช้วิธีมอบหมาย (( Stretch assignment - งานที่ท้าทายและยากกว่าทักษะปัจจุบันของพนักงานเล็กน้อย เพื่อกระตุ้นการเรียนรู้และขยายขีดความสามารถ )) และติดตามงานแบบพอดี (Light touch) คือไม่ขอให้อัปเดตทุกวัน แต่ตกลงกันว่าหากติดปัญหาให้รีบบอกทันที
สร้างสภาพแวดล้อมที่เปิดรับและใส่ใจสุขภาวะของทีม: สร้างพื้นที่ให้ทุกคนกล้าแชร์ไอเดีย และใส่ใจสมดุลชีวิต โดย Google มีเทคนิคที่เรียกว่า (( One Simple Thing - การให้พนักงานเลือกตั้งเป้าหมายส่วนตัวง่าย ๆ นอกเวลางาน 1 อย่างเพื่อรักษาสมดุลชีวิต เช่น ออกกำลังกายสัปดาห์ละ 3 วัน หรือตัดขาดจากการสื่อสารเรื่องงานในช่วงวันหยุดยาว ))
มุ่งเน้นผลลัพธ์และมีประสิทธิภาพ: ตั้งเป้าหมายที่ชัดเจน จัดสรรคนและทรัพยากรให้ดี และคอยเคลียร์อุปสรรคให้ทีมทำงานได้สะดวก
เป็นนักสื่อสารที่ดี: รับฟังอย่างตั้งใจและสื่อสารข้อมูลอย่างโปร่งใส โดยเฉพาะการทำ One-on-one ที่ไม่ควรเป็นเพียงการอัปเดตสถานะโปรเจกต์ แต่ควรพูดคุยถึงเป้าหมายชีวิต แรงจูงใจ และสุขภาวะของพนักงานด้วย
สนับสนุนการเติบโตในสายอาชีพ: ให้ฟีดแบ็กสม่ำเสมอตลอดปีโดยไม่ต้องรอประเมินผลปลายปี แนะนำให้ใช้ (( GROW model - กรอบการสนทนาเพื่อพัฒนาสายอาชีพ 4 ขั้นตอน เริ่มจากการหาเป้าหมาย (Goal) ดูความเป็นจริงปัจจุบัน (Reality) สำรวจทางเลือก (Options) และจบที่ความตั้งใจที่จะลงมือทำ (Will) ))
มีวิสัยทัศน์และกลยุทธ์ที่ชัดเจน: สามารถวาดภาพให้ทีมเห็นได้ว่าทิศทางของทีมคืออะไร และสอดคล้องกับเป้าหมายของบริษัทอย่างไร
มีทักษะทางเทคนิคที่ช่วยแนะนำทีมได้: เข้าใจเนื้องานเพื่อช่วยหาทางออก และทำหน้าที่เป็นสะพานเชื่อม อธิบายเรื่องเทคนิคยาก ๆ ให้ฝ่ายธุรกิจเข้าใจได้ง่าย
ตัดสินใจเด็ดขาด: กล้าตัดสินใจในเรื่องสำคัญโดยอิงจากข้อมูลและผลประโยชน์ของบริษัท และต้องสื่อสารอธิบายเหตุผลเบื้องหลังให้ทีมเข้าใจด้วย
ทำงานข้ามแผนกได้ดี: มองเป้าหมายรวมของบริษัทเป็นหลัก ทำงานร่วมกับทีมอื่น ๆ ได้ดี ไม่หวงก้างหรือสนใจแค่ทีมของตัวเอง

ส่วนที่ 2: การสร้าง 5 พลังขับเคลื่อนให้ทีม (จาก Project Aristotle) งานของผู้จัดการคือการนำพฤติกรรมทั้ง 10 ข้อข้างต้นมาสร้างสภาพแวดล้อม 5 ประการนี้ให้เกิดขึ้นในทีม:

ความรู้สึกปลอดภัยทางจิตวิทยา (Psychological safety): นี่คือหัวใจสำคัญที่สุด! เมื่อมีความผิดพลาดเกิดขึ้น ผู้จัดการต้องเปลี่ยนจากการด่าทอหรือหาคนผิด มาเป็นการใช้ความสงสัยใคร่รู้ (Replace blame with curiosity) เพื่อตั้งคำถามหาบทเรียนร่วมกัน
ความพึ่งพากันได้ (Dependability): สร้างความไว้วางใจให้เกิดขึ้นในทีม โดยผู้จัดการต้องทำเป็นแบบอย่างให้เห็นว่ารับปากอะไรแล้วต้องทำได้จริง และส่งมอบงานที่มีคุณภาพตรงเวลา
โครงสร้างและความชัดเจน (Structure and clarity): ลดความสับสนในการทำงานด้วยเครื่องมืออย่าง OKR ในการตั้งเป้าหมาย หรือใช้ (( RACI matrix - ตารางตกลงความรับผิดชอบในเนื้องาน เพื่อให้ชัดเจนว่าใครเป็นคนลงมือทำ (Responsible) ใครเป็นคนรับผิดชอบผลลัพธ์/อนุมัติ (Accountable) ใครทำหน้าที่ให้คำปรึกษา (Consulted) และใครที่เพียงแค่ต้องรับทราบ (Informed) ))
ความหมายของงาน (Meaning): ผู้จัดการมีหน้าที่ช่วยหามุมมอง หรือผูกเรื่องราวให้พนักงานแต่ละคนสัมผัสได้ว่า งานที่เขาทำอยู่นั้นมีความหมายต่อตัวเขาเองอย่างไร
ผลกระทบของงาน (Impact): ชี้ให้เห็นว่าผลงานของทีมไปตอบโจทย์ใหญ่ขององค์กร หรือไปสร้างการเปลี่ยนแปลงที่ดีให้กับผู้ใช้งานจริงได้อย่างไรบ้าง

ส่วนที่ 3: หลุมพรางที่ต้องระวัง (Common Pitfalls) ข้อควรระวังสำคัญคือ หลายคนเข้าใจผิดว่าการสร้างความรู้สึกปลอดภัยทางจิตวิทยาหมายถึงการลดมาตรฐานการทำงาน หรือยอมให้พฤติกรรมที่ไม่ดีเกิดขึ้นเพื่อให้คนในทีมสบายใจ แต่ความเข้าใจนี้ไม่ถูกต้อง ผู้เขียนย้ำว่า มาตรฐานการทำงานและความรู้สึกปลอดภัยต้องสูงทั้งคู่ ทีมจึงจะกล้าแสดงความคิดเห็น กล้าโต้แย้ง และกล้าเตือนกันเพื่อให้ได้ผลลัพธ์ที่ดีที่สุด

หากต้องการเริ่มพัฒนาบรรยากาศในทีม ลองประยุกต์ใช้แนวคิดแบบ (( gTeams exercise - แบบสอบถามสั้น ๆ 10 นาทีที่ให้สมาชิกประเมินบรรยากาศการทำงานในทีมทั้ง 5 ด้าน แล้วนำผลคะแนนมาพูดคุยกันอย่างเปิดใจเพื่อหาทางปรับปรุง )) Google พบว่าเพียงการปรับพฤติกรรมเล็ก ๆ น้อย ๆ เช่น เริ่มประชุมด้วยการถามไถ่เรื่องทั่วไป (Casual chat) ก่อนเข้าเรื่องงาน ก็ช่วยเพิ่มคะแนนความรู้สึกปลอดภัยในทีมได้อย่างเป็นรูปธรรม

Common Effectiveness Antipatterns

(( Antipattern - พฤติกรรมหรือการแก้ปัญหาที่ทำซ้ำ ๆ ซึ่งผิวเผินดูเหมือนเป็นเรื่องดีหรือเป็นความขยัน แต่จริง ๆ แล้วไม่ได้ผลและยังสร้างผลเสียในระยะยาว ))

1. ปัญหาระดับบุคคล (Individual Antipatterns) เป็นปัญหาที่เกิดจากพฤติกรรมส่วนตัวของสมาชิกในทีม ซึ่งมักเริ่มต้นจาก “ความหวังดี” แต่อาจส่งผลร้ายได้หากไม่มีขอบเขต:

The Specialist (ผู้เชี่ยวชาญผูกขาด): คนที่รู้ลึกรู้จริงแต่ทำงานอยู่กับโมดูลเดียวจนไม่มีใครกล้าแตะ ทำให้กลายเป็น (( SPOF (Single Point of Failure) - จุดเปราะบางของระบบหรือโปรเจกต์ หากคนคนนี้ไม่อยู่หรือลาพักร้อน งานส่วนนั้นจะหยุดชะงักและพังลงทันที )) ผู้นำควรสร้างคนสำรองให้มีความรู้ตามทันอย่างน้อย 60–80%
The Generalist (เป็ดผู้รู้กว้างแต่ไม่ลึก): คนที่ชอบกระโดดไปช่วยทำทุกอย่างจนไม่มีความเชี่ยวชาญเฉพาะด้านเลย สร้างภาพลวงตาว่าเก่งแต่ขาดความรู้เชิงลึก เป้าหมายที่ควรปรับคือการสร้างให้เขามี (( T-shaped skill set - โครงสร้างทักษะในอุดมคติ ที่รู้ลึกเชี่ยวชาญในสายงานตัวเอง 1 ด้าน (แกนตั้ง) แต่ก็มีความรู้กว้างพอที่จะประสานงานกับสายงานอื่นได้ (แกนนอน) ))
The Hoarder (นักดองงาน): คนที่ชอบเก็บงานไว้ทำคนเดียวเงียบ ๆ แล้วค่อยส่งทีเดียวเป็นก้อนใหญ่ ๆ ก่อนหมดเวลา ทำให้คนอื่นตรวจงานไม่ทันและเกิดปัญหาตอนรวมโค้ด
The Relentless Guide (พี่เลี้ยงใจดีเกินเหตุ): คนที่กระตือรือร้นชอบเข้าไปช่วยแก้ปัญหาหรือป้อนคำตอบให้คนอื่นจนเสร็จสรรพ กลายเป็นว่าเพื่อนร่วมทีมคิดเองไม่เป็นและขาดความสามารถในการพึ่งพาตัวเอง
The Trivial Tweaker (นักแก้จุกจิก): คนที่ชอบส่งการแก้โค้ดเล็ก ๆ น้อย ๆ ที่ไม่ได้สำคัญต่อภาพรวม ทำให้ทีมเสียเวลาไปกับการตรวจงานที่ไม่ได้สร้างคุณค่า

2. ปัญหาจากกระบวนการทำงาน (Practice-Related Antipatterns) เป็นปัญหาที่มาจากข้อบกพร่องในระบบขั้นตอนการทำงาน ซึ่งต้องแก้ด้วยความร่วมมือของทั้งทีม:

Last-Minute Heroics (ฮีโร่นาทีสุดท้าย): การเร่งปั่นงานหรือกู้สถานการณ์แก้บั๊กแบบไฟลนก้นก่อนปล่อยงาน ซึ่งดูน่าประทับใจ แต่จริง ๆ สะท้อนการวางแผนที่ย่ำแย่และการซ่อนปัญหาไว้ใต้พรม
PR Process Irregularities (กระบวนการตรวจโค้ดผิดเพี้ยน): เช่น การอนุมัติงานให้กันแบบผ่าน ๆ (( Rubber-stamping - การอนุมัติงานโดยไม่ได้ตรวจสอบรายละเอียดจริง ๆ )), การอนุมัติงานของตัวเองโดยไม่ผ่านคนอื่น หรือการปล่อยให้งานค้างรอตรวจนานเกินไป
Protracted Refactoring (การรื้อโค้ดที่ไม่มีวันจบ): การพยายามปรับปรุงโค้ดที่ขยายขอบเขตไปเรื่อยๆ ตามความต้องการความสมบูรณ์แบบ จนดึงทรัพยากรและเวลาจากงานหลัก
Retrospective Negligence (การละเลยการประชุมย้อนหลัง): การมองข้ามหรือทำแบบขอไปทีกับการประชุมสะท้อนผลการทำงาน ทำให้อดเห็นปัญหาที่แท้จริง ควรแก้ด้วยการเจาะลึกหาต้นตอโดยใช้เทคนิค (( Five whys - การตั้งคำถามว่า “ทำไม” ต่อเนื่องกัน 5 ครั้งเพื่อเจาะลึกหาสาเหตุรากเหง้าของปัญหา ))

3. ปัญหาเชิงโครงสร้าง (Structural Antipatterns) เกิดจากการจัดโครงสร้างการทำงานในทีมที่ทำให้ความรู้ไม่กระจายตัว:

Isolated Clusters (กลุ่มคนทำงานแบบปิด): การจับกลุ่มย่อยในทีมที่คุยและตรวจงานกันเอง ไม่สุงสิงกับคนนอกกลุ่ม ทำให้เกิดกำแพงความรู้และขาดมุมมองที่หลากหลาย
Knowledge Bottlenecks (คอขวดของความรู้): ความรู้สำคัญ ๆ กระจุกตัวอยู่กับคนเพียงไม่กี่คน ส่งผลให้ทีมมีค่า (( Bus Factor - จำนวนคนที่ต้องหายไปก่อนที่โปรเจกต์จะพัง ยิ่งค่านี้น้อย โปรเจกต์ก็ยิ่งมีความเสี่ยงสูง )) ต่ำเกินไป ผู้นำต้องแก้ด้วยการจับคู่ทำงานหรือสลับหมุนเวียนหน้าที่กัน

4. ปัญหาจากการเป็นผู้นำ (Leadership Antipatterns) เกิดจากพฤติกรรมหรือการตัดสินใจของผู้จัดการเอง การแก้ปัญหากลุ่มนี้จึงมักต้องอาศัยผู้บริหารระดับสูงกว่าเข้ามาช่วยจัดการ:

Micromanagement (การจู้จี้จุกจิก): การควบคุมทุกกระเบียดนิ้วจนทีมหมดอิสระ ผู้นำที่ดีควรทำตัวเป็น (( Glass barrier - ผู้นำที่เป็นเหมือนกระจกใส คือยอมให้โปร่งใสพอที่ทีมจะเห็นเป้าหมายและข้อมูลที่จำเป็น แต่ทำหน้าที่เป็นเกราะป้องกันสิ่งรบกวนภายนอกไม่ให้มากระทบทีม ))
Scope Mismanagement (บริหารขอบเขตงานไม่ได้): ปล่อยให้มีคำขอปรับเปลี่ยนเนื้องานงอกขึ้นมาเรื่อยๆ จนทีมงานล้นมือและส่งงานไม่ทันกำหนด
Planning Overkill (วางแผนละเอียดเกินความจำเป็น): พยายามคิดเผื่อทุกรายละเอียดล่วงหน้ามากเกินไปจนทีมไม่ได้เริ่มลงมือทำ
Skeptical Leadership (ผู้นำขี้ระแวง): แสดงความไม่มั่นใจในตัวทีมโดยไม่มีเหตุผล คอยตั้งคำถามกับเทคโนโลยีหรือการตัดสินใจของทีมจากข่าวลือ ทำให้ลูกทีมเสียกำลังใจ
Passive Leadership (ผู้นำลอยตัว): ผู้นำที่หลีกเลี่ยงการตัดสินใจและไม่กล้าสร้างความเปลี่ยนแปลง จนกลายเป็น (( Absentee leader - ผู้นำที่มีตำแหน่งแต่เหมือนไม่มีตัวตน ไม่ได้ช่วยขับเคลื่อนหรือให้คำแนะนำใด ๆ แก่ทีม ))
Underappreciation (การมองข้ามความดีความชอบ): ละเลยที่จะชื่นชมพฤติกรรมดีๆ หรือผลงานของลูกทีม ทำให้คนที่ตั้งใจทำงานเงียบๆ รู้สึกไร้ตัวตนและหมดไฟในที่สุด

แก่นสำคัญของบทนี้คือ พฤติกรรมที่ทำให้ทีมไร้ประสิทธิภาพมักแฝงตัวมาในรูปแบบของ “พฤติกรรมที่ดูเหมือนจะดี” ผู้นำจึงต้องรู้ทันรูปแบบเหล่านี้และหาทางป้องกัน ก่อนที่ปัญหาจะลุกลามไปทั่วทั้งทีม

Effective Managers

บทบาทเชิงปฏิบัติการ (Operational Role) ของผู้จัดการ (Manager) แตกต่างจากบทบาทผู้นำ (Leader) ที่เน้นเรื่องวิสัยทัศน์ ผู้จัดการจะเน้นการวางแผน จัดระเบียบ และดูแลให้ทีมเดินหน้าได้อย่างราบรื่น

1. การเปลี่ยนผ่านจากวิศวกรสู่ผู้จัดการ (From Engineering to Management) เมื่อเลื่อนขั้นเป็นผู้จัดการ สิ่งสำคัญที่สุดคือการเปลี่ยนกรอบความคิดจาก “ตัวฉัน (Me)” เป็น “พวกเรา (We)” ผู้จัดการต้องเลิกเป็นผู้เล่นดาวเด่นที่คอยแก้ทุกปัญหาด้วยตัวเอง แล้วเปลี่ยนบทบาทเป็น “โค้ช” หรือ วาทยกรควบคุมวงดนตรี ที่ไม่ได้เล่นเครื่องดนตรีเอง แต่ทำให้ทุกคนเล่นประสานกันจนเกิดผลงานที่ดีที่สุด

ต้องรู้จักอดทนรอผลลัพธ์: การเขียนโค้ดมักให้ความรู้สึกสำเร็จทันที แต่ผลลัพธ์ของงานบริหาร เช่น การสร้างความไว้วางใจในทีม ต้องใช้ (( Delayed gratification - การอดทนรอคอยผลลัพธ์ที่จะเกิดในระยะยาว ซึ่งต่างจากการทำงานเทคนิคที่มักจะเห็นผลลัพธ์ทันทีเมื่อทำเสร็จ ))
ระวังกับดักคนเก่ง: ผู้จัดการมือใหม่มักจะเผลอลงไปจัดการทุกรายละเอียดทางเทคนิคเพราะความเคยชิน ซึ่งจะนำไปสู่พฤติกรรม (( Micromanagement - การเข้าไปควบคุมหรือสั่งการลูกทีมในทุกรายละเอียดปลีกย่อยจนทีมขาดอิสระในการคิดและตัดสินใจเอง ))

2. การเริ่มต้นบทบาทใหม่ (Getting Started) การเริ่มบทบาทใหม่มักมาพร้อมความรู้สึกไม่เก่งพอ (Imposter syndrome) ซึ่งเป็นเรื่องปกติ ในช่วงสัปดาห์แรก ๆ ไม่ต้องรีบเร่งเต็มที่ แต่ควรโฟกัสที่การทำความรู้จักทีมแบบตัวต่อตัว ประเมินสถานะโปรเจกต์ ทำความเข้าใจเทคโนโลยีที่ทีมใช้ จัดการปัญหาเร่งด่วน และสร้างผลงานเล็ก ๆ ให้สำเร็จเร็ว (Quick wins) เพื่อสร้างความมั่นใจให้ทีม

3. กลยุทธ์และการบริหารเวลา (Defining a Strategy & Managing Time) การกำหนดกลยุทธ์ควรมีเป้าหมายระยะยาวที่เป็นเหมือน (( North Star - ดาวเหนือ หรือเป้าหมายวิสัยทัศน์หลักที่คอยนำทางให้ทุกการตัดสินใจของทีมไปในทิศทางเดียวกัน )) และเมื่อต้องบริหารเวลาที่มักถูกรบกวนอยู่เสมอ ควรใช้วงจร วางแผน -> ลงมือทำ -> ประเมินผล (Plan -> Execute -> Assess) ดังนี้:

วางแผน (Plan): ใช้เทคนิค (( Time blocking - การแบ่งเวลาโดยจองช่วงเวลาเฉพาะบนปฏิทินให้แต่ละงานอย่างชัดเจน เหมือนการนัดประชุมกับตัวเองและห้ามใครกวน )) และ (( Chunking - การจัดกลุ่มงานที่คล้ายกันมาทำรวดเดียวในบล็อกเวลาเดียว เพื่อลดการเสียเวลาและพลังสมองจากการต้องสลับบริบทการทำงานไปมา ))
ลงมือทำ (Execute): รู้จักกระจายงาน (Delegate) ให้คนในทีม และหัดปฏิเสธงานที่ไม่ตรงกับเป้าหมายหลัก
ประเมินผล (Assess): ทำ (( Calendar audit - การตรวจสอบปฏิทินการทำงานย้อนหลัง เพื่อประเมินว่าเราใช้เวลาไปกับงานที่ตรงตามเป้าหมายสำคัญจริง ๆ หรือไม่ หากไม่ใช่ก็ควรปรับเปลี่ยน ))

4. หัวใจของการสื่อสาร (Communication Essentials) ความสม่ำเสมอ (Consistency) คือสิ่งสำคัญที่สุด สิ่งที่พูดในที่ประชุมกับสิ่งที่มอบหมายในระบบต้องตรงกัน มิฉะนั้นความไว้วางใจจะพังทลาย

การคุยแบบ 1-on-1: ต้องเน้นที่ตัวพนักงานและการเติบโตของเขา ไม่ใช่แค่ตามงาน ผู้จัดการต้องใช้ทักษะการฟังอย่างตั้งใจ (Active listening) และอย่ารีบด่วนให้คำตอบ แต่ควรตั้งคำถามปลายเปิดเพื่อโค้ชให้เขาคิดหาทางออกเองได้
เลือกช่องทางให้ถูก: ใช้อีเมลกับงานที่เป็นทางการหรือต้องการบันทึกไว้ ใช้แชตสำหรับเรื่องด่วนหรือถามตอบสั้น ๆ และห้ามให้ฟีดแบ็กด้านลบในที่สาธารณะเด็ดขาด

5. การบริหารคน (People Management)

การจ้างงาน: หากต้องเลือก ให้ความสำคัญกับ “ทัศนคติ” มากกว่า “ทักษะเทคนิค” เพราะคนที่ทำงานร่วมกับคนอื่นไม่ได้จะสร้างผลเสียต่อทั้งทีม
การประเมินผล: อย่าดูแค่ตัวเลขผลงาน แต่ต้องคุยไปถึงเป้าหมายอาชีพ การพัฒนาทักษะ และสมดุลชีวิตการทำงานด้วย
เมื่อคนจะออก: หากคนในทีมจะลาออก ให้จัดการอย่างเข้าใจและทำ Exit interview เพื่อหาข้อควรปรับปรุง และควรป้องกันล่วงหน้าด้วยการทำ (( Stay interview - การสัมภาษณ์พูดคุยกับพนักงานที่ยังทำงานอยู่เชิงรุก เพื่อค้นหาความต้องการหรือปัญหาที่ซ่อนอยู่ และหาทางแก้ไขก่อนที่พวกเขาจะตัดสินใจลาออก ))
การพัฒนาคน: สนับสนุนให้เกิดการเรียนรู้ในทีม โดยทำความเข้าใจความต่างระหว่าง (( Mentorship - ความสัมพันธ์ระยะยาวที่ผู้มีประสบการณ์มากกว่า (Mentor) คอยให้คำแนะนำและสนับสนุนในภาพรวม )) และ (( Coaching - ความสัมพันธ์ระยะสั้นที่โค้ชช่วยให้ผู้ถูกโค้ชบรรลุเป้าหมายเฉพาะเจาะจงเรื่องใดเรื่องหนึ่ง ))

6. การผลักดันทีมให้เติบโต (Managing Dynamics & Growth) ผู้จัดการต้องหาวิธีผลักดันให้ทีมเก่งขึ้นอยู่เสมอ หากเป็นช่วงที่งานน้อย ลองหาโปรเจกต์เล็ก ๆ (Mini-project) ให้ทำเพื่อพัฒนาเครื่องมือใหม่ ๆ หรือหากเป็นช่วงที่งานยุ่งมาก ก็ยังสอดแทรกการเรียนรู้ผ่านการตรวจโค้ดร่วมกัน (Code review) หรือแบ่งเวลาเรียนรู้วันละ 10–15 นาทีได้ และหากเกิดความขัดแย้งในทีม อย่าปล่อยผ่าน แต่ควรรีบจัดการและเปลี่ยนความขัดแย้งให้เป็นโอกาสในการหาทางออกที่ตอบโจทย์ทุกฝ่าย

7. การสร้างเครือข่าย (Networking Essentials) การสร้างคอนเนกชันกับคนทั้งในและนอกองค์กรเป็นสิ่งสำคัญที่ควรทำอย่างสม่ำเสมอ (อย่างน้อยไตรมาสละครั้ง) ไม่ใช่ทำเฉพาะตอนที่ต้องการความช่วยเหลือ เพราะเครือข่ายที่ดีช่วยให้เราแลกเปลี่ยนความรู้ หาทางแก้ปัญหา และเปิดโอกาสใหม่ ๆ ในอนาคต

Becoming an Effective Leader

การยกระดับตัวเองจาก “ผู้จัดการ” สู่ “ผู้นำ” เพื่อขยายผลความสำเร็จ (Expand) ไปสู่ทีมและองค์กร:

1. ความแตกต่างระหว่างผู้นำ (Leader) กับผู้จัดการ (Manager) หลายคนมักสับสนสองคำนี้ แต่จริง ๆ แล้วบทบาททั้งสองแตกต่างกันและควรทำงานร่วมกันเพื่อเสริมจุดแข็งของกันและกัน

ผู้จัดการ (Manager): เน้นสร้างความเป็นระเบียบและสม่ำเสมอ (Order & Consistency) ผ่านการวางแผน จัดงบประมาณ และแก้ปัญหาเพื่อให้งานเดินหน้าได้อย่างราบรื่น
ผู้นำ (Leader): เน้นสร้างการเปลี่ยนแปลงและการขับเคลื่อน (Change & Movement) ด้วยการสร้างวิสัยทัศน์ จูงใจ และสร้างแรงบันดาลใจให้ทีมพร้อมรับมือกับสิ่งใหม่ ๆ ผู้นำที่ดีมักมีทักษะการจัดการที่ดีอยู่แล้ว โดยเส้นแบ่งนี้จะจางลงเมื่อเรานำทักษะทั้งสองมารวมกัน

2. 3 เส้นทางสายผู้นำของวิศวกรซอฟต์แวร์ เมื่อวิศวกรเติบโตขึ้น มักมีเส้นทางให้เลือก 3 รูปแบบหลัก ได้แก่:

Technical Lead: เน้นลุยงานเทคนิค นำการออกแบบสถาปัตยกรรมระบบ ตั้งมาตรฐานการเขียนโค้ด และเป็นพี่เลี้ยงสอนงานเทคนิคให้คนในทีม
Engineering Manager: เน้นบริหารคนและโปรเจกต์ ดูแลการเติบโตของพนักงาน จัดการกระบวนการทำงาน ประสานงาน และขจัดอุปสรรคให้ทีมทำงานได้สะดวก
Tech Lead Manager (TLM): (( TLM (Tech Lead Manager) - บทบาทที่ผสมผสานการนำทีมเทคนิค การบริหารโปรเจกต์ และการบริหารคนเข้าด้วยกัน มักใช้ในทีมขนาดเล็กที่ต้องการคนดูแลทั้งภาพรวมและรายละเอียด )) บทบาทนี้ท้าทาย เพราะต้องรักษาสมดุลไม่ให้เอนเอียงไปด้านใดด้านหนึ่งมากเกินไป

3. การสำรวจและประเมินทักษะผู้นำของตัวเอง ผู้นำต้องมีทักษะสำคัญ 2 กลุ่ม ได้แก่:

ทักษะที่ขาดไม่ได้ (Critical Traits): ได้แก่ ความเชี่ยวชาญทางเทคนิค (Technical expertise) ที่ต้องแน่นพอจะช่วยทีมแก้ปัญหาได้, ความคล่องตัว (( Agility - ความสามารถในการเรียนรู้ ละทิ้งความรู้เดิมที่ล้าสมัย และปรับตัวรับมือกับสถานการณ์ที่เปลี่ยนแปลงได้อย่างรวดเร็ว )), และทักษะการสื่อสารที่สามารถอ้างอิงตามหลัก (( 7 C’s - หลักการสื่อสาร 7 ข้อ ได้แก่ Clear (ชัดเจน), Concise (กระชับ), Concrete (เป็นรูปธรรม), Correct (ถูกต้อง), Coherent (สอดคล้อง), Complete (ครบถ้วน), และ Courteous (สุภาพ) ))
ทักษะเสริมบารมี (Desirable Traits): เช่น ความมีคุณธรรม (Integrity) ความถ่อมตัว (Humility) ที่กล้ายอมรับข้อผิดพลาดและรับฟังคนอื่น ความกล้าหาญ (Courage) ในการตัดสินใจเรื่องยาก ๆ และการมีอิทธิพลต่อผู้อื่น (Influence) ที่ทำให้คนอยากทำตามเพราะความเชื่อใจ ไม่ใช่เพราะตำแหน่ง ที่สำคัญคือต้องมี Self-awareness ซึ่งจะรู้ได้จากการขอฟีดแบ็กจากคนที่กล้าพูดความจริงกับเรา

4. การปรับสไตล์การเป็นผู้นำ (Leadership Styles) ผู้นำที่เก่งจะไม่ใช้สไตล์เดียวกับทุกเรื่อง แต่รู้จักใช้ (( Situational leadership - การเลือกหรือปรับเปลี่ยนสไตล์การเป็นผู้นำให้เหมาะสมกับสถานการณ์ ความเร่งด่วน และบริบทของทีมในเวลานั้น )) โดยสไตล์ที่มักพบ ได้แก่:

Transformational: เน้นสร้างแรงบันดาลใจและกระตุ้นให้เกิดนวัตกรรม พร้อมท้าทายกรอบการทำงานเดิม ๆ
Democratic: เน้นเปิดรับฟังความเห็น ให้ทุกคนมีส่วนร่วมในการตัดสินใจ
Servant: (( Servant leadership - สไตล์ความเป็นผู้นำที่เน้นการรับใช้ทีม ให้ความสำคัญกับความต้องการและการเติบโตของลูกทีมเป็นอันดับแรก เพื่อสนับสนุนให้ทีมทำงานได้ดีที่สุด ))

5. การวางกลยุทธ์ (Strategizing) ผู้นำต้องวาดภาพอนาคตให้ชัดและสร้างแผนงาน (Roadmap) ที่ยืดหยุ่นและวัดผลได้ สิ่งสำคัญที่สุดคือการทำ (( Ruthless prioritization - การจัดลำดับความสำคัญอย่างเด็ดขาด โดยเลือกทำเฉพาะงานสำคัญ 3–5 อย่างที่ตอบโจทย์วิสัยทัศน์สูงสุด และต้องกล้าปฏิเสธงานอื่น ๆ ที่ไม่เกี่ยวข้อง )) ผู้นำต้องรู้จักปฏิเสธเพื่อปกป้องเวลาไว้ทำสิ่งที่สร้างผลกระทบได้มากที่สุด

6. การลงมือทำและวางตัวให้เหมาะสม (Playing the Part)

สื่อสารอย่างไม่ลดละ: ต้องอัปเดตเป้าหมาย บริบท หรืออุปสรรคให้ทีมรับรู้อยู่เสมออย่างโปร่งใส
สร้างพื้นที่ปลอดภัย: เมื่อมีคนยกปัญหามาพูด ผู้นำต้องเปลี่ยนจากการหาตัวคนผิด เป็นการตั้งคำถามด้วยความอยากรู้และขอบคุณที่เขากล้าพูดปัญหาออกมา
พัฒนาดาวเด่นในทีม: เลิกคิดว่าตัวเองต้องทำทุกอย่าง แต่ควรรู้จักกระจายงาน (Delegate) และโค้ชให้ลูกทีมเก่งขึ้น ซึ่งเป็นการขยายขีดความสามารถของตัวเองไปด้วย

7. การปรับทัศนคติและพฤติกรรม (Mastering the Attitude)

ให้อิสระควบคู่กับขอบเขต: ผู้นำต้องเชื่อใจทีมและมอบความเป็นอิสระ แต่ต้องไม่ลืมที่จะสร้าง (( Guardrails - ขอบเขตหรือกฎเกณฑ์การทำงานที่ตั้งไว้ เช่น ช่องทางการสื่อสารที่ชัดเจน หรือมาตรฐานการเขียนโค้ด เพื่อให้ทีมสามารถใช้อิสระในการตัดสินใจได้อย่างมีความรับผิดชอบและไม่หลุดกรอบ ))
บริหารด้วยข้อมูล: ใช้ตัวชี้วัดที่ชัดเจน เช่น ความเร็วในการทำงาน (Velocity) หรือความหนาแน่นของบั๊ก (Defect density) มาช่วยในการตัดสินใจแทนการใช้แค่สัญชาตญาณ
รับมือกับการเปลี่ยนแปลง: ใช้หลักการ (( 4 A’s of adaptive leadership - ขั้นตอนการรับมือความเปลี่ยนแปลง 4 ด้าน ได้แก่ Anticipation (คาดการณ์ล่วงหน้า), Articulation (สื่อสารวิสัยทัศน์ให้ทีมเข้าใจ), Adaptation (ปรับตัวหรือปรับโครงสร้างทีม) และ Accountability (รับผิดชอบต่อผลลัพธ์) ))

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