Management

บทเรียนจากกูเกิล - ปัจจัยที่เหนี่ยวรั้งให้คนเก่งอยู่กับองค์กรต่อไป

Do Cool Things That Matter

คำถามที่สำคัญมากในแวดวง HR สมัยใหม่คือ "บริษัทจะรักษายอดฝีมือไว้ได้อย่างไร" บางทีคนที่ตอบคำถามนี้ได้อาจเป็นบริษัทไอทีชื่อดังทั้งหลาย ที่หาคนเก่งๆ มาทำงานได้ตลอดเวลา

Laszlo Bock ผู้บริหารตำแหน่ง SVP of People Operations ของกูเกิล ตอบคำถามเรื่องนี้ว่าปัจจัยที่คนเก่ง (talent) จะอยู่ทำงานกับคุณต่อไป มีแค่ 2 ข้อ และไม่มีเรื่องเงินมาเกี่ยวข้องสักเท่าไร

Bad Boss - เจ้านายห่วยเป็นสาเหตุสำคัญที่ทำให้พนักงานลาออก

Akuma  Shun Goku Satsu

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

เรื่องคนเป็นเรื่องใหญ่ เมืองไทยเองก็มีสุภาษิต (ที่มีคนโพสต์ไว้ในกระทู้) ว่า "คับที่อยู่ได้ คับใจอยู่ยาก" ประเด็นนี้เป็นเรื่องน่าสนใจ น่าไปหาข้อมูลเพิ่ม

The HP Way วิถีแห่งเอชพี

HP Way

วันเดียวกับที่ HP เผยโลโก้ของบริษัทใหม่ที่จะแยกตัวออกมา ผมก็อ่านหนังสือคลาสสิค The HP Way ที่เขียนโดยผู้ก่อตั้ง David Packard จนจบ (คนขวาในภาพคือ Packard คนซ้ายคือ Hewlett)

เลือกอ่านหนังสือเล่มนี้เพราะได้ยินการอ้างถึง "HP Way" อยู่บ่อยครั้งในตำราด้านบริหารธุรกิจ บวกกับอยากรู้ประวัติศาสตร์ของซิลิคอนวัลเลย์ในยุคก่อตั้งด้วย (HP ก่อตั้งปี 1939 ตอนนั้นยังไม่มีคอมพิวเตอร์ และสตีฟ จ็อบส์ ยังชดใช้กรรมชาติก่อนอยู่เลยกระมัง) อ่านจบแล้วพบว่าได้ความรู้ด้านประวัติศาสตร์ดังที่ต้องการ และได้เรียนรู้ว่า "วิถีแห่งเอชพี" ว่าตกลงแล้ว HP Way คืออะไรกันแน่

Being CEO: Ones and Twos

Bill Gates One

อ่านหนังสือ The Hard Thing About Hard Things ของ Ben Horowitz เขียนเล่าประสบการณ์สมัยเขาเป็น CEO เอง และการทำงานร่วมกับ CEO ในฐานะนักลงทุน มีประเด็นน่าสนใจหลายอย่าง เดี๋ยวจะทยอยเขียนถึง

อันที่คิดว่าน่าสนใจมากคือ Ben จัดกลุ่ม "ทักษะ" ที่จำเป็นต่อการเป็น CEO ว่ามีด้วยกัน 2 อย่างคือ 1. รู้ว่าจะต้องทำอะไร 2. พาบริษัททำในสิ่งที่คิดให้ได้

ถึงแม้ CEO จำเป็นต้องมีทักษะทั้ง 2 อย่างนี้ แต่ CEO ส่วนใหญ่มักถนัดไปสักทาง ทำให้ Ben เรียกซีอีโอที่ถนัดเรื่องคิด/วิสัยทัศน์ว่าเป็นกลุ่ม "หนึ่ง" (Ones) ส่วนซีอีโอที่ชอบบริหารองค์กรให้มีประสิทธิภาพสูงสุดเป็นกลุ่ม "สอง" (Twos)

Delegation

Fred Wilson เขียนภาคต่อจาก บทบาทของ CEO ที่ควรจะเป็น โดยยกประเด็นเรื่อง ทำเอง vs ให้คนอื่นทำแทน (DIY vs Delegate)

Fred บอกว่า CEO จำเป็นต้องกระจายงานให้คนอื่นเสมอ (CEOs must delegate) เพราะเมื่อบริษัทมีขนาดใหญ่ในระดับหนึ่งแล้ว CEO จะต้องทำงานเพียง 3 อย่างตามบล็อกตอนก่อนคือ "กำหนดวิสัยทัศน์, จ้างคนเก่ง, ทำให้บริษัทมีเงินพอใช้" งานอย่างอื่นให้คนอื่นทำ

[Startup CEO] การวางแผนการทำงานและแผนการเงิน

บล็อกตอนนี้เป็นต้นไป จะเก็บตกเนื้อหาในหนังสือ Startup CEO ส่วนของ Part Three: Execution โดยจะต่อจากตอน Company Operating System แล้วค่อยตามด้วยตอน ว่าด้วยบอร์ดของบริษัท Startup และ บริหารตัวเองให้ได้ก่อนไปบริหารคนอื่น

Startup CEO: A Field Guide to Scaling Up Your Business

[Startup CEO] บริหารตัวเองให้ได้ก่อนไปบริหารคนอื่น

สรุปเนื้อหาจากหนังสือ Startup CEO ของ Matt Blumberg (ตอนเก่า) ตอนนี้เป็นภาคสุดท้ายของหนังสือ ที่จะพูดถึงเทคนิค "การบริหารตัวเอง" ก่อนที่ซีอีโอจะไปบริหารคนอื่น ก็ควรจัดการชีวิตและการทำงานของตัวเองให้ได้ก่อน (Managing Yourself So You Can Manage Others)

Startup CEO: A Field Guide to Scaling Up Your Business

[Startup CEO] ว่าด้วยบอร์ดของบริษัท Startup

สรุปเนื้อหาจากหนังสือ Startup CEO ของ Matt Blumberg (ตอนเก่าอ่านได้จากแท็ก Startup CEO นะครับ)

Startup CEO: A Field Guide to Scaling Up Your Business

ตอนนี้ขอตัดตอนเข้าสู่ภาค 4 เรื่อง "บอร์ด" ของ Startup ก่อน ส่วนนี้น่าสนใจมากเพราะไม่ใช่ว่าทุกคนจะเคยนั่งประชุมบอร์ด คัดเลือกบอร์ด คุยกับบอร์ด ฯลฯ การอ่านประสบการณ์ของ Matt Blumberg อย่างน้อยก็ช่วยให้เห็นภาพว่าบอร์ดคืออะไร มีไปทำไม ควรมีอย่างไร ฯลฯ

[Startup CEO] Company Operating System

สรุปเนื้อหาจากหนังสือ Startup CEO ของ Matt Blumberg (ตอนเก่าอ่านได้จากแท็ก Startup CEO นะครับ)

Startup CEO: A Field Guide to Scaling Up Your Business

บทที่ 17 เริ่มหมดเนื้อหาช่วง HR เข้าสู่ส่วนของ business operation โดยผู้เขียนแนะนำแนวคิดที่น่าสนใจคือ Company Operating System ซึ่งไม่ใช่ OS จริงๆ หรอกแต่เป็น "จังหวะ" (rhythm) ของการทำงานภายในบริษัท ที่เราสามารถสร้างและควบคุมมันได้

Founder and Wife

ข่าวใหญ่ของวงการไอทีต่างประเทศวันนี้คือดราม่าของพนักงานหญิงของ GitHub อันแสนวุ่นวาย ถ้ามีเวลาและใจรักสามารถอ่านเรื่องแบบเต็มๆ ได้จาก TechCrunch

เนื้อหามันยาวมาก และคนเขียนบทความเล่าแบบสับสนมาก แต่สรุปแบบสั้นๆ เท่าที่จับความได้คือ พนักงานหญิงคนนี้ของ GitHub มีปัญหาความรักกับพนักงานคนหนึ่ง แล้วดราม่ากันจนพนักงานชายคนนี้ไล่ลบโค้ดของเธอในระบบ