บริษัทใหญ่โครงสร้างมันทำให้เกิด win ที่มีขอบเขตชัด ระบุได้ว่าเป็นของใคร และมองเห็นเป็นชิ้นเป็นอันได้ยาก เงินเดือนส่วนหนึ่งคือค่าที่ต้องอยู่ให้ได้โดยไม่มีสิ่งนั้น
จากฝั่งproductที่ต้องคุมว่าอะไรปิดจบ กรอบนี้ใช้ได้จริงกว่าที่คิด แต่สามข้อที่ว่ามาไม่ได้พังเองตามธรรมชาติเสมอ มันพังเพราะการตัดสินใจ ขอบเขตชัด มักหายไปเพราะไม่มีใครกล้าตัดscopeให้เล็กพอจะจบในควอเตอร์เดียว ความเป็นเจ้าของถูกเฉลี่ย เพราะแปะชื่อคนสิบแปดคนปลอ
จากฝั่งproductที่ต้องคุมว่าอะไรปิดจบ กรอบนี้ใช้ได้จริงกว่าที่คิด แต่สามข้อที่ว่ามาไม่ได้พังเองตามธรรมชาติเสมอ มันพังเพราะการตัดสินใจ
ขอบเขตชัด มักหายไปเพราะไม่มีใครกล้าตัดscopeให้เล็กพอจะจบในควอเตอร์เดียว
ความเป็นเจ้าของถูกเฉลี่ย เพราะแปะชื่อคนสิบแปดคนปลอดภัยกว่าให้คนเดียวรับผิดชอบแล้วพลาด
feedback loopช้า เพราะdashboardมันโชว์ให้ผู้บริหารสบายใจ ไม่ได้ทำมาให้คนทำงานเห็นว่าตัวเองขยับอะไร
สเกลเป็นข้ออ้างได้ครึ่งเดียว อีกครึ่งคือปัญหาความกล้าในการตัดงาน
ผมเห็นเรื่องนี้เกิดซ้ำมาพอจนตอนนี้รูปแบบมันชัดแล้ว ทำงานมาได้สองสามปี เงินเดือนดี สวัสดิการดี impact ระดับ FAANG (maango อะไรก็ว่าไป) ทำงานได้ดี ได้ขึ้นเงินเดือนเรื่อยๆ แต่มันมีอะไรไม่เข้าที่ ยังไม่ถึงขั้น burn out หรอก แต่พอจะชี้ไปที่อะไรสักอย่างแล้วบอกว่า "อันนี้เกิดเพราะผม" กลับไม่มีอะไรให้ชี้ได้เลย เวลาเจอครอบครัวเจอเพื่อนแล้วเขาถามว่าทำงานอะไร ก็ตอบได้แบบคลุมเครือ อธิบายให้ชัดไม่ได้จริงๆ โปรเจกต์นึงมี stakeholder สิบแปดคน การตัดสินใจผ่าน approval สี่ชั้น วนไปวนมา แล้วใครกันแน่ที่เป็นคนชี้ขาดก็ไม่มีใครรู้ ผลลัพธ์ไปนั่งอยู่บน dashboard ที่อ่านได้แต่แทบไม่มีทางไปขยับมันจริงๆ สิ่งที่เราทำลงไปคงมีค่าจริง แต่มันสำคัญแค่ไหน หรือสำคัญจริงไหม ตอบไม่ได้เลยจริงๆ
ความรู้สึกแบบนี้ไม่ใช่ปัญหาที่นิสัยใครหรอก บริษัทใหญ่ทำให้ทุกคนรู้สึกเหมือนกันหมด ไม่ได้เป็นที่เราคนเดียว สิ่งที่ขาดไป อย่างน้อยผมขอเรียกมันแบบนี้ คือ win density การได้ความสำเร็จที่ระบุว่าเป็นของเราอย่างสม่ำเสมอ win คือ 1) มีขอบเขตชัด ระบุได้ว่าเป็นของใคร และมองเห็นเป็นชิ้นเป็นอัน 2) มันจบ และเราได้ทำอะไรสำเร็จไปจริงๆ 3) สาวกลับไปได้ว่ามาจากสิ่งที่เราทำ ชี้ไปที่ร่องรอยที่มันทิ้งไว้ได้ บริษัทใหญ่กดทั้งสามข้อนี้พร้อมกัน งานยืดข้ามไปหลายไตรมาส ความเป็นเจ้าของถูกเฉลี่ยให้คนมากพอจนไม่มีใครเห็นเค้าโครงตัวเองในนั้น feedback loop มาช้า ถูกกรองผ่าน dashboard ผ่านลำดับชั้น ผ่านรอบ review มันคือวิธีที่องค์กรใหญ่ประสานงานกันในสเกลใหญ่
ดีลของ startup มันกลับด้านกัน เงินเดือนน้อยลง win density สูงขึ้น ได้ทำอะไรเสร็จทุกวัน แล้วมันเสพติด ปัญหาคือ startup มักจะเจ๊ง สุดท้ายก็ burn out แล้วเงินเก็บก็แทบไม่มี
สิ่งที่ win density ต่ำๆทำกับคนไม่ได้ดราม่าอะไร มันไม่ได้ทำให้ลุกออกจากห้องไป ส่วนใหญ่ก็แค่ชินไปเอง แต่มันทำให้อยากทำอะไรให้เสร็จสักอย่าง อะไรใหม่ๆ engineer เริ่ม overengineer เพราะ milestone ที่ปั้นขึ้นมาเองยังดีกว่าไม่มี milestone เลย ถ้างานไม่ยอมให้เส้นชัยชัดๆ ก็ปั้นมันขึ้นมาเอง refactor อีกรอบ เขียน re-architecture doc อีกฉบับให้ service ที่มันก็ทำงานได้ดีอยู่แล้ว โปรเจกต์ cleanup ที่มีอยู่เพราะมันทำให้จบได้เป็นหลัก หาวิธีใหม่ๆมาทำ testing... บางคนก็แค่ซีดลงแล้วตายข้างใน ทำตามที่สั่งเป๊ะๆ ยังมาทำงาน ยังดูปกติดีในห้อง status meeting แต่เงินเดือนส่วนหนึ่งเริ่มรู้สึกเหมือนเป็นค่าที่ต้องยอมไม่ได้เห็นงานตัวเองลงจอด
อันนี้ส่วนใหญ่เป็นเรื่องบ่นของคนทำงานออฟฟิศ คนอีกเยอะที่ทั้งเงินน้อย และ win density ก็ต่ำ บทความนี้พูดถึงดีลในเวอร์ชันของคนทำงานออฟฟิศ ใช่ เงินเดือนเราดี คุณภาพชีวิตก็ดี แต่เราก็ใช้เวลาวันละ 8 ชั่วโมงกว่าๆไปกับงาน บ่อยครั้งมากกว่านั้นด้วยซ้ำ แล้วเราต้องทำให้มันเข้ากันได้กับวิธีที่แรงขับและสมองเราทำงาน ใช่ งานมันสบาย และบ่อยครั้งเราก็ได้เงินดี และใช่ จะทำให้งานออฟฟิศน่าอยู่และสนุกสุดๆก็ทำได้ ประเด็นที่ผมจะบอกคือ ต้องมี win density ถึงจะได้แบบนั้น ต้องมีความสำเร็จที่เป็นของเราเองอย่างสม่ำเสมอ ถึงจะรู้สึกเหมือนได้ชนะ
และนั่นก็คือเหตุผลที่ปัญหานี้สำคัญกับ manager ด้วย แม้จะแก้ปัญหาเรื่องสเกลที่เป็นต้นตอให้หมดจดไม่ได้ก็ตาม งานบางอย่างมันช้าโดยธรรมชาติ ไม่ใช่ทุกอย่างจะ ship ได้ในลูปหนึ่งสัปดาห์ แต่ทีมจะไปได้ดีกว่าเมื่องานมันปิดจบ การระบุว่าเป็นของใครเป็นเรื่องจริง และคนยังเห็นได้ว่าอะไรขยับเพราะตัวเอง ยังรู้สึกได้ว่าเป็นเจ้าของมันตั้งแต่ต้นจนจบ และทำมันสำเร็จ ความถี่ในการ ship ที่สูงขึ้นมักสัมพันธ์กับ performance ขององค์กรที่ดีขึ้นและ engagement ที่แข็งแรงขึ้น ประเด็นในทางปฏิบัติมันง่ายกว่าข้อถกเถียงเชิงวิจัย ถ้าไม่มีใครบอกได้ว่าอะไรเสร็จไปแล้ว ใครเป็นเจ้าของ หรืออะไรเปลี่ยนไป ความทะเยอทะยานก็เริ่มบูดกลายเป็นแค่งานประคองระบบ
ไม่ต้องจ่ายเงินคนเพิ่มเพื่อให้เขามีความสุขขึ้นก็ได้ (เฮ้ย กูเพิ่งพูดอะไรลงไป???) บ่อยครั้งแค่ต้อง "gamify" งานให้เขา ป้อน dopamine ให้ engineer บ่อยๆถี่ๆ บางคนจะรับดีลนี้แบบตั้งใจเองด้วยซ้ำ ผมเองก็เคยรับมันแบบตั้งใจมาแล้ว แต่ถ้าให้ดี จ่ายเงินเขาด้วยนะ
งานวิจัยชุด State of DevOps ของ DORA พบสม่ำเสมอว่าความถี่ในการ deploy ที่สูงขึ้นสัมพันธ์กับ performance ขององค์กรที่แข็งแรงขึ้น และมักสัมพันธ์กับ engagement ที่สูงขึ้น แม้ทิศทางของเหตุและผลจะยังเป็นที่ถกเถียงกันอยู่
เวอร์ชันที่แข็งที่สุดของโพสต์นี้คือประโยคที่ว่าเงินเดือนส่วนหนึ่งคือค่าที่ต้องอยู่ให้ได้โดยไม่เห็นงานตัวเองลงจอด อันนี้จริงและไม่ค่อยมีคนพูดตรงๆ แต่win densityมันกระจายไม่เท่ากันในทีม งานfrontendกับaccessibilityนี่คือจุดที่ความคลุมเครือของproductกลายเป็นสิ่งที่คนคลิกจริงๆ เราเห็นผลทันทีกว่าใคร ปัญหาคือพอถึงรอบreview สิ่งที่นับเป็นwin กลับเป็นfeatureที่ผู้บริหารชี้ได้บนสไลด์ ไม่ใช่edge caseที่เราอุดไปเงียบๆสามสิบเคส
มองจากมุมการเงินแล้วดีลนี้คุ้มกว่าที่โพสต์ทำให้รู้สึก เงินเดือนสูงที่ความสำเร็จต่ำ แปลงเป็นsavings rateสูงได้ ถ้าคุมรายจ่ายอยู่ งานที่win densityสูงแต่เงินน้อยอย่างstartup ส่วนใหญ่จบที่burn outแล้วเงินเก็บแทบไม่มี แบบที่โพสต์เขียนเอง ความรู้สึกว่าได้ชนะทุกวันมันไม่ได้จ่ายค่าอิสรภาพตอนห้าสิบ อัตราการออมต่างหากที่จ่าย ความเบื่อในงานที่มั่นคงคือต้นทุนที่ถูกที่สุดในบรรดาทางเลือกทั้งหมด
จากฝั่งproductที่ต้องคุมว่าอะไรปิดจบ กรอบนี้ใช้ได้จริงกว่าที่คิด แต่สามข้อที่ว่ามาไม่ได้พังเองตามธรรมชาติเสมอ มันพังเพราะการตัดสินใจ
ขอบเขตชัด มักหายไปเพราะไม่มีใครกล้าตัดscopeให้เล็กพอจะจบในควอเตอร์เดียว
ความเป็นเจ้าของถูกเฉลี่ย เพราะแปะชื่อคนสิบแปดคนปลอดภัยกว่าให้คนเดียวรับผิดชอบแล้วพลาด
feedback loopช้า เพราะdashboardมันโชว์ให้ผู้บริหารสบายใจ ไม่ได้ทำมาให้คนทำงานเห็นว่าตัวเองขยับอะไร
สเกลเป็นข้ออ้างได้ครึ่งเดียว อีกครึ่งคือปัญหาความกล้าในการตัดงาน
เห็นด้วยกับอาการนะ แต่คำว่าwin densityมันเอียงไปทางคนที่งานมองเห็นได้อยู่แล้ว งานสายreleaseกับinfraนี่win densityต่ำตลอดกาลโดยธรรมชาติ คุณกันความพังได้สำเร็จสิบครั้งก็ไม่มีใครเห็น แต่พังหนเดียวทั้งบริษัทรู้ สิ่งที่ขาดไม่ใช่ความสำเร็จที่ชี้ได้ มันคือเครดิตของงานที่ไม่มีร่องรอยให้ชี้ ปัญหาคนละชั้นกัน
ที่เขียนว่าtech debtครึ่งหนึ่งเป็นการปั้นมิลสโตนเองเพราะงานจริงมันไม่ยอมจบนี่ตรงเกินไปจนแสบ ทีมกูช่วงปีก่อนมีคนเสนอre-architecture docให้serviceที่ทำงานนิ่งมาสองปี เหตุผลที่ขายกันในห้องคือscalability แต่เหตุผลจริงคือมันเป็นงานชิ้นเดียวในควอเตอร์นั้นที่มีจุดเริ่มกับจุดจบชัดๆ ปัญหาคือwin ที่ปั้นเองพวกนี้มันมีต้นทุนจริงตอนตีสอง คนที่ไม่ได้เลือกให้rewrite ต้องมารับon-callดูแลblast radiusที่โตขึ้นเพราะใครคนนึงอยากรู้สึกว่างานเสร็จ
บริษัทจ่ายเงินคนเพื่อกันไม่ให้ออกไปทำอะไรสำเร็จที่อื่น คือประโยคที่อ่านแล้วอยากquote tweetพร้อมคำว่าโดนจับได้
สิ่งที่เริ่มทำให้หงุดหงิดไม่ใช่การดัน AI เอง tool บางตัวก็มีประโยชน์จริง ตอนนี้ใช้ทุกวันแล้ว ที่หงุดหงิดคือ management สั่งให้ทำงานแบบ AI-first แต่ปล่อยให้ทุก process รอบข้างเป็นศัตรูกับการใช้ AI แบบเต็มที่ คนถูกสั่งให้เอา AI มาใช้ทั้งเขียน code วางแผน research ร่างงาน debug ดึงความรู้ คุมโปรเจกต์ แต่ความรู้เชิงปฏิบัติครึ่งบริษัทก็ยังฝังอยู่ในบทสนทนาที่ไม่มีใครจดและ…
Amazon คือเครื่องจักรที่มีประสิทธิภาพที่สุดในวงการเทค แล้วพนักงานของมันก็ดันไปตัดสินใจว่าการเป็นเชื้อเพลิงมันเท่ากับการเป็นเครื่องยนต์ Leadership Principles ถูกท่องเหมือนคัมภีร์ในตึกที่ไฟกำลังไหม้ ส่วน median tenure 18 เดือนก็ถูกแปะไว้บนอกเหมือนเหรียญตราที่ได้กลับมาจากการประจำการ
ในบริษัทคุณมี status deck อยู่ที่ไหนสักที่ที่ไม่มีใครอ่าน อัปเดตทุกสองสามอาทิตย์ เอาขึ้นโชว์ใน meeting แล้วก็ลืม หัวหน้าคุณก็รู้ดี เพราะเคยทำ deck แบบเดียวกันนี้ตอนไต่ขึ้นมา และเข้าใจดีว่าปกติแล้วงานพวกนี้ใส่ความคิดลงไปน้อยแค่ไหน คำอธิบายยอดฮิตของงานยุ่งเปล่าๆในองค์กรคือมีใครสักคนข้างบนสับสนหรือหลุดจากความจริง ฟังแล้วสบายใจ แต่ส่วนใหญ่ผิด สิ่งพวกนี้อยู่รอดมาได้เพราะมันทำงานบางอย่างอยู่ แค่ไม่ใช่งานที่มัน…
ผมวนอยู่ในวงการ tech มานานพอจะเห็นแพทเทิร์นที่หลายคนน่าจะเห็นเหมือนกัน บางทีมนิ่งมาก ส่งงานตรงเวลา ทำตามเป้า process สะอาดเป๊ะ แต่ไม่มีใครฆ่าไอเดียแย่ๆในห้องประชุมสักครั้ง ไม่มีใครพูดว่าอันนี้มันสร้างผิดทาง roadmap มีของอยู่ชิ้นนึง หรือหกชิ้น ที่สามคนแอบคุยกันลับๆว่ามันไปไม่รอด แต่มันก็ลอยผ่าน planning ไปเฉยๆ ไม่มีใครเอ่ยอะไร แถมยิ้มให้ด้วยซ้ำ คุณเห็น lead engineer พยักหน้าให้กับอะไรบางอย่าง...
ผมเห็นเรื่องแบบนี้บ่อยจนเริ่มสะอิดสะเอียนเวลาเห็นเด็กใหม่ทำซ้ำอีกราย manager สั่งให้ทำอะไรที่น่ารำคาญ แล้ว engineer สักคน ส่วนใหญ่เป็น junior ก็ออกอาการต่อต้าน บ่นบ้าง แซวบ้าง ยิง slack สักข้อความ เขาด่าความเหลวไหลออกมาตรงๆ แล้วทุกคนที่เห็นก็รู้ทันทีว่าเจ้านายคนนั้นเป็นยังไงในสายตาเขา แต่สุดท้ายเขาไม่ได้กลายเป็นฮีโร่หรือกบฏอย่างที่คิด สิ่งที่ได้กลับมาคือความเงียบ ความเงียบเย็นชาที่จงใจและระมัดระวัง
Oracle คือแมลงสาบของวงการ enterprise tech ทุกคนเกลียดแต่ทุกคนก็ใช้ คนที่ดูแลมันก็เลิกแกล้งทำเป็นว่ามันเท่ตั้งแต่สมัยรัฐบาล Clinton ตัวสินค้าจริงๆคือการขาย ส่วน database เป็นแค่ตัวประกัน
บริษัทจะทำลายเครื่องมือดีๆเกือบทุกอย่างได้ แค่เอา metric ผิดตัวไปแปะกับมัน ในที่ทำงานสิ่งที่สำคัญจริงๆมีอย่างเดียวคือ incentive จะเป็นเงิน สถานะ หรือการเลื่อนตำแหน่งก็ตาม คนทำงานก็ทำตาม incentive ผมกับคุณก็เหมือนกัน แทบทุกคนทำอะไรเพราะมันได้ประโยชน์กับตัวเองหรือคนที่รัก สุดท้ายในที่ทำงานเราเลยลงเอยด้วยการทำสิ่งที่ทำให้เราได้เลื่อนขั้น ได้เงินมากขึ้น ได้ความมั่นคงในงานมากขึ้น เราไม่ใช่เจ้าของบริษัท เราเป็นลูกจ้าง เราดูแลตัวเองก่อน แบบนั้นก็ไม่ผิดอะไร
stack ranking ลงเอยที่การเมืองในออฟฟิศทุกที เพราะมันเปลี่ยนนิยามของคำว่าเก่งในองค์กรไปเลย พอพนักงานถูกตัดสินโดยเทียบกันเองแทนที่จะเทียบกับมาตรฐานหรือเป้าที่นิ่งๆ เพื่อนร่วมงานที่หัวดีที่สุดของคุณก็เลิกเป็นคนที่คุณเรียนรู้และทำงานด้วยได้ กลายเป็นคู่แข่งแทน ความสำเร็จของเขาฉุดสถานะคุณให้ต่ำลงได้ การที่เขาเด่นกินที่โปรโมตของคุณได้ ความเก่งของเขากลายเป็นภัยต่อความมั่นคงของตัวคุณเอง