- ในสภาพแวดล้อมที่มี ผู้เชี่ยวชาญจากหลายสาขามารวมตัวกัน ผู้นำไม่ได้มีหน้าที่รู้รายละเอียดทางเทคนิคมากที่สุด แต่ต้อง เชื่อมโยงปัญหาและกำหนดทิศทางการแก้ไข
- ภาวะผู้นำให้ความสำคัญกับ ทักษะการแปลความและทักษะทางสังคม มากกว่าความรู้เชิงเทคนิคเพียงอย่างเดียว และต้อง ประสานสถานการณ์ความขัดแย้งพร้อมย้ำเป้าหมายร่วมกัน
- สิ่งสำคัญไม่ใช่ความเชี่ยวชาญลึกของแต่ละคน แต่คือการทำให้ นิยามปัญหาจริงและทิศทางการแก้ไข ชัดเจน และทำให้การอภิปรายเชื่อมไปสู่ความต้องการของผู้ใช้และผลลัพธ์
- ผู้นำที่มีประสิทธิภาพจะไม่แกล้งทำเป็นรู้ทุกอย่าง แต่มี ความกล้าที่จะพูดว่า “ไม่รู้” และสร้างพื้นที่ให้ผู้เชี่ยวชาญมีส่วนร่วมได้อย่างเต็มที่
- คุณค่าที่แท้จริงของผู้นำอยู่ที่ การแปลมุมมอง การให้บริบทของปัญหา และการสร้างพื้นที่สำหรับความร่วมมือ ซึ่งเป็นปัจจัยสำคัญที่นำไปสู่ผลงานที่ดีที่สุด
สิ่งที่เพิ่งตระหนักได้ไม่นานนี้
- อยู่ในห้องประชุมร่วมกับ นักพัฒนาผู้เชี่ยวชาญและทีมผลิตภัณฑ์ จากหลากหลายสายงาน
- แม้ฉันจะไม่ได้มี ความเชี่ยวชาญสูงสุด ในเทคโนโลยีใดเทคโนโลยีหนึ่ง แต่กำลังทำหน้าที่เป็น หัวหน้านักพัฒนา
- บทบาทของฉันในฐานะผู้นำท่ามกลางผู้เชี่ยวชาญ ไม่ใช่การรู้ทุกคำตอบ แต่คือความสามารถในการ ค้นหาคำตอบและเชื่อมโยงมันเข้าด้วยกัน
Technical Leadership
- บทบาทของผู้นำไม่ใช่แค่ ความลึกของความรู้ทางเทคนิค แต่คือการเป็น นักแปลที่มีประสิทธิภาพ เพื่อเปิดการสื่อสารระหว่างทีม
- ไม่ว่าจะเป็นการอธิบายกำหนดการของทีมพัฒนาแบ็กเอนด์ หรือความต้องการจากทีมผลิตภัณฑ์ ผู้นำต้อง ตีความจากมุมมองของแต่ละฝ่ายเพื่อพาทีมทำงานร่วมกันได้
Leading is a Social Skill
- แค่ความน่าเชื่อถือทางเทคนิคอย่างเดียวไม่เพียงพอ ทักษะทางสังคม ต่างหากที่สร้างผลิตภาพที่แท้จริง
- จำเป็นต้องมีความสามารถในการอ่านบรรยากาศของการอภิปรายระหว่างนักพัฒนา และตัดสินใจว่า เมื่อไรควรไกล่เกลี่ยข้อถกเถียงหรือผลักให้เดินหน้าต่อ
- การสื่อสารที่มีประสิทธิภาพไม่ได้เกิดจากเอกสารเท่านั้น แต่เกิดจากการสนทนาเชิงรุกด้วย
Leading is Remembering the Goal
- ยิ่งเป็นผู้เชี่ยวชาญก็มักยิ่งจดจ่อกับรายละเอียดทางเทคนิค แต่ผู้นำต้อง โฟกัสที่เป้าหมายภาพรวม
- บทบาทสำคัญคือการกำหนดให้ชัดเจนว่า ไม่ใช่แค่ประเด็นทางเทคนิค แต่คือ ปัญหาแก่นแท้ของประสบการณ์ผู้ใช้ และเป้าหมายทางธุรกิจ
- หากไม่กำหนดแก่นของปัญหาให้ชัดเจน สมาชิกทีมอาจ พลาดประเด็นที่แท้จริง ไปตามวิธีวิเคราะห์ของแต่ละคน
- ผู้นำมีหน้าที่ แปลให้ทีมเข้าใจปัญหาอย่างถูกต้องและมองเห็นเป้าหมายเดียวกัน
Leading is Saying "I Don't Know"
- แทนที่จะทำเหมือนรู้ทุกคำตอบ ท่าทีแบบ "ไม่รู้ มาช่วยกันหาคำตอบ" จะสร้าง ความไว้วางใจและวัฒนธรรมที่เปิดกว้าง
- ท่าทีนี้เปิดโอกาสให้ผู้เชี่ยวชาญ ตั้งคำถามและถกเถียงกันได้ พร้อมเปิดพื้นที่ให้แต่ละคนแสดงศักยภาพ
- ผู้นำต้องมอบ สิทธิ์ในการตัดสินใจและสิทธิ์ในการพูด ให้กับผู้เชี่ยวชาญในแต่ละหัวข้อ พร้อมกำหนดทิศทางของการอภิปรายให้เกิดประโยชน์
- เมื่อผู้เชี่ยวชาญสองคนเห็นต่างกันเรื่องวิธีการพัฒนา บทบาทของผู้นำไม่ใช่การเลือก "คำตอบที่ถูกต้อง" แต่คือ วางกรอบด้วยมุมมองเรื่อง trade-off และผลกระทบต่อผู้ใช้
The Translation Challenge
- ผู้นำต้องสามารถ แปลภาษาแบบนักพัฒนา ภาษาแบบทีมผลิตภัณฑ์ และภาษาแบบผู้บริหาร ให้เหมาะกับแต่ละสถานการณ์
- นักพัฒนา: "ถ้าไม่มี circuit breaker ที่เหมาะสมในบริการยืนยันตัวตน อาจเกิดความล้มเหลวต่อเนื่องเป็นลูกโซ่เมื่อระบบอยู่ภายใต้โหลด"
- ทีมผลิตภัณฑ์: "ถ้าระบบล็อกอินมีปัญหา อาจกระทบทั้งแอป จึงต้องเพิ่มกลไกป้องกัน และทำให้กำหนดการยืดออกไปหนึ่งสัปดาห์"
- ผู้บริหาร: "ในสปรินต์นี้ เราให้ความสำคัญกับเสถียรภาพของระบบก่อนเพื่อลดความเสี่ยงทางธุรกิจ"
- ไม่จำเป็นต้องให้ผู้เชี่ยวชาญ ต้องเรียนรู้ภาษาของทุกแผนก แต่ผู้นำต้องทำหน้าที่เป็นสะพานเชื่อมช่องว่างนั้น
Beyond "Because, that's why!"
- วิธีตัดสินใจแบบ "ฉันเป็นคนลี้ด ก็ทำแบบนี้" บ่อนทำลายความไว้วางใจและวัฒนธรรมการทำงานร่วมกัน อีกทั้งลดผลิตภาพของทีม
- สิ่งสำคัญคือการปฏิบัติต่อทีมอย่างเป็นผู้ใหญ่ และ อธิบายเหตุผลกับบริบทของการตัดสินใจให้ชัดเจน
- "เหตุผลที่เลือกแนวทางแบบระมัดระวังคือ เพราะต้นทุนหากผิดพลาดสูงมาก และเราค่อยปรับปรุงซ้ำได้ในภายหลัง"
- "อาจรู้สึกว่าเป็นงานเพิ่ม แต่สอดคล้องกับเป้าหมายด้านสถาปัตยกรรม และจะช่วยให้พัฒนาฟีเจอร์ถัดไปได้ง่ายขึ้น"
- "วิธีนี้อาจไม่ใช่ทางออกที่สวยงามที่สุด แต่เราสามารถปล่อยใช้งานได้อย่างมั่นใจภายในกำหนดเวลา"
- ยิ่งปล่อยวางความยึดติดกับความเป็นผู้เชี่ยวชาญได้มากเท่าไร ก็ยิ่งแสดง ภาวะผู้นำที่แท้จริง ได้มากขึ้น
คุณค่าที่ผู้นำควรมอบให้ทีม
- ให้ นิยามปัญหาที่ชัดเจน
- ให้ คำอธิบายบริบทของการตัดสินใจอย่างเพียงพอ
- แปลความต่างของมุมมอง ระหว่างทีม
- ปกป้องทีมจาก ความซับซ้อนที่ไม่จำเป็น
- สร้างสภาพแวดล้อมเพื่อผลลัพธ์ที่ดีที่สุด
บทสรุป
- ภาวะผู้นำทางเทคนิค ในองค์กรที่เต็มไปด้วยผู้เชี่ยวชาญ ไม่ได้เน้นการสั่งการและควบคุม แต่เน้น การเชื่อมโยงและการให้บริบท
- ผู้นำไม่ใช่นักดนตรีที่ลงมือเล่นเครื่องดนตรีเอง แต่เป็น วาทยกรที่ช่วยให้ออร์เคสตราบรรเลงบทเพลงหนึ่งจนสมบูรณ์
- นี่เป็นความท้าทายที่ น่าสนใจกว่า การพยายามเป็นคนที่ฉลาดที่สุดในห้องเสียอีก
4 ความคิดเห็น
คิดกลับกัน ในสภาพแวดล้อมที่ไม่มีผู้เชี่ยวชาญ ก็คงหลีกเลี่ยงไม่ได้ที่จะต้องกลายเป็นผู้เชี่ยวชาญเสียเอง
แน่นอนว่าก็มีความคิดว่าอยากเป็นผู้นำในด้านอื่นนอกเหนือจากการเป็นผู้นำทางเทคนิคด้วย แต่พอเจอเพื่อนร่วมทีมที่ไม่ค่อยแบ่งปันกัน ความเป็นจริงก็ทำให้แม้แต่แบบนั้นยังทำได้ยาก เลยรู้สึกว่าแต่ละสถานการณ์ก็ต่างกันไปครับ
มุมมองที่ยอดเยี่ยมมากครับ
ต้องทำงานแบบนี้นี่เอง
ความคิดเห็นบน Hacker News
ในฐานะหัวหน้าทีม ฉันพยายามหลีกเลี่ยงการตัดสินใจแบบ “ฉันเป็นหัวหน้า และเราจะตัดสินใจแบบนี้” ให้มากที่สุด แต่ก็อยากเน้นว่าหากจำเป็นก็ต้องกล้าใช้โดยไม่ลังเล ฉันใช้เวลาในการฟังความคิดเห็นของทุกคนและตัดสินใจอย่างรอบคอบ แต่เมื่อทีมตกอยู่ในวงจรถกเถียงไม่รู้จบเรื่องรายละเอียดที่ไม่ใช่สาระสำคัญ ก็ได้ตระหนักว่าในฐานะผู้นำจำเป็นต้องสร้างระเบียบขึ้นมา ฉันนึกทบทวนคำพูดที่ว่า Steve Jobs เคยพูดว่า “ถ้าอยากทำให้ทุกคนมีความสุข ก็อย่าเป็นผู้นำ ไปขายไอศกรีมแทน” หลังจากสถานการณ์แบบนี้ผ่านไปแล้ว สิ่งสำคัญคือต้องกลับมาสร้างความไว้วางใจใหม่ และอธิบายให้สมาชิกทีมเข้าใจว่าทำไมถึงจำเป็นต้องทำแบบนั้น
ฉันเองก็เรียนรู้บทเรียนนี้อย่างยากลำบาก ตอนที่ได้เป็นผู้จัดการครั้งแรก ฉันคิดอย่างไร้เดียงสาว่าจะหาฉันทามติจากทุกคนได้เสมอ และทีมจะรวมเป็นหนึ่งเองตามธรรมชาติ มันใช้ได้ในช่วงแรกกับทีมที่ยอดเยี่ยม แต่ต่อมาเมื่อได้ทำงานกับวิศวกรที่ยึดติดกับวิธีเมื่อ 25 ปีก่อนจากทีมอื่น ฉันก็เสียเวลาไปมากกับการรอให้เกิดจุดร่วม สุดท้ายจึงตระหนักว่าเมื่อทุกคนได้แสดงจุดยืนอย่างเต็มที่แล้ว ก็จะมีช่วงเวลาที่ผู้นำต้องกำหนดทิศทางและตัดสินใจให้เด็ดขาด
จากประสบการณ์ของฉัน ตอนทำงานอยู่ที่ F50 หลายปี ฉันเจอสถานการณ์คล้ายกัน ในโดเมนที่มีคนสำคัญอยู่ 3 คน มีเพียงพวกเราที่รู้ว่าแนวทาง A แม้ดูดีภายนอกแต่จริง ๆ มีปัญหามาก แม้อธิบายแล้วก็ยังโน้มน้าวทีมไม่ได้ สุดท้ายจึงต้องมองข้ามผลโหวตและไปคุยกับหัวหน้าเพื่อให้มีการตัดสินใจที่ถูกต้อง กระบวนการนี้ทำให้ตระหนักชัดว่า ถ้าเดินตามความเห็นส่วนใหญ่คือแนวทาง A แทนที่จะตามทิศทางที่คนซึ่งต้องรับมือกับผลลัพธ์จริง ๆ ต้องการคือแนวทาง C โครงการก็จะมีปัญหาและความล่าช้าต่อเนื่อง สิ่งสำคัญคือ คนที่ต้องรับผิดชอบและรับผลลัพธ์โดยตรงควรมี “สิทธิยับยั้ง” มากกว่าจะเป็นการโหวตเอาความนิยม จึงจะทำให้โครงการเดินหน้าได้ และในโครงการใหญ่ หัวหน้าหลายคนควรตัดสินใจในแต่ละโดเมน ส่วนหัวหน้าระดับบนควรลงมาชี้ขาดอย่างชัดเจนเฉพาะตอนที่เกิดทางตันเท่านั้น หากผู้นำหลีกเลี่ยงการตัดสินใจ ทุกคนก็จะได้แต่บ่นไม่พอใจ และขวัญกำลังใจของทีมจะตกต่ำลงอย่างหนัก ซึ่งเป็นประสบการณ์ที่น่าหงุดหงิดมาก
ยังนึกถึงเรื่องเล่าที่ Steve Jobs เคยขังทีมไว้ในห้องเดียวกันแล้วให้ถกกันจนกว่าจะหาวิสัยทัศน์ร่วมได้ การพาทุกคนไปในทิศทางเดียวกันเป็นเรื่องยาก แต่ถ้าทำไม่สำเร็จ พลังในการลงมือทำจะลดลงอย่างมาก อีกอย่าง หากเมินความคิดเห็นของสมาชิกทีม พวกเขาก็จะรู้สึกว่าตัวเองถูกเมิน ดังนั้นแม้ผลลัพธ์จะสำคัญ แต่วิธีแบบนั้นก็ไม่ใช่วิธีที่ยั่งยืนในระยะยาว
ฉันชอบประเด็นที่ว่า “การรับฟังเสียงของทุกคน” กับ “การให้ทุกคนมีสิทธิยับยั้ง” เป็นคนละเรื่องกันโดยสิ้นเชิง ฉันคิดว่าในฐานะผู้นำ การตัดวงจรทางตันเป็นบทบาทที่จำเป็น แน่นอนว่าถ้าผู้นำต้องเป็นคนตัดสินใจทุกเรื่อง นั่นก็เป็นสัญญาณของปัญหาด้านการจัดการ แรงจูงใจ หรือไม่ก็หมายความว่าทีมยังไม่เข้าใจกลยุทธ์
วิธีที่ฉันชอบคือพูดว่า “ถ้าคุณเป็นคนรับผิดชอบเอง คุณจะตัดสินใจว่าอย่างไร บอกฉันมา” หน้าที่ของผู้นำไม่ใช่การเป็นคนตัดสินใจทุกครั้ง แต่คือต้องทำให้เกิดการตัดสินใจขึ้นให้ได้
ฉันคิดว่าตัวเองมีความเชี่ยวชาญในเรื่องนี้อยู่บ้าง ในอดีตฉันเคยถูกแต่งตั้งให้เป็นผู้นำโครงการที่ล้มเหลวมาแล้วถึงสามครั้ง และต้องทำงานร่วมกับวิศวกรที่เก่งที่สุด 6 คนจากแต่ละทีม ทุกคนมีความคิดเห็นชัดเจนและมีเหตุผลของตัวเอง แต่ฉันพยายามถือแนวคิดแบบ “อย่าขัดศัตรูเวลาที่เขากำลังทำพลาด” มาปรับเป็น “อย่าขัดเพื่อนร่วมทีมเวลาที่เขากำลังทำสิ่งดี ๆ” ทัศนคติของฉันคือ “ถ้าไม่ใช่ส่วนที่คุณรับผิดชอบ ก็ไปสร้างอย่างอื่นที่คุณทำได้ดีแทน” เราแบ่งบทบาทกันอย่างเป็นธรรมชาติ มีอิทธิพลต่อกันอย่างนุ่มนวล และยอมรับได้ว่าบางส่วนที่สำคัญน้อยกว่าไม่จำเป็นต้องสมบูรณ์แบบ ผลลัพธ์คือโครงการประสบความสำเร็จ และฉันภูมิใจมากที่ได้สร้างโครงสร้างทีมที่คนเก่งหลายคนมาร่วมกันเรียนรู้ซึ่งกันและกัน และโฟกัสการถกเถียงจริงจังเฉพาะในจุดที่จำเป็น
ฉันคิดว่าประสบการณ์ของคุณคล้ายกับภาวะผู้นำแบบ Servant Leadership(ลิงก์วิกิที่เกี่ยวข้อง) ซึ่งก็เป็นรูปแบบผู้นำที่ฉันชอบเช่นกัน
ฉันคิดว่าการปล่อยให้วิศวกรที่เก่งมากได้ขับเคลื่อนและผลักดันไอเดียของตัวเองโดยไม่เข้าไปแทรกแซงมากเกินไปนั้น ต้องอาศัยความไว้วางใจอย่างแท้จริง ความยับยั้งชั่งใจ และความมั่นใจในตัวเองของผู้นำ
ทุกครั้งที่ทีมผลิตภัณฑ์ขอฟีเจอร์ “ง่าย ๆ” ในหัวของฉันจะนึกถึงทันทีว่าต้องใช้ถึง 3 ทีม และต้องอัปเดต microservice ของแต่ละทีม ในแง่นั้นบางครั้งฉันก็เกลียดระบบเว็บสมัยใหม่จริง ๆ
ฉันคิดว่าปัญหาที่นี่ไม่ใช่ตัวเว็บสมัยใหม่เสียทีเดียว แต่เป็นสถาปัตยกรรมที่ทำให้ฟีเจอร์ “ง่าย ๆ” หนึ่งอย่างต้องพึ่งพา microservice 3 จุดจน dependency กระจัดกระจาย สุดท้ายแล้วความล้มเหลวในการออกแบบระบบน่าจะเป็นสาเหตุที่ใหญ่กว่า
ถ้าอย่างนั้นก็สงสัยว่ามีทางเลือกอื่นอะไรบ้าง
จากประสบการณ์ของฉัน คำพูดว่า “ฉันเป็นหัวหน้า” ควรหลีกเลี่ยง เพราะอาจดูเหมือนขาดความมั่นใจ ตรงกันข้าม เมื่อรวบรวมข้อมูลครบและตัดสินใจแล้ว ควรพูดอย่างมั่นใจว่า “เอาล่ะ ตอนนี้เราจะทำแบบนี้” หรือ “อยากให้ทำแบบนี้”
แก่นของปัญหาไม่ใช่ความเข้าใจผิด แต่คือการขาดความไว้วางใจระหว่างกัน หากทีมหนึ่งบอกว่างานบางอย่างใช้เวลา 2 สัปดาห์ อีกทีมก็อาจคิดว่าเป็นงานที่เสร็จได้ในวันเดียวและไม่เชื่อใจกัน ถ้าเชื่อใจกันมากพอ ก็จะยอมรับได้ว่าอีกทีมเชี่ยวชาญกว่า แต่ในโลกจริง ผู้คนมักสงสัยว่าการประเมินเวลาดังกล่าวไม่ใช่ปริมาณงานที่ต้องทำจริง แต่เป็นการเผื่อเวลาไว้ให้ตัวเอง ในสถานการณ์แบบนี้ การแชร์คำอธิบายและเหตุผลที่เพียงพอจะช่วยเพิ่มความไว้วางใจได้
ฉันเพิ่งเลื่อนตำแหน่งเป็นหัวหน้านักพัฒนาได้ประมาณ 1 ปี ฉันสับสนว่าบทบาทและความรับผิดชอบของตัวเองคืออะไร แต่ก็รู้สึกโล่งใจที่พบว่าตัวเองทำงานด้วยแนวคิดคล้ายกับที่อยู่ในบทความต้นฉบับ ไม่กี่วันก่อนฉันเพิ่งเจอบทความเรื่อง “วิธีอ่าน tutorial จากมุมมองของคนที่ไม่ใช่นักพัฒนา” แล้วรู้สึกเห็นด้วยมาก จึงคิดว่าตัวเองน่าจะกำลังไปในทิศทางที่ถูกต้อง
ฉันเองก็เคยเห็นกรณีที่หัวหน้าทีมนำทีมแบบกดดันและสั่งการในทีมพัฒนาผลิตภัณฑ์ที่เกี่ยวเนื่องกับซอฟต์แวร์มา 3 ครั้ง และทุกครั้งผลลัพธ์ก็ไม่ดี พอได้ลองเป็นหัวหน้าทีมเองหลายครั้ง ฉันก็ได้ตระหนักว่าบทบาทของฉันไม่ใช่ “ผู้บัญชาการ” แต่เป็น “ศูนย์กลางและผู้ไกล่เกลี่ย” เมื่อสมาชิกทีมมีความขัดแย้งกัน ฉันช่วยคลี่คลาย ถ้ามีคำถามก็ช่วยลดความกังวล เมื่อมีไอเดียก็ช่วยประเมินความเป็นไปได้และคุณค่า และถ้าต้องใช้ทรัพยากรเพิ่มเติม ก็ช่วยให้พวกเขาไปหาคนที่จำเป็นได้ ไม่ว่าเป็นใครก็ตาม เมื่อเกิดปัญหา ฉันรับผิดชอบ และกระตุ้นให้ทีมร่วมกันแก้ไขปัญหา ฉันใช้เวลากว่าสิบปีในการเรียนรู้ทั้งหมดนี้ ฉันไม่ใช่คนที่เก่งที่สุด และชื่อของฉันก็ไม่ได้เป็นที่รู้จักสำหรับคนส่วนใหญ่ แต่เมื่อทำงานในฐานะ “สมาชิกคนหนึ่ง” ของทีม ผลลัพธ์กลับดีขึ้นและการสูญเสียคนเก่งก็ลดลง และในฐานะผู้นำ ฉันรู้สึกว่าสิ่งสำคัญมากคือการพูดว่า “ฉันเองก็ยังไม่แน่ใจ แต่เรามาหาคำตอบไปด้วยกันเถอะ” เพราะมันเปิดพื้นที่ให้ผู้เชี่ยวชาญยอมรับความไม่แน่นอน ไม่ต้องตั้งการ์ดป้องกันตัว และรู้สึกว่าตัวเองไม่ได้อยู่ลำพัง สำหรับคนที่เคยรู้สึกถูกกันออกไปหรือรู้สึกเหมือนเป็นแค่ชิ้นส่วนที่เปลี่ยนแทนกันได้จากผู้นำคนก่อน ๆ ฉันหวังว่าคุณจะได้รับการปลอบโยน และถ้าผู้นำอยากพาทีมไปได้ดีในระยะยาว ก็ควรเลิกมองคนเหมือนเครื่องจักร และหันมาใส่ใจดูแลกันจริง ๆ
ฉันทึ่งที่ผู้เขียนเป็นคนอัดเสียงบทความด้วยตัวเอง
เขาบอกว่าชอบวลี “It's because that's why” และแนะนำว่าถ้าสนใจเรื่องนี้ หนังสือของ Vanessa Van Edwards ช่วยได้มากในการเรียนรู้ว่าจะส่งสัญญาณความอบอุ่นและความเป็นมืออาชีพให้เหมาะกับสถานการณ์อย่างไร แม้จะยากที่คนคนเดียวจะให้คำตอบได้ทั้งหมด แต่เขาก็มีประสบการณ์เชิงบวกหลายครั้ง
ฉันรู้สึกว่าเรื่องการตัดสินใจนั้นมีมากกว่าและไม่น้อยไปกว่า “ทำให้เกิดการตัดสินใจขึ้นให้ได้” ข้อแรก ถ้าเป็นไปได้ ฉันแนะนำให้คนอื่นเป็นผู้ตัดสินใจเอง ตอนอยู่ที่ Apple, Jean-Louis Gassee เคยเล่าเกร็ดว่าถ้าผู้จัดการสองคนยกข้อพิพาทมาให้เขา เขามักจะตัดสินในแบบที่ทั้งคู่ไม่ชอบ แล้วทั้งสองก็จะกลับไปหาทางออกอื่นที่พอเห็นพ้องกันได้เอง ข้อสอง จำเป็นต้องทำให้ทุกคนในทีมเห็นด้วยกับการตัดสินใจนั้นอย่างแท้จริง และตัวคุณเองก็ต้องเป็นคนแรกที่ทำเช่นนั้น เขาเสริมว่านี่เป็นเรื่องยากมากสำหรับผู้จัดการที่ไหลไปตามลม นักศึกษากฎหมายมักคิดอย่างระมัดระวังและวิเคราะห์ทุกด้าน แต่ทนายความต้องโต้แย้งอย่างหนักแน่น และต้องมีท่าทีที่พร้อมจะโน้มน้าวทุกคน เขายกสิ่งนี้เป็นอุปมา พร้อมแชร์เคล็ดลับว่าเพราะฉันทามติในอุดมคติไม่ได้เกิดขึ้นเสมอไป การกำหนดจุดอ้างอิงที่เป็นรูปธรรม เช่น ลูกค้าหรือเป้าหมายผลลัพธ์ จะช่วยผลักดันการตัดสินใจและการลงมือทำตามนั้นได้