PlanetScale CEO เกี่ยวกับ Cloud-Prem และการปีนบันไดวิศวกรรม

Sam Lambert เป็น CEO ของ แพลนเน็ตสเกลผู้ให้บริการฐานข้อมูลแบบไร้เซิร์ฟเวอร์ที่เข้ากันได้กับ MySQL ก่อนที่จะร่วมงานกับ PlanetScale (จากนั้นในตำแหน่ง Chief Product Officer) เขาเป็นรองประธานฝ่ายวิศวกรรมที่ GitHub

ในการสัมภาษณ์ครั้งนี้ Lambert กล่าวถึงหัวข้อต่างๆ ที่เกี่ยวข้องกับรูปแบบการนำส่งซอฟต์แวร์บนระบบคลาวด์ รวมถึงลักษณะของเซิร์ฟเวอร์ที่ไม่มีเซิร์ฟเวอร์ที่ดี ใครควรใช้งาน Kubernetes และการเกิดขึ้นของ "cloud-prem" ซึ่งเป็นรูปแบบการใช้งานที่รวมจุดแข็งของ -prem ซอฟต์แวร์และข้อเสนอ SaaS เขายังแบ่งปันประสบการณ์ของเขาในการเป็นซีอีโอที่ไม่ใช่ผู้ก่อตั้ง และคำแนะนำของเขาเกี่ยวกับเวลาและวิธีที่จะเปลี่ยนจากวิศวกรรมไปสู่การจัดการ

---

อนาคต: คุณได้อธิบายสิ่งที่ PlanetScale กำลังทำ — อย่างน้อยก็ไม่ใช่ข้อเสนอ SaaS ล้วนๆ — การประมวลผลแบบ “cloud-prem” คุณนิยามคำนั้นอย่างไร?

แซม แลมเบิร์ต: คลาวด์พรีม เป็นโมเดลใหม่ — โดยพื้นฐานแล้ว โซลูชันคลาวด์เนทีฟสำหรับภายในองค์กร ตามเนื้อผ้า บริษัทต้องมี ภายในองค์กร สารละลายหรือ a เมฆ การแก้ปัญหาและการคร่อมทั้งสองนั้นเป็นเรื่องยากมาก ที่ GitHub เรามีความตึงเครียดในการรัน github.com และขาย GitHub Enterprise เป็นโซลูชันภายในองค์กรด้วย ด้วยผลิตภัณฑ์คลาวด์ เราต้องสามารถผลักดันและส่งมอบได้อย่างต่อเนื่อง การตัดรุ่นโดยอิงจากสิ่งนั้นเป็นงานที่ยากมาก และการสร้างสถาปัตยกรรมสำหรับทั้งคู่หมายความว่าเราไม่ได้นำเสนอโซลูชันภายในองค์กรเช่นเดียวกับที่เราสามารถทำได้ มันยากมากที่จะทำ 

เมื่อเรามาที่ PlanetScale เราตัดสินใจว่าเราต้องการใช้ระบบคลาวด์เท่านั้น แต่แน่นอนว่า คุณไม่สามารถทำได้ด้วยผลิตภัณฑ์ฐานข้อมูลหรือผลิตภัณฑ์ที่มีข้อกำหนดการปฏิบัติตามกฎระเบียบที่เข้มงวด ดังนั้น ด้วย cloud-prem เราจึงปรับใช้ data plane ของผลิตภัณฑ์ของเราเป็นหลักใน a วี.พี.ซี จัดการโดยผู้ใช้ ซึ่งพวกเขาใช้ระนาบการควบคุมของเราเพื่อควบคุมมันและเราจัดการมัน เป็นหลัก รู้สึกเหมือนคุณกำลังใช้ผลิตภัณฑ์ SaaS บนคลาวด์ปกติ แต่ข้อมูลอยู่ในบัญชีของคุณ. ทีมรักษาความปลอดภัยของคุณสามารถตรวจสอบได้ และพวกเขารู้สึกถึงความปลอดภัยและความไว้วางใจที่มีให้อยู่ภายในขอบเขตของโครงสร้างพื้นฐาน โดยไม่ต้องมีข้อเสียของการแพตช์ เผยแพร่ และจัดการซอฟต์แวร์ภายในองค์กรเอง

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

คุณได้รับการตอบกลับแบบใด มี SaaS ที่มิจฉาทิฐิและร้านค้าในองค์กรอยู่ที่นั่น ...

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

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

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

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

นักพัฒนาสามารถให้ความเห็นเกี่ยวกับฐานข้อมูลที่พวกเขาใช้ได้เป็นอย่างดี โมเดลการปรับใช้ cloud-prem พูดถึงประสบการณ์ของนักพัฒนาอย่างไร

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

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

Kubernetes มีบทบาทอย่างไรในโมเดลการปรับใช้ของคุณ และคุณคิดว่า Kubernetes ควรมีบทบาทอย่างไรโดยรวมสำหรับการปรับใช้คลาวด์พรีม

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

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

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

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

ในความคิดของคุณมีระดับของมาตราส่วนที่เริ่มสมเหตุสมผลหรือไม่? หรือกรณีการใช้งานเฉพาะ เช่น การเรียกใช้ทีมแพลตฟอร์มภายใน

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

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

แต่แน่นอนว่ามีจุดที่องค์กรมีรอยเท้าขนาดใหญ่พอที่จะพิสูจน์ให้เห็นถึงการทำงานบางอย่างเช่น Kubernetes ภายในใช่ไหม เช่นเดียวกับที่คุณทำที่ GitHub?

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

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

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

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

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

คุณเห็นว่าข้อกังวลด้านความปลอดภัยและความเป็นส่วนตัวของข้อมูลพัฒนาขึ้นอย่างไร โดยเฉพาะสำหรับผู้ให้บริการ SaaS

ทุกคนใส่ใจเรื่องความปลอดภัย เป็นสิ่งที่เราต้องให้ความสำคัญอย่างยิ่งในฐานะบริษัทที่โฮสต์ข้อมูลของผู้คน เทรนด์หนึ่งที่ฉันเห็นคือ บริษัทต่างๆ จะดำเนินการรับรองการปฏิบัติตามข้อกำหนดเร็วกว่าที่เคย ตอนนี้คุณต้องได้รับ ใบรับรอง SOC 2 แทบจะในทันที มิฉะนั้น คุณจะไม่สามารถเล่นได้ (ถ้าคุณต้องการอ่านดีๆ Fly.io เขียน a บล็อกโพสต์บน SOC 2 ที่ควรค่าแก่การพิจารณา)

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

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

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

สำหรับ [บริการผู้ให้บริการระบบคลาวด์] ทุกแห่ง — และใน Amazon มีหลายร้อยแห่ง — มีบริษัทสตาร์ทอัพอายุน้อยห้ารายที่แข่งขันกัน และจะเป็นการยากมากที่จะดูแลผู้ใช้จำนวนมากและกรณีการใช้งาน และรักษาขนาดไว้

คุณพูดถึง Serverless มาก่อน นิยามการทำงานแบบไร้เซิร์ฟเวอร์ของคุณคืออะไร?

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

Serverless กล่าวว่า "หน่วยมูลค่าของ .คืออะไร ผู้ใช้งาน? อะไร ผู้ใช้งาน อยากทำ?” และไม่ได้บังคับให้พวกเขาทำอะไรมากกว่านั้น ดังนั้น สำหรับฉัน การมองโลกในแง่ดีที่มุ่งไปสู่ความเรียบง่ายและการออกแบบผลิตภัณฑ์ที่ดีขึ้น 

คุณจะประเมินความสัมพันธ์ระหว่างบริษัทและผู้ให้บริการระบบคลาวด์ในตอนนี้อย่างไร “ frenemies” เป็นคำอธิบายที่ยุติธรรมหรือไม่?

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

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

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

ไม่เกี่ยวข้องกัน: คุณไม่ใช่ CEO ของ PlanetScale ตั้งแต่แรก การเปลี่ยนจาก CPO เป็น CEO ของคุณเกิดขึ้นได้อย่างไร?

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

ณ จุดนั้น บริษัทและวัฒนธรรมจำนวนมากคือคนที่มาร่วมงานกับฉัน—เพื่อทำงานร่วมกันอีกครั้ง — ดังนั้นการเปลี่ยนแปลงสองครั้งของวัฒนธรรมและผลิตภัณฑ์จึงเข้ามาผ่านสิ่งที่ฉันอยากทำ เหตุผลสุดท้ายคือการจัดวางทุกอย่างภายใต้วิสัยทัศน์นั้น นั่นเป็นเหตุผลที่ฉันกลายเป็นซีอีโอ

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

คุณยังก้าวขึ้นบันไดที่ GitHub อย่างรวดเร็ว จาก DBA เป็นรองประธานฝ่ายวิศวกรรม คุณมีคำแนะนำอย่างไรในการทำให้การเปลี่ยนแปลงประเภทนั้นประสบความสำเร็จ และยังตัดสินใจว่าการย้ายเข้าสู่ฝ่ายบริหารเป็นสิ่งที่ถูกต้องหรือไม่

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

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

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

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

และสิ่งที่ฉันภาคภูมิใจที่สุดคือจำนวนคนที่มาจาก GitHub ไปยัง PlanetScale เพราะพวกเขารู้เรื่องนี้ คุณรู้ว่าฉันหมายถึงอะไร? พวกเขาไม่ได้ มี ถึง. สำหรับฉัน นั่นคือสัญญาณว่าฉันได้แสดงให้เห็นแล้วว่าฉันสามารถทำในสิ่งที่ฉันบอกว่าฉันจะทำในฐานะผู้นำได้อย่างสม่ำเสมอ ผู้คนมาเพื่อสิ่งนั้น

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

หากคุณไม่สามารถจัดการกับความคิดที่ว่าความผิดพลาดของคุณจะยุ่งกับอาชีพการงานของผู้คน และคนเหล่านั้นต้องพึ่งพาคุณอย่างแท้จริง การจัดการนั้นไม่เหมาะกับคุณ 

หากคุณเป็น IC ที่ต้องการเปลี่ยนไปสู่การจัดการ ขั้นตอนแรกคืออะไร

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

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

ถ้าคุณคิดว่าคุณทำได้และต้องการช่วยให้คนอื่นเป็นตัวเองในเวอร์ชันที่ดีขึ้น ให้ลงมือ

เผยแพร่ 2 สิงหาคม 2022