2 คะแนน โดย GN⁺ 2024-04-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • บทบาทผู้นำในสตาร์ทอัพต้องรับมือกับ ความรับผิดชอบที่ไม่แน่นอน มากกว่าการเขียนโค้ด และอาการแพนิก วิตกกังวล และ burnout อาจสั่นคลอนทั้งผลงานและชีวิตโดยรวมได้
  • ยิ่งตำแหน่งสูงขึ้น แทนที่จะมี ticket ที่ชัดเจน ก็จะเจอกับข้อกำหนดที่เปลี่ยนไป deadline ที่ซ้อนกัน และการรับมือ incident แบบ 24/7 ซึ่งเป็น แรงกดดันที่ปลายทางไม่ชัดเจน มากขึ้น
  • วัฒนธรรมแบบ “make it happen” ทำให้ burnout หนักขึ้นจากการยอมรับ deadline ที่เกินกำลัง, micromanagement, การเขียน PR ใหม่ตอนดึก, การอดมื้ออาหาร และการประชุมที่ทับถม
  • deadline ไม่ได้มีความเสี่ยงเท่ากันทั้งหมด การแยก deadline ด้านกฎระเบียบ สัญญา และที่กำหนดขึ้นเอง จะช่วยมองเห็นว่าแรงกดดันใดต่อรองได้ และอะไรคือความเสี่ยงจริง
  • การฟื้นตัวเริ่มได้จาก การกระทำเล็ก ๆ ที่ทำซ้ำได้ เช่น รับรู้สัญญาณเตือนตั้งแต่เนิ่น ๆ, ปกป้องวันหยุดสุดสัปดาห์, มอบหมายงาน, ปิดการแจ้งเตือน และปรึกษาผู้เชี่ยวชาญ มากกว่าการตั้งปณิธานใหญ่โต

ความวิตกกังวลและ burnout ที่เริ่มจากบทบาทผู้นำในสตาร์ทอัพ

  • ในปี 2017 ผู้เขียนรับช่วงบทบาท Head of IT พร้อมกับต้องแบกรับทีมพัฒนาขนาด 5 คน งานจำนวนมากที่สัญญาไว้กับพาร์ตเนอร์ และแรงกดดันที่ว่า “ต้องส่งมอบทุกอย่าง อย่าให้มีอะไรพัง และอย่าให้ใครหมดไฟ”
  • ตอนนั้นไม่รู้สึกว่าสามารถลาป่วยด้วยเหตุผลด้านสุขภาพจิตได้ และแม้ในคู่มือบริษัทจะมี mental health day วิศวกรก็ยังลังเลอยู่ดีในหลายกรณี
  • เมื่อความวิตกกังวลถาโถมเข้ามา ผู้เขียนค้นหาอาการคล้ายกันใน r/Anxiety ของ Reddit แม้ไม่ใช่ทางออกระยะยาว แต่ช่วยให้ประคองตัวไม่วิ่งออกจากออฟฟิศได้
  • ท้ายที่สุดได้ไปพบแพทย์ รับ การวินิจฉัยอย่างเป็นทางการ และค่อย ๆ กลับสู่สภาวะพื้นฐานของตัวเอง โดยทุกวันนี้ยังคงเก็บ checklist ฉุกเฉินไว้ใกล้ตัว

จากงานพัฒนาที่ควบคุมได้ สู่บทบาทผู้นำที่เต็มไปด้วยความไม่แน่นอน

  • งานพัฒนาในช่วงแรกมี flow ที่ค่อนข้างควบคุมได้ เช่น ticket ที่ชัดเจน, acceptance criteria, test และ merge
  • ยิ่งตำแหน่งสูงขึ้น นิยามของงานก็ยิ่งพร่าเลือน deadline ซ้อนกัน stakeholder เปลี่ยนใจกลาง sprint และการตัดสินใจบนความน่าจะเป็นกลายเป็นเรื่องประจำวัน
  • งาน infrastructure และ SRE มาพร้อมกับ pager 24/7 จึงมีความตึงเครียดต่อเนื่องรุนแรงกว่างาน deadline ของ product
  • เคยมีสถานการณ์ที่ CEO สั่งให้ทำฟีเจอร์ที่สัญญาไว้กับลูกค้ารายใหญ่ที่สุดเป็นลำดับแรก แล้ววันถัดมาก็เรียกร้องให้ฟีเจอร์อีกอย่างที่ขัดแย้งกันเป็นลำดับแรกเช่นกัน
    • แม้จะบอกว่าสองฟีเจอร์นี้ไม่สามารถเป็นลำดับแรกพร้อมกันได้ คำตอบที่ได้กลับมาก็คือ “make it happen”

ความเสียหายสะสมที่ “make it happen” สร้างขึ้น

  • burnout ไม่ได้เกิดจากอุบัติเหตุใหญ่ครั้งเดียว แต่ใกล้เคียงกับผลลัพธ์ของ การทำร้ายตัวเองเล็ก ๆ นับพันครั้ง ที่สะสมกัน
  • พฤติกรรมที่เพิ่มภาระทางใจเกิดซ้ำ ๆ
    • ยอมรับ deadline ที่เกินกำลังทั้งหมดเพื่อรักษาหน้าทีมขาย
    • กระโดดลงไปเขียนโค้ดเองโดยอ้างว่าปกป้องทีม และทำ micromanagement
    • รีเฟรชบัญชีธนาคารตอนตี 2 เพื่อตรวจว่ายังจ่ายเงินเดือนได้หรือไม่
    • พยายามดับ incident ตรงหน้าไปพร้อมกับวางแผน architecture ในอนาคต
    • โค้ช junior ไปด้วย แล้วแอบเขียน PR ใหม่เองตอนกลางคืน
    • ประชุมต่อเนื่อง กาแฟเย็นชืด และมื้อเที่ยงที่ไม่ได้กิน
  • เช้าวันหยุดสุดสัปดาห์ ช่วง 10 วินาทีแรกยังรู้สึกโอเค ก่อนที่ความวิตกกังวลจะตกใส่ทันที เป็นความรู้สึกที่เกิดซ้ำ ๆ

deadline ทุกอย่างไม่ได้มีความเสี่ยงเท่ากัน

  • เมื่อก่อนผู้เขียนปฏิบัติต่อทุก release เหมือนการลงจอดของ Mars Rover แต่เมื่อมองย้อนกลับไป deadline ที่มีผลต่อการอยู่รอดของบริษัทจริง ๆ มีเพียงไม่กี่รายการ ส่วนที่เหลือมักใกล้เคียงกับอีโก้และการตั้งความคาดหวังที่ล้มเหลว
  • เมื่อ cash flow ของบริษัทดีขึ้นและลูกค้าเริ่มมั่นคง work-life balance ก็เริ่มดูไม่ใช่เรื่องเพ้อฝันจนเกินไป
  • เคยมี deployment คืนวันศุกร์พังและต้องใช้เวลา 6 ชั่วโมงแก้ไข คิดว่าลูกค้าจะยกเลิกสัญญา แต่วันจันทร์ลูกค้ากลับไปเที่ยวเรือใบอยู่ และไม่ได้เปิด staging link ด้วยซ้ำ
  • deadline แบ่งได้เป็นสามประเภท
    • deadline ด้านกฎระเบียบ: ต่อรองไม่ได้
    • deadline ตามสัญญา: โดยมากต่อรองได้หากบอกตั้งแต่เนิ่น ๆ
    • deadline ที่กำหนดขึ้นเอง: ส่วนใหญ่มีที่มาจากอีโก้
  • บางบริษัทชูเรื่องการทำงาน 4 วันต่อสัปดาห์และห้ามใช้ Slack หลังเลิกงาน จึงไม่จำเป็นต้องอยู่กับบริษัทที่ปฏิบัติต่อ burnout เหมือนเป็นเหรียญเกียรติยศเท่านั้น

วิธีรับมือส่วนตัวที่ได้ผล

  • นี่ไม่ใช่คำแนะนำทางการแพทย์ แต่มีพฤติกรรมบางอย่างที่ช่วยให้ยังทำงานได้
  • มองหาสัญญาณเตือนตั้งแต่เนิ่น ๆ
    • สำหรับผู้เขียน สัญญาณคือการนอนไม่หลับเพราะ doom-scroll และความรังเกียจอย่างฉับพลันต่องาน code review ที่ปกติชอบ
    • เมื่อสัญญาณเหล่านี้ปรากฏ ก็ลดความเร็วลง
  • พูดคำว่า “ไม่” ให้ชัดเจน
    • วันหยุดสุดสัปดาห์ต้องได้รับการปกป้อง และถ้าไม่ใช่การแจ้งเตือนจาก pager ก็ให้รอถึงวันจันทร์
  • มอบหมายงานอย่างจริงจัง
    • PR ทุกอันที่กอดไว้เองคือการเสียโอกาส mentoring และเป็นการสะสมความวิตกกังวล
  • ลดคาเฟอีน
    • เปลี่ยนจาก half-caf ไปเป็น decaf และหัวใจก็สบายขึ้น
  • เดินวันละ 12,000 ก้าว
    • ไม่ต้องมีอุปกรณ์พิเศษ แค่มีรองเท้าและเส้นทางก็พอ
  • ปิดการแจ้งเตือนในโทรศัพท์
    • ถ้า production กำลังลุกเป็นไฟจริง ๆ คงมีใครสักคนโทรมา

ภาวะผู้นำที่มองคนก่อน

  • เมื่อเริ่มอ่านเรื่อง emotional intelligence ก็เลิกมองผู้คนเหมือนเป็นเครื่องจักรสร้าง merge conflict
  • บางครั้งการฟังก่อนแล้วค่อยแก้ทีหลังช่วยได้มากกว่า sprint retrospective อีกหนึ่งรอบ
  • เราไม่อายที่จะให้คนอื่นดูแลการรักษาฟัน แต่ท่าทีที่คาดหวังว่าสุขภาพจิตต้อง refactor เองคนเดียวนั้นไม่ถูกต้อง
  • เวลาที่ใช้พบผู้เชี่ยวชาญเป็นหนึ่งในช่วงเวลาที่มี ROI สูงที่สุด
  • การฟื้นตัวเป็นกระบวนการที่ทำซ้ำ ๆ และแม้ยังมีวันที่ทำงานดึกหรือลืมกินมื้อเที่ยงอยู่ แต่ตอนนี้ผู้เขียนรู้ตัว แก้ไข แล้วเดินหน้าต่อ

สินทรัพย์ที่สำคัญกว่าโค้ด

  • โค้ดเขียนใหม่ได้ แต่คนไม่สามารถถูกปฏิบัติแบบนั้นได้
  • ภาวะซึมเศร้าไม่สนใจ uptime ของ Kubernetes และถ้าภาวะผู้นำบดคนให้หมดแรง แม้ cluster จะยังทำงานได้ แต่คนที่ขับเคลื่อน cluster นั้นจะยืนระยะไม่ไหว
  • แม้จะมีแรงกระตุ้นให้อยากแก้ customer ticket ทั้งหมดด้วยตัวเอง ตอนนี้ผู้เขียนจะถามก่อนว่า “สิ่งนี้อยู่ในขอบเขตที่ฉันควบคุมได้หรือไม่” และถ้าไม่ใช่ก็ส่งต่อ
  • ผลลัพธ์คือผู้เขียนกลายเป็นวิศวกรที่สงบขึ้นเล็กน้อย และตามข้อมูลจาก Apple Watch ได้นอนเพิ่มขึ้น 45 นาทีต่อคืน
  • หากกำลังอยู่ในช่วงยากลำบาก คุณไม่ได้พัง และไม่ได้อยู่คนเดียว การขอความช่วยเหลือ ทดลองสิ่งเล็ก ๆ และใช้วันลาพักสุขภาพจิตเป็นทางเลือกที่ดีกว่า
  • บริษัทที่วัดคุณค่าด้วยชั่วโมง burnout ไม่คุ้มค่ากับเวลาที่คุณต้องมอบให้ และสินทรัพย์ที่ใหญ่ที่สุดไม่ใช่โค้ดที่ถูกเขียนขึ้น แต่คือ คนที่เขียนโค้ดนั้น

1 ความคิดเห็น

 
GN⁺ 2024-04-12
ความคิดเห็นจาก Hacker News
  • หลังจากทำงานด้านวิศวกรรมซอฟต์แวร์มาเกือบ 30 ปี ฉันได้ข้อสรุปว่า เดดไลน์ส่วนใหญ่ถูกกำหนดขึ้นมาแบบตามอำเภอใจล้วนๆ
    ต่อให้ช้าไป 1 สัปดาห์หรือแม้แต่ 6 เดือน บริษัทก็ไม่ได้ล่มสลายเพราะเรื่องนั้น และถ้าจะล่มจริง โดยทั่วไปก็ไม่ใช่ความผิดของวิศวกรรม เว้นแต่องค์กรวิศวกรรมจะพังถึงขั้นคาดการณ์กำหนดส่งของตัวเองพลาดซ้ำแล้วซ้ำเล่า
    แน่นอนว่ามีเดดไลน์จริง เช่น เรื่องกฎระเบียบ การพิสูจน์แนวคิดกับลูกค้า หรือการส่งมอบ แต่ถ้าเป็นองค์กรวิศวกรรม/ธุรกิจที่ทำงานเป็นปกติ ก็มักรู้เดดไลน์เหล่านั้นล่วงหน้านานมาก และประเด็นสำคัญคือสามารถพัฒนาให้เสร็จภายในตารางเวลาที่เผื่อไว้มากพอได้หรือไม่
    แทบไม่เคยเห็นลูกค้าหนีไปเพราะสินค้าออกรุ่นใหม่ไม่สม่ำเสมอ ตรงกันข้าม ลูกค้าหลายรายยังไม่ค่อยยินดีกับการอัปเกรดด้วยซ้ำ ถ้ามันไม่ได้แก้ปัญหาที่พวกเขาเป็นคนร้องขอ
    การทำงาน 80 ชั่วโมงต่อสัปดาห์ แบบไม่รู้จบมักให้ผลตรงกันข้าม และทำให้ได้ผลิตภัณฑ์คุณภาพต่ำที่พังไม่หยุดจนอยากทิ้ง

    • จากประสบการณ์ของฉัน ตัวงานส่วนใหญ่เองก็เป็นเรื่องตามอำเภอใจเหมือนกัน
      เมื่อมองย้อนกลับไป 30 ปีที่ผ่านมา มีงานกี่เปอร์เซ็นต์ที่ต่อให้ข้ามไปทั้งหมดก็แทบไม่ต่างอะไรในระยะยาว? สำหรับฉันเกิน 50% ได้สบายๆ และถ้าเป็นวันที่อารมณ์ไม่ดี ก็คงบอกว่าใกล้ 90%
    • มันต่างกันไปตามอุตสาหกรรม
      วิดีโอเกมยังคงขายใน ร้านค้าปลีก อย่าง Target หรือ Best Buy และร้านต้องจัดสรรพื้นที่วางสินค้าล่วงหน้าหลายเดือน ถ้าคุณสัญญาว่าจะนำเกมแบบแพ็กเกจไปถึงท่าโหลดสินค้าภายในวันที่ 15 พฤศจิกายนแล้วพลาด ชั้นวางที่เว้นไว้ให้คุณก็จะว่างเปล่าแบบนั้น
      สินค้าอิเล็กทรอนิกส์สำหรับผู้บริโภคก็คล้ายกัน และโฆษณา โดยเฉพาะโฆษณาทีวี เมื่อก่อนก็ต้องจองล่วงหน้านานกว่านั้นมาก ถ้าไม่ซื้อสล็อตโฆษณาตั้งแต่ 6 เดือนก่อน มันก็จะขายหมด และถ้าสินค้ายังซื้อไม่ได้ตอนโฆษณาออกอากาศ ก็เท่ากับเผาเงินก้อนใหญ่ทิ้ง
      เดดไลน์ของโปรเจกต์ IT ทั่วไปอาจจะเหลวไหลพอสมควร แต่ในโลกของ สินค้าปลีก ก็พอเข้าใจได้ว่าทำไมเดดไลน์ถึงเกิดขึ้น
      ทางแก้คงเป็นไม่เริ่มเจรจาพื้นที่วางสินค้าก่อนที่สินค้าจะเสร็จ 100% แต่บริษัทส่วนใหญ่มักทำแบบนั้นไม่ได้ พวกเขาต้องจ่ายเงินเดือนด้วยเงินจากคำสั่งซื้อ และถ้ารอให้สินค้าทำเสร็จก่อนแล้วค่อยไปซื้อโฆษณาและจองพื้นที่ชั้นวาง จากนั้นต้องรออีก 6 เดือน ระหว่างนั้นก็จะไม่ชัดเจนว่าพนักงานควรทำอะไรต่อ แถมต้นทุนในการย้ายไปทำสินค้าตัวถัดไปแล้ววกกลับมาซัพพอร์ตสินค้าตัวก่อนก็สูงมาก
    • ในฐานะคนที่ใช้ซอฟต์แวร์หลายตัวอย่าง VirtualBox และ Docker ฉันเกลียดการอัปเดตและสิ่งที่เรียกว่า อัปเกรด มาก
      ฉันชอบเวอร์ชันเสถียรที่อัปเดตน้อยกว่ามาก
    • บริษัทไม่ได้ทุกข์กับตัวเดดไลน์มากเท่ากับการ ไม่ได้รับการแจ้งล่วงหน้าอย่างเพียงพอ ว่าจะทำเดดไลน์ไม่ทัน
      สิ่งที่น่าหงุดหงิดกว่าคือไม่มีสัญญาณเตือนเลย แล้วอยู่ๆ ฝั่งวิศวกรรมก็มาประกาศว่าเดดไลน์ที่ใกล้เข้ามาจะทำไม่ทัน หรือพูดว่า “ใกล้เสร็จแล้ว ขออีกแค่หนึ่งสปรินต์” ซ้ำไปซ้ำมา
      เพราะงั้นปฏิกิริยาแบบหุนหันอย่าง “จากนี้จะไม่ประเมินเวลาแล้ว” หรือ “เสร็จเมื่อไหร่ก็คือเสร็จเมื่อนั้น” จึงไม่ช่วยอะไรเลย
    • ผู้จัดการและผู้นำจำนวนมากตั้งสมมติฐานว่าทุกงาน จำเป็นต้องมีเดดไลน์
      พวกเขาจัดการตารางของตัวเองด้วยการแบ่งช่วงเวลาและกำหนดเส้นตายแบบตามอำเภอใจ แล้วรู้สึกว่าตัวเองมีประสิทธิภาพ จึงขยายแนวคิดนั้นไปทั้งบริษัท มีสมมติฐานแฝงอยู่ว่าถ้าไม่มีแรงกดดันจากข้อจำกัดด้านเวลา งานก็จะไม่เสร็จทัน
      ความรู้สึกว่าบางอย่างจะเสร็จในวันที่กำหนดนั้นดึงดูดใจในระดับมนุษย์ และยังให้ความรู้สึกอบอุ่นเหมือนเครื่องจักรที่ได้รับการหล่อลื่นอย่างดี กำลังทำงานตามตารางที่คาดการณ์ได้
      แต่การบังคับตารางเวลาใส่คนจำนวนมากเพียงเพื่อจัดการความกังวลและความยึดติดกับตารางของใครบางคนเป็นเรื่องโหดร้าย ความจริงนั้นซับซ้อน และความอยากจะยัดมันใส่กล่องให้เรียบร้อยก็ทั้งเพ้อฝันและไร้ประสิทธิผล
  • ไม่ได้มั่นใจมากนักว่า software engineering แย่ต่อสุขภาพจิตมากกว่า อาชีพ white-collar อื่น ๆ อย่างแพทย์ ทนาย เซลส์ วิศวกร นักกีฬามืออาชีพ หรือครู
    อาชีพเหล่านี้ล้วนมีปัจจัยกดดันเฉพาะตัว และก็มีบทความมากมายจากคนที่ลาออกเพราะมันหนักเกินไปเหมือนกัน ถ้าไม่ตั้งขอบเขตให้ดี เวลาพักผ่อนก็จะถูกงานกินไป และความเครียดจากเดดไลน์ก็เป็นเรื่องร่วมกัน
    ส่วนที่บอกว่าไม่สามารถพูดกับทีมได้ว่า “วันนี้สภาพจิตใจไม่ไหว ขอลาหยุดสักวัน” เพื่อใช้สิทธิลาป่วยนั้นอ่านแล้วทรมานใจ
    ตลอดอาชีพ 20 ปีที่ผ่านมาไม่เคยเห็นทัศนคติแบบนั้นเลย และผู้คนก็ลาป่วยเพราะปัญหาสุขภาพจิตกันบ่อย ๆ น่าเสียดายที่เจ้าตัวรู้สึกว่าพูดแบบนั้นไม่ได้ แต่สิ่งนั้นใกล้เคียงกับข้อยกเว้นมากกว่าจะเป็นกฎ
    ตลอด 20 ปีที่ผ่านมา มีบริษัทไหนออกตัวชัด ๆ ว่าต่อต้านสุขภาพจิตบ้างหรือ?

    • ในสภาพแวดล้อมแบบทหาร กลับพยายามป้องกันสถานการณ์แบบนี้อย่างจริงจัง
      มีเด็กอายุ 18~20 จำนวนมากที่มีปัญหาสุขภาพจิต แต่หลายครั้งการปล่อยให้พักง่ายเกินไปก็ไม่ได้ช่วยอะไร ผู้เชี่ยวชาญมักพยายามให้พวกเขายังทำงานต่อ มากกว่าปล่อยให้อยู่บ้านดื่มเหล้าและเล่นเกมอย่างเดียว
      เด็กบางคนกลับตอบสนองได้ดีขึ้นเมื่อความเครียดจากงานเพิ่มขึ้น ถ้าทำงานหนักแบบช่วงฝึกทหารจนเหนื่อยแล้วกลับบ้านไปนอนก็ยังดี แต่ถ้าส่งกลับบ้านทั้งที่ยังไม่เหนื่อย ก็มักจะลงเอยด้วยการดื่มและเล่นเกมดึก แล้ววันถัดมาก็มาทำงานเหมือนซอมบี้
      มันไม่ได้ใช้ได้กับทุกคน แต่เราควรยอมรับว่าเราไม่จำเป็นต้องเป็นผู้รักษาที่ดีที่สุดให้ตัวเองเสมอไป หลายคนยิ่งมีวันหยุดมาก พฤติกรรมด้านลบก็ยิ่งรุนแรงขึ้น
      คำตอบที่ดีกว่าน่าจะใกล้กับ “พรุ่งนี้ฉันมีนัดปรึกษาตอน 08:00” มากกว่า “ฉันต้องหยุดพักสักวัน”
    • จากมุมของคนที่ย้ายมาจากวงการแพทย์ software engineer ถือว่าอยู่ในสถานะที่ดีมากจริง ๆ ควรเห็นคุณค่ากับสิ่งที่มี
      ยอมรับว่าประสบการณ์ส่วนตัวเรื่องการบริหารแย่ ตารางงานไม่สมจริง และโปรเจ็กต์ที่ไม่น่าสนใจนั้นมีอยู่จริง แต่เรื่องพวกนี้มีอยู่ทุกที่
      ลองบวกเข้าไปด้วยว่าทุกวันต้องอยู่ในที่ที่คนไข้และครอบครัวกำลังเผชิญวันที่แย่ที่สุดในชีวิต ต้องตัดสินใจภายใต้แรงกดดันสูง และแทบไม่มีโอกาสแม้แต่นั่งหรือเข้าห้องน้ำตลอดกะงาน แล้วมันก็จะต่างออกไป
      แถมวันที่สภาพร่างกายหรือจิตใจไม่ดีเพียงวันเดียว อาจลากยาวไปสู่การสอบสวนหรือคดีความอันยาวนานได้
      อาจฟังดูเย็นชา แต่ software engineering ไม่ได้ซับซ้อนหรือเครียดเท่าหลายสายงานในวงการแพทย์ และใช้ทั้งแรงกายแรงใจน้อยกว่า
    • ไม่คิดว่า software engineering จะกระทบสุขภาพจิตน้อยกว่างานทนาย
      เคยทำงานร่วมกับทนายเกือบ 10 ปี โดยให้บริการวิชาชีพที่ไม่ใช่งานวิศวกรรม และก็มีประสบการณ์ใน software engineering กับสตาร์ตอัปมาหลายสิบปี
      แรงกดดันใน software engineering นั้นต่างจากที่เจอในสายกฎหมายโดยสิ้นเชิง และแย่กว่ามาก
      โดยทั่วไปแล้วทนายก็คือทนาย มากกว่าจะเป็นผู้จัดการ แม้จะมีลำดับชั้นตั้งแต่ junior associate ไปจนถึง partner ระดับสูงสุด แต่ทั้งข้างบนและข้างล่างก็ล้วนเป็นทนาย ไม่เหมือนโครงสร้างที่ทนายต้องทำงานใต้ผู้จัดการ
      ในสายกฎหมายก็มีแรงกดดันและชั่วโมงงานยาวนานเหมือนกัน และคู่สมรสมักบ่นว่าทนายอยู่แต่ที่ทำงานหรือกลับบ้านแล้วยังใจลอยเรื่องงาน แต่ในที่นั่นไม่เคยมีอาการ panic attack หรือปัญหาสุขภาพจิตแบบที่เจอในวงการซอฟต์แวร์และสตาร์ตอัป
      ในฝั่งกฎหมาย ทุกคนรู้กระบวนการและทำตามกระบวนการนั้น และหัวหน้าก็เป็นคนที่เคยทำกระบวนการนั้นมาก่อน
      แต่ในซอฟต์แวร์ หลายครั้งกลับไม่มีใครรู้กระบวนการ และเราก็มักถูกบดขยี้ต่อไปเพื่อทำให้คนที่ไม่เคยผ่านประสบการณ์นั้นพอใจ บริษัทมหาชนที่ประสบความสำเร็จแห่งหนึ่งที่เคยทำงานด้วยเปิดรับสมัคร senior software engineer อยู่ตลอดก็เพราะเหตุนี้เอง
    • หลายคนไม่รู้ว่าเวลาจะบอกผู้จัดการว่าขอลาหยุดด้วยเหตุผลด้านสุขภาพ/การแพทย์ แค่บอกแค่นั้นก็พอ ไม่จำเป็นต้องให้ข้อมูลเพิ่มเติมว่าเป็นไข้หวัด ปัญหาหลัง หรือปัญหาสุขภาพจิต
      ถ้าโรงเรียนสอนเรื่อง กฎหมายพื้นฐาน ที่เกี่ยวกับการจ้างงาน ก็น่าจะช่วยคนได้มาก
    • ทำไมต้องสำคัญด้วยว่าใครบอกว่า software engineering หนักกว่า?
      ไม่ว่าจะเหยียบอึหรือจมลงไปถึงเข่า สุดท้ายก็ยังอยู่ในกองอึเหมือนกัน แทนที่จะมาแข่งกันว่าใครเลอะกว่า เราน่าจะช่วยกันเช็ดออกไม่ดีกว่าหรือ?
      เราควรหยุดการเปรียบเทียบ ตอนนี้ไม่ใช่สถานการณ์ที่ต้องจัดลำดับประเภท และเราสามารถเห็นใจหรือเข้าอกเข้าใจคนที่โดยเฉลี่ยอาจอยู่ในสถานะดีกว่าเราได้ เราทุกคนเป็นมนุษย์ และต่างได้ประโยชน์เมื่ออยู่ร่วมกัน
  • เมื่อก่อนเคยรู้สึกยำเกรง CEO หนุ่มวัยมหาวิทยาลัยไม่จบบ้างเล็กน้อย แต่หลังจากได้ทำงานใต้คนแบบนั้นมาหลายคน ก็เลยตัดสินใจว่าจะไม่ทำงานใน สตาร์ตอัปที่มีคนวัย 20 ต้น ๆ อยู่บนสุด อีกแล้ว
    พวกเขาไม่เข้าใจการบริหารหรือภาวะผู้นำจริง ๆ ขับเคลื่อนด้วยความกลัวความล้มเหลว และเพราะยังไม่เคยสร้างอะไรสำเร็จ จึงปฏิบัติต่อคนอื่นเหมือนขยะ ควรหลีกเลี่ยงไว้ดีกว่า

    • ปรากฏการณ์ที่มีคนโผล่ไปที่ Stanford แล้วบอกเด็กอายุ 21 ว่าคุณคือพระเยซูคริสต์ พร้อมยื่นเงินหลายล้านดอลลาร์ให้นั้น เป็น ฝีร้ายของวัฒนธรรมธุรกิจอเมริกัน พอ ๆ กับพวก corporate raider
      มันคือเวอร์ชันประหลาดของการรีครูตนักกีฬาอเมริกันฟุตบอล/บาสเกตบอลระดับมหาวิทยาลัย
    • ผมไม่เห็นเหตุผลว่าทำไมคนอายุ 25 จะเป็น CEO สตาร์ตอัปที่ยอดเยี่ยมไม่ได้
      ประเด็นสำคัญที่ยุ่งยากคือ ต่อให้คนอายุ 25 จะฉลาดโดยรวม มี self-awareness และความถ่อมตนแบบหาได้ยาก และกำลังท้าทายปัญหาใหญ่ ก็ยังยากที่จะรู้ว่าเมื่อไรควรฟังทีมหรือที่ปรึกษา ควรฟังใคร และเมื่อไรควรเชื่อการตัดสินใจของตัวเองแล้วเดินสวนทาง
      ถ้ามีคุณสมบัติดีครบ และได้อยู่ท่ามกลางทีมกับที่ปรึกษาที่ดี ก็อาจเป็นไปได้ในระดับหนึ่ง
      เพียงแต่หลายวงการเต็มไปด้วยแนวปฏิบัติแย่ ๆ คำแนะนำแย่ ๆ รวมถึงการหลอกลวงและการชักใยแบบโจ่งแจ้ง ซึ่งไม่ได้ช่วยอะไรเลย สมัยที่ยังอ่านบทความเก่า ๆ ของ PG เราอาจคาดหวังได้ว่าคนสายเทคนิคที่เป็นนักธุรกิจเหมือนกันจะหวังดีและให้คำแนะนำฉลาด ๆ เพื่อช่วยให้สำเร็จ แต่ตอนนี้มันไม่ใช่มาตรฐานอีกต่อไปแล้ว
      ตอนนี้ไม่ว่ามองไปทางไหน โอกาสที่จะได้รับ คำแนะนำที่แย่ มีมากกว่ามาก และยังมีคนหรือองค์กรที่พยายามชักใยมากขึ้นด้วย ต่อให้เรากรองเองได้ ก็ยังรับอิทธิพลทางอ้อมที่ไหลผ่านคนฉลาดและใช้ได้ซึ่งยอมเปิดช่องให้อิทธิพลเหล่านั้นเข้ามา
    • ไม่ว่าจะอายุ 20 หรือ 60 ก็ไม่จำเป็นต้องยำเกรงคนที่ปฏิบัติต่อคนอื่นเหมือนขยะ
      เพิ่งหลุดพ้นจากประสบการณ์กับผู้ก่อตั้ง/CEO วัย 49 ปีมาได้ และต่อไปคงจะสังเกตสัญญาณขยะพวกนี้ทุกอย่าง
    • ในบรรดาผู้จัดการระดับกลางอายุน้อยก็มีคนที่น่ารำคาญมากจริง ๆ เหมือนกัน พวก workaholic ที่ไม่มั่นคง ช่วงปลาย 20 ถึงต้น 30 ซึ่งก็ไม่ได้เด็กมากแล้ว ทำให้ชีวิตของทุกคนย่ำแย่
      พวกเขาทำงานอย่างบ้าคลั่งเพื่อให้ได้เลื่อนตำแหน่ง และตอนนี้ก็คิดว่าสามารถเติมทีมด้วยคนแบบตัวเองได้
      แต่ไม่ใช่เลย คน “แบบตัวเอง” เหล่านั้นไม่ได้เลื่อนตำแหน่งเพราะฉลาดพอที่จะไม่ทำลายสุขภาพตัวเอง หรือไม่ก็ไม่อยากใช้ชีวิตแบบนั้น
      คุณทำได้ดีกว่าและได้เงินกับอำนาจมากขึ้นก็ยินดีด้วย แต่ตอนนี้ทุกคนต้องมานอนบนเตียงเดียวกันที่คุณดึงผ้าปูออกและทำเศษขนมเลอะไว้
    • ในทางทฤษฎีอาจจริง แต่ในความเป็นจริงก็เป็นแบบนั้นหรือ? Amazon กับ Oracle เป็นที่ทำงานที่ดีกว่า Facebook กับ Stripe จริงหรือ?
  • เมื่อถึงจุดหนึ่ง ก็ต้องแค่สร้าง คิวงาน แล้วเริ่มทำสิ่งที่มีลำดับความสำคัญสูงสุดถัดไป
    ถ้ามีงานที่กำลังทำค้างอยู่มากเกินไปก็พังแน่

    • นั่นจึงเป็นเหตุผลว่าทำไม Kanban ถึงเป็นหนึ่งในวิธีการบริหารโครงการที่ฉันชอบที่สุด
      “อ๋อ ฟีเจอร์ใหม่ที่สำคัญที่สุดสินะ ลองสำรวจคร่าว ๆ แล้ว งานนี้น่าจะอธิบายได้ด้วย sticky note 20 ใบ ความเร็วการทำงานที่ผ่านมา củaทีมเราคือ sticky note 10 ใบต่อ 2 สัปดาห์ เพราะงั้นถ้าหยุดงานที่กำลังทำอยู่ทั้งหมด ก็น่าจะเสร็จในอีก 4 สัปดาห์ ช่วยดู sticky note เดิมแต่ละใบด้วยว่าอันไหนหยุดได้จริงไหม”
      ผู้มีส่วนได้ส่วนเสียยังคงตัดสินใจได้ แต่มีผลทำให้พวกเขาเข้าใจตามความเป็นจริงว่ากำลังขออะไรจากทีม
    • เมื่อหลายปีก่อน ฉันเคยทำงานเป็นผู้อำนวยการฝ่ายวิศวกรรมในบริษัทแห่งหนึ่ง ตอนนั้นกำลังเตรียมผลิตภัณฑ์เวอร์ชันใหม่ตัวสำคัญ
      ผ่านไปไม่กี่สัปดาห์ ฉันบอก CEO ว่าคิดว่าน่าจะเข้าใจขอบเขตและความยากของรีลีสใหม่นี้ได้ค่อนข้างดีแล้ว แต่ CEO กลับบอกว่า “ไม่ คุณยังไม่เข้าใจ”
      พอถามเหตุผล เขาก็บอกว่ามีฟีเจอร์ “จำเป็น” ที่เพิ่งคิดขึ้นมาใหม่ในช่วงสุดสัปดาห์ ซึ่งเห็นได้ชัดว่าทางเทคนิคแล้วทำได้ยากมาก แล้วก็ยังยืนกรานอีกว่าอะไรก็ สร้างได้ภายใน 48 ชั่วโมง
      น่าแปลกใจเหมือนกันที่ฉันทนอยู่ที่นั่นได้นานขนาดนั้น
    • ในฐานะผู้จัดการ ต่อให้ข้างบนเปลี่ยนลำดับความสำคัญ ถ้างานที่กำลังทำอยู่ใกล้เสร็จแล้ว ฉันก็มักจะทำให้มันจบไปเลย
      พอกลับมาดูงานเดิมทีไร พวกเขาก็มักแปลกใจเสมอว่ามันเสร็จไปแล้ว
    • ที่ทำงานเก่าของฉันก็เป็นแบบนั้นเป๊ะ และคนที่อยู่ในตำแหน่งแบบนั้นนานเกินกว่าที่จำเป็นก็ควรหาบทบาทอื่น
      สุดท้ายมันคือเส้นทางไปสู่ burnout หรือไม่ก็ความเฉยชา
      ตอนนั้นฉันดู X-Files เยอะ ก็เลยเรียกมันว่า “สัตว์ประหลาดประจำสัปดาห์” และจนถึงตอนนี้ก็ยังชอบคำนี้อยู่
    • หนึ่งในทักษะที่ทรงพลังที่สุดสำหรับนักพัฒนาที่ต้องรับมือกับฝั่งธุรกิจ คือ ความสามารถในการพูดว่าไม่
  • ความสามารถในการ ตัดตัวเองออก จากงานที่กำลังทำอยู่ แม้เพียงช่วงสั้น ๆ ก็สำคัญมาก
    จะออกไปเดิน ชงกาแฟ หรือแค่หลับตาหายใจก็ได้
    ความเครียดจำนวนมากถูกสร้างขึ้นมาอย่างไม่จำเป็น แถมยังบั่นทอนผลงานและทำให้ความสามารถในการคิดลดลง
    ฉันเคยเจอสถานการณ์หลายครั้งที่งานกลายเป็น “เรื่องด่วน” เพราะบริษัทอาจได้สัญญาหรือยอดขาย และถ้าผ่าน “crunch” นี้ไปได้ ทุกคนก็จะกลายเป็นซูเปอร์สตาร์
    ถ้าคุณอดนอนและนอนวันละ 3–4 ชั่วโมงอยู่ 2 เดือนเพื่อส่งมอบโครงการก่อนกำหนด ฝั่งผู้บริหารและผู้ตัดสินใจก็จะเริ่มชินชากับ crunch แบบ “ของขวัญ” นี้ และโยนมันมาให้อีกเรื่อย ๆ
    คนส่วนใหญ่คงเคยช่วยบริษัทและยอมทุ่มเพิ่มอีกก้าวหนึ่งมาแล้ว และก็อาจทำได้อีกในอนาคต แต่ถ้าทุกอย่างด่วนไปหมดและทุกงานต้องทำเดี๋ยวนี้ทั้งหมด นั่นหมายความว่ามีปัญหาใหญ่กว่านั้น
    ปกติแล้วเงิน เวลา และแรงย่อมมีขีดจำกัดและงบประมาณ หากใช้ขีดจำกัดและความอดทนเหล่านั้นจนเกินเลย ผู้คนก็จะเลิกให้ความเคารพคนที่ร้องว่าหมาป่ามา และจะใส่ใจกับงานน้อยลงด้วย

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

    • ในบริษัทส่วนใหญ่ที่ฉันเคยทำงาน แค่บอกว่า “วันนี้ไม่ค่อยสบาย ขอหยุดหนึ่งวันครับ/ค่ะ” ก็พอแล้ว
      ไม่มีใครถามรายละเอียด
    • คำว่า “ผู้ใหญ่ก็เข้าใจ” นี่เป็นประสบการณ์แบบ อยู่ในฟองสบู่ พอสมควร
      งานส่วนใหญ่ไม่ได้เป็นแบบนั้น
    • ที่ที่คุณทำงานอาจเป็นแบบนั้น แต่ของฉัน ฉันคงพูดแค่ว่าวันนี้ไม่เข้าไปทำงาน
      ถ้าพูดกับหัวหน้าทีมหรือเจ้านายแบบนั้น เขาคงซักว่าทำไมถึงไม่มา
    • ด้วยเหตุผลเดียวกัน คุณอาจใช้ wellness day ได้เหมือนกัน
  • ฉันเริ่มเชื่อว่าในการปฏิบัติวิชาชีพพัฒนาซอฟต์แวร์เอง มีบางอย่างที่ทำให้เกิดหรืออาจทำให้เกิดความเจ็บป่วยทางจิตได้
    ตลอดหลายทศวรรษ ฉันเห็นเพื่อนร่วมงานบางคนประสบปัญหาร้ายแรงมาก และคิดว่านี่เป็นปัญหาที่ค่อนข้างหนักจริง ๆ ในอุตสาหกรรมของเรา

    • ดูเหมือนว่าวิศวกรรมซอฟต์แวร์จะดึงดูดคนที่มี neurodiversity
      ฉันเป็นวิศวกรซอฟต์แวร์ที่มี ADHD และรู้จักวิศวกรซอฟต์แวร์ที่มี ADHD มากผิดปกติ
      ความบกพร่องด้าน executive function ระดับนั้นและการต้อง “ไล่ตามให้ทัน” กลายเป็นปัญหา
    • ถ้าจะให้อารมณ์ดีขึ้น คุณต้องมี ประสบการณ์แห่งชัยชนะ หรือโครงการที่มีจุดจบ
      แต่หลายโครงการกลับยืดเยื้อไปทุกปีแบบไม่มีที่สิ้นสุด จนกว่าบริษัทหรือเจ้าตัวจะหมดแรง หรือไม่ก็ย้ายไปบริษัทอื่นแล้วทำเรื่องเดิมซ้ำอีก
      ในงานเว็บดีเวลอปเมนต์ วันเปิดตัวคือเส้นชัยที่ใกล้ที่สุด แต่ไม่ใช่เส้นชัยจริง ๆ การทำเป้าหมายตัวชี้วัดหลักให้ได้ก็ใกล้เคียงอยู่บ้าง แต่ก็ยังไม่อิ่มเอมทางใจเท่าการทำโต๊ะหรือเครื่องปั้นดินเผาให้เสร็จ หรือเก็บเกี่ยวพืชผลไปขายหรือเสิร์ฟเป็นอาหารเย็น
    • โดยพื้นฐานแล้ว อุตสาหกรรมนี้คือการเปลี่ยน ความคิดอย่างมีสติ ให้เป็นทุนอย่างมีประสิทธิภาพที่สุดเท่าที่จะทำได้
      เพราะงั้นการบอกว่ามันไม่ดีกับใจก็ฟังสมเหตุสมผล
    • ความเครียดจำนวนมากมาจากความรับผิดชอบที่ต้องทำให้ “บางสิ่งนั้น” ใช้งานได้ ทั้งที่นิยามของมันอาจเปลี่ยนไปอย่างฉับพลันเพราะอารมณ์ของเพื่อนร่วมงาน การขาดวิสัยทัศน์ล่วงหน้า และการวางแผนที่แย่
    • ท้ายที่สุดแล้ว งานที่เราทำส่วนใหญ่ก็คืองานเขียน
      แค่ดูว่านักเขียนคนอื่น ๆ ปรับตัวและใช้ชีวิตกันได้ดีแค่ไหนก็พอ โดยเฉพาะคนที่ต้องใช้เวลามากมายเขียนสิ่งที่ตัวเองรู้ว่าไร้ค่าเพราะต้องจ่ายค่าเช่า
  • คำอธิบายว่าคุณพยายามควบคุมความไม่แน่นอนรอบตัวทั้งหมดในปี 2017 ฟังดูเหมือนการโทษตัวเองจากการพยายามอดทนอยู่ใน ที่ทำงานนรกของบริษัทห่วย ๆ

  • คนแบบนี้ไม่ควรอยู่ในตำแหน่งผู้นำเลย
    ฉันเคยทำงานใต้คนประเภทนี้มาแล้ว ตัวเขาเองเป็นวิศวกรที่ยอดเยี่ยม แต่เป็นหัวหน้าที่แย่มาก
    เขาไม่ไว้ใจทีม ทำเองทุกอย่างตลอด ไม่มีการพูดคุย ไปคุยลับหลัง และยอมตามใจผู้บริหารเสมอ ทุกอย่างเป็น “เรื่องสำคัญ” หรือ “วิกฤต” ไปหมด และเป็น micro-managing ที่แย่ที่สุด
    ในขณะเดียวกัน ถ้าฉันถูกจับไปอยู่ในตำแหน่งนั้น ก็มีโอกาสเหมือนกันว่าจะล้มเหลวแบบคล้าย ๆ กัน แม้อาจจะไม่หนักเท่า ผู้บริหารมักผลักเราเข้าไปอยู่ในสถานการณ์ที่เป็นไปไม่ได้ โดยแทบไม่มีเหตุผลดี ๆ นอกจาก “เพื่อให้ X พอใจ”
    ถ้าทำแบบนั้นเพื่อเอาหน้าเอาตากับผู้บริหารระดับกลางที่ไม่มีใครรู้จัก ยิ่งแย่เข้าไปอีก
    เพราะแบบนี้ฉันเลยคิดว่าในวงการเทคควรมี สหภาพแรงงาน เพื่อกำหนดความคาดหวังที่สมจริง และสามารถเข้าหาฝ่ายบริหารด้วยมุมมองแบบส่วนรวมได้
    น่าเสียดายที่ทุกวันนี้บริษัทต่าง ๆ สนใจแค่การ exit ให้ไวและ IPO เพื่อถอนทุน venture capital คืน ดูเหมือนความรู้สึกทั่วไปในหมู่นักลงทุนประเภทแร้งคือสหภาพแรงงานจะลดโอกาสในการ exit แบบรวดเร็ว

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