ประสบการณ์ในองค์กรขนาดใหญ่
(churchofturing.github.io)- ทำงานในบริษัทขนาดใหญ่มา 1 ปี และสัมผัสได้ถึงความแตกต่างอย่างชัดเจนจากสภาพแวดล้อมแบบ สตาร์ทอัพ, SME ที่เคยอยู่
- เมื่อการระบุความรับผิดชอบและกระบวนการภายในองค์กรซับซ้อนขึ้น สิ่งที่ไม่เป็นปัญหาในองค์กรขนาดเล็กกลับกลายเป็นโจทย์ที่แก้ไม่ได้
- เกิดปัญหาด้านประสิทธิภาพและแรงจูงใจขององค์กรจากการสิ้นเปลืองทรัพยากรและความไม่สมดุลของเกณฑ์การจ้างงาน
- แนวคิดสำคัญในองค์กรอย่างความเร่งด่วนของงาน, การจัดการความปลอดภัย ถูกบิดเบือนจากความหมายจริงจนกลายเป็นการกระทำเชิงพิธีการและขั้นตอน
- แม้จะมีปัญหาหลากหลาย ก็ยังค้นพบประสบการณ์เชิงบวก เช่น การพัฒนาทักษะ, การเติบโตในสายอาชีพ
ย้อนมอง 1 ปีของประสบการณ์ในองค์กรขนาดใหญ่
ความแตกต่างระหว่างบริษัทใหญ่กับสตาร์ทอัพ
- ใช้เวลา 1 ปีแรกที่ $ENTERPRISE และได้สัมผัสความแตกต่างจากสตาร์ทอัพและ SME (ธุรกิจขนาดกลางและขนาดย่อม) ที่เคยทำงานมา
- ภายหลังจึงตระหนักได้ว่า การขาดประสบการณ์ด้านการพัฒนาซอฟต์แวร์ภายในองค์กรไม่ใช่เรื่องให้วิจารณ์ แต่กลับเป็นสัญญาณเชิงบวกเสียด้วยซ้ำ
- ผู้เขียนรวบรวมสิ่งที่สังเกตเห็นเพื่อถ่ายทอดความเป็นจริงของสภาพแวดล้อมการทำงานในบริษัทขนาดใหญ่
สิ่งที่ไม่เป็นปัญหาในบริษัทเล็ก กลับกลายเป็นปัญหาใหญ่ในบริษัทใหญ่
- เมื่อต้องแก้ไขข้อผิดพลาดที่เกี่ยวกับ Tool มักใช้เวลานานในการหาว่าใครคือผู้รับผิดชอบหรือผู้ดูแล
- การขาดการแบ่งปันข้อมูลภายในองค์กรและการเปลี่ยนผู้รับผิดชอบทำให้เกิดความไร้ประสิทธิภาพและการสิ้นเปลืองต้นทุน
- วิธีแก้ชั่วคราวคือ local setting override แต่โดยพื้นฐานแล้วนี่คือข้อจำกัดเชิงโครงสร้างขององค์กร
ความไม่มีเหตุผลในการจัดสรรทรัพยากร
- ต่างจากประสบการณ์ในบริษัทขนาดเล็กที่ต้องทำงานโดยมีงบประมาณจำกัด บริษัทใหญ่กลับเกิดการสิ้นเปลืองทรัพยากรเกินจำเป็นอยู่บ่อยครั้ง
- ความล้มเหลวของโปรเจ็กต์ระยะสั้น การใช้คลาวด์ที่ไม่จำเป็น และเรื่องอื่น ๆ นำไปสู่การสูญเสียงบประมาณ
- การบริหารงบประมาณและทรัพยากรที่ห่างไกลจากความต้องการจริง ทำให้แรงจูงใจในการทำงานลดลง
เพื่อนร่วมงานและโครงสร้างการจ้างงานที่ไม่สม่ำเสมอ
- ในสตาร์ทอัพ การจ้างงานตามความสามารถยังคงรักษามาตรฐานเชิงเปรียบเทียบได้ในระดับหนึ่ง
- แต่ในบริษัทใหญ่ การจ้างงานและการปรับโครงสร้างที่ไม่เกี่ยวข้องกับความสามารถเป็นเรื่องปกติ
- เกิดปรากฏการณ์ที่บางตำแหน่งไม่เกี่ยวข้องกับความสามารถในการทำงาน หรือองค์กรยังคงอยู่ได้โดยไม่สนคุณภาพของรายงาน
การตีความความเร่งด่วนของงาน
- ในสตาร์ทอัพ ความเร่งด่วนที่ชัดเจนคือเกณฑ์หลัก แต่ในบริษัทใหญ่จำเป็นต้องตีความความหมายหลายชั้นของงาน
- นอกเหนือจากสถานการณ์เร่งด่วนจริง ๆ (เช่น บริการล่ม) ยังมีความเร่งด่วนเชิงพิธีการเกิดขึ้นบ่อยครั้ง
- ภายใต้ขั้นตอนแบบนี้ จึงต้องมีความสามารถในการแยกแยะว่าอะไรคือลำดับความสำคัญที่แท้จริงของงาน
การจัดการความปลอดภัยที่กลายเป็นพิธีการ
- กระบวนการด้านความปลอดภัยมีบทบาทสำคัญต่อองค์กร แต่ในทางปฏิบัติกลับเน้นไปที่การรายงานเชิงพิธีการมากกว่าความเสี่ยงจริง
- งานด้านความปลอดภัยที่ความหมายเลือนหายไปเพราะมุ่งทำให้ถึงเป้าหมายเชิงตัวเลขหรือ KPI กลายเป็นเรื่องปกติในชีวิตประจำวัน
- ยังมีความไร้ประสิทธิภาพในการสื่อสารระหว่างวิศวกรกับผู้รับผิดชอบด้านความปลอดภัยด้วย
- ผู้เขียนเน้นย้ำว่า วัฒนธรรมที่ทุกคนสนใจแต่ตัวเลขนั้นเป็นสิ่งอันตราย
ความไร้ความหมายของตำแหน่งงาน
- ตำแหน่งซ้ำซ้อนอย่าง "Head of Architecture" เป็นเรื่องพบได้บ่อย และบทบาทก็ไม่ชัดเจน
วัฒนธรรมองค์กรที่มองความไม่แน่นอนเป็นจุดอ่อน
- ท่ามกลางการปรับโครงสร้างองค์กรครั้งใหญ่และการเลย์ออฟที่เกิดขึ้นเป็นระยะ ผู้นำมองว่าการพูดว่า “ไม่รู้” เป็นเรื่องต้องห้าม
- แม้โดเมนจะซับซ้อนเพียงใด แต่ในระดับผู้นำกลับให้ความสำคัญกับความฉับไวและความมั่นใจเป็นอันดับแรก
- ส่งผลให้โครงสร้างที่ทำให้ความผิดพลาดในอดีตเกิดซ้ำ ถูกทำให้ฝังแน่นยิ่งขึ้น
ทีมวิศวกรรมที่แยกเป็นไซโล
- ทีมวิศวกรรมแต่ละทีม (หรืออาจเรียกว่า 'จักรวรรดิ') ต่างมีมาตรฐานและวัฒนธรรมของตัวเอง
- อุปสรรคระหว่างแผนกสูงขึ้น และยากต่อการทำมาตรฐานหรือการกระจายbest practice
- ความเป็นอิสระของแต่ละแผนกกลายเป็นข้อจำกัดต่อความร่วมมือระหว่างทีม
ประสบการณ์เชิงบวก
- การมีส่วนร่วมในชุมชนวิศวกรช่วยขยายมุมมองต่อการพัฒนาซอฟต์แวร์
- ยังมีความพึงพอใจรูปแบบใหม่ เช่น การเติบโตในสายอาชีพ, โอกาสในการมีเมนเทอร์, ประสบการณ์กับผู้ใช้งานขนาดใหญ่
- องค์กรยังสนับสนุนอย่างแข็งขันในเรื่องการยกระดับความเชี่ยวชาญ, การทำงานร่วมกับเพื่อนร่วมงานที่หลากหลาย, และการศึกษาและพัฒนาศักยภาพ
- ความมั่นคงอย่างการจ่ายเงินเดือนสม่ำเสมอและความมั่นคงในหน้าที่การงานก็เป็นข้อดีเช่นกัน
บทสรุป
- แม้จะมีมุมมองเชิงวิพากษ์ แต่คุณค่าเชิงบวกของบริษัทขนาดใหญ่ก็ชัดเจน
- ผู้เขียนตั้งใจว่าจะกลับมาตรวจสอบมุมมองนี้อีกครั้งเมื่อเวลาผ่านไปอีกนาน
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ต้องจำ Remy's Law of Enterprise Software ไว้เสมอ (ลิงก์ที่เกี่ยวข้อง: https://thedailywtf.com/articles/graceful-depredations) ถ้าซอฟต์แวร์ถูกเรียกว่า "enterprise" โดยมากก็มักจะไม่ค่อยดี เอาจริง ๆ นอกจากมุกตลกแล้ว ผมก็สนใจประเด็นเชิงบวกที่กล่าวถึงตอนท้ายบทความ บางข้อก็เข้าใจได้ แต่บางข้อก็ดูเหมือนจะสร้างปัญหาเพิ่มมากกว่าเดิม เช่น ข้อที่ว่า "มีโอกาสพัฒนาอาชีพจริง ๆ" ถ้าการพัฒนาอาชีพหมายถึงแค่หาเงินได้มากขึ้น ก็น่าจะพูดตรง ๆ ว่า "หาเงินได้มากขึ้น" ไปเลย ไม่จำเป็นต้องอ้อมค้อม ถ้าไม่ใช่แบบนั้น ก็สงสัยว่าการพัฒนาอาชีพในบริบทนี้คืออะไร นอกจากการจมลึกลงไปอีกในความไร้ประสิทธิภาพและปัญหาขององค์กรที่พูดถึงมาตลอด และประโยคที่ว่า "การได้สร้างซอฟต์แวร์ที่มีคนใช้หลายล้านคนเป็นเรื่องน่าพอใจ" ก็ทำให้สงสัยเหมือนกันว่า ถ้าซอฟต์แวร์นั้นไม่ดีหรือสร้างอันตรายต่อผู้ใช้ มันยังน่าพอใจอยู่ไหม
สำหรับคำถามที่ว่าการพัฒนาอาชีพคือแค่การหาเงินเพิ่มหรือไม่นั้น ถ้าคิดเรื่องชีวิตไปนานพอ สุดท้ายเราจะเจอความจริงว่าเราต่างก็เป็นเพียงชิ้นส่วนเล็ก ๆ ในระบบที่ใหญ่กว่ามาก และเมื่อคิดลึกลงไปก็จะมีคำถามหนัก ๆ ตามมา เช่น 'ในสังคมที่ไม่ยุติธรรม ฉันจะยังเป็นคนเที่ยงธรรมได้ไหม?' หรือ 'ในเมื่อฉันมีบทบาทเล็กน้อย ฉันจะสร้างผลเชิงบวกต่อชุมชนได้อย่างไร?' แต่ละคนตอบสนองต่อคำถามเหล่านี้ไม่เหมือนกัน บางคนพยายามอย่างแข็งขันเพื่อหาโอกาสเปลี่ยนแปลง ขณะที่บางคนรู้สึกหมดพลังภายในระบบจนเลือกจะเมินมันไป สำหรับผม ผมเชื่อในงานที่เราทำ และการพัฒนาอาชีพในบริษัทไม่ได้มีแค่เรื่องเงิน แต่หมายถึงความรับผิดชอบที่เพิ่มขึ้นและความสามารถในการสร้างการเปลี่ยนแปลงที่มากขึ้นด้วย ในองค์กรที่ไร้ประสิทธิภาพ ทางเลือกของผมคือออกไป อยู่ที่เดิม หรือเข้าไปลึกขึ้นในองค์กรแล้วพยายามสร้างการเปลี่ยนแปลงเชิงบวก ส่วนคำถามว่า "ถ้าซอฟต์แวร์ที่ใช้อยู่มันแย่หรือเป็นอันตราย ยังน่าพอใจไหม?" บางคนอาจตอบว่าน่าพอใจแม้จะเป็นงานที่สร้างโทษ แต่ผมไม่ใช่คนแบบนั้น และผมเชื่อว่างานที่ผมทำมีผลดีต่อสังคม หมายถึงว่า "การได้สร้างซอฟต์แวร์เชิงบวกต่อสังคมที่มีคนใช้หลายล้านคนนั้นน่าพอใจ"
การพัฒนาอาชีพในบริษัทใหญ่มีความหมายมากกว่าเรื่องเงิน ตัวอย่างเช่น คุณมักมีโอกาสได้เป็นผู้นำโปรเจกต์ที่ใหญ่ขึ้น หรือได้สร้างผลิตภัณฑ์ทั้งชิ้นภายในบริษัท ซึ่งเมื่อก่อนอาจเป็นงานระดับที่ต้องให้ทั้งสตาร์ตอัปหนึ่งแห่งทำ คุณยังมีโอกาสได้ร่วมหลายโปรเจกต์ตลอดหลายปี หรือได้ประสบการณ์ในการนำทีมที่มีขนาดใหญ่กว่า ซึ่งในบริษัทใหญ่จะหาได้ง่ายกว่าโดยเปรียบเทียบ และถ้าซอฟต์แวร์นั้นแย่หรือเป็นอันตรายล่ะ? สตาร์ตอัปหรือบริษัทเล็กก็ไม่ได้ดีกว่าเสมอไป ทุกอย่างขึ้นอยู่กับแต่ละกรณี
ถ้าคุณฝันอยากทำงานอย่าง data scientist researcher หรือ developer evangelist คุณก็ต้องอยู่ในองค์กรที่รองรับบทบาทแบบนั้นได้ บทบาทอย่าง microservice architect ก็ไม่เหมาะกับองค์กรเล็ก แต่เป็นที่ต้องการในบริษัทใหญ่ระดับ 3000 คนขึ้นไป เช่นเดียวกับสาย engineering manager ที่จะมีความหมายก็ต่อเมื่อมีบุคลากรมากพอ ดังนั้นขนาดองค์กรจึงเปิดโอกาสด้านการพัฒนาอาชีพบางอย่างได้ และแน่นอนว่าซอฟต์แวร์บางอย่างก็แย่หรือเป็นอันตราย แต่สิ่งที่เราทำก็ไม่จำเป็นต้องเป็น enterprise software เสมอไป และจริง ๆ ก็หวังว่าจะไม่ใช่
ผมไม่คิดว่า enterprise software จะเลวร้ายโดยเนื้อแท้ แน่นอนว่าเราสร้าง enterprise software ที่ดีได้ และการทำแบบนั้นให้สำเร็จภายใต้ข้อกำหนดอันซับซ้อนก็ต้องใช้ความสามารถมากทีเดียว แต่ในความเป็นจริง แทบไม่มีใครถูกประเมินจากการใส่ใจประสบการณ์ผู้ใช้ในองค์กรเลย แม้แต่ผมเองที่อยู่ใน $ENTERPRISE มาเกิน 7 ปี ก็เคยเจอผู้ใช้ตัวจริงแค่ครั้งเดียว
สำหรับคำถามว่าถ้าซอฟต์แวร์แย่หรือเป็นอันตรายแล้วยังรู้สึกพอใจไหม วิศวกรจำนวนมากอาจพอใจเพียงเพราะได้ทำงานในสเกลใหญ่ หรือไม่ก็รู้สึกหมดแรงจนมองว่ามันไม่เกี่ยวกับตัวเอง และถ้าจะให้มีสเกลระดับนั้นจริง ๆ ก็มักต้องอยู่ในบริษัทยักษ์ใหญ่เท่านั้น สุดท้ายจึงหลีกไม่พ้นการไหลไปสู่โครงสร้างทุนนิยมแบบอัลกอริทึม dark pattern การทำกำไรสูงสุดให้ผู้ถือหุ้น และอื่น ๆ
ยังมีอีกประเด็นที่ตกไป คือเมื่อมีผู้นำชุดใหม่เข้ามา ก็มักจะไล่คนเดิมออกแล้วเอาคนของตัวเองเข้ามาแทน และทุกปีชื่อทีมก็เปลี่ยน ทั้งที่งานจริงไม่ได้เปลี่ยนเลย แค่เติมคำอย่าง "Innovation", "Discovery", "Leadership" ลงไปในชื่อทีมซ้ำ ๆ
ถ้าชื่อทีมจะเปลี่ยนบ่อยขนาดนั้น ก็อยากให้ล็อกเป็นชื่ออย่าง ‘Pikachu’ ไปเลยแล้วใช้ยาว ๆ เราทุกคนก็รู้อยู่แล้วว่าชื่อไม่ได้สำคัญอะไร ถ้ารับความจริงข้อนี้กันได้ก็คงเลิกเปลี่ยนชื่อสักที เพราะทุกครั้งที่เปลี่ยนก็ต้องแก้เอกสารและประกาศให้คนทั้งองค์กรรู้ เสียแรงเสียเวลาโดยไม่จำเป็นมาก
ในองค์กรของเรา มีไลบรารีโค้ดโครงสร้างพื้นฐานภายในที่สร้างด้วย Terraform CDK มันช่วยสร้างทรัพยากร monitoring ใน Datadog และ Pagerduty แบบอัตโนมัติ อยู่มาวันหนึ่งผมลบ argument บังคับชื่อ ‘team’ ทิ้งไปเลย เพราะในทางปฏิบัติมันเปลี่ยนแทบทุก 7 เดือนอยู่แล้ว
คู่แข่งของผมชอบทำแบบนี้มาก คือทุกครั้งที่ย้ายบริษัทใหม่ เขาจะค่อย ๆ ดึงเพื่อนร่วมงานเก่าทั้งฝ่าย help desk และทีมพัฒนามาหมด เหตุผลคือความภักดี ต่อให้ผลลัพธ์ไม่ดี คนกลุ่มนี้ก็ไม่บ่นและไม่ยกปัญหาขึ้นไปข้างบน ถ้าฟังอดีตพนักงานที่เคยทำงานกับเขา เรื่องจะออกมาเหมือนเดิมทุกครั้ง:
ถ้าชื่อโปรเจกต์มีคำอย่าง ‘Excellence’ อยู่ด้วย โดยทั่วไปผมมักจะไม่ค่อยไว้ใจ
เนื้อหาในบทความนี้ส่วนใหญ่ใช้กับหน่วยงานภาครัฐได้เหมือนกัน ต่างกันก็แค่เรื่องไม่มีงานสุดสัปดาห์ มีโอกาสเติบโตทางอาชีพ (เชิงเทคนิค) และมีการสนับสนุนการพัฒนาทักษะหรือการอบรม
เป็นบทความที่สนุกและน่าสนใจมาก ผมทำงานใน enterprise มาได้ราว 3 ปี กำลังเติบโตทางเทคนิคอยู่ แต่รู้สึกว่าในความเป็นจริงกลับได้เรียนรู้เรื่องคน การสื่อสาร และระบบราชการมากกว่า ผมเข้าใจคอมเมนต์เรื่องงบประมาณกับเมาส์มาก แต่ด้วยเสถียรภาพทางการเงินของ $ENTERPRISE ผมเลยซื้อเมาส์เองไปเลยก็ได้ อาจมีใครบางคนมาตั้งประเด็นเรื่องเมาส์ที่ไม่ได้รับอนุมัติบ้างก็ได้... แต่ก็แค่เมินไป หรือมองความเร่งด่วนปลอม ๆ ของการอนุมัติเมาส์ว่าไม่ใช่เรื่องใหญ่อะไร
ผมทนอยู่ในองค์กรแบบนี้ไม่ได้จริง ๆ ต่อให้เพิ่มเงินเดือนเป็น 3 เท่า ผ่านไปไม่กี่เดือนก็คงพังหมด
เงินชดเชยมักแปรผกผันกับปริมาณงานที่จำเป็นต้องทำจริง
ต้องกินยาจิตเวช (Zoloft) หนักมากถึงจะพอทนได้
บางครั้งผมก็คิดเหมือนกันว่าจะให้ความสำคัญกับเงินก่อน รับเงินเดือนสูง ๆ จาก $ENTERPRISE เก็บเงินให้พอ แล้วค่อยออกไปพักยาว แต่แค่คิดถึงขั้นตอนสัมภาษณ์ก็หมดแรงแล้ว ตอนนี้ผมอยู่ที่ $MIDSIZENOLONGERSTARTUP ซึ่งที่นี่เองก็มีเรื่องแปลก ๆ หลายอย่างในแบบของมันที่คอยบั่นทอนผม
ผมก็ทำงานในสภาพแวดล้อมคล้ายกัน และรู้สึกว่าบทความนี้ตรงจนเจ็บ ผมคิดว่างานของตัวเองคือการแก้ปัญหาและ deploy ซอฟต์แวร์ แต่ในโลกความจริง "ลำดับความสำคัญที่แท้จริง (revealed preferences, ลิงก์ที่เกี่ยวข้อง: https://en.wikipedia.org/wiki/Revealed_preference)" ขององค์กรไม่ใช่แบบนั้นเลย เหมือนเรื่องที่ผู้เขียนย้ายจากบริษัทเล็กไปบริษัทใหญ่ ผมเลยสงสัยว่ามีใครเคยย้ายกลับจากบริษัทใหญ่ไปบริษัทเล็กไหม และควรเล่าประสบการณ์แบบ enterprise ให้ดูมีน้ำหนักในการสัมภาษณ์ทีมเล็กอย่างไรดี
จากประสบการณ์ของผม มันเหมือนเรื่องเล่าของสองเมือง ผมเองก็เหนื่อยกับการเสียเวลาแบบไร้ความหมายใน $ENTERPRISE มากจนตอนนี้ยอมเสียเงินเดือน 20% เพื่อไปอยู่ที่เล็กกว่าแต่ทำงานได้จริงและสร้างผลงานบางอย่าง แต่ตลอด 3 ปีที่ผ่านมา แม้ผมจะพยายามอธิบายสิ่งที่ได้เรียนรู้มาโดยไม่ให้ดูเป็นลบ ผู้ก่อตั้งสตาร์ตอัปก็มักมองประวัติของผมว่าเป็นภาระอยู่ดี ทักษะเอาตัวรอดที่ต้องใช้ในป่ากับในสวนสัตว์มันต่างกันเกินไป และปฏิกิริยาที่ได้รับก็มักจะเป็นทำนองว่า ผมอยู่ในสวนสัตว์นานเกินไปแล้วหรือเปล่า ในทางกลับกัน บริษัทใหญ่เองก็อยากจ้างคนที่เข้าใจกระบวนการภายในและลำดับชั้นขององค์กร ทำให้คนจากสตาร์ตอัปจะไปสัมภาษณ์ที่แบบนั้นก็ไม่ได้ง่ายเช่นกัน
ผมเคยย้ายจากบริษัทใหญ่ไปบริษัทเล็ก และยิ่งบริษัทใหญ่ขึ้น ปัญหาที่ต้องแก้ก็ยิ่งเป็นเรื่องคนกับการเมืองในองค์กรมากกว่าเรื่องเทคนิค ในบริษัทใหญ่ มักมีการใช้ค่าตอบแทนแบบ golden handcuffs (ลิงก์ที่เกี่ยวข้อง: https://en.wikipedia.org/wiki/Golden_handcuffs) เพื่อรั้งคนเก่งไว้ และเพราะแบบนั้นคนจึงยอมทนเรื่องไร้สาระต่าง ๆ ขององค์กรได้นานขึ้นจนกว่าจะยอมทิ้งค่าตอบแทน ถ้าคุณเล่าเรื่องในทำนองว่า "ผมออกจากบริษัทใหญ่เพราะอยากสร้างความเปลี่ยนแปลงที่จับต้องได้จริง" ทีมเล็กก็มักจะเข้าใจได้
บริษัทใหญ่สนใจแค่การส่งมอบผลลัพธ์แบบของพวกเขาให้สม่ำเสมอเท่านั้น การตั้งเป้าหมายก็ถูกกำหนดด้วยเหตุผลหลากหลาย ทั้งการทำตัวเลขให้ถึง ขั้นตอนกำกับดูแล หรือการตัดสินใจของผู้บริหาร มันเป็นโลกคนละใบกับความมีเหตุผลแบบมนุษย์ที่เราคิดกัน
สำหรับบทความต้นฉบับที่พูดว่า "ยังมีจักรวรรดิอื่น ๆ อีก" ก็มีการแซวต่อว่า นอกจากอังกฤษ (manual QA) และอียิปต์ (พีระมิดซอฟต์แวร์) ยังมีมองโกล (วันดีคืนดีก็โยน requirement มหาศาลมาแล้วหายไป), สเปน (พยายามทำทุกกฎให้สมบูรณ์แบบจนกลายเป็นมีแต่แรงเสียดทาน), ญี่ปุ่น (โดนผู้บริหารตำหนิแล้วออกผจญภัยทำร้ายเส้นทางอาชีพตัวเอง), จีน (หลงอยู่ในเขาวงกตของการประชุมและการสื่อสารที่ลับสุดยอด) อะไรทำนองนั้น
เป็นบทความที่ให้ insight ดีมาก และสื่อให้เห็นความสำคัญของการเมืองในออฟฟิศกับบทบาทของผู้บริหารได้ดี
ตอนนี้อยู่ใน $ENTERPRISE มา 18 เดือนแล้ว รู้สึกเจ็บจี๊ดเพราะมันตรงกับความจริงมาก