หลายๆคนพูดถึง Spotify ในมุมที่ดีมากๆหลายๆมุมเช่น การที่เป็น product-driven company การที่มีหลายๆ framework ที่ใช้ได้จริงหรือการที่มี culture ที่ดี ซึ่งในฐานะที่นัทเองเคยอยู่ Spotify ทั้งในส่วนของ business และ product วันนี้อยากจะมาเล่าจากมุมมองจากภายในว่ามันเป็นอย่างไร — the good, the bad and the ugly
ปล. ถ้ายังไม่เคยอ่านเรื่อง Spotify engineering culture แนะนำให้ลอง search ดูนะคะ มีเยอะมากเลย และ article นี้เป็นความคิดเห็นส่วนตัวจากประสบการณ์ที่เคยอยู่ช่วงปี 2016–2018 หลายๆอย่างอาจจะเปลี่ยนไปแล้วหรือไม่ valid แล้วนะคะ
The good
Scrum vs Agile
ในแต่ละทีมที่ Spotify เราสามารถเลือกได้เลยว่าจะใช้ Agile methodology ไหน ซึ่งบาง squad ก็จะใช้ Kanban บาง squad จะใช้ Scrum แล้วแต่เห็นสมควรและแล้วแต่ว่าคนใน squad ตกลงกันยังไง ซึ่งเราเองมองว่าส่วนนี้ดีมากๆ และเป็นที่มาของการเรียก squad แทนคำว่า scrum team
แต่ละ squad ก็สามารถเลือกใช้ event ต่างๆได้โดยที่ไม่มีการบังคับให้ align กันเช่น backlog grooming อาจจะมีหรือไม่มีแล้วแต่ความต้องการ retrospective อาจจะเกิดขึ้นทุกๆ 2 sprints แทนทุกๆ sprint แต่ละ squad เลือกเองตามความเหมาะสมของจำนวนคนและความต้องการ
Autonomous squad owning mission and vision of its own product
แต่ละ squad มีความ autonomous มากๆ ตอนที่อยู่ Spotify นี่ไม่เคยต้อง validate product vision mission กับ senior manager หรือ CXOs เลย เราเป็นเหมือน mini-CEO จริงๆแต่สิ่งที่ต้องทำคือทำงานกับ squad แล้วทำให้ทุกๆคนใน squad เข้าใจว่าทำไมเราถึงสร้าง product นี้ มันจะไปช่วยอะไรกับ users ของเรา goal, mission ของเราคืออะไร และสร้างขึ้นร่วมกัน เข้าใจและ challenge กันและกัน คำว่า roadmap disruption ไม่เคยเกิดขึ้น ไม่มีใครมีอำนาจเหนือ product roadmap มากกว่า product manager ของ squad นั้น เวลาเกิดปัญหาหรือ bug, squad ก็จะทำงานร่วมกันเองเพื่อหา solution ที่ดีที่สุดโดยที่ไม่ต้องมีการ report หรือมี management เข้ามา
ซึ่งในความเป็นจริงก็อาจจะมีบาง tribe ที่ไม่ได้เข้าใจสิ่งๆนี้ 100% แต่ Spotify เป็นบริษัทที่ทุกคนมีเสียงเท่ากัน การเชิญออกเพราะไม่ได้เข้าใจ culture เกิดขึ้นได้ทั้ง top-down and bottom-up จึงทำให้ Spotify มีหลายๆ initiative ที่เปิดโอกาสให้ทุกคนมี safe space ที่จะ speak up
Loosely coupled but tightly aligned
ในส่วนนี้หลายๆคนที่ทำงานด้วยบางคนคง consider เป็น the ugly มากกว่า แต่ในมุมมองเราเองยังเป็น the good เนื่องจากตอนนั้นโชคดีที่ไม่ได้ทำงานที่ต้องพึ่ง squad อื่นมากเท่าไหร่ จึงไม่ได้มีปัญหาในมุมนี้ สำหรับบาง squad ที่จะต้องทำงาน cross Tribe หรือ Mission เนี่ยอาจจะไม่ชอบ setup แบบนี้เลยเพราะมัน loosely coupled มากเกินและทำให้ไม่สามารถทำงานอย่างราบรื่นได้ แทบจะต้องนั่งรอกันตลอดเวลา
Frequent and decoupled releases
ส่วนนี้น่าจะเป็นมุมของ engineering มากๆ การสร้าง infrastructure ให้สามารถ release เล็กๆแต่บ่อยๆและการ decoupled ระบบหรือ product แต่ละ product ออกมาทำให้ทุก squad สามารถ take ownership ของ product ตัวเองได้ 100%
ซึ่งพอเป็นแบบนี้แล้วจึงทำให้หลายๆ squad ไม่ต้อง communicate มากเท่าที่ควร (อาจจะมองเป็นผลเสียได้) เพราะเรามั่นใจว่าการ release ของเราไม่ทำให้อีก squad เดือนร้อน การทำ end to end testing ใน product ของตัวเองจึงเป็นสิ่งที่ทุก squad ทำและไม่ได้ต้องการ QA role
แต่ปัญหาเกิดขึ้นเมื่อเราต้องการทำ project ใหญ่ๆ อย่างเช่นตอนยังอยู่ที่นั่นคือเราต้อง align กันเพื่อจะ release NFT — New Free Tier งานนั้นวุ่นวายมากเนื่องจากทุกคนไม่ชินกับการทำ bet ใหญ่ๆ เลยคิดว่าน่าจะเป็น the ugly ได้จากในมุมมองของ collaboration
Trust > control, Trust at scale
ที่ Spotify มีสิ่งๆนึงที่เราเองไม่เคยเจอที่อื่นเลยคือการที่ทีม หัวหน้า และองค์กร trust เราที่จะทำงาน แทนที่จะพยายาม control ให้เราอยู่ในกรอบ สิ่งนี้เป็นหนึ่งในสิ่งที่ปลดล๊อคไอเดียใหม่ๆ การสร้าง innovation และการคิดนอกกรอบ ทำให้ Spotify สามารถที่จะมี features ใหม่ๆไม่เหมือนใครเป็นแอพแรกๆ
การที่เราจะสามารถใช้ Agile at scale จริงๆเนี่ย trust เป็นสิ่งที่สำคัญมากๆ เพราะ trust จะทำให้ไม่มี fear พอไม่มี fear ก็จะไม่มี politics สิ่งนึงที่ Spotify เชื่อก็คือ
“If failure gets punished no one will dare to try new things.”
ซึ่งทำให้เรามีคำพูดที่ว่า fail fast, learn fast, improve fast เพราะ Daniel Ek เชื่อว่าการที่เราล้มก่อนคนอื่น จะทำให้เราแข็งแกร่งและโตเร็วกว่าคนอื่นในระยะยาว
Lean startup: Think it, build it, ship it, tweak it
หลายๆคนอาจจะคิดว่าทุกๆ squad ใน Spotify ต้องใช้ framework นี้หมดเลย แต่พูดได้อย่างมั่นใจเลยว่าไม่ใช่ เนื่องจากเรามี autonomy กันสูงมากๆทำให้แต่ละ squad สามารถที่จะ pick & choose ว่าเราอยากใช้ framework อะไร แบบไหนเหมาะกับ product ของเรา ถ้าพูดถึงประสบการณ์ตรง ตอนที่อยู่ใน data product ก็ได้ใช้ framework นี้ ทำตามทุกๆสเตปเลยเพราะตอนนั้น user ของเราคือคนที่ใช้ product จริงๆ แต่พอย้ายไปอยู่ใน SDK product ก็โยน framework นี้ทิ้งไปเพราะว่าเราแทบจะไม่ต้อง think it แต่จะอยู่ในมุมว่า build ยังไงให้ scalable มากกว่า challenge เลยไปอยู่ใน technology ที่เราใช้ซะส่วนใหญ่
Hack week
Hack week คือสิ่งที่ชอบมากๆ มันเป็นหนึ่งอาทิตย์ใน quarter ที่เราจะทำอะไรก็ได้ จะไปลองตำแหน่งไหนก็ได้ ถ้าเราเป็น software engineer แต่อยากจะลองไปทำ data science ก็ได้ อีกอย่างคือเราจะทำงานกับใครก็ได้ ไม่จำเป็นต้องเป็นคนในทีม goal ของงานนี้ก็คือการเปิดโอกาสให้คุณใช้เวลาหนึ่งอาทิตย์ในการ think it, build it and ship it ภายในช่วงเวลานั้น (แอบบอกว่าบางทีมนี่ถึงกับไม่นอน อยู่ในออฟฟิศไปเลยห้าวัน) แล้วก็ทำ product ใหม่ๆขึ้นมาแล้ว CEO, Chief R&D จะมาดูแล้วให้หลายๆคนโหวตและเลือก feature หรือ product นั้นไปใช้จริงๆ หลายๆ feature ที่เราเห็นกันก็มาจาก hack week อย่างเช่น discover weekly หรือ time capsule ที่ทีมทำขึ้นมา ตัวนัทเองก็เคยได้มีโอกาสได้ลองเป็น user researcher ในช่วงนั้น สนุกมากๆ เหมือนได้ลองอะไรใหม่ๆทุกๆ quarter
The bad
มาถึงส่วนของ the bad ละ ซึ่งความหมายก็คือมันแย่ มันไม่น่าเป็นแบบนี้เลย มันต้องปรับปรุง
No standard tools
สิ่งที่ Spotify เชื่อคือ autonomy ใช่ไหมคะ แต่บางที่มันก็สูงเกินไป ไปถึงการเลือกใช้ tools ต่างๆในการทำงาน ตัวอย่างเช่น visualization tools; squad นี้ใช้ qliksense อีก squad ใช้ tableau อีก squad ใช้ looker พอมาดูในมุม costs แล้วมันสูงลิบลิ่วเลย แทบจะเป็นลม แถมยังมีในมุมของ skillsets คนที่จะเข้ามาใช้ ต้องมีการเทรนหลาย tools แล้วก็ในมุม support ด้วย ต้องมี internal consultant ที่คอยช่วยเหลือ เราเลยรุ้สึกว่ามันกว้างไปแต่ช่วงหลังๆ Spotify เองก็เห็นว่ามันเริ่มเลยเถิด จาก employee 1000 กว่าคนกลายเป็น 3000 กว่าคนก็เริ่มมี tools เยอะขึ้นเรื่อยๆ เลยทำให้เริ่มมีการสร้าง squad มา support internal infrastructure ทั้งหลายตอนนี้ก็เริ่ม standardize ในบางส่วนแล้ว
The squad needs to be physically together
เรื่องนี้ตอนนั้นเป็นปัญหาใหญ่มากๆ เนื่องจาก squad อยู่ทั้ง Stockholm และ New York จึงทำให้ไม่ตรงตาม culture ก็เลยมีคนอยากจะมาขโมยตัว engineers หรือ พยายามมาแก้ปัญหานี้บ่อยๆ แต่จริงๆแล้วถ้าถามคนใน squad ก็ไม่มีใครรู้สึกมีปัญหานะ เพราะเราก็มีเทคโนโลยีที่จะมารับรองการทำ remote work อันนี้ขอเดาว่าตั้งแต่มี Covid-19 Spotify คงยกเลิกข้อนี้ไปแล้ว
The ugly
มาถึง the ugly ถ้าให้ reframe จริงๆคือสิ่งที่เป็น pain point ของเราในมุมของการใช้ culture ของ Spotify ซึ่งหนึ่งในนั้นคือสิ่งที่ดังมากๆจาก Spotify ในมุมของ cross functional team เนื่องจากเราเองต้องเผชิญปัญหาจาก setup นี้โดยตรงเลยขอเล่านิดนึง
Scrum master to agile coach
จริงๆแล้วชื่อ title ไม่ได้มีความหมายอะไรเลยถ้า roles&responsibilities มันไม่เคลียร์ Agile coach หลายๆคนที่ได้ทำงานด้วยเหมือนเป็น facilitator ที่คอยถามว่าจะให้ทำอะไรต่อมากกว่า scrum master ที่มี clear expectation จาก scrum.org เป้าหมายที่แท้จริงของการเปลี่ยนชื่อก็คล้ายๆกับเรื่อง scrum team เป็น squad คือไม่อยากให้คิดว่ามีการบังคับให้ใช้ scrum methodology แต่ผลลัพธ์ที่ออกมามันเปลี่ยนไปเพราะ Agile coach แต่ละคนไม่ได้เข้าใจ role อย่างแท้จริงจึงทำให้หลายๆ squad เห็น Agile coach ไม่สำคัญและงานก็เลยตกมาที่ product เต็มๆ
Chapter leads vs engineering manager; tribe lead vs discipline lead
ภาพนี้เป็นภาพที่ทำให้หลายๆคนรู้จัก Spotify culture แต่ขอแสดงความเสียใจด้วยนะคะที่ภาพที่คุณคิดว่ามันสุดยอดเลย เป็นสิ่งที่เราไม่ชอบมากที่สุดที่นั่น
ปัญหาแรกเลยคือ chapter leads (CL) ถามว่า CL ทำอะไรบ้าง CL คือคนที่ล่องลอยไปมามี catch up กับ engineers ว่า happy ดีมั้ย PO กดดันรึเปล่า หรืออยากไปลองงานอื่นมั้ย เนื่องจาก Spotify แคร์คนมากๆ แคร์ว่าคนจะรู้สึกอย่างไร หรืออยากไปเติบโตด้านอื่น มีอะไรที่อยากไปลอง จึงทำให้ CL focus ที่คนมากกว่างาน CL ไม่เคยรู้ว่า engineer คนนั้นทำงานอะไรอยู่ทำดีแค่ไหน PO ได้แต่ feedback ไปแต่ก็ไม่สามารถลงลึกเพราะ PO ไม่ได้ technical ปัญหาที่เราเจอเองเลยคือ skillsets ของ engineers ใน squad ไม่เหมาะกับงานและ direction ที่ product จะไปแต่ CL ก็ทำอะไรมากไม่ได้เพราะไม่ได้เข้ามาดูตัวงาน ซึ่งทำให้ accountability ต่ำมากๆในมุมของ tech
ปัญหาถัดมาคือ 1 squad มี CL 3–4 คนเพราะอยากให้มีการกระจาย CL คนนึงให้ดูทุก squad ฉะนั้นทำให้เราเองซึ่งเป็น PO ต้องมี 1–1 กับ CL ทุกคน อาทิตย์นึงเสียเวลากับการประชุมเยอะมากๆ
อีก concept คือ tribe lead ซึ่งคล้ายๆกัน บาง Tribe เนี่ยคนที่เรา report ด้วยไม่ได้อยู่ใน discipline เรา บางครั้งการปรึกษาในมุม product จึงทำได้ยาก บาง Tribe ก็มาจาก ux หรือ tech discipline ทำให้การ mentor จาก direct manager แทบไม่มีเลย ซึ่งเลยเป็นที่มาของ poor management ในหลายๆทีมที่ Spotify ถ้าให้พูดตรงๆคือบาง Tribe หรือ Mission ใน Spotify เลิกใช้ setup นี้ไปสักพักแล้ว
High autonomy, high alignment
ภาพนี้คือสิ่งที่เรียกว่าพูดง่ายทำยาก concept มันดีมากๆนะ แต่ก็ต้องดูด้วยว่าคนของเรามีความสามารถพอไหมที่จะให้ high autonomy ภาพนี้คือการ assume competency จากคนในทีมโดยเฉพาะ tech decision ซึ่งส่วนตัวแล้วภาพนี้จะเกิดขึ้นได้หลังจากที่ผ่าน low autonomy, high alignment จนมั่นใจว่าจะเดินได้ด้วยตัวเอง สังเกตเห็นหลายๆ squad ใหม่ที่ fail การ launch product แรกๆ เพราะ too high autonomy และทำให้หลายๆ squad เสียความมั่นใจ
No ego, awesome colleagues
ช่วงปีแรกๆ ให้ข้อนี้เป็น the good เลย ไม่สิ the best เลย รุ้สึกว่าทุกอย่าง positive มากๆ แต่พอมาช่วงหลังๆเริ่มเห็นว่า weak performers ก็ยัง awesome อยู่เพราะ awesome culture ของเรา ทำให้หลายๆคนที่ทำงานดีแต่ดันมาเจอ weak performer ในทีมที่ต้องทำงานทดแทน ฉะนั้นขอใส่เป็น the ugly in hindsight ละกัน
Chaos > bureaucracy
ข้อสุดท้ายแล้ว อันนี้น่าจะเป็น comment in general ของทุกคนที่เข้าไปทำงานที่นั่น คือทำไมมัน chaotic จัง เนื่องจาก Spotify ตอนนี้เป็นบริษัทใหญ่มากแล้ว เทียบได้กับ corporate ใหญ่ๆที่อื่น แต่ process หลายๆอย่างยังไม่มี (แอบบอกอีกว่าใครจะเบิกอะไรไปไหนเท่าไหร่ก็ได้ อย่างเราบินไปมา New York — Stockholm ก็ได้อยู่รร 5 ดาวตลอด) ซึ่งพอ CFO คนก่อนเข้ามาก็จัดการเกือบเรียบแล้ว ตอนนี้น่าจะลด chaos ไปได้เยอะพอควร
หวังว่า article นี้จะมีประโยชน์กับหลายๆคนที่อยากจะนำ Spotify culture ไปใช้ในองค์กร อยากจะให้ลองผิดลองถูก ลองหาดูว่าอะไรที่เหมาะกับทีมของเรามากที่สุด หรือมีอะไรบ้างที่ไม่ควรทำตามค่ะ
Credit ภาพจาก labs.spotify.com
