วิศวกรรมแบบไร้อีโก้
(egoless.engineering)วิศวกรรมที่ตัดอีโก้ออก: บทเรียนและข้อค้นพบ
บทนำ
- ในอุตสาหกรรมเทคโนโลยี อีโก้และลัทธิแบ่งพวกพ้องในองค์กรเป็นปัจจัยหลักที่ขัดขวางการทำงานเป็นทีม
- แบ่งปันข้อค้นพบที่ได้จากการคิดหาวิธีทำให้ทีมวิศวกรรมมีประสิทธิภาพและทำงานร่วมกันได้ดีขึ้น
ภาวะกลืนไม่เข้าคายไม่ออกของการกระจายความรับผิดชอบ
- แม้จะมีพนักงานเพียงสองคน การแบ่งงานก็เป็นสิ่งจำเป็น
- แต่วิธีการแบ่งสามารถส่งผลได้ทั้งในทันทีและระยะยาว
- หลายบริษัทไม่ได้ใคร่ครวญปัญหานี้อย่างลึกซึ้ง
ความเป็นจริงของวิทยาการคอมพิวเตอร์
- นักวิทยาการคอมพิวเตอร์จำนวนมากมารู้ภายหลังว่าตนได้ก้าวเข้าสู่ศาสตร์ที่เกี่ยวข้องกับงานนามธรรมเชิงคณิตศาสตร์
- ความตกใจในช่วงแรกนี้ทำให้หลายคนตลอดอาชีพไม่ค่อยอยากนำสิ่งที่เรียนไปประยุกต์ใช้กับเรื่องนอกเหนือจากคอมพิวเตอร์
- หากให้ความสำคัญกับสภาพแวดล้อมการทำงานอย่างลึกซึ้งพอๆ กับแนวทางทางเทคนิค ก็มีโอกาสจะปรับปรุงได้
โรคเรื้อรังขององค์กรและประสบการณ์ที่ได้พบ
- แม้แต่บริษัทที่ประสบความสำเร็จก็ยากจะหลีกเลี่ยงปัญหาเชิงโครงสร้างขององค์กร และเราสามารถเรียนรู้จากสิ่งเหล่านี้ได้
- กรณีของสตาร์ทอัพแห่งหนึ่งในช่วงต้นอาชีพ:
- ทั้งที่บริษัทยังอยู่ในระยะแรกและขนาดเล็ก แต่กลับใช้โครงสร้างที่เป็นระบบราชการมากเกินไปตั้งแต่ต้น
- เพิ่ม "Python middleware" จากทฤษฎีที่ผิดว่ามันจะทำให้คำขอเว็บเร็วขึ้น
- สุดท้ายกลับเพิ่ม network hop มากขึ้นและทำให้ประสิทธิภาพแย่ลง
- การปล่อยฟีเจอร์หนึ่งฟีเจอร์ต้องอาศัยความร่วมมือที่ซับซ้อนระหว่างหลายบทบาท
- ฝั่งฐานข้อมูลเขียน DDL และพัฒนา stored procedure
- นักพัฒนา Python ทำงานกับ middleware ที่ไม่มีประสิทธิภาพ
- นักพัฒนา PHP เขียนโค้ดฝั่งฟรอนต์เอนด์
- ด้วยโครงสร้างแบ่งงานแบบนี้ ทำให้ตลอดสองปีไม่สามารถปล่อยฟีเจอร์ใหม่ได้เลย
- ผลลัพธ์
- พนักงานทั้งหมดถูกเลิกจ้างอันเป็นผลจากโครงสร้างและเวิร์กโฟลว์ที่ไร้ประสิทธิภาพ
- ยกเว้นฉัน ฉันรอดเพราะชอบร้องเรียน
ปัญหาการแยกบทบาทในบริษัทขนาดใหญ่
- ฉากหลัง: ทำงานในบริษัทผลิตภัณฑ์ B2B ที่มีพนักงานมากกว่า 1,000 คน
- ในช่วงแรกใช้โครงสร้างทีมฟังก์ชันเฉพาะอย่าง Feature Teams และทีมบริการส่วนกลางร่วมกัน เช่น ฝ่ายปฏิบัติการ, DBA เป็นต้น
- ตอนแรกมันดูเป็นโครงสร้างที่พบได้ทั่วไป
- เมื่อเวลาผ่านไป บทบาทถูกแยกย่อยมากเกินไปและความไร้ประสิทธิภาพก็เพิ่มขึ้น
- มีการเพิ่มบทบาทใหม่ชื่อ "Release Manager" เพื่อดูแลการปล่อยรีลีส
- เหตุผลของการเพิ่มบทบาทไม่ชัดเจน และโครงสร้างองค์กรก็ซับซ้อนขึ้นเรื่อยๆ
- ตัวอย่างปัญหา:
- วิศวกรฟรอนต์เอนด์ถูกจำกัดให้ทำแต่งานฟรอนต์เอนด์ ส่วนวิศวกรแบ็กเอนด์ก็ทำได้เฉพาะงานแบ็กเอนด์
- การแยกแบบนี้ยังพออยู่ได้ แต่การกำหนดให้งานด้านความปลอดภัยทั้งหมดเป็นหน้าที่ของทีมความปลอดภัยกลับก่อปัญหาร้ายแรง
- ผลลัพธ์: เมื่อทำให้บทบาทกลายเป็นสิ่งเดียวกับงาน ก็ทำลายประสิทธิภาพขององค์กร
- เกิดการทำงานซ้ำซ้อนและการร่วมมือระหว่างทีมน้อยลง
พอร์ตโฟลิโอผลิตภัณฑ์ที่กระจัดกระจายและการขาดโครงสร้างกำกับดูแล
- ทำงานในบริษัทที่พัฒนา native client application เป็นหลัก
- ในช่วงแรกมีแอปไคลเอนต์หลักที่ประสบความสำเร็จ แต่พอเข้าสู่ทศวรรษ 2020 กลับมีโครงการที่กระจัดกระจายและไม่สอดคล้องกันจำนวนมากดำเนินไปพร้อมกัน
- ปัญหาในการบริหารพอร์ตโฟลิโอผลิตภัณฑ์
- โครงสร้างกำกับดูแลภาพรวมของผลิตภัณฑ์ทั้งหมดอ่อนแอ
- ไม่มีการประสานกันระหว่างผลิตภัณฑ์เลย ทั้งในด้านเทคโนโลยีสแต็กและการตัดสินใจ
- แต่ละทีมผลิตภัณฑ์รายงานตรงต่อ CEO อย่างอิสระ และ CEO ก็ไม่พยายามประสานงาน
- ความพยายามในการสร้างฟังก์ชันปฏิบัติการส่วนกลางร่วมกัน
- เกิดความยากลำบากเพราะกลุ่มปฏิบัติการไม่ได้มีส่วนร่วมในกระบวนการตัดสินใจด้านสถาปัตยกรรม
- ทีมปฏิบัติการยุ่งกับการดูแลบริการหลายร้อยตัวที่ทีมพัฒนาเคยใช้งานในอดีต จนไม่มีเวลาพอจะเข้าร่วมการตัดสินใจสำคัญ
- นี่ถือเป็นตัวอย่างคลาสสิกของความไร้ประสิทธิภาพเชิงองค์กร
[การสรุปรูปแบบปัญหาขององค์กร]
รูปแบบที่ 1: สับสนระหว่างบทบาทกับงาน
- มีแนวโน้มจะสร้างคำบรรยายตำแหน่งใหม่สำหรับงานใหม่เสมอ
- ตัวอย่าง: ทั้งที่วิศวกรเดิมก็ทำงานเกี่ยวกับ AI ได้ แต่กลับตั้งบทบาทใหม่ว่า AI engineer
- สิ่งนี้ก่อให้เกิดความขัดแย้งในองค์กร และอาจบั่นทอนแรงจูงใจของสมาชิกเดิมในทีม
- การแยกบทบาทมากเกินไปเช่นนี้นำไปสู่ระบบราชการที่ไม่จำเป็น
รูปแบบที่ 2: การกระจายตัวที่ไม่สมบูรณ์ของการปฏิวัติ DevOps
- หลายบริษัทอ้างว่า "เราใช้ DevOps แล้ว" แต่ในความเป็นจริง การแบ่งงานและความขัดแย้งยังคงอยู่
- เส้นแบ่งที่ชัดเจนระหว่างทีมปฏิบัติการกับทีมพัฒนา หรือระหว่าง SRE กับทีมพัฒนา ขัดขวางการร่วมมือ
- เป้าหมายดั้งเดิมของ DevOps คือการทลายเส้นแบ่งผ่านความร่วมมือและความเข้าอกเข้าใจ แต่ในโลกจริงแทบไม่ค่อยเกิดขึ้น
รูปแบบที่ 3: ข้อจำกัดของการแบ่งงานอย่างเคร่งครัด
- การแยกงานให้ย่อยลงและเชี่ยวชาญเฉพาะด้านอาจดูเป็นเรื่องธรรมดาสำหรับผู้นำ
- ตัวอย่าง: งาน AI ให้ผู้เชี่ยวชาญ AI ทำ งานปฏิบัติการให้ฝ่ายปฏิบัติการรับผิดชอบทั้งหมด
- แต่โครงสร้างแบบนี้ทำให้เกิดคอขวด
- วิศวกรที่เพิ่มเข้ามาพยายามสร้างงานใหม่เพื่อเร่งความเร็ว แต่สุดท้ายเวลารอการวิเคราะห์กลับเพิ่มขึ้นแบบไม่เป็นเชิงเส้น
- เมื่อ data scientist หรือทรัพยากรด้านการวิเคราะห์ถึงขีดจำกัด กระบวนการทั้งหมดก็ช้าลง
รูปแบบที่ 4: โครงสร้างองค์กรที่ผิดก่อให้เกิดงานเพิ่ม
- หากเส้นแบ่งขององค์กรไม่ชัดเจนหรือตั้งผิด งานที่ไม่จำเป็นจะเพิ่มขึ้น
- ตัวอย่าง: ทีมความปลอดภัยรับผิดชอบปัญหาความปลอดภัยทั้งหมดจนเกิดคิว ticket ด้านความปลอดภัย
- ทีมพัฒนาทำงานต่อไปโดยไม่คำนึงถึงความปลอดภัย ส่งผลให้ภาระงานด้านความปลอดภัยยิ่งมากขึ้น
- ในระยะสั้นอาจถูกมองข้ามได้ แต่ระยะยาวจะกลายเป็นปัญหาร้ายแรง
รูปแบบที่ 5: อคติเรื้อรังของมนุษย์
- ผู้คนมักประเมินค่าบทบาทของตัวเองสูงเกินไปและประเมินค่าบทบาทของผู้อื่นต่ำเกินไป
- บางคนตัดสินผิดว่า งานฝั่งเซิร์ฟเวอร์ "ไม่ใช่งานเทคนิค"
- ในทางกลับกัน ก็มีคนจำนวนมากที่มองว่างานผลิตภัณฑ์มีความเป็นเทคนิคน้อยกว่า
- ทัศนคติเช่นนี้บั่นทอนความไว้วางใจระหว่างทีมและขัดขวางการร่วมมือ
- "คนเก่งแบบเผด็จการ" ไม่ได้สร้างคุณค่าที่แท้จริงจากมุมมองเชิงระบบ
- ผู้นำและองค์กรมักประเมินท่าทีเช่นนี้ผิดว่าเป็นสิ่ง "ฉลาด" หรือ "มีคุณค่า"
[ลัทธิแบ่งพวกพ้องกับอีโก้]
- ลัทธิแบ่งพวกพ้อง (Parochialism) และอีโก้ (Ego) เป็นสาเหตุสำคัญของความไร้ประสิทธิภาพในองค์กร
- ลัทธิแบ่งพวกพ้อง: ท่าทีที่ไม่อยากล้ำเข้าไปในพื้นที่ของผู้อื่น หรือขาดความอยากรู้อยากเห็น
- อีโก้: ความภาคภูมิใจในงานอาจส่งผลดีได้ แต่ก็อาจแสดงออกในทางลบ เช่น การหวงเขตงานหรือลดทอนความสามารถของผู้อื่น
- พฤติกรรมที่เป็นสัญชาตญาณเหล่านี้ทำให้เกิดการขาดความเข้าอกเข้าใจและขัดขวางการร่วมมือ
ตัวอย่างที่ดีกว่า: ประสบการณ์จากทีมวิศวกรรมที่ประสบความสำเร็จ
- ที่สตาร์ทอัพแห่งหนึ่งในอดีต มีการลดความซับซ้อนของโครงสร้าง "อาณาจักรย่อย (fiefdom)" ที่แบ่งแยกในแนวนอน และจัดทีมใหม่ให้เล็กลง
- ผู้นำที่เอา DevOps มาใช้อย่างจริงจังได้ทลายกำแพงและส่งเสริมความร่วมมือ
- ผ่าน "การทำลายอย่างสร้างสรรค์" ราว 2 ปี สมาชิกทุกคนในทีมได้มีส่วนร่วมกับงานหลากหลายประเภท
- ผลลัพธ์คือความเสถียรของ infrastructure และความสามารถในการปล่อยซอฟต์แวร์กลับคืนมา
- หลังการปรับโครงสร้างองค์กร ทีมวิศวกรรมมีทั้งเวลาและอิสระมากขึ้น
- จากนั้นจึงเริ่มคุยกันว่าจะใช้ศักยภาพส่วนเกินของทีมอย่างไร
ข้อเสนอ 1: รีแฟกเตอร์ครั้งใหญ่ (Proposition 1: Boil the Ocean)
- บ่อยครั้งทีมจะใช้ทรัพยากรที่เหลือไปกับการรีแฟกเตอร์ส่วนที่ตนไม่ชอบแบบยกเครื่องทั้งหมด
- แต่นี่เป็นวิธีที่เคยลองมาแล้วและไม่ค่อยได้รับความนิยม
ข้อเสนอ 2: กิจกรรม "โชว์ตัว" (Proposition 2: Dress Like Big Dorks)
- ใช้เวลาว่างของทีมไปทำของที่ระลึกหรือกิจกรรมที่เน้นวัฒนธรรมทีม
- แต่นี่ไม่เหมาะจะเป็นกลยุทธ์หลัก
- เหตุการณ์ชี้ขาด: build error ของดีไซเนอร์
- คืนหนึ่งดีไซเนอร์ทำ build พัง และทีมต้องกู้คืนมัน
- ตอนแรกมีความเห็นว่าควรแบ่งบทบาทระหว่างดีไซเนอร์กับโค้ดเดอร์ให้ชัดเจนยิ่งขึ้น
- แต่มีคนหนึ่งในทีมตัดสินใจอย่างกล้าหาญด้วยการให้ deployment key กับดีไซเนอร์โดยตรง
- ผลลัพธ์:
- ดีไซเนอร์เข้ามามีส่วนร่วมกับงานโค้ดมากขึ้น และระดับความร่วมมือก็ดีขึ้น
- ทีมสร้าง monitoring, test suite และสิ่งอื่นๆ เพื่อทำให้สภาพแวดล้อมการทำงานปลอดภัยขึ้น
- ประสิทธิภาพการทำงานและผลิตภาพดีขึ้นอย่างมาก
ข้อเสนอ 3: เสริมพลังให้ทุกทีมอื่น (Proposition 3: Empower Everybody Else)
- เลือกใช้กลยุทธ์นำทรัพยากรส่วนเกินของทีมไปสนับสนุนและเสริมศักยภาพให้ทีมอื่น
- ใช้ได้ทั้งกับทีมเทคนิคและไม่ใช่เทคนิค
- ส่งเสริมความร่วมมือทั่วทั้งองค์กรและนำไปสู่การลงมือทำที่มีประสิทธิผล
ความตั้งใจที่จะลงมือทำ
- หลังจากกรณีของดีไซเนอร์ ก็ได้ร่วมงานกับหลายกลุ่มและพบความสำเร็จในลักษณะคล้ายกัน
- ใช้เวลาว่างและอำนาจเชิงองค์กรของทีมเพื่อช่วยให้แต่ละทีมร่วมมือกันได้อย่างมีประสิทธิภาพ
- ความสำเร็จของการลงมือทำตั้งอยู่บนพื้นฐานของความร่วมมือและความเข้าอกเข้าใจทั่วทั้งบริษัท
[ความรู้สึกของการลงมือทำที่ประสบความสำเร็จ]
- ผู้เชี่ยวชาญ vs. เจ้าของงาน
- ทีมมีผู้เชี่ยวชาญประจำโดเมน แต่ไม่มี "เจ้าของ" ของงานหรือโดเมนใดโดเมนหนึ่งโดยเฉพาะ
- กรณีความปลอดภัย: แทนที่ทีมความปลอดภัยจะจัดการทุกปัญหาด้วยตัวเอง ทั้งทีมกลับรับผิดชอบเรื่องความปลอดภัยร่วมกัน และทีมความปลอดภัยมีบทบาทในการยกระดับความสามารถของสมาชิกทีม
- โมเดลนี้ควรถูกนำไปใช้ในด้านอื่นด้วย แต่ทีมส่วนใหญ่ทำไม่สำเร็จ
- กรณีล้มเหลว
- แยกวิศวกรฟรอนต์เอนด์และแบ็กเอนด์ออกจากกันอย่างเด็ดขาด
- การขาดความร่วมมือก่อให้เกิดความซับซ้อนที่ไม่จำเป็น เช่น GraphQL
- แม้จะต้องการผู้เชี่ยวชาญเฉพาะบทบาท แต่การแบ่งตำแหน่งเป็น "ฟรอนต์เอนด์" และ "แบ็กเอนด์" นั้นไม่มีประสิทธิภาพ
- หลักการสำคัญ:
- "เป็นผู้เชี่ยวชาญประจำโดเมน ไม่ใช่เจ้าของงาน"
- ส่งเสริมให้ผู้เชี่ยวชาญมีเวลาไปช่วยสมาชิกคนอื่นนอกเหนือจากงานของตนเอง
การส่งเสริมความร่วมมือเชิงรุก
- ให้เวลาว่าง
- มอบเวลาว่างให้สมาชิกทีมเพื่อรักษาการทำงานเป็นทีมในภาพรวม
- ไม่ใช่แค่รอให้ความร่วมมือเกิดขึ้นเองตามธรรมชาติ แต่ตั้งใจเติมพลังให้ระบบ
- ความปลอดภัยทางจิตใจและการขยาย in-group
- ผู้คนมักรู้สึกปลอดภัยทางจิตใจเมื่ออยู่ในกลุ่มที่ตนสังกัด จึงกล้าทดลองหรือเรียนรู้สิ่งใหม่
- ลงทุนทั้งเวลาและทรัพยากรเพื่อขยาย "in-group" ของสมาชิกทีม
- bootcamp: ให้ไปทำงานกับทีมอื่นแบบบังคับเพื่อเปิดโอกาสในการร่วมมือ
- hackathon: ใช้เป็นกิจกรรมที่ให้ผลคล้ายกัน
คุณค่าของทีมที่ตั้งใจสร้าง
- วางปรัชญาและหลักการของทีม
- กำหนดเป้าหมายระดับสูงของกิจกรรมต่างๆ เช่น code review, bootcamp, hackathon ให้ชัดเจน
- ประกาศชัดว่าแนวคิดแบบชนชั้นนำเป็นพิษ
- สร้างวัฒนธรรมที่ทุกคน "ลงมือทำสิ่งที่จำเป็นด้วยตัวเอง"
- ความไว้วางใจซึ่งกันและกันและความคาดหวังในการปรับปรุง
- ตั้งความคาดหวังอย่างหนักแน่นว่า เมื่อแตะต้องผลงานของคนอื่นจะต้องปล่อยให้มันดีขึ้นกว่าเดิมเสมอ
- วัฒนธรรมแบบนี้ทำให้สมาชิกทีมเต็มใจร่วมมือกัน
ข้อคิดส่งท้าย
- ปัญหาในอุตสาหกรรมเทคโนโลยี: แนวคิดแบบชนชั้นนำและผู้นำแบบเผด็จการ
- ผู้นำแบบเผด็จการที่ขาดความอ่อนน้อมถ่อมตนขัดขวางความร่วมมือของทีมและส่งเสริมความโหดร้ายที่ไม่จำเป็น
- อุตสาหกรรมเทคโนโลยีมักเข้าใจผิดว่าผู้นำแบบนี้มีประโยชน์ ทั้งที่จริงเป็นปรากฏการณ์แบบ寄生และเป็นอันตราย
- การปฏิบัติต่อผู้อื่นอย่างให้เกียรติไม่ควรเป็นเรื่องหัวรุนแรง แต่ในความเป็นจริงกลับไม่เป็นเช่นนั้น
- ความร่วมมือนำไปสู่ผลลัพธ์ที่ดีกว่า
- ความร่วมมือทำให้ผลลัพธ์ดีขึ้น และชีวิตที่ไม่มีผู้นำแบบเผด็จการก็ดีกว่า
- จำเป็นต้องพยายามกำจัดลัทธิแบ่งพวกพ้องและอีโก้
- ความสำคัญของการให้อำนาจ
- หากต้องการสนับสนุนให้สมาชิกทีมมีความอยากรู้อยากเห็นและร่วมมือกัน ก็ต้องได้รับอนุญาตและการสนับสนุนจากผู้นำ
- ตัวอย่าง: เปลี่ยนจากให้ SRE ทำ deployment มาเป็นให้นักพัฒนาทำเองโดยตรง
- ตอนแรกมีความกังวลเรื่องความผิดพลาดของนักพัฒนา แต่สุดท้ายนักพัฒนาส่วนใหญ่ก็แก้ปัญหาได้ด้วยตนเองและประสบความสำเร็จ
- วิศวกรผลิตภัณฑ์แสดงให้เห็นท่าทีที่อยากจัดการปัญหาด้วยตัวเอง
- ให้ระบบมี slack
- โปรแกรมอย่าง bootcamp หรือ hackathon ต้องการความมุ่งมั่นอย่างต่อเนื่อง
- หากระบบไม่มี slack โปรแกรมเหล่านี้ก็หายไปได้ง่าย
- เราไม่เคยใช้งานคอมพิวเตอร์ที่ 100% ตลอดเวลา แต่กลับมีแนวโน้มจะปฏิบัติกับตัวเองแบบนั้น
- ความสำคัญของคุณค่าและรางวัลตอบแทน
- ผู้นำต้องให้รางวัลกับความร่วมมือและความอยากรู้อยากเห็น และทำให้สิ่งเหล่านี้ฝังรากเป็นวัฒนธรรมทีม
- CEO มักพยายามยกเลิกโปรแกรมเชิงบวกอย่าง bootcamp หรือ hackathon แต่กลับไม่ค่อยพยายามยกเลิกโปรแกรมเชิงลบอย่าง code review แบบบังคับ
- ต้องละทิ้งความเชื่อที่ผิดว่า "ความเจ็บปวด" จะนำมาซึ่งผลลัพธ์
- ความเจ็บปวดไม่ใช่ตัวชี้วัดแทนผลลัพธ์ที่ดี ขณะที่ความร่วมมือและความไว้วางใจต่างหากที่นำไปสู่ผลงานที่ดีกว่า
7 ความคิดเห็น
> หากต้องการกระตุ้นให้สมาชิกในทีมร่วมมือกันด้วยความอยากรู้อยากเห็น จำเป็นต้องได้รับการอนุญาตและการสนับสนุนจากผู้นำ
ดูเหมือนว่าการส่งเสริมให้สนใจงานของเพื่อนร่วมทีม แม้จะไม่ใช่ขอบเขตงานของตัวเอง ก็เป็นเรื่องสำคัญมาก!
ในความเป็นจริงคือ...!
ดูเป็นโครงสร้างที่เป็นไปไม่ได้เลยสำหรับสตาร์ทอัพสาย "เวจา-il" ที่คอยเร่งรัดความคืบหน้าทุกวัน.. ทุกคนที่ทำงานหน้างานควรจะรักษาความสนใจที่มีในช่วงแรกที่เข้ามาทำงานไว้ได้อย่างต่อเนื่อง แต่โดยทั่วไปแล้วมักไม่มีการสนับสนุนในแง่มุมนั้น หรือมีก็น้อยมากครับ
พูดได้ถูกทุกคำจริง ๆ..
แต่ความเป็นจริงคือ..................ฮือ ๆ
ดูเหมือนจะเป็นบทความที่ดีมากจริง ๆ!
เป็นบทความที่ดีครับ
ความเห็นจาก Hacker News
มีความเห็นว่าการตัดอัตตาของโปรแกรมเมอร์ออกจากการพัฒนาซอฟต์แวร์เป็นสิ่งสำคัญ และควรมองผลิตภัณฑ์ซอฟต์แวร์ว่าเป็นผลงานของทีมผ่านการทำงานร่วมกัน
จากบทเรียนที่ได้รับในเส้นทางอาชีพด้านการพัฒนา มีคำแนะนำว่าไม่ควรเพิ่มกระบวนการที่ไม่จำเป็น ควรกำหนดให้ทุกบทบาทมีความเป็นเจ้าของผลิตภัณฑ์ หลีกเลี่ยงการตัดสินใจแบบตอบสนองตามสถานการณ์ และส่งเสริมความร่วมมือระหว่างทีม
ทีมที่ดีที่สุดประกอบด้วยทีมพิซซ่าที่ดูแลทั้งสแตกทั้งหมด และผู้เชี่ยวชาญที่คอยให้คำแนะนำเมื่อจำเป็น
แม้อุปมาเรื่องกีฬาอาจไม่ค่อยได้รับความนิยมในแวดวงเทคโนโลยี แต่มีความเห็นว่าพลวัตของทีมกีฬาคล้ายกับทีมธุรกิจที่ดี
ความสำเร็จขององค์กรขึ้นอยู่กับการที่สมาชิกแต่ละคนลงมืออย่างไม่เห็นแก่ตัวเพื่อเติมเต็มความต้องการของกลุ่ม
มีการเน้นย้ำถึงความสำคัญของการกำหนดคุณค่าของทีมอย่างตั้งใจ
ระหว่างทำงานในฝ่าย Growth ตอนแรกผู้จัดการเป็นคนตรวจและรวมทุกคอมมิต แต่ต่อมาจึงตระหนักว่าตนเองมีสิทธิ์นำขึ้นโปรดักชันได้โดยตรง
ผู้เชี่ยวชาญด้านโดเมนเป็นที่ต้องการมากกว่าเจ้าของโดเมน และการทำให้การแบ่งความเชี่ยวชาญชัดเจนเกินไปอาจก่อปัญหาได้