คำแนะนำสำหรับ Principal Engineer มือใหม่

• บทความนี้รวบรวมคำแนะนำ 31 ข้อจากวิศวกรอดีต Amazon โดยสรุปสิ่งที่เขาสังเกตและเรียนรู้จากเหล่าโรลโมเดลเกี่ยวกับ บทบาท Principal Engineer/Scientist
• Principal ในความเป็นจริงคือ คนที่สวมหลายบทบาท ครอบคลุมทั้งผลิตภัณฑ์ ดีไซน์ วิศวกรรม และวัฒนธรรมองค์กร โดยอาศัยวิจารณญาณในการทำงานที่กว้างขวาง
• แก่นสำคัญคือ ไม่ใช่การเขียนโค้ด แต่เป็นวิสัยทัศน์ด้านเทคนิค การให้ฟีดแบ็กต่อการออกแบบ และการเชื่อมโยงคนในองค์กร ขณะที่งานที่เคยเป็นแกนหลักในบทบาทก่อนหน้า กลายเป็นงานรอง
• งานส่วนใหญ่คือ การสอนให้องค์กรเห็นคุณค่าในสิ่งที่ยังไม่ให้คุณค่า และมากกว่าการตัดสินใจที่ถูกต้อง คือ ความสามารถในการโน้มน้าวให้คนอื่นเข้าใจ คล้อยตาม และลงมือทำ
• ควรโฟกัสกับงานประเภทที่ จะไม่เกิดขึ้นเลยหากไม่มี Principal และในหลายกรณี การเชื่อมคนและพัฒนาคนอื่น อาจมีค่ามากกว่าการลงมือทำเอง
• อิสระมาพร้อมความรับผิดชอบ ต้องเป็นคนค้นหาปัญหาที่องค์กรควรให้ความสำคัญด้วยตัวเอง และในระยะยาวจะมีประสิทธิภาพกว่าหาก ขยับจากเส้นทางวิกฤตไปอยู่ในตำแหน่งที่อยู่ติดกัน

---

1-3. แก่นของบทบาทและสไตล์

• ข้อ 1: Principal แต่ละคนมีสไตล์ที่ต่างกัน
  • มีทั้งสายที่เจาะลึกในสาขาเดียว กับสายที่มีอิทธิพลเชิงกว้างในแนวราบ
  • อาจเป็นผู้บุกเบิกทางเทคนิค, คนที่ทำให้ความซับซ้อนชัดเจน, หรือคนที่ทำให้องค์กรหลายส่วนไปในทิศทางเดียวกันตามวิสัยทัศน์ร่วม
  • ควรหาสไตล์ที่เหมาะกับจุดแข็งของตัวเอง และไม่มีสไตล์ไหนสำคัญกว่าสไตล์อื่น

  Amazon ระบุอย่างชัดเจนว่า Principal ต้องทำงานแบบ hands-on และหากไม่ได้ลงมือจริงต่อเนื่องเป็นเวลานาน มีโอกาสล้มเหลวสูง

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

  เรื่องเล่าที่เป็นที่รู้จักของบทบาท L7+: ต่อให้ใช้เวลา 80% ไปกับการเขียนโค้ด ส่วนที่มีอิมแพ็กต์ที่สุดก็ยังเป็นการทำให้ทุกคนทำงานได้มีประสิทธิภาพขึ้น
  ต้องเปลี่ยนกรอบความคิดจากการโฟกัสการเขียนโค้ดในโปรเจกต์เดียว ไปสู่การสร้างอิทธิพลให้คนสร้างทุกคนสร้างสิ่งต่าง ๆ ได้ดีขึ้น
  ไม่ใช่แค่เขียนโค้ดคุณภาพสูงลงใน repository แล้วปล่อยให้โค้ดพูดแทนตัวมันเอง แต่ความพยายามอย่างการให้ฟีดแบ็กต่อข้อเสนอการออกแบบ การเขียน technical guide หรือการขับเคลื่อนวิสัยทัศน์ระยะยาว อาจมีประสิทธิภาพกว่า

• ข้อ 3: เป็น PM พาร์ตไทม์ของสายเทคนิค แต่จริง ๆ แล้วเป็นคนพาร์ตไทม์ของทุกเรื่อง
  • ครอบคลุมทั้งผลิตภัณฑ์ ดีไซน์ วิศวกรรม วิทยาศาสตร์ QA การจ้างงาน การเงิน และวัฒนธรรม
  • "ไม่มีอะไรที่ไม่ใช่งานของคุณ"
  • ด้วยวิจารณญาณระดับสูง จึงสามารถก้าวออกไปนอกขอบเขตความเชี่ยวชาญเฉพาะทางได้

4-7. การสื่อสารและอิทธิพล

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

  บางครั้งต้องเริ่มโปรเจกต์ก่อนและแสดงให้เห็นคุณค่า จึงจะได้สิ่งเหล่านี้มา
  Principal ต้องเป็นตัวอย่าง เพราะต้องการให้ผู้คนลงมือแก้ปัญหาอย่างเชิงรุกโดยไม่รอคณะกรรมการ
  "Principal ก็คือคณะกรรมการนั่นแหละ แล้วจะรอใครอยู่ :)"

• ข้อ 6: งานส่วนใหญ่คือการสอนให้องค์กรเห็นคุณค่าในสิ่งที่ยังไม่ให้คุณค่า
  • ผู้ฟังมีตั้งแต่ผู้บริหารไปจนถึง IC (Individual Contributor) ที่ลงมือทำงานจริง
  • นี่เป็นงานที่ยากที่สุดและมักล้มเหลวบ่อย แต่ในฐานะคนที่มองเห็นอนาคตและมีมุมมองกว้างกว่า ก็ยังจำเป็นต้องทำ
  • เมนเทอร์คนหนึ่งมองว่า ถ้าเอกสารข้อเสนอ 10 ฉบับมีสัก 3 ฉบับถูกนำไปใช้ ก็ถือว่ายอดเยี่ยมแล้ว

  ต่างจาก IC ที่ดูแลงานระดับทีมในชีวิตประจำวัน บทบาท L7+ มีพื้นที่ให้มองในมุมที่กว้างและยาวกว่าของบริษัท
  จึงสามารถประเมินอิมแพ็กต์ได้อย่างเป็นกลางกว่า และการมีส่วนร่วมในระดับนั้นคือสิ่งที่เพิ่มคุณค่าได้มากที่สุด

• ข้อ 7: มีหมวดงานที่หากไม่มี Principal งานนั้นจะไม่เกิดขึ้นเลย
  • โดยทั่วไปมักอยู่ตรง จุดตัดระหว่างสิ่งที่ตัวเองสนใจจริง ๆ กับสิ่งที่ตัวเองทำได้ยอดเยี่ยม
  • เช่น สร้าง prototype อย่างรวดเร็วแล้วแชร์กับฝ่ายบริหารและประสบการณ์ลูกค้าแบบใหม่, สร้างสะพานเชื่อมระหว่างองค์กรหรือกับผู้ปฏิบัติงานในอุตสาหกรรมอื่น, หรือเขียนวิสัยทัศน์ 3 ปี
  • ควรโฟกัสกับงานในหมวดนี้
  • เมื่ออาชีพก้าวหน้าไป งานลักษณะนี้มักจะลึกขึ้นและแคบลง

8-11. การขยายผลผ่านคนอื่น

• ข้อ 8: งานที่มีค่าที่สุดอาจไม่ใช่การลงมือทำเอง แต่คือการเชื่อมโยง
  • เชื่อมทีมที่กำลังจะทำงานบางอย่าง เข้ากับทีมที่เคยทำไปแล้ว เพื่อให้ reuse หรือเรียนรู้จากกันได้
  • รวมถึงการระบุตัวคนที่เหมาะสมซึ่งทำงานนั้นได้และจะเติบโตจากกระบวนการนั้น
• ข้อ 9: สิ่งที่คุณทำคนเดียวมีขีดจำกัด
  • การลงทุนเวลาเพื่อ โค้ชและเมนเทอร์คนอื่น ให้ทำงานได้มีประสิทธิภาพขึ้น มีประโยชน์ต่อองค์กรมากกว่า
  • กันเวลาไว้สัปดาห์ละหลายชั่วโมง เช่น office hours หรือ sync ประจำ
  • ระบุ IC 1-2 คนที่อยากพัฒนา และตั้งเป้าหมายว่าจะช่วยพวกเขาอย่างไร

  หัวใจคือการขยายผลผ่านคนอื่น: ความสำเร็จของ PE (Principal Engineer) คือเมื่อองค์กรสามารถตัดสินใจแบบเดียวกับ PE ได้
  PE จึงสามารถย้ายไปแก้ปัญหาคลุมเครืออื่น ๆ และวางวัฒนธรรมที่พาไปสู่ผลลัพธ์ที่ถูกต้อง

  คุณอาจอยากช่วยทุกคน แต่ในระยะยาวควรทุ่มพลังไปกับการสร้างคนที่สามารถมาแทนที่บทบาทของคุณได้
  ต้องลงทุนเวลาอย่างจริงจังให้กับทุกคนที่แสดงศักยภาพแบบนั้น เพื่อให้พวกเขากลับไปช่วยคนอื่นต่อได้ แม้ตอนนี้คนเหล่านั้นอาจยังดูมีศักยภาพไม่มากนัก

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

  การใช้เวลา 1-2 ชั่วโมงต่อสัปดาห์กับใครสักคน แล้วทำให้พวกเขาสามารถทำงานได้ 40 ชั่วโมงภายใต้ insight ของคุณ คือ สเกลที่แท้จริงของ Principal

• ข้อ 11: เมื่อส่งงานให้คนอื่นแล้ว งานนั้นคือของพวกเขา
  • คุณให้บริบทและแนวทางได้ แต่ท้ายที่สุดการกำหนดทิศทางเป็นหน้าที่ของพวกเขา
  • รวมถึงการยอมให้พวกเขาเลือกแนวทางที่คุณเองอาจไม่เลือก
  • ถ้าผิดพลาด ทุกคนก็ได้เรียนรู้ และถ้าสำเร็จ คุณเองก็อาจได้เรียนรู้เช่นกัน
  • แต่ถ้าโปรเจกต์กำลังมุ่งหน้าไปสู่ความเสี่ยงสูงแบบ one-way door ที่อาจย้อนกลับมาสร้างผลเสีย ก็จำเป็นต้องเข้าไปแทรกแซง

12-15. การจัดการการประชุมและการมีส่วนร่วม

• ข้อ 12: สร้างพื้นที่ให้คนอื่นในการประชุม
  • บางครั้งห้องประชุมคาดหวังความเห็นหรือการตัดสินใจจากคนที่อาวุโสที่สุด คุณสามารถใช้การตั้งคำถามเพื่อเปิดพื้นที่ให้คนอื่นได้
  • หากเห็นใครไม่ค่อยมีส่วนร่วม ให้ค่อย ๆ ดึงเข้ามาด้วยประเด็นที่สอดคล้องกับจุดแข็งของเขา
  • หากการประชุมลืมใครบางคนที่ควรอยู่ในวงสนทนา ให้เพิ่มเขาเข้ามาในการประชุมครั้งถัดไป
• ข้อ 13: ไม่จำเป็นต้องพิสูจน์คุณค่าอยู่ตลอดเวลา
  • Principal ที่มีประสิทธิภาพที่สุดหลายคนอาจเงียบตลอดการประชุม หรือแทบไม่คอมเมนต์ใน document review เลย
  • ถ้าทีมและการสนทนาดำเนินไปได้ดี นั่นก็ยอดเยี่ยมแล้ว
  • คุณสามารถถอยออกจาก flow ของงานหนึ่งก้าว และเอาพลังไปลงกับที่อื่นได้

  ข้อควรระวัง: การเข้าร่วมแล้วเงียบ อาจถูกตีความว่าเป็นการเห็นชอบโดยนัย ดังนั้นต้องระวังทั้งการ multitask และความหมายของการเข้าประชุม

• ข้อ 14: ในการประชุมกับผู้บริหาร ไม่จำเป็นต้องคุยครบทุกหัวข้อใน agenda
  • ถ้าผู้บริหารมีส่วนร่วมกับประเด็นนั้นจริง ๆ ถามคำถามที่มีความหมาย และตัดสินใจหรือปลดอุปสรรคในสิ่งที่มีแต่พวกเขาเท่านั้นที่ทำได้ ก็ถือว่าเป็นการประชุมที่ดีแล้ว
• ข้อ 15: เมื่อทำงานในบทบาทที่กว้าง ทั้งสัปดาห์อาจถูกเติมเต็มด้วยทุกสิ่งที่ไหลเข้ามา
  • ทั้ง review, escalation, email, คำขอความช่วยเหลือ ฯลฯ
  • ยิ่งอยู่องค์กรนาน ปัญหานี้ยิ่งใหญ่ขึ้น เพราะคุณกลายเป็นคนที่รู้เยอะหรือได้รับความไว้วางใจจนเป็น "go-to"
  • ผลคือกลายเป็นผู้เข้าร่วม "ที่ขาดไม่ได้" ในทุกการประชุม
  • หาก ไม่เรียนรู้วิธีปกป้องเวลาของตัวเอง ก็จะไม่มีเวลาไปผลักดันไอเดียที่คุณสนใจจริง ๆ
  • คุณไม่จำเป็นต้องอยู่ทุกประชุมหรือมีความเห็นกับทุกไอเดีย มีเฉพาะเรื่องสำคัญก็พอ

  สิ่งที่เมนเทอร์คนหนึ่งแชร์ไว้คือ: เวลาสำหรับการคิดเป็นสิ่งจำเป็นมาก หากวิ่งจากประชุมหนึ่งไปอีกประชุมหนึ่ง คุณจะไม่มีเวลาทั้งจัดการเรื่องต่าง ๆ และมองไปข้างหน้า
  ต้องจัดตารางเวลาคิดเชิงลึกที่มีคุณภาพ และตัดตัวเองออกจากการประชุมบ้างเพื่อมองหาเรื่องใหญ่ถัดไป

  ต้องหาวิธีมอบหมายงาน: ทำให้คนอื่นกลายเป็นคนที่ถูกเรียกหาแทนคุณ เพื่อคืนเวลาให้ตัวเอง และในขณะเดียวกันก็สร้างขอบเขตที่ช่วยให้คนใหม่เติบโต

16-19. อิมแพ็กต์และการสื่อสาร

• ข้อ 16: ถ้าคุณอธิบายไม่ได้ว่างานที่ทำอยู่ต้องใช้ Principal เพราะอะไร คุณอาจกำลังทำงานผิดอย่าง (ใช้ได้กับ L6 เช่นกัน)
• ข้อ 17: บางครั้งสถานะของคุณช่วยปรับปรุงผลลัพธ์ได้ด้วยแรงที่ไม่มากนัก
  • ตำแหน่งมอบสิทธิพิเศษเชิงองค์กร และทำให้เข้าถึงความสัมพันธ์กับบริบทได้มากขึ้น
  • เมื่อรวมกับประสบการณ์ ก็ช่วยให้มองเห็นสิ่งที่อยู่ถัดไปได้ดีกว่า
  • ดังนั้น การลงแรงไม่มากนักก็อาจเพิ่มโอกาสสำเร็จและคุณภาพผลลัพธ์ของโปรเจกต์ได้อย่างมีนัยสำคัญ
  • ROI สูงมาก และเมื่อเห็นโอกาสแบบนี้ก็ควรลงมือ
• ข้อ 18: ตำแหน่งมักสร้าง aura ของความน่าเชื่อถือ แม้ในเวลาที่ไม่ควรมี
  • บางครั้งผู้คนตีความคอมเมนต์สด ๆ ของคุณมากเกินไป โดยเฉพาะเมื่อพวกเขาไม่รู้จักคุณดี
  • ผลคืออาจมีงานจำนวนมากเกิดขึ้นเพียงเพราะคอมเมนต์สบาย ๆ ที่คุณพูดออกไป
  • ซึ่งอาจทำให้เสียเวลาและความพยายาม
  • ดังนั้นต้อง ทำให้ชัดว่าอะไรคือสิ่งที่รู้ อะไรคือสิ่งที่ไม่รู้ อะไรคือคำขอ และอะไรคือเพียงความเห็น
• ข้อ 19: อย่าพูดแค่ว่า "อะไร" แต่ให้แชร์ด้วยว่า "ทำไม" คุณถึงคิดแบบนั้น
  • เพื่อช่วยให้คนอื่นตัดสินใจได้ดีขึ้น
  • และลดสถานการณ์ที่คนอื่นพูดว่า "Principal <ชื่อ> บอกแบบนี้ ดังนั้นเราจะ..." โดยทำตามทั้งที่ยังไม่เข้าใจจริง

  ปัญหาที่ต้องการ input จาก L7 มักเกี่ยวข้องกับการตัดสินใจภายใต้ความไม่แน่นอนสูงพอสมควร
  สิ่งสำคัญแต่ยากคือ การอธิบาย mental model ของตัวเองให้ชัด — คุณใช้วิธีใดในการไปถึงข้อสรุปภายใต้ข้อมูลที่ไม่ครบ และเหตุใดความรู้บางอย่างจึงสำคัญกว่าจุดข้อมูลอื่น

20-24. รักษาการเชื่อมต่อกับองค์กร

• ข้อ 20: หา mechanism ที่ช่วยให้คุณยังเชื่อมกับทีมได้อยู่เสมอ
  • เช่น design review, demo ประจำสัปดาห์, นั่งใกล้ ๆ แล้วฟัง, มื้อเที่ยงกับทีม หรือบทสนทนาในทางเดินแบบสบาย ๆ
  • สิ่งเหล่านี้ช่วยให้คุณรับรู้ pulse ขององค์กร และมองออกว่าปัญหาหรือโอกาสสำคัญอยู่ตรงไหน
• ข้อ 21: ช่วยให้ทีมยังมองเห็นภาพใหญ่เสมอ
  • เมื่อคนระดับปฏิบัติการจมอยู่กับงานหน้างานและการส่งมอบรายวัน บางครั้งอาจพลาดปัญหาหรือโอกาสที่ใหญ่และระยะยาวกว่า และติดอยู่กับ local optimum
  • คุณสามารถใช้บริบทที่มี เพื่อช่วยเตือนทีมถึงสิ่งเหล่านี้ได้
• ข้อ 22: ต้องปฏิบัติได้จริง; สร้างสมดุลระหว่างการมองภาพใหญ่กับการยอมรับวิธีแก้ปัญหาเฉพาะพื้นที่
  • ปรึกษาและรับฟังคนระดับปฏิบัติการในรายละเอียด เพราะพวกเขาคือผู้เชี่ยวชาญหน้างาน
• ข้อ 23: คุณอาจถูกขอให้รีวิวหรือให้ฟีดแบ็กเรื่องเลื่อนตำแหน่งของคนที่คุณเคยใช้เวลาด้วยเพียงหนึ่งหรือสองชั่วโมง
  • แทนที่จะให้ฟีดแบ็กคุณภาพต่ำบนฐานข้อมูลพฤติกรรมเพียงเล็กน้อย คุณสามารถปฏิเสธได้
• ข้อ 24: หาเวลาโต้ตอบกับ intern และ mentor
  • ระหว่าง internship การมี touchpoint เพียงไม่กี่ครั้งก็อาจเปลี่ยนเกมได้
  • รวมถึงการเช็กอินช่วงต้นเพื่อปรับทิศทางหากจำเป็น และการเข้าร่วม demo day
  • ทำงานร่วมกับ mentor และ intern เพื่อมุ่งไปสู่ ผลลัพธ์ที่ยังมีคุณค่าต่อเนื่องแม้จบ internship แล้ว
  • เช่น product one-pager, ซอฟต์แวร์ที่ใช้งานได้จริง, หรือเอกสารทางเทคนิค

25-28. การเปลี่ยนผ่านและความรับผิดชอบในฐานะ Principal

• ข้อ 25: หากอยากไปถึง Principal คุณต้องวางตัวเองไว้บนเส้นทางวิกฤต แต่ถ้าอยากมีประสิทธิภาพในฐานะ Principal และก้าวต่อไปได้ คุณต้องค่อย ๆ ดึงตัวเองออกอย่างตั้งใจ
  • ก่อนหน้านี้คุณอาจเป็น "go-to" แต่ตอนนี้ต้อง เปลี่ยนจากคนที่ขาดไม่ได้ ไปเป็นคนที่อยู่ติดกับเส้นทางวิกฤต
  • องค์กรควรได้รับประโยชน์จากคุณมากขึ้นเรื่อย ๆ แต่ไม่ควรต้องพึ่งพาคุณเพื่อให้ทำงานได้อย่างมีประสิทธิภาพ
  • ควรคิดว่าจะให้อำนาจคนอื่นอย่างไร เพื่อให้พวกเขาสามารถทำสิ่งที่คุณเคยสร้างคุณค่าได้

  ระวังการเอาตัวเองไปผูกกับโปรเจกต์บน critical path เพราะจุดโฟกัสของคุณอาจถูกดึงไปด้วยลำดับความสำคัญอื่นได้ง่าย ดังนั้นควรหลีกออกจาก critical path หรือถ้าต้องอยู่จริง ๆ ก็ต้องล็อกเวลาและโฟกัสอย่างเข้มงวดมาก

• ข้อ 26: ถ้าคุณเพิ่งได้เลื่อนเป็น Principal นั่นเป็นเพราะคุณทำตัวเหมือน Principal มาสักพักแล้ว
  • โดยทั่วไปมักนานกว่าหนึ่งปี
  • ดังนั้นไม่ต้องกังวลกับความคาดหวังที่เพิ่มขึ้นเพราะตำแหน่งใหม่มากนัก
  • แค่ทำสิ่งที่ทำอยู่ต่อไป พูดคุยกับ Principal คนอื่น ๆ ทำความเข้าใจสไตล์ของตัวเอง และร่วมมือกับผู้นำเพื่อระบุพื้นที่โฟกัส
• ข้อ 27: อิสระที่มากขึ้นมาพร้อมความรับผิดชอบที่มากขึ้น
  • คุณมีอิสระในการเลือกว่าจะทำอะไร แต่ก็มีความคาดหวังเรื่องความรับผิดชอบและอิมแพ็กต์เช่นกัน
  • อิสระไม่ได้หมายถึงการทำอะไรก็ได้ตามใจ แต่คือ ความเป็นเจ้าของในการค้นหาปัญหาที่มี leverage สูงที่สุดให้แก้
  • อย่าคาดหวังว่าจะมีคนมาบอกว่าควรทำอะไร หรือจะมีคู่มือชัดเจนให้
  • องค์กรคาดหวังให้คุณเป็นคนมองออกว่าควรโฟกัสกับอะไร
• ข้อ 28: กำหนดขอบเขตหน้าที่และจัดแนวกับผู้นำ
  • วิธีหนึ่งคือแบ่งงานออกเป็นสาม bucket — (i) เจ้าของงาน, (ii) ผู้สนับสนุน, (iii) ที่ปรึกษา
  • ที่ปรึกษา: เข้าร่วม review ให้คำแนะนำ และมีความเข้าใจระดับสูงต่อเจตนาของระบบหรือผลิตภัณฑ์
  • ผู้สนับสนุน: นอกจากข้างต้นแล้ว ยังทำให้ไอเดียกลายเป็นลำดับความสำคัญขององค์กร ช่วยสร้างการจัดแนวและผลักดันการตัดสินใจ พร้อมประสานกับ stakeholder
  • เจ้าของงาน: นอกจากทั้งหมดข้างต้น ยังเป็นผู้เชี่ยวชาญของระบบ เป็นจุดติดต่อแรก และใส่ใจความสำเร็จด้านการออกแบบ การดำเนินการ และอิมแพ็กต์ในระดับเกือบหมกมุ่น
  • โดยทั่วไปผู้เขียนถือ ownership ของ 1-2 โปรเจกต์ (>50% ของเวลา), sponsor 2-3 โปรเจกต์ (~20% ของเวลา), และใช้เวลาที่เหลือไปกับการเป็น consultant

29-31. การเติบโตส่วนบุคคลและความยั่งยืน

• ข้อ 29: การเป็น Principal อาจทำให้รู้สึกโดดเดี่ยว
  • คุณเป็นส่วนหนึ่งของทุกทีม แต่ก็เหมือนไม่ได้เป็นส่วนหนึ่งของทีมไหนอย่างแท้จริง
  • ควรสร้างเครือข่ายเพื่อนร่วมทางที่พูดคุยกันได้อย่างเปิดอก
  • พวกเขาอาจไม่จำเป็นต้องอยู่บริษัทเดียวกันหรืออยู่ในโดเมนเดียวกันก็ได้
• ข้อ 30: อย่ามองข้ามความต้องการของตัวเอง
  • จัดสรรเวลาและพื้นที่ให้กับโปรเจกต์ที่สนับสนุนการเรียนรู้ การเติบโต และความเป็นอยู่ที่ดีของคุณ
  • ระยะสั้นอาจรู้สึกเหมือนเห็นแก่ตัว แต่ดีกว่าการหมดไฟในองค์กรอย่างมาก
  • หากคุณตั้งใจหางานที่ทำให้ตัวเองยังแข็งแรง มีความสุข และเติบโต องค์กรก็จะได้ประโยชน์เช่นกัน และองค์กรก็จะรักษาคุณไว้ได้ง่ายขึ้น
  • ร่วมมือกับผู้จัดการเพื่อหาสมดุลที่เหมาะสม
• ข้อ 31: เรียนรู้อย่างต่อเนื่อง; อุตสาหกรรมนี้เคลื่อนที่เร็วมาก
  • ถ้ารับโปรเจกต์ที่ไม่ได้สอนอะไรเลย หรืออย่างน้อยไม่ได้สอนสิ่งที่เกี่ยวข้องกับงาน เท่ากับคุณกำลังถอยหลัง
  • บางครั้งก็หลีกเลี่ยงไม่ได้ และเมื่อโปรเจกต์แบบนั้นมาถึง ก็ควรกำหนด timebox ไว้
  • การเรียนรู้ไม่จำเป็นต้องมาจากงานประจำเท่านั้น
  • มี PE จำนวนไม่น้อยที่อ่าน paper และตำราเทคนิค หรือหาเวลาช่วงสุดสัปดาห์มาลอง hack prototype เพื่อทำความเข้าใจไอเดียและเทคโนโลยีใหม่ ๆ ให้ลึกขึ้น

แหล่งข้อมูลเพิ่มเติม

• Amazon Principal Engineering Community Tenets
• Staff Engineer: Leadership Beyond the Management Track
• The Staff Engineer's Path: A Guide for ICs Navigating Growth and Change
• The job behind the job [of a high level IC]

หมายเหตุ: Principal Tech IC ของ Amazon/Google เป็นแนวคิดที่อยู่สูงกว่า "วิศวกรอาวุโส" ในความหมายที่ใช้กันในเกาหลี เพราะเป็น ผู้นำทางเทคนิคระดับสูงสุดที่มีบทบาทเชิงกลยุทธ์เทียบเคียงสายบริหาร

[roxie]

การตัดสินใจได้โดยไม่มีข้อมูลครบถ้วน และรู้ว่าทำไมความรู้บางอย่างจึงสำคัญกว่าจุดข้อมูลอื่น ๆ ได้ นั่นถือว่าน่าทึ่งมากจริง ๆ