หลายคนมักนำตรรกะเดียวกัน มาใช้ในการบริหารทีม โดยพยายามสร้าง "ความเท่าเทียม" ด้วยการปฏิบัติกับทุกคนเหมือนกันเป๊ะๆ ไม่ว่าจะเป็นการแจกงานในปริมาณที่เท่ากัน หรือ การเข้าไป Micro-manage ทุกคนด้วยมาตรฐานเดียวกันเพราะกลัวข้อครหาเรื่องความลำเอียง
แต่ในโลกของความเป็นจริง การบริหารทีมแบบ "One size fits all" คือ ความผิดพลาดที่ร้ายแรงที่สุดอย่างหนึ่งของ Leader สิ่งที่คนส่วนใหญ่พลาด คือ การตีความคำว่ายุติธรรมผิดไป ความยุติธรรมที่แท้จริงไม่ใช่การปฏิบัติกับทุกคนเหมือนกัน แต่ คือ การปฏิบัติต่อบุคคลให้เหมาะสมกับ "ความพร้อม" ของเขาในแต่ละสถานการณ์ นี่ คือ หัวใจของ Situational Leadership ซึ่งไม่ใช่เรื่องของการรับมือวิกฤตน้ำท่วมไฟไหม้ แต่เป็นเรื่องการรับมือความพร้อมของ "คน" ที่มีต่อ "งาน" ที่เปลี่ยนไปในทุกๆ วัน
แกนวัดความพร้อม: แผนภูมิ Can vs. Want ที่คนทำงานมักมองข้าม
ในการประเมินลูกน้อง เราไม่ควรประเมินคนแบบเหมาเข่งว่า "คนนี้เก่ง" หรือ "คนนี้ไม่เก่ง" แต่ต้องประเมินเป็นรายชิ้นงาน (Task-based) โดยใช้ 2 แกนหลักตามระดับความพร้อม (Readiness)
- แกนตั้ง - ความสามารถ (Ability/Can): วัดจากความรู้ ทักษะ และประสบการณ์ (ทำได้ไหม?)
- แกนนอน - ความเต็มใจ (Willingness/Want): วัดจากพลังงาน ความกระตือรือร้น และใจที่อยากจะทำ (อยากทำไหม?)
ในฐานะ Manager คุณต้องมองคนให้เหมือนกับ Component ในระบบ คนหนึ่งคนไม่จำเป็นต้องมีระดับความพร้อมเดียวในทุกงาน วิศวกรระดับ Senior ของคุณอาจเป็น R4 ที่ไว้ใจได้ที่สุดในการเขียน Backend ด้วย Python (Can สูง, Want สูง) แต่เขาอาจกลายเป็น R1 ทันทีเมื่อต้องเขียนเอกสารเพื่อทำ SOC2 Compliance (Can ต่ำ, Want ต่ำ) หากคุณประเมินความพร้อมผิดและปล่อยให้เขาทำเอกสารโดยไม่กำกับดูแล ระบบการทำงานของคุณจะเกิดคอขวด (Bottleneck) ทันที
ถอดรหัสลูกน้อง 4 แบบ (R1 - R4) และ กลยุทธ์การบริหาร
เมื่อเรานำ 2 แกนมาพล็อต เราจะพบความพร้อม 4 ระดับที่ต้องการสไตล์การนำที่ต่างกันอย่างสิ้นเชิง
- R4 (Can สูง, Want สูง): กลุ่มดาวเด่นไฟแรง
- สไตล์: Empower (ให้อำนาจ) บอกเป้าหมายที่ชัดเจนแล้วถอยออกมา อย่าเป็นคอขวดในกระบวนการ Pull Request (PR) ของเขา อย่าจุกจิก แต่ต้องคอยซัพพอร์ตห่างๆ การเข้าไปวุ่นวายกับ R4 มากเกินไปจะทำให้เขาเบื่อและรู้สึกว่าคุณไม่ไว้วางใจ
- R3 (Can สูง, Want ต่ำ): กลุ่มมือเก่าไฟตก
- สไตล์: Ask (ใช้การตั้งคำถาม) เขาเก่งอยู่แล้ว อย่าไปสอนงานเขา แต่ต้องตั้งคำถามเพื่อหาต้นตอของปัญหาใจ เช่น ผิดหวังเรื่องผลประเมิน หรือเบื่อ Legacy Code เดิมๆ
- R2 (Can ต่ำ, Want สูง): กลุ่มน้องใหม่ไฟแรง
- สไตล์: Explain (ชี้แนะ) เช่น น้องใหม่ที่อยากลองทำ Vector Database แม้จะยังไม่มีประสบการณ์ คุณไม่ต้องกระตุ้นใจเขาเพราะเขามีเต็มเปี่ยม แต่คุณต้อง "สอน" ไกด์วิธีการทำงาน และอธิบาย "How" ให้ชัดเจน
- R1 (Can ต่ำ, Want ต่ำ): กลุ่มไม้ตายซาก (Deadwood)
- สไตล์: Tell/Sell (สั่งการและจูงใจ) นี่ คือ กลุ่มที่น่าปวดหัวที่สุดเพราะทั้งทำไม่เป็นและไม่อยากทำ
- กฎเหล็ก: สำหรับ R1 คุณต้อง เคลื่อนแกน "Want" ก่อนแกน "Can" เสมอ อย่าส่ง R1 ไปเรียนคอร์สเทคนิคราคาแพง (Can) ตราบใดที่เขายังไม่อยากทำ (Want) เพราะจะเสียเวลาเปล่า คุณต้องสื่อสารว่า "ทำไม" งานนี้ถึงสำคัญต่อเขาและทีม เพื่อดึงใจเขากลับมาให้ได้ก่อน
Deep Dive: เทคนิคการถามแบบ "ตัว T" (T-Question) สำหรับกลุ่ม R3
การจัดการกลุ่ม R3 คือ ความท้าทายที่สุด ผู้นำที่ดียังไม่ควรรีบ "รักษา" หรือ เสนอทางแก้ทันที แต่ต้องทำตัวเหมือน "คุณหมอ" ที่ถามอาการอย่างละเอียดก่อนจ่ายยา โดยใช้เทคนิคคำถามตัว T
- แนวราบ (Wide): ถามกว้างๆ เพื่อเปิดประเด็น
- แนวตั้ง (Deep): ถามลึกลงไปเมื่อเจอจุดที่น่าสงสัย
สิ่งที่หัวหน้าส่วนใหญ่ทำ (รีบรักษา) | สิ่งที่หัวหน้าที่ดีควรทำ (ถามแบบหมอ) |
เมื่อลูกน้องบอกว่า "งานยุ่ง/Velocity ตก" -> รีบสอนวิธีจัด Priority หรือดุเรื่องวินัย | ถามกว้าง (Wide): "ผมเห็น Velocity ของ Module นี้ลดลง นอกจากความซับซ้อนของ Code แล้ว มีปัจจัยอื่นไหม?" |
เมื่อลูกน้องบ่ายเบี่ยงการทำ On-call -> รีบโน้มน้าวด้วยเหตุผลของบริษัท | ถามลึก (Deep): "ที่บอกว่าติดธุระบ่อยๆ จริงๆ แล้วกังวลเรื่องการแก้ปัญหาหน้างานตอนดึก หรือรู้สึกว่าผลตอบแทนไม่คุ้มกับความเหนื่อย?" |
รีบเสนอทางออกเพื่อให้จบการสนทนา | ถามกว้างซ้ำ (Return to Wide): "นอกจากเรื่องเนื้องานแล้ว มีประเด็นอื่นที่ทำให้เรารู้สึกไม่อยากแตะโปรเจกต์นี้อีกไหม?" |
บริหารจัดการ vs. ปล่อยปละละเลย: Trade-off ที่เลี่ยงไม่ได้
คำว่า "บริหารจัดการ" (Management & Administration) มีสองด้านที่ต้องรักษาสมดุล:
- การบริหาร (Manage): คือ การพยายามโค้ชและพัฒนาคนจาก R1 ไปสู่ R4 ตามกลยุทธ์ที่กล่าวไป
- การจัดการ (Administer): เมื่อเราพยายาม "บริหาร" อย่างสุดความสามารถแล้วแต่ "ไม้ตายซาก" ยังไม่ยอมแตกกิ่งก้านใหม่ เราต้องกล้าตัดสินใจจัดการ เช่น การโยกย้ายตำแหน่ง หรือแม้แต่การให้เขาออกจากทีม
ในฐานะผู้นำ คุณต้องแบกรับความรับผิดชอบนี้ เพราะ "การปล่อยคนที่ไม่ทำงานไว้เฉยๆ คือ การให้รางวัลคนทำไม่ดี" และนี่ คือ Opportunity Cost ที่มหาศาล การปกป้อง R1 ที่ไม่ยอมโต คือ การลงโทษ R4 ที่ตั้งใจทำงาน เพราะสุดท้ายคนเก่งจะต้องแบกงานหนักขึ้นจนเกิดอาการ Burnout และลาออกไปในที่สุด
การสร้างความเข้าใจในทีม: ทำอย่างไรไม่ให้ถูกมองว่า "ลำเอียง"
เพื่อไม่ให้เกิดข้อครหาว่าคุณมี "เด็กเส้น" หรือ "รักลูกน้องไม่เท่ากัน" คุณควรเปิดเผยแนวคิด Situational Leadership นี้ให้ทีมรับทราบอย่างโปร่งใส:
- ใช้ภาษาเดียวกัน: สอนทีมให้เข้าใจ R1-R4 เพื่อให้เขารู้ว่าทำไมสไตล์การ Manage ของคุณถึงเปลี่ยนไปตามเนื้องาน
- Self-Assessment: ในช่วง Sprint Planning หรือการรับโปรเจกต์ใหม่ (เช่น การ Migrate จาก Monolith ไป Microservices) ลองถามน้องๆ ว่า "งานนี้คุณประเมิน R-level ของตัวเองไว้ที่เท่าไหร่?"
- สื่อสารเหตุผล: อธิบายว่า "ที่ผมต้องลงรายละเอียดกับคุณในงานนี้ เพราะมันเป็นเรื่องใหม่สำหรับคุณ (R2) แต่ในงาน Coding ผมปล่อยคุณเต็มที่เพราะคุณ คือ มืออาชีพ (R4)"
บทสรุป: ความเป็นผู้นำ คือ การออกแบบระบบที่ยืดหยุ่น
การบริหารคนก็เหมือนการทำ System Design ที่ไม่มี Parameter ตายตัว คุณไม่สามารถใช้ Configuration เดียวกันกับทุก Microservice ได้ คนก็เช่นกัน ความเป็นผู้นำที่มีประสิทธิภาพ คือ ความยืดหยุ่นที่จะปรับสไตล์ตามความพร้อมของงานในขณะนั้น
ลองกลับไปสำรวจทีมของคุณเสมือนการทำ System Audit: "วันนี้ Nodes ในระบบของคุณ (ลูกน้อง) กำลังล้มเหลวเพราะ Capacity (Can) หรือเพราะ Connectivity (Want)?"
ความยุติธรรมที่แท้จริงไม่ใช่การมองทุกคนให้เหมือนกัน แต่ คือ การมองเห็นศักยภาพที่แตกต่าง และออกแบบวิธีการทำงานที่ช่วยให้แต่ละคนเติบโตได้ดีที่สุดในแบบของเขาครับ.