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

• โครงสร้างพื้นฐาน : สะพานโกลเดนเกตใช้เวลาประมาณสี่ปีในการสร้าง (พ.ศ. 2476-2480) และมีค่าใช้จ่ายประมาณ 500 ล้านดอลลาร์ในปัจจุบัน ในทางตรงกันข้าม SDS ( Suicide Deterrent System ) ซึ่งโดยทั่วไปจะเพิ่มตาข่ายรอบสะพานจะใช้เวลาห้าปีจึงจะเสร็จสมบูรณ์ (2017–2023) และคาดว่าจะมีค่าใช้จ่ายประมาณ 217 ล้านเหรียญสหรัฐ หากคุณทบทวนโครงการโครงสร้างพื้นฐานที่สำคัญในแคลิฟอร์เนีย คุณจะพบว่าสำหรับโครงการที่สร้างเสร็จก่อนปี 1950 งานเสร็จเร็วกว่า ถูกกว่า และมีคุณภาพสูงกว่าที่ทำในปัจจุบันอย่างน้อย 5 เท่า แม้ว่าในปัจจุบันนี้ เรามีเงินทุนมากขึ้น เทคโนโลยีที่ดีขึ้น วัตถุดิบที่ดีขึ้น และจำนวนวิศวกรโยธาและสถาปนิกที่สูงขึ้น
• บริษัทเทคโนโลยี : Adobe แม้จะมีทรัพยากรทางการเงินและทรัพยากรมนุษย์ทั้งหมด แต่ก็พบว่าตัวเองต้องได้คู่แข่งในราคา 20 พันล้านดอลลาร์ ยังต้องดูว่า Adobe จ่ายเงินมากเกินไปสำหรับ Figma หรือไม่ แต่คำถามที่น่าสนใจกว่าคือเหตุใดบริษัทที่มีบุคลากร 100 เท่า ประสบการณ์เชิงลึกในการออกแบบเครื่องมือ 100 เท่า และเงินทุน 100 เท่าจึงล้มเหลว

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

ทำไมกระบวนการคืบคลานเกิดขึ้น?

ทุกกระบวนการเริ่มต้นด้วยความตั้งใจที่ดี

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

ถนนสู่ความสมบูรณ์แบบ

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

กาวมากเกินไป

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

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

ตอนที่ฉันอยู่ที่โนเวลล์ ฉันได้เรียนรู้ว่ามีคนที่ฉันเรียกว่า "คนกาว" พวกกาวเป็นคนดีอย่างไม่น่าเชื่อที่จะนั่งคั่นกลางระหว่างกลุ่มต่างๆ และช่วยเหลือในกิจกรรมต่างๆ และพวกเขาซื่อสัตย์มาก และผู้คนก็รักพวกเขา และคุณไม่ต้องการพวกเขาเลย

ที่โนเวลล์ ฉันพยายามกำจัดพวกกาวเหล่านี้ เพราะพวกเขาเข้ามาขวางทาง เพราะพวกเขาทำให้ทุกอย่างช้าลง และทุกครั้งที่ฉันกำจัดพวกเขาในกลุ่มหนึ่ง พวกเขาจะปรากฏตัวในอีกกลุ่มหนึ่ง และพวกเขาจะโอนย้าย และได้รับการว่าจ้างใหม่ และทั้งหมดนั้น

เอนโทรปี

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

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

• การลบรหัสที่ตายแล้วที่ไม่ได้ดำเนินการในการผลิต ฉันได้โต้ตอบกับ codebases จำนวนมากซึ่งมากกว่า 50% ของโค้ดนั้นเป็นโค้ดที่ตายแล้วและสร้างภาระทางความคิดให้กับเพื่อนร่วมงาน ฉันหวังว่าจะมีบางอย่างในพื้นที่การผลิตของ dev ที่สร้างความครอบคลุมของโค้ดตามบรรทัดที่ดำเนินการในการผลิต ทุกๆ ไตรมาส คุณจะหยุดและตรวจสอบรายงานเหล่านั้น และเพียงแค่ลบไฟล์ที่ไม่มีการดำเนินการ
• ในฐานะผู้จัดการผลิตภัณฑ์ เราไม่ได้ไตร่ตรองมากพอเกี่ยวกับคุณสมบัติที่เราควรยกเลิกหรือเปลี่ยนกลับ แต่การหยุดและไตร่ตรองถึงสิ่งที่ควรลบก็มีความหมายอย่างมากในการทำให้ผู้ใช้ง่ายขึ้นและปรับปรุงประสบการณ์ ฉันคิดว่าตัวเองเชี่ยวชาญด้านเทคโนโลยี แต่ฉันพบว่าผลิตภัณฑ์จำนวนมากที่สร้างขึ้นในปัจจุบันได้รับการปรับให้เหมาะสมมากเกินไปกับกลุ่มผู้ใช้ที่มีอยู่ ซึ่งนำไปสู่ประสบการณ์ UX ที่ยุ่งเหยิงและสับสนสำหรับผู้ใช้ใหม่ การถามเมื่อสิ้นสุดไตรมาส “ฟีเจอร์ใดที่เราสามารถยกเลิกการจัดส่งได้” จะมีประโยชน์ในการลดความยุ่งเหยิง

อัตตาคือศัตรู

Ryan Holiday แนะนำในหนังสือของเขาว่า Ego is the Enemy มี "สิ่งล่อใจที่มีอยู่จริงสำหรับทุกคน - สำหรับการพูดคุยและการโฆษณาเพื่อแทนที่การกระทำ" อัตตาเป็นเหตุผลสำคัญที่ทำให้ความก้าวหน้าและนวัตกรรมอาจดูจืดชืดในหลายๆ สถาบัน นี่คือวิธีที่อัตตาแสดงออก:

• การเห็นคนกลุ่มเดียวกันอยากจะนำเสนอความคิดของพวกเขาในการสนทนากลุ่ม แม้ว่าความคิดของพวกเขาไม่ได้เพิ่มคุณค่าส่วนเพิ่มเลยหรือน้อยมากก็ตาม
• การมีคนที่ไม่เคยมีส่วนร่วมในการสนับสนุนเพื่อนร่วมงานอย่างจริงจังหรือผู้ที่พยายามกักตุนการมองเห็น หากคุณเป็นผู้จัดการหรือผู้จัดการระดับผู้จัดการ คุณสามารถสังเกตสิ่งนี้ได้จากการดูว่าผู้ใต้บังคับบัญชาของคุณพูดถึงความสำเร็จหรือการมีส่วนร่วมของผู้อื่นใน 1:1 บ่อยเพียงใด การขาดการยอมรับหรือการสนับสนุนที่ไม่เห็นแก่ตัวของผู้อื่นสามารถเป็นสัญญาณของอัตตาที่ไม่ดี
• การเพิ่มประสิทธิภาพสำหรับทีมแทนที่จะเป็นบริษัทหรือองค์กรโดยรวม ฉันยืมไดอะแกรมมาจากStaff Engineer's Pathโดย Tanya Reilly และมันแสดงตัวอย่างปัญหานี้ได้อย่างสมบูรณ์แบบโดยที่ทีมปรับให้เหมาะสมที่สุดในท้องถิ่น ตัวอย่างเช่น คุณจะโอเคกับการยกเลิกทีมและกระจายพนักงานไปยังทีมอื่นหรือไม่ หากอยู่ในโดเมนของคุณ คุณเข้าสู่โหมดการบำรุงรักษา ผู้จัดการส่วนใหญ่จะไม่ทำอย่างนั้นเพราะมันหมายถึงการสูญเสียทุนทางสังคมและการเมืองภายในบริษัท

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

บทสรุป

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

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