เส้นทางสู่การเป็น VP of Engineering

 (honeycomb.io)
1 คะแนน โดย GN⁺ 2023-07-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • VP of Engineering คนแรกของ Honeycomb ได้เลื่อนตำแหน่งจาก Director of Engineering ในเดือนกุมภาพันธ์ 2020 และเส้นทางนี้ใกล้เคียงกับการเข้ามาอุดช่องว่างที่เกิดขึ้นเมื่อบริษัทเติบโต มากกว่าจะเป็นเส้นทางผู้บริหารที่วางแผนไว้ล่วงหน้า
  • ในช่วงแรกของ Honeycomb ผู้ร่วมก่อตั้ง Charity Majors เป็นคนดูแลแทบทุกคน และคนสองคนที่มีแนวคิดการบริหารคล้ายกันแต่มีพื้นเพและสไตล์ต่างกัน ก็เริ่มแบ่งความรับผิดชอบในการบริหาร R&D กัน
  • การเลื่อนตำแหน่งไม่ใช่การเปลี่ยนครั้งใหญ่ในคราวเดียว แต่เป็นการสะสมของ การขยายขอบเขตเล็ก ๆ และในสตาร์ตอัป งานสำคัญมักเป็นการค่อย ๆ สร้างกระบวนการและความรับผิดชอบใหม่ขึ้นมา
  • การเตรียมตัวให้เหมาะกับบทบาทนี้ต้องอาศัยมุมมองแบบมองทั้งบริษัท ความเป็น generalist ความสามารถในการสลับไปมาระหว่างหลายระดับของ abstraction ความรับผิดชอบ การคิดเชิงระบบ การช่วยให้เพื่อนร่วมทีมเติบโต และความสัมพันธ์ที่กว้างขวาง
  • ภาพของ VP of Engineering ที่ดีไม่ได้ขึ้นอยู่กับเทมเพลตมาตรฐาน แต่ขึ้นอยู่กับปัญหาปัจจุบันของบริษัท โครงสร้างผู้นำและ IC ที่มีอยู่ ความท้าทายทางเทคนิค และช่วงการเติบโตขององค์กร

จุดเริ่มต้นที่ไม่ใช่เส้นทางผู้บริหารที่วางแผนไว้

  • VP of Engineering คนแรกของ Honeycomb ได้เลื่อนตำแหน่งจาก Director of Engineering ในเดือนกุมภาพันธ์ 2020
  • เป้าหมายตอนเข้าร่วม Honeycomb ในตอนแรกคือการทำงานเป็นวิศวกร และมีความเข้าใจตรงกันว่าหากจำเป็นก็สามารถกลับไปรับบทบาทบริหารได้อีก
  • ช่วงที่เข้าร่วมเป็นพนักงานประมาณคนที่ 12 และรู้ดีว่าสำหรับสตาร์ตอัประยะแรก ยิ่งบริษัทประสบความสำเร็จมากเท่าไร ก็ยิ่งต้องรับงานหลากหลายขึ้นในหลายช่วง
  • มองว่าการยึดติดกับตำแหน่งหน้าที่ใดหน้าที่หนึ่งมากเกินไป อาจกลายเป็นอุปสรรคมากกว่าจะเป็นประโยชน์ ทั้งกับตัวบุคคลและกับบริษัท
  • เหตุผลที่เลือก Honeycomb คือทีมดูฉลาดและใจดี ดูเป็นที่ที่มีสิ่งให้เรียนรู้อีกมาก และผลิตภัณฑ์ก็ดูเหมือนสิ่งที่เคยอยากได้จากงานก่อนหน้าแต่หาไม่พบ
  • ถ้าต้องการเติบโตอย่างรวดเร็วไปสู่บทบาทเฉพาะ การเข้าร่วมสตาร์ตอัปหลัง Series B อาจมีประสิทธิภาพกว่า แต่ในกรณีนี้ได้เข้าร่วม Honeycomb ตั้งแต่ช่วง Series A

วิธีที่ความรับผิดชอบด้านการบริหารถูกถ่ายโอน

  • ในช่วงแรก ผู้ร่วมก่อตั้งและ CEO ในขณะนั้น Charity Majors เป็นคนดูแลแทบทุกคน ตั้งแต่ผู้บริหารไปจนถึงวิศวกรรายบุคคล
  • ทั้งสองคนเข้ากันได้ดีพอสมควรในด้านปรัชญาการบริหาร แต่มีพื้นเพและจุดแข็งต่างกัน
    • Charity Majors มีประสบการณ์ลึกในงานโครงสร้างพื้นฐาน การปฏิบัติการ ฐานข้อมูล และวิศวกรรมฝั่งแบ็กเอนด์
    • ผู้ที่ได้รับการเลื่อนตำแหน่งเริ่มต้นมาจากงานด้านดีไซน์ ฟรอนต์เอนด์ และ product engineering และชอบการทำงานร่วมกับ product management และ UX design
  • ทั้งคู่มีประสบการณ์ด้าน metric และเทคโนโลยี monitoring แต่มีทัศนคติต่อสิ่งเหล่านี้ต่างกัน
    • Charity Majors ค่อนข้างไม่ชอบสิ่งนี้
    • ส่วนผู้ที่ได้รับการเลื่อนตำแหน่งกลับชื่นชอบอย่างมาก
  • สไตล์การทำงานก็แตกต่างกันมากเช่นกัน
    • ผู้ที่ได้รับการเลื่อนตำแหน่งให้ความสำคัญกับกฎและกระบวนการ และมักใช้การวางแผนกับการจัดการความเสี่ยงทั้งในงานประจำและงานอดิเรก
    • Charity Majors มีสไตล์อาศัยสัญชาตญาณและด้นสด โดดเด่นเป็นพิเศษในสถานการณ์วิกฤต ไม่ชอบ checklist และมักรับรู้ได้เร็วเมื่อกฎหรือกระบวนการนั้นไม่ช่วยอะไร
  • เมื่อ Honeycomb เติบโตขึ้น งานบริหาร R&D ก็เพิ่มขึ้น และความรับผิดชอบก็ถูกแบ่งกันมากขึ้นเรื่อย ๆ โดยยึดตามพื้นที่ที่สอดคล้องกับพื้นเพของแต่ละคนมากกว่า

การเลื่อนตำแหน่งคือการสะสมของการขยายขอบเขตเล็ก ๆ

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

การเปลี่ยนผ่านจากการดูแล IC ไปสู่การดูแลผู้จัดการ

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

การมองหาผู้สมัคร VP ภายนอกและการเลื่อนตำแหน่งจากภายใน

  • ในช่วงที่ทิศทางของบริษัทค่อนข้างสั่นคลอน ก็เคยพิจารณาทางเลือกในการจ้าง VP of Engineering จากภายนอกด้วย
  • Charity Majors พูดเรื่องนี้อย่างตรงไปตรงมา และให้มีส่วนร่วมทั้งในกระบวนการค้นหาและคัดเลือกคนที่เหมาะสม
  • ได้พูดคุยกับผู้นำสายวิศวกรรมที่ยอดเยี่ยมหลายคน แต่บางคนไม่เหมาะกับ Honeycomb ในเวลานั้น และบางคนก็ไม่ได้เลือก Honeycomb เป็นก้าวถัดไปของตัวเอง
  • หลังจากนั้น บริษัทก็เจอปัญหาใหม่ ๆ และปัญหาเก่าที่เคยดูเหมือนแก้ไม่ได้นั้นกลับจัดการได้ง่ายขึ้น
  • แม้จะยังไม่ได้เลื่อนตำแหน่งในทันที ณ จุดนั้น แต่การค้นหาคนจากภายนอกก็หยุดลง
  • การเลื่อนตำแหน่งผู้นำในระดับสูงขึ้นไปควรยึดตาม สิ่งที่บริษัทต้องการ ไม่ใช่ยึดตามตัวบุคคล และกระบวนการช่วยกันจินตนาการว่า VP of Engineering ที่เหมาะกับ Honeycomb ควรเป็นแบบไหน ก็มีประโยชน์มาก

คุณลักษณะที่ช่วยให้กลายเป็นคนที่เหมาะกับบทบาทนี้

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

ประสบการณ์การทำงานที่ช่วยได้

  • ประสบการณ์ในสตาร์ตอัปหลายช่วงและหลายขนาด โดยเฉพาะ สตาร์ตอัป B2B SaaS ช่วยได้มาก
    • สตาร์ตอัป B2C และ B2B ต้องรับมือกับหมวดปัญหาที่ค่อนข้างต่างกัน และต่างก็พัฒนาเทคนิคการแก้ปัญหาในแบบของตัวเอง
    • การได้เห็นทั้งสองด้านก็ดี แต่การสร้างความเชี่ยวชาญในด้านใดด้านหนึ่งระหว่าง B2B หรือ B2C ก็มีคุณค่าเช่นกัน
    • วิธีเข้าสู่ตลาด โครงสร้างองค์กร ปัญหาทางวิศวกรรม และโจทย์ด้านการขยายตัว อาจแตกต่างกันระหว่าง B2B และ B2C
  • ประสบการณ์การทำงาน ครอบคลุมทั้งสแตก ก็ช่วยได้
    • ประสบการณ์ทางวิศวกรรมที่ลึกที่สุดอยู่ในเทคโนโลยีฝั่งฟรอนต์เอนด์
    • เก็บเกี่ยวประสบการณ์ช่วงแรกในหลายองค์กรที่ทำ pair programming และใช้แนวคิดแบบ DevOps
    • ได้เรียนรู้จากวิศวกรแบ็กเอนด์ โครงสร้างพื้นฐาน แพลตฟอร์ม และปฏิบัติการ และเข้าใจว่าพวกเขาคิดอย่างไรและให้ความสำคัญกับปัญหาแบบไหน
    • ไม่จำเป็นต้องเป็นผู้เชี่ยวชาญในทุกด้านของวิศวกรรม แต่ความเห็นอกเห็นใจต่อหลายทีมและความเข้าใจโดเมนในระดับสูงนั้นช่วยได้มาก
  • ประสบการณ์ในสาย developer tools และ monitoring ก็สอดคล้องกับบทบาทนี้
    • ทำงานกับบริษัท developer tools ติดต่อกันถึงสามแห่ง
    • ชื่นชอบผลิตภัณฑ์ของ Honeycomb อย่างจริงใจ และยังชอบผลิตภัณฑ์อื่น ๆ ในสาย observability, monitoring และ developer tools ด้วย
    • ความรู้ในโดเมนและความหลงใหลในเครื่องมือเหล่านี้ช่วยเพื่อนร่วมงานได้ และอาจเป็นแหล่งพลังงานในสถานการณ์ที่ชวนท้อแท้

ความเหมาะสมที่เกิดจากโชคและองค์ประกอบของทีม

  • การกลายเป็นคนที่เหมาะกับบทบาทนี้มีองค์ประกอบของ โชค อยู่มากเช่นกัน
  • การมีทักษะและประสบการณ์ที่เสริมกันกับ Charity Majors เพียงอย่างเดียวไม่พอ สิ่งสำคัญอีกอย่างคือ IC รุ่นอาวุโสในช่วงแรกสามารถรับมือกับโจทย์วิศวกรรมหลักได้ดี
  • VP of Engineering ที่มีพื้นเพฟรอนต์เอนด์ถือว่าค่อนข้างพบได้น้อย เพราะโจทย์เทคนิคที่เร่งด่วนที่สุดของสตาร์ตอัปมักอยู่ที่การขยายระบบ ความเสถียร และสถาปัตยกรรมฝั่งแบ็กเอนด์
  • หากในเวลานั้นยังมีปัญหา outage ต่อเนื่อง ปัญหาการขยายตัวของระบบ หรือปัญหาสถาปัตยกรรมใหญ่เกี่ยวกับ query และ storage engine อยู่ต่อเนื่อง ก็มีโอกาสสูงที่จะเลือกคนที่มีประสบการณ์เชิงลึกด้านแบ็กเอนด์และปฏิบัติการมากกว่า
  • ด้วย Ben Hartshorne, Ian Wilkes, IC คนเก่งอีกหลายคน และการตัดสินใจออกแบบที่แข็งแรงจากทีมผู้ก่อตั้ง ทำให้มีพื้นที่ทางเทคนิคเพียงพอ และสิ่งที่ผู้นำให้ความสำคัญสูงสุดในเวลานั้นคือการขับเคลื่อนกลยุทธ์ผลิตภัณฑ์และยกระดับประสบการณ์ผู้ใช้
  • ในทีมผู้บริหารก็มีผู้บริหารที่ดึงเข้ามาจากภายนอกซึ่งมีประสบการณ์สูงอยู่แล้วในฟังก์ชัน go-to-market
  • ทั้ง Christine และ Charity ที่อาจนับเป็นผู้นำที่เติบโตมาจากภายในบริษัท ต่างก็มีประสบการณ์เป็นผู้ก่อตั้งหรือผู้นำจากบริษัทก่อนหน้า และ Charity ก็เป็นที่รู้จักว่าเป็นผู้จัดการที่ยอดเยี่ยมมาตั้งแต่ก่อนก่อตั้ง Honeycomb
  • หากทีมผู้บริหารในตอนนั้นเอนเอียงไปทางผู้บริหารใหม่หรือผู้ที่เพิ่งเลื่อนจากภายในมากกว่านี้ ก็อาจไม่มีพื้นที่พอที่จะปั้นผู้บริหารเพิ่มอีกคน

VP of Engineering เปลี่ยนไปตามบริบทของบริษัท

  • บทเรียนสำคัญที่สุดคือภาพของ VP of Engineering ที่ดีนั้นขึ้นอยู่กับบริบท
  • ก่อนหน้านี้เคยคิดว่าสามารถไล่รายการคุณลักษณะมาตรฐานของ VP of Engineering ที่ยอดเยี่ยมได้ แต่ยิ่งไปยิ่งรู้ว่าความคิดที่ว่าทุกบริษัทมีเทมเพลตพื้นฐานคล้ายกันนั้นไม่ค่อยจริง
  • แม้งานพื้นฐานที่ต้องทำในบริษัทซอฟต์แวร์ส่วนใหญ่จะคล้ายกัน แต่ลักษณะของผู้บริหารที่จะมานำงานเหล่านั้นแตกต่างกันได้มาก ตามปัญหาปัจจุบันขององค์กรและองค์ประกอบของผู้บริหาร ผู้จัดการ และ IC ที่มีอยู่แล้ว
  • แม้จะเข้ารับบทบาทไปแล้ว ข้อกำหนดของงานก็ไม่ได้ตายตัว
  • ในบริษัทที่กำลังเติบโต บทบาท VP of Engineering ก็อาจเปลี่ยนรูปไปตามเวลาได้เหมือนบทบาทอื่น ๆ ในสตาร์ตอัป

บทความที่เกี่ยวข้อง

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

 
GN⁺ 2023-07-16
ความคิดเห็นจาก Hacker News

  • ช่วงนี้น่าสนใจดี: ข้อความที่ว่า “Charity มีสไตล์ที่ใช้สัญชาตญาณและด้นสดมากกว่า เปล่งประกายในยามวิกฤตที่สุด และเกลียดเช็กลิสต์” ดูเหมือนจะเป็นการยอมรับแบบเผลอ ๆ อยู่เหมือนกัน
    พูดอีกอย่างคือ ผู้ก่อตั้งไม่ได้มีคุณสมบัติหรือลักษณะที่ลูกน้องมองว่าจำเป็นต่อการอยู่ในตำแหน่งผู้นำ
    พอตั้งบริษัทก็ได้เป็น CEO, CTO อัตโนมัติ และผู้ก่อตั้งบริษัทที่ตอนนี้กลายเป็นบริษัทยักษ์ใหญ่ก็เหมือนกัน
    ผู้ก่อตั้งไม่ต้องมีคุณสมบัติเฉพาะมารองรับตำแหน่งนั้น แค่ตั้งตัวเองเป็นผู้นำแล้วเลือกเพื่อนมาเป็นพนักงานชุดแรก
    การจ้างงานจะกลายเป็นระบบทางการทีหลังอีกมาก และไม่ว่าเราอยากเชื่อว่าลำดับชั้นนั้นเป็นแบบ ยึดความสามารถ แค่ไหน จุดเริ่มต้นของลำดับชั้นนั้นก็ชัดเจนว่าเป็นความโกลาหล
    วิธีคิดแบบลำดับชั้นและต้องเชื่อฟังดูแปลกสำหรับฉันมาโดยตลอด และฉันก็ไม่เคยคิดว่าหัวหน้าเก่า ๆ “เก่งกว่า” ฉัน
    การไต่บันไดบริษัทโดยเนื้อแท้แล้วใกล้เคียงกับการเมือง และบทความไม่รู้จบอย่าง “วิศวกรอาวุโสคืออะไร” ก็ดูเหมือนจะออกมาจาก วิธีคิดแบบบรรษัทนิยม ที่พยายามสร้างความชอบธรรมให้ลำดับชั้น

    • ถ้าคุณมีส่วนร่วมในการเริ่มบริษัท ช่วงแรก ๆ คุณก็จะได้ตำแหน่งอย่าง CEO, CTO แบบค่อนข้างตามอำเภอใจจริง
      แต่เมื่อเวลาผ่านไป คุณต้องพิสูจน์ความชอบธรรมของตำแหน่งนั้นด้วยการทำให้บริษัทสำเร็จโดยไม่ทำมันพัง
      หลายครั้งนี่เป็น วิธีวัดความสามารถ ที่ตรงไปตรงมาและโหดกว่าการประเมินแบบไหน ๆ มาก
      บริษัทใหญ่อย่าง Google ไม่ได้ล้มละลายเพราะ VP ที่ไร้ความสามารถและขี้เกียจเพียงคนเดียว จึงต้องมีระบบประเมิน
      เทียบดูได้กับ https://gwern.net/backstop
    • ในระดับบนสุดของบริษัทต้องมีทั้ง ผู้นำที่ไม่ใช่แบบแผน และผู้นำที่เน้นการลงมือทำ
      ฉันเป็นสายลงมือทำเต็มตัว แต่ก็เรียนรู้ตั้งแต่เนิ่น ๆ ว่าคุณลักษณะในอุดมคติของผู้ร่วมก่อตั้งคือสิ่งตรงข้ามกับฉัน และสิ่งที่เห็นที่นี่ก็คือความต่างนั้น
      คนที่ถูกบรรยายไว้เป็นผู้นำที่ไม่ใช่แบบแผนอย่างชัดเจน คือด้นสด วิ่งไปวิ่งมาจนดูวอกแวกได้ แต่ในขณะเดียวกันก็เป็นนักนวัตกรรมชั้นยอดและเป็นคนสร้างแรงจูงใจให้คนอื่นได้
      สตาร์ตอัปที่ประสบความสำเร็จต้องมีทั้งคนสายวิสัยทัศน์ที่ไม่ตามแบบและคนสายลงมือทำ
      ขอแนะนำ Rocket Fuel: https://www.amazon.com/Rocket-Fuel-Essential-Combination-Bus...
    • ฉันไม่ได้อ่านประโยคนั้นว่าเป็นคำพูดเรื่องคุณสมบัติของใคร
      มันดูเป็นการยอมรับอย่างตรงไปตรงมาและเป็นมิตร ว่ามีอยู่สองสไตล์ที่แตกต่างกัน และการยอมรับความต่างแบบนั้นก็เป็นเรื่องดีต่อสุขภาวะขององค์กร ไม่ใช่การอุทธรณ์เชิงนัยต่อเรื่องลำดับชั้น
      ตรงกันข้าม การใช้คำอย่าง “ลูกน้อง”, “หัวหน้า” และการมองว่าการก่อตั้งบริษัทเท่ากับการสร้างลำดับชั้น กลับทำให้ทั้งคอมเมนต์นี้ไปเสริมความแข็งแรงให้ลำดับชั้น ทั้งที่บอกว่าตั้งคำถามกับมัน
      ในอุตสาหกรรมความรู้ ผู้จัดการไม่ใช่ผู้นำ แต่เป็น บุคลากรสายสนับสนุน
      ผู้จัดการซอฟต์แวร์และผู้บริหารที่ดีที่สุดรู้ดีว่าหน้าที่ของพวกเขาคือช่วยให้ผู้นำและผู้เชี่ยวชาญตัวจริง หรือก็คือ individual contributors ที่ลงมือทำงาน สามารถทำงานได้ง่ายขึ้น
      หนึ่งในหน้าที่สนับสนุนของฝ่ายบริหารคือการสร้างความคาดหวังนั้นผ่านการกระทำของตนเอง
    • โดยเฉพาะในบริษัทขนาดใหญ่มาก เรื่องนี้จริงมาก
      เวลาสตาร์ตอัปถูกขายให้บริษัทใหญ่ มันจะตลกไม่น้อยเมื่อพบว่าไม่มีใครในสตาร์ตอัปทีมนั้นเลยที่จะผ่านเกณฑ์ HR ของบริษัทนั้นได้ถ้าสมัครเข้าไปตามปกติ
      แล้วจู่ ๆ สมาชิกทีมสตาร์ตอัปพวกนั้นกลับ เลื่อนตำแหน่ง ได้ก่อนพนักงานบริษัทใหญ่ที่โปรไฟล์การศึกษาดูดีกว่าและผ่าน HR มาแล้ว
    • เห็นด้วยอย่างยิ่ง
      คนจำนวนมากถูกปลูกฝังด้วย สายการบังคับบัญชา แบบบริษัทอเมริกัน และมักสมมติว่าถ้าใครมีตำแหน่งหนึ่งอยู่ ก็แปลว่าเขามีคุณสมบัติเหมาะกับตำแหน่งนั้นจริง ๆ
      เงินเฟ้อตำแหน่งมีอยู่ทุกที่ และจากที่เห็น ตำแหน่งมักถูกใช้เป็นเครื่องมือขึ้นเงินเดือนและรับรองอายุงาน มากกว่าจะเป็นการยอมรับความสามารถ
      ฉันไม่ได้ตั้งใจจะพูดจำกัดแค่สหรัฐฯ

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

    • ไม่ใช่ปัญหาเฉพาะของสตาร์ตอัป และไม่ใช่เรื่องบังเอิญที่มีคำแนะนำเก่าแก่เสมอมาว่า ถ้าอยากขึ้นเงินเดือนหรือเลื่อนตำแหน่ง ก็ให้เตรียม ย้ายงาน ไว้ตลอด
      ตรรกะดูจะใกล้เคียงกับการพยายามรั้งคนเก่งที่ทำผลงานได้เกินตำแหน่งไว้ด้วยต้นทุนต่ำที่สุด มากกว่าจะเป็นอย่างอื่น
      การย้ายงานมีต้นทุนจริงสำหรับพนักงาน และยิ่งมากขึ้นเมื่อเศรษฐกิจไม่ดี
      ถึงอย่างนั้นก็ยังมีคนที่ลาออก มีคนที่ปล่อยมือเงียบ ๆ และมีคนที่แค่ทนอยู่ต่อ
    • พอบริษัทโตถึงระดับหนึ่ง ฉันเห็นพนักงานยุคแรกบ่นนับครั้งไม่ถ้วนว่า “มันไม่เหมือนเดิมแล้ว”
      จากประสบการณ์ของฉัน คนเหล่านั้นมักปฏิเสธที่จะปรับตัว แล้วก็จากไปหรือไม่ก็ถูกให้ออก
    • สตาร์ตอัปเติบโตเร็วกว่าที่ ความสามารถด้านการบริหารจัดการ จะตามทัน
      แค่คุณบริหารทีม 10 คนได้ ไม่ได้แปลว่าคุณจะบริหารองค์กร 100 คน หรือยิ่งไปกว่านั้น 1000 คนได้
      ไม่ได้หมายความว่ากรณีนี้ต้องเป็นแบบนั้นเสมอไป แต่ในบางกรณีก็เป็นเหตุผลที่ชอบธรรมในการหลีกเลี่ยงกฎของ Peter
    • ถ้าเลื่อนตำแหน่งจากภายในมากเกินไป ข้อบกพร่องของผู้ก่อตั้งมักไม่ถูกแก้ไข
      เพราะคนที่ได้เลื่อนตำแหน่งคือคนที่ทนกับข้อบกพร่องนั้นมาได้ หรือไม่ก็ไม่เคยมองเห็นมันเลย
      ถ้ามีคนจากภายนอกที่มีประสบการณ์พอจะมองเห็นข้อบกพร่องแบบนั้นได้อยู่ไม่กี่คน คนเหล่านั้นก็มักมีโอกาสเจอช่วงเวลาที่ยากลำบากมาก
    • ฉันทำงานอยู่ในสตาร์ตอัปขนาดใหญ่ หรือ scale-up ที่ไปได้ค่อนข้างดี
      ผู้นำระดับสูงส่วนใหญ่เติบโตขึ้นมาจากการเลื่อนตำแหน่งภายใน และบางครั้งก็ไต่จาก individual contributor ไปถึง VP ได้เลย ซึ่งเห็นผลของมันชัดเจน
      ถ้ามีคนที่เคยผ่านขนาดองค์กรระดับนั้นจากหลายองค์กรเข้ามา ก็น่าจะช่วยองค์กรได้อย่างแน่นอน

  • ในทางปฏิบัติกลับเข้าใจได้ยากว่าเขาเคยทำอะไรจริง ๆ และตอนนี้ในบทบาท VP ทำอะไรอยู่บ้าง
    มีคำพูดสวยหรูเยอะ แต่ก็ยังไม่ชัดเจนว่าแต่ละวันใช้เวลาส่วนใหญ่ไปกับอะไร
    คำว่า “มาจากสายดีไซน์ ฟรอนต์เอนด์ และ product engineering” ก็ไม่ได้ให้ข้อมูลมากนัก
    ฉันเองก็เป็นคนประเภทที่ทำได้ตั้งแต่สเก็ตช์, เลย์เอาต์ใน Figma, ฟรอนต์เอนด์และมิดเดิลเลเยอร์ของ SvelteKit, ไปจนถึงสร้าง FastAPI API พอดี เลยยิ่งไม่รู้ว่าเขาเก่งอะไรถึงได้เป็น VP แล้วตอนนี้เมื่อออกจากงานภาคสนามแล้วกำลังทำอะไร และคิดถึงอะไรมากที่สุด
    บทความยาวมาก แต่ก็ยังไม่ค่อยเข้าใจว่าต้องการจะสื่ออะไร

    • จากงานภาคสนามไปถึง VP ฝ่ายวิศวกรรม ยังมีอีกหลายขั้น
      ทุกวันนี้ถ้าอยากดูบทบาทที่บริษัทขนาดเล็กกว่า FAANG คาดหวัง และเส้นทางที่วิศวกรไต่ขึ้นสู่สายบริหาร ควรดู “The Manager's Path”
    • ก็ให้ความรู้สึกคล้ายกัน
      ฉันเคยคิดว่ายิ่งไปสู่ความเป็นผู้นำระดับผู้บริหาร งานก็จะยิ่งเป็นเชิงกลยุทธ์มากขึ้น และแทบไม่ค่อยได้ลงมือทำเองโดยตรง แต่ในบทความกลับไล่เรียงประสบการณ์และคุณสมบัติเชิงยุทธวิธีจำนวนมากที่บอกว่าเป็นสิ่งที่ทำให้ตัวเองเป็น VP ที่ดี
    • ดูเหมือนบทความที่ทีม PR ฝ่าย HR ให้คนที่น่าสงสารสักคนเขียน
      ในฐานะคนยากจนชายขอบของวงการเทคโนโลยี ฉันเห็นกรณีที่บริษัทบังคับให้คนเขียนอะไรสักอย่างมาเยอะ และมันก็ออกมาแนวนี้ทุกที
      ตอนรับสมัครนักศึกษาจบใหม่ บริษัทจะให้คนในบริษัทเขียนบทความแบบนี้คนละชิ้นสองชิ้น เพื่อให้มีบทความใหม่ ๆ โผล่ในผลการค้นหา
      มันตอบโจทย์สองอย่างพร้อมกัน คือประจบแบบพอประมาณ และยกยอผู้สมัครที่มีแนวโน้มจะมาสมัคร
    • On Becoming a VP of Engineering, Part 2: Doing the Job
      https://www.honeycomb.io/blog/becoming-vp-of-engineering-pt2
    • ยินดีต้อนรับสู่สายบริหาร

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

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

  • ในมุมของ CTO บริษัทสตาร์ตอัปที่ได้รับเงินลงทุนจาก VC คนที่อยู่ตำแหน่งสูง ๆ ส่วนใหญ่ฉลาด และฉันนับความเจ้าเล่ห์ไว้ในหมวดเดียวกันด้วย
    แต่ก็มีคนจำนวนมากที่ฉลาดพอ ๆ กันแต่ไม่ได้อยู่ตำแหน่งสูง เพราะพวกเขาไม่มี โอกาส
    ถ้าเริ่มธุรกิจเอง โอกาสก็จะดีขึ้น และถึงไม่มีใครก่อตั้งบริษัทเพราะอยากได้ตำแหน่ง VP ที่บริษัทอื่น แต่มันก็เป็นเส้นทางทางเลือกที่ดี
    หรือไม่ก็ต้องมี networking รู้จักคนที่ใช่ ซึ่งโดยมากก็มักมาคู่กับเส้นทางการก่อตั้งบริษัทข้างต้น
    อีกวิธีคือไปทำงานที่บริษัทดังอย่าง Google แล้วค่อยย้ายไปที่เล็กกว่าเพื่อเป็นปลาใหญ่ในบ่อเล็ก
    หรือไม่ก็ต้องเข้าตาหัวหน้าและหัวหน้าของหัวหน้า เพื่อให้ตัวเองเป็นคนถัดไปที่จะถูกแต่งตั้งเมื่อหัวหน้าตรงลาออก

    • ประเด็นที่ว่าคนตำแหน่งสูงนั้นฉลาด แต่คนที่ฉลาดพอ ๆ กันแต่ไม่ได้อยู่สูงไม่มี โอกาส นั้นสำคัญมาก
    • ทุกข้อเป็นประเด็นที่ดี
      สิ่งหนึ่งที่ฉันได้เรียนรู้คือ ถ้าเห็นบริษัทเลื่อนตำแหน่งหรือจ้างผู้บริหารด้วยเหตุผลอื่นนอกเหนือจากความสามารถ นั่นคือเวลาที่ควรเริ่มมองหางานใหม่
      ตอนสัมภาษณ์งานฉันไม่รู้เรื่องนี้ แต่ตำแหน่ง VP ขึ้นไปในบริษัทก่อนหน้าถูกผูกขาดแทบทั้งหมดโดยคนที่มีสายสัมพันธ์กับ CEO โดยไม่เกี่ยวกับคุณสมบัติเลย
      ก็มีบางคนที่ได้เลื่อนเพราะความสามารถจริง หรือขึ้นมาแบบเป็นธรรมชาติจากกระบวนการควบรวมกิจการ แต่เมื่อเวลาผ่านไป พวกเขาก็ค่อย ๆ ถูกแทนที่หรือถูกลดขั้น เพื่อเปิดทางให้เพื่อนของผู้บริหารระดับ C-level หรือแม้แต่สมาชิกในครอบครัวเข้ามารับตำแหน่ง
      ผู้บริหาร C-level คนหนึ่งที่ร่วมงานด้วยแล้วดีมาก ถูกลดลงมาเป็น VP และตำแหน่ง C-level นั้นก็ถูกยกให้เพื่อนสนิทเก่าแก่ของ CEO
      ผู้บริหารที่ถูกลดตำแหน่งคนนั้นสั่งสมประสบการณ์มาหลายปีจากบริษัทชั้นนำที่สุดของอุตสาหกรรม และถึงขั้นพาครอบครัวย้ายข้ามประเทศเพื่อรับตำแหน่งนี้ แต่คนที่มารับช่วงต่อกลับไม่มีประสบการณ์ในอุตสาหกรรมนี้เลย
      VP คนนั้นถูกขอให้อยู่ต่อเพื่อให้เพื่อนเก่าแก่ของ CEO ได้เรียนรู้งานและรับช่วงต่อไป และยังถูก “อนุญาต” ให้คงสิทธิใน stock option เอาไว้
      มันเปิดตาให้เห็นว่า ระบบพวกพ้องและความภักดี ทำงานอย่างไรในบางบริษัท

  • ข้อความอ้างอิงนี้สะดุดตาเป็นพิเศษ
    ประเด็นคือเหตุผลที่ VP ฝั่งวิศวกรรมที่มาจากสายฟรอนต์เอนด์พบได้ค่อนข้างน้อย เป็นเพราะปัญหาทางเทคนิคที่เร่งด่วนที่สุดของสตาร์ตอัปมักอยู่ที่ scalability, reliability และสถาปัตยกรรมแบ็กเอนด์
    ในอดีตเคยทำงานในบริษัทที่ผู้นำล้วนมาจากฝั่งแบ็กเอนด์และอินฟราฯ จน ฟรอนต์เอนด์ ถูกประเมินค่าต่ำ และก็เคยเห็นว่าคุณภาพโค้ดของนักพัฒนาแบ็กเอนด์เหล่านั้นค่อนข้างแย่มาก
    เลยสงสัยว่ามันมีความสัมพันธ์เชิงผกผันระหว่างการเป็นตัวแทนในภาวะผู้นำกับพรสวรรค์ด้านวิศวกรรมหรือไม่

    • คำพูดที่ว่า “คุณภาพโค้ดของนักพัฒนาแบ็กเอนด์แย่มาก” นั้น มีโอกาสสูงว่าจะกำลังโฟกัสผิดจุด ถ้าไม่รู้ว่าใช้เกณฑ์อะไรในการวัดคุณภาพโค้ด
      ฉันเป็นคนที่เติบโตจากวิศวกรฟรอนต์เอนด์มาเป็น tech lead และมองว่านักพัฒนาจะเลือกจุดโฟกัสตามนิสัยส่วนตัวและคุณค่าที่ตนให้ความสำคัญ
      คนที่เลือกฟรอนต์เอนด์กับนักพัฒนาแบ็กเอนด์มักมีแนวโน้มทางนิสัยต่างกัน
      โค้ดที่แย่หมายถึงอะไร
      หมายถึง format ไม่สม่ำเสมอหรือไม่สวยงาม ชื่อตัวแปรไม่สื่อความหมาย หรือโค้ดไม่ได้ถูกแยกและจัดโครงสร้างให้อ่านง่ายหรือไม่
      รู้สึกว่านักพัฒนาฟรอนต์เอนด์มีแนวโน้มจะตัดสินโค้ดจากคุณค่าระดับผิวหน้า
      โดยเฉพาะในองค์กรที่เน้นวิศวกรรม ผู้คนจะได้รับการยอมรับจากการแก้ปัญหา
      หลายทีมสามารถเดินหน้าต่อได้สบายแม้ไม่มีคนฟรอนต์เอนด์ตัวหลัก แต่ถ้าไม่มีวิศวกรอินฟราหรือแบ็กเอนด์ที่แข็งแรงสักคน หรือยิ่งกว่านั้นหลายคน ก็มักจะสั่นคลอน
      นั่นคือความจริง
    • มีหลายปัจจัยในเรื่องนี้ แต่หนึ่งในนั้นชัดเจนว่าเป็นเรื่องของ เพศสภาพ
      งานพัฒนาฟรอนต์เอนด์มักถูกทำให้มีภาพลักษณ์แบบผู้หญิงและถูกมองว่าสำคัญน้อยกว่า
      ตัวอย่าง: https://thoughtbot.com/blog/tailwind-and-the-femininity-of-c...
      ในอุตสาหกรรมเทคโนโลยีก็มีแนวโน้มจะเชื่อมโยงภาวะผู้นำเข้ากับคุณลักษณะที่ถูกทำให้มีภาพลักษณ์แบบผู้ชายด้วย
      ดังนั้นจึงไม่น่าแปลกใจเลยที่ภาวะผู้นำกับพื้นเพสายฟรอนต์เอนด์จะถูกมองว่าไม่ค่อยเข้ากัน
      พลวัตทางเพศเดียวกันนี้ยังเกี่ยวข้องกับโค้ดด้วย
      สำหรับฉัน โค้ดที่ดีส่วนหนึ่งคือโค้ดที่ดีต่อผู้อื่นและดีต่อการทำงานร่วมกัน
      แต่ถ้าอยากวางตัวแบบ macho, alpha nerd tech bro ก็สามารถคาวบอยโค้ดดิ้งคนเดียวแล้วอวดความอัจฉริยะได้
      ตอนนั้นเป้าหมายไม่ใช่การร่วมมืออย่างใกล้ชิดกับทีมเพื่อสร้างบางอย่างร่วมกัน แต่คือการเป็นผู้สร้างผลงานเดี่ยวอันน่าทึ่งที่โดดเด่นเข้าตาผู้บริหาร
    • ฉันคิดว่าคนที่มองโดเมนที่ตัวเองไม่รู้แล้วพูดว่า “ตรงนั้นดูไม่มีปัญหา งั้นก็คงง่าย” มีโอกาสสูงมากที่จะทำได้ไม่ดีแม้แต่ในสาขาที่ตัวเองคิดว่ารู้

  • VP ฝั่งวิศวกรรม ไม่ใช่บทบาทที่ทำให้เป็นมาตรฐานเดียวกันแล้วเทียบข้ามบริษัทได้
    ที่บริษัทปัจจุบัน director มักดูแลองค์กรได้มากสุดราว 500 คน ส่วน VP มักดูแล 1000 คนขึ้นไป และบางครั้งก็ 3000~5000 คน
    การมองว่า VP ของสตาร์ตอัปที่มี 50 คน เทียบเท่ากับ VP ใน FAANG ที่ดูแลองค์กรระดับ 1000+ คน เป็นเรื่องไม่สมเหตุสมผล
    ไม่ได้หมายความว่าฝั่งไหนดีกว่า แค่ทักษะที่ต้องใช้ต่างกันอย่างชัดเจน
    ในความเป็นจริง เคยเห็นคนที่ได้ตำแหน่ง VP จากบริษัทเล็กไม่เข้าใจความต่างนี้ พอไปสมัคร FAANG แล้วถูกเสนอบทบาท manager หรือ senior manager ก็ช็อกไปเลย

    • เคยทำงานที่บริษัทเล็กขนาด 40 คนแห่งหนึ่ง ซึ่งมี VP กับ director อยู่ในแผนกที่มีคน 2 คน
      ไร้เหตุผลโดยสิ้นเชิง
      จากประสบการณ์ของฉัน VP คนนั้นถ้าวัดตามมาตรฐานองค์กรใหญ่ก็มีประสบการณ์ระดับเด็กฝึกงาน แต่เป็นคนที่เข้ามาอยู่ก่อน
      ส่วน director แย่ยิ่งกว่า ขณะที่ลูกทีมสองคนกลับมีความสามารถ

  • อยากให้พนักงาน Honeycomb ใช้เวลาไปกับการปรับปรุงผลิตภัณฑ์ให้เห็นชัดเจนบ้าง แทนที่จะเขียนบล็อกโพสต์
    ฉันเคยโชคร้ายต้องใช้ Honeycomb ในที่ทำงาน และในระบบที่มีการโต้ตอบกันมากกว่าสองสาม service มันใช้งานไม่ได้เลย
    ไม่เข้าใจว่าทำไมบริษัทนี้ถึงถูกคาดหวัง เกินจริง ขนาดนั้น

  • ฉันอ่านบทความนี้โดยคำนึงไว้ว่า VP ของ Honeycomb นั้นใกล้เคียงกับ senior manager ในบริษัทเทคโนโลยีขนาดใหญ่

    • คนนี้กำลังอยู่ในช่วงเรียนรู้วิธีบริหารผู้จัดการให้มีประสิทธิภาพ
      ถ้าวัดตามมาตรฐานบริษัทใหญ่ก็คือระดับ director

  • จากประสบการณ์ของฉัน individual contributor สร้างผลิตภัณฑ์, manager สร้างคน, director สร้าง process, และ VP สร้าง policy
    ส่วนคนที่อยู่สูงกว่านั้นทั้งหมดคือขั้นตอนอนุมัติคำของบประมาณ

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