स्टार्टअप में डेटा टीम बनाना

• सालाना 10 बिलियन राजस्व वाले Mid-Stage startup में लगभग 4 लोगों की एक छोटी data team बनाने के लिए शामिल हुए व्यक्ति की कहानी

• यह कुछ अनुभवों पर आधारित एक रूपकात्मक लेख है, और पक्षपाती* हो सकता है, इसलिए इसे उसी हिसाब से पढ़ें

1 जुलाई : सुबह

• data team के जिम्मेदार लीड के रूप में ऑफिस का पहला दिन

• CMO से मुलाकात

(CMO इस बात से बहुत उत्साहित हैं कि मैं आ गया हूँ, बताते हैं कि उनके दोस्त की कंपनी AI का इस्तेमाल करके customer segmentation कर रही है और वह काफ़ी शानदार लगता है)

(संक्षिप्त बातचीत के बाद marketing team की data practice की जाँच)

DATA: "customer acquisition cost (CAC) कैसा है?"

CMO: "उम्.. वास्तव में बहुत शानदार है। हमारे data scientist ने numbers मापे हैं, और cost per click लगातार कम हो रही है"

DATA: (मैंने सुना था कि सभी data scientist data team को report करते हैं, तो क्या किसी दूसरी टीम में भी data scientist है?)

CMO: "असली समस्या यह है कि Growth team उस traffic को convert नहीं कर पा रही जो हम site पर ला रहे हैं"

DATA: "क्या conversion funnel देखने के लिए कोई dashboard है?"

CMO: "leads को convert करना तो Growth team का काम है, है न।"

• Product Manager में से एक के साथ बातचीत

start page को पूरी तरह redesign करने वाले PM इस बात से उत्साहित थे कि user registration 14% बढ़ गया है

DATA: "क्या इस संख्या का अंतर statistically significant है?"

PM: "वह मेरा काम नहीं है, वह आपकी team का काम है"

PM: "जब हमने पहले पूछा था, data team ने कहा था कि data नहीं है, और data पाने में कई महीने लगेंगे"

PM: "हैरानी की बात यह है कि हमने इसे incremental change की तरह नहीं किया। हमने इस बदलाव के लिए A/B test न करने का फैसला किया। कभी-कभी local maxima से बाहर निकलने के लिए बड़ा bet लगाना पड़ता है।"

PM: "Steve Jobs ने iPhone launch करते समय A/B test नहीं किया था। हमारी team ने इसे deadline से 2 दिन पहले launch किया, और वही महत्वपूर्ण है!"

DATA: (व्यस्त दिखने का नाटक करते हुए notebook में कुछ लिखता है)

• नए team members के साथ बातचीत

→ team में 3 लोग हैं, लेकिन साल के अंत तक इसे 10 लोगों तक बढ़ाने का budget मिल चुका है

→ लगता है मेरे आने से team members उत्साहित हैं

→ उन्होंने अब तक बनाई गई चीज़ें दिखाईं। चीज़ें काफ़ी हैं, और उनमें से कुछ प्रभावशाली भी हैं

✓ user churn prediction के लिए neural network

✓ related product recommendation system implement किया हुआ notebook

→ बहुत-सा code अलग-अलग systems से data लाने वाले बहुत जटिल preprocessing step से शुरू होता है

✓ लगता है इस काम का कुछ हिस्सा करने के लिए कई scripts को सही क्रम में manually चलाना पड़ता है

→ team members से पूछा कि इन्हें production में क्यों नहीं डाला गया

✓ engineers का कहना है कि इसे production level पर ले जाना बहुत बड़ा project होगा

✓ Product Manager ने इसे backlog में डाला है, लेकिन दूसरे काम आते रहने से यह टलता जा रहा है

✓ उनका कहना है कि इसके लिए management support की ज़रूरत है

1 जुलाई : दोपहर

• Head of Supply Chain के साथ बातचीत (वह शायद CMO जितने उत्साहित नहीं हैं)

"सच कहूँ तो मुझे नहीं पता कि हमें data team की मदद की ज़रूरत भी है या नहीं"

"हमारे पास उस तरह की समस्या नहीं है। हमें तो business analyst चाहिए"

"मेरे पास पूरी team है, और वे बहुत complex models पर काम करने में हर दिन कई घंटे खर्च करते हैं"

"उनके पास मेरे बुनियादी सवालों का जवाब देने का भी समय नहीं है।"

"मेरे पास ऐसे सवालों से भरी spreadsheet है जिनके जवाब मैं चाहता हूँ"

(spreadsheet देखने पर उसमें ऐसी चीज़ें हैं)

"जिन customers के tickets 1 घंटे के भीतर resolve हुए और जिनके 1 घंटे बाद resolve हुए, उनकी conversion rate की तुलना order amount को $100 डॉलर के अंतराल में classify करके करना"

(models के बारे में पूछने पर)

• लगता है इसे countless VLOOKUPs वाले Google Sheet में सही format में सही tab पर copy करना पड़ता है

• data हर दिन update होता है, और model के output के आधार पर उस दिन team की priorities तय होती हैं

• vendors को जाने वाली payments भी spreadsheet में ही calculate की जा रही हैं

(घर जाकर whiskey का एक बड़ा पैग भरता हूँ.. )

[ क्या हुआ था?]

• यह मूल रूप से data maturity के शुरुआती चरण में मौजूद कई कंपनियों में होने वाली चीज़ों का एक (कुछ हद तक निंदक) चित्रण है

• data की कमी और बिखरा हुआ data

→ अक्सर product ठीक से instrumented नहीं होता, इसलिए data शुरू से मौजूद ही नहीं होता

→ data कई systems में बँटा हुआ होता है, यानी data system fragmentation

→ business processes data-driven तो हैं, लेकिन automation बहुत कम या बिल्कुल नहीं है, इसलिए वे नाज़ुक हैं

• data team का काम क्या है, इस बारे में अस्पष्ट अपेक्षाएँ

→ R&D करने और AI deploy करने के लिए hire किए गए data scientists — नतीजतन स्पष्ट business goals नहीं हैं

→ data team ML को production में ले जाना मुश्किल होने की शिकायत करती है, लेकिन product team को उस feature की ज़्यादा परवाह ही नहीं है

→ ऐसे लोग जिन्हें "English-to-SQL translator" चाहिए

• data-driven training न पाने वाली product team

→ Product Managers data को बेहतर features बनाने के tool के रूप में नहीं देखते

→ product team जो बनाना चाहती है और data team के पास जो है, उनके बीच alignment की कमी

• मूल रूप से data-centric culture से टकराने वाली culture

→ measurable progress और learning का जश्न मनाने के बजाय shipping का जश्न मनाने वाली culture

→ जो teams वास्तव में metrics इस्तेमाल भी करती हैं, वे भी असंगत हैं, measurement ठीक से नहीं होता, और कुछ मामलों में दूसरी teams से टकराव भी होता है

• data leadership का अभाव

→ अलग-अलग data personnel कई अलग departments/functions को report करने वाली बंटी हुई data organization

→ दूसरे departments को ज़रूरी मदद नहीं मिलती, इसलिए वे data team के आसपास बहुत से analysts hire कर लेते हैं

→ toolchain और best practices के standardization की कमी

(वाह, यह तो उदास करने वाला है। इस समस्या को हल करने के लिए क्या करना होगा?)

8 जुलाई

• अगले हफ़्ते से data team की नई direction तय करना शुरू

• लगता है एक व्यक्ति को infrastructure का अनुभव है, इसलिए उसे centralized data warehouse बनाने को कहा

• अभी के लिए बस data को एक जगह इकट्ठा करने का सबसे तेज़ रास्ता चाहिए

• योजना मूल रूप से हर घंटे production DB को data warehouse में dump करने की है

• frontend में ad tracking के लिए इस्तेमाल होने वाले framework से बड़े event logs भी भेजे जा सकते हैं, लेकिन उसे technical debt के रूप में बाद के लिए रखा

• hiring team के साथ मिलकर Generalist Data Role को define किया

→ core software skills पर ज़ोर, लेकिन साथ ही Generalist (जो हर तरह का काम कर सके) mindset और business requirements के प्रति गहरी सहानुभूति रखने वाला व्यक्ति

→ फिलहाल artificial intelligence और machine learning के सभी उल्लेख हटा दिए

• उन दूसरे data personnel के साथ समय बिताया जो data team को report नहीं करते

→ marketing team में मौजूद data scientist एक युवा व्यक्ति था। "मैं हमेशा data scientist बनना चाहता था। मैं आपसे बहुत कुछ सीखना चाहता हूँ"

• coding bootcamp चलाने वाले एक दोस्त से पूछा कि क्या उसके पास कोई अच्छा "SQL training course" है, उसने कहा हाँ, तो इसे इस महीने के अंत में शुरू करने का फैसला किया

• product team के लिए यह समझाने वाली presentation material तैयार की कि A/B test क्या है और कैसे काम करता है

→ ऐसे tests के कई उदाहरण दिखाए जिनमें unexpected results आए,

→ और इसे interactive बनाया ताकि लोग अंदाज़ा लगा सकें कि कौन-सा जीता

• CEO के सहायक से मिलकर यह पता करना कि "हर हफ़्ते ऑटोमेटिक भेजी जाने वाली ईमेल के ज़रिए कौन-से मेट्रिक्स रिपोर्ट किए जाएँ"

• Supply Chain टीम के business analysts से बात की तो पता चला कि वे तार्किक लोग हैं, लेकिन पहले data team से बात करते हुए आहत हो चुके थे

• उनमें से एक के पास पहले SQL इस्तेमाल करने का अनुभव था। उसे conversion rate के बारे में सवाल करते देख data warehouse की access दे दी

• पूरी organization में जिन लोगों को data की ज़रूरत है, उनके साथ साप्ताहिक 1:1 meetings सेटअप करना

→ मकसद है data gap और opportunities ढूँढकर data scientists तक पहुँचाना

→ data scientists निराश हो सकते हैं क्योंकि उनकी research priorities पीछे खिसकती हैं

→ "जितनी जल्दी हो सके business value देने पर फ़ोकस करें" यह कहते हुए भी, "हो सकता है हम जल्द ही फिर से machine learning वाले काम पर लौटें। पहले देखते हैं" ऐसा कहना

1 सितंबर : सुबह

• 3 महीने बीत चुके हैं, और अब थोड़ा-थोड़ा लग रहा है कि काम आकार ले रहा है

• अलग-अलग stakeholders के साथ हर हफ़्ते 1:1 meetings करते हुए लगातार blind spots और opportunities खोज रहे हैं जहाँ data बदलाव ला सकता है

• जो चीज़ें मिलीं, उनका उपयोग core platform work को आगे बढ़ाने के लिए करना

• "derived" datasets बनाने के लिए बहुत सारे pipelines बनाने पड़ते हैं। शुरुआती लागत ज़्यादा है, लेकिन सही datasets बन जाने पर आगे की analysis बहुत आसान हो जाती है

• दूसरे departments के लिए data warehouse access खोलना शुरू

• खुद SQL इस्तेमाल करके basic analysis करना शुरू

→ शानदार बात: एक junior product manager ने पाया कि iOS Safari का conversion rate बहुत ख़राब है। यह local storage से जुड़ा frontend bug था, और एक लाइन में ठीक हो गया

• supply chain lead ने ग़ुस्से वाला ईमेल भेजा

→ database बदल गया था, इसलिए 500-line query fail हो रही थी..

→ बड़बड़ाते हुए data scientist को fix करने को कहा और एक और carrot टाँग दी: "इस महीने के अंत तक मैं आपके लिए कोई बढ़िया machine learning problem ढूँढ दूँगा"

1 सितंबर : दोपहर

• checkout team का product manager अभी भी metrics analysis नहीं कर रहा है

• marketing team का data scientist अपने manager से बात करके तय करता है कि वह सीधे मुझे report करेगा

[ क्या हो रहा है? ]

• सबसे ज़रूरी चीज़ों की बुनियादी नींव रखी जा रही है

→ महत्वपूर्ण data को एक ही जगह queryable बनाया जा रहा है

→ SQL access खोलकर और दूसरी teams को इस्तेमाल करने देकर बहुत-से "SQL translation" वाले काम ख़त्म किए जा रहे हैं

• दूसरी तरफ़, दूसरी teams इस आज़ादी की वजह से ज़रूरत से ज़्यादा आगे जाने की कोशिश कर सकती हैं। data access पर permissions लगाकर इसे रोका जा सकता है, लेकिन उसके नुकसान ज़्यादा हैं

• checkout team data analysis इसलिए नहीं कर पा रही थी क्योंकि उन्हें पता ही नहीं था कि किससे पूछना है

• यह मुख्य रूप से organization की समस्या है

→ teams को नहीं पता कि data team के साथ कैसे collaborate करना है

→ शायद एहसास न हो, लेकिन data team ही bottleneck हो सकती है

• सबसे तार्किक बात है "reporting को centralized रखना और work management को decentralized करना"

→ क्योंकि data और decisions मिलकर एक ज़्यादा क़रीबी feedback loop बनाते हैं

→ ताकि data team के सदस्य अपनी-अपनी teams में collaborate करें और reporting सिर्फ़ मुझे (data team lead) करें

2 सितंबर

• data team 6 लोगों की हो गई

→ 1 व्यक्ति data warehouse infrastructure

→ 5 लोग अलग-अलग teams में assigned: onboarding, supply chain, checkout, marketing, और CEO support व investors/board के लिए presentation materials तैयार करना

• पूरे company में बदलाव समझाना, और यह स्पष्ट करना कि data requirements के लिए किसके साथ काम करना है

• आगे data hires होंगी तो उन्हें भी दूसरी teams में assign करने की योजना

3 जनवरी

• data scientists में से एक ने जाने का फ़ैसला किया। उसके लिए आनंद लेने लायक काम भी ज़्यादा नहीं था, इसलिए उसे रोकने की कोशिश नहीं की

• team में कई नए लोग हैं। थोड़ा software engineering ज्ञान, SQL, और data में दिलचस्प चीज़ें खोजने की इच्छा रखने वाले लोग

→ ये लोग data में "scoop" ढूँढते हैं, इसलिए इन्हें "data journalists" की तरह सोचना

• onboarding team के साथ काम करने वाले सदस्य के मामले में

→ उसने पाया कि onboarding flow में customer address की ज़रूरत न होने पर भी address पूछा जा रहा है

→ इसे हटाने पर A/B test में conversion rate 21% बढ़ गया

→ data को query करना आसान बनाने के लिए ETL काम की ज़रूरत थी, इसलिए यह आसान नहीं था, लेकिन Python ने थोड़ा साथ दिया और यह संभव हो गया

• CEO के साथ quarterly review

→ growth initiative में PM ने हाल ही में launch किए गए landing page redesign का परिचय दिया

→ PM ने ज़ोर देकर कहा कि 20 engineers deadline पूरी करने के लिए overtime कर रहे हैं

→ CMO भी इस redesign के हिस्से के रूप में Direct Mail से बड़ी उम्मीद लगाए हुए है, इसलिए गहराई से शामिल है

→ CEO का सवाल: "अभी metrics कैसे हैं? क्या customer acquisition cost घटी है?"

→ (आपको उम्मीद थी कि CEO ऐसा सवाल करेगा, और ठीक वैसा ही होने पर आप मुस्कुरा देते हैं)

→ PM दिखाता है कि वास्तव में A/B test किया गया था, और appendix में मौजूद numbers दिखाता है

→ कुछ metrics ऊपर गए, कुछ नीचे, इसलिए कोई statistically meaningful result नहीं दिखता, और customer acquisition cost के numbers अच्छे नहीं लगते

→ CMO ज़ोर देकर कहता है कि numbers अभी बन रहे हैं, और ऐसी campaigns में कई महीने लग सकते हैं

[ क्या हो रहा है? ]

• अच्छी ख़बर यह है कि product team ने A/B testing शुरू कर दी है

• बुरी ख़बर यह है कि results को नज़रअंदाज़ करके projects ज़्यादातर milestones और artificial deadlines के हिसाब से चल रहे हैं

• सबसे अच्छी ख़बर यह है कि CEO हर team पर दबाव डाल रहा है कि data को truth की तरह इस्तेमाल किया जाए

• जैसे-जैसे organization पर ज़्यादा data-driven बनने का दबाव बढ़ता है, data team को दूसरी teams के साथ अपने collaboration के तरीक़े तेज़ करने होंगे

• ख़ासकर top management metrics पर ज़्यादा फ़ोकस करेगी, और data team से इन metrics पर काम करवाना आपका काम है

• एक सबसे आसान तरीक़ा यह है कि यह सुनिश्चित किया जाए कि हर team के लिए उन metrics का dashboard हो जिन्हें वह महत्वपूर्ण मानती है

1 अप्रैल

• data team के पुराने machine learning काम अभी भी वैसे ही पड़े हैं

• inventory product team में काम करने वाला data scientist पहले बनाए गए recommendation system के काम में दिलचस्पी ले रहा है

• नए hires में से एक member generalist है, इसलिए उसने recommendation system notebook को एक छोटे Flask app में बदलकर internally deploy कर दिया

• inventory team के product manager ने देखकर पसंद किया: "इसे deploy कैसे करें?"

• inventory team के प्रमुख metrics में से एक "average order value" है, और लगता है कि यह recommendation उसे काफ़ी सुधार सकता है

• एक छोटे estimate से भी लगता है कि बड़े पैमाने पर deploy करना मुश्किल होगा, लेकिन विचार आया: "क्यों न इसे सिर्फ़ 1% customers पर deploy करके देखें?"

• "थोड़ा बेवकूफ़ी भरा है, लेकिन Cron Job से recommended products पहले से generate कर लें तो हो जाएगा, और शायद कुछ दिनों में बना सकते हैं"

• supply chain team के साथ काम करते हुए और भी बहुत बड़े SQL queries मिले

• वे लगातार टूटते रहते हैं, लेकिन data team इन्हें सही pipelines में बदलने का काम कर रही है

• supply chain team head ने और data scientists hire करने की माँग की

[ ठीक है, अब क्या हो रहा है? ]

• पहली बात, अब शानदार machine learning काम की उम्मीद पैदा हो गई है

• product team आख़िरकार recommendation system को एक छोटे test के रूप में launch करने को लेकर उत्साहित है

• पहले यह आगे नहीं बढ़ पाता था, क्योंकि product engineering team के लिए इस काम का अनुमान लगाना मुश्किल था, वे सीधे योगदान नहीं देना चाहते थे, और data team के पास इसे productionize करने की skills नहीं थीं

• इस समस्या का हल इसलिए हुआ क्योंकि data team ने सचमुच demo बना दिया। इससे न सिर्फ़ चीज़ production के क़रीब आती है, बल्कि संभावना भी साफ़ दिखती है

• दूसरी बात, supply chain team में जो हो रहा है

→ शुरुआत अपने "business analysts" से हुई थी, लेकिन data पाने के लिए data team से query चलवानी पड़ती थी

→ analysts ने data team की मदद से खुद queries चलाना शुरू कर दिया

→ सबसे पहले, डेटा टीम के साथ टकराव पैदा कर रहे "shadow technical debt" (राक्षसी आकार की SQL queries) को खत्म करना शुरू किया

→ डेटा टीम ने supply chain टीम के साथ जुड़कर मदद करना शुरू किया

→ जैसे-जैसे डेटा टीम के सदस्य embedded हुए, business analysts की ज़रूरत कम हुई और data scientists की संख्या बढ़ी

• याद रखें कि शुरुआत में production DB को सीधे data warehouse में dump करना शुरू करते समय आपने "technical debt" अपने ऊपर ले लिया था

• शुरुआत में बहुत-सी चीज़ें टूटेंगी, लेकिन stable तरीके से query करने लायक एक layer जोड़नी होगी। यह बहुत बड़ा काम हो सकता है

1 जुलाई

• Q3 planning meeting

→ पहले इस बात पर बहस होती थी कि कंपनी अगली तिमाही में किस पर दांव लगाएगी

→ इस बार आप कंपनी के top-level metrics पेश करते हैं, और हर टीम sub-metrics के ज़रिए उन top-level metrics को विभाजित करके प्रस्तुत करती है

• product management टीम का काम असर दिखा चुका था

→ PM ने tests चलाकर जो सीखा और data में जो पाया, उसके आधार पर project में निवेश को justify किया

• एक बड़ी उपलब्धि यह थी कि checkout टीम के साथ काम कर रहे data scientist ने पाया कि जब उपयोगकर्ता confirmation page पर back button दबाते थे, तो cart object अजीब तरह से बदल जाता था

→ इस समस्या को ठीक करने पर conversion rate काफ़ी बढ़ गया

• एक और insight यह थी कि अलग-अलग ad campaigns से आने वाला traffic बहुत अलग conversion profiles रखता है

→ कुछ campaigns में click price कम था लेकिन conversion rate बेहद खराब था, जबकि कुछ campaigns महंगे थे लेकिन conversion rate बहुत ऊँचा था

• UTM variables को track करके और उन्हें account creation से जोड़कर, ad click से purchase तक conversion rate मापना संभव हो गया

→ इससे पहले यह संभव नहीं था, क्योंकि पहले सभी data को एक ही data warehouse में लाकर आसानी से query करने लायक normalize करना ज़रूरी था

→ marketing के साथ मिलकर यह स्पष्ट हुआ कि मुख्य KPI cost per click नहीं, बल्कि end-to-end customer acquisition cost है

• एक और दिलचस्प खबर यह थी कि 1% recommendation system test असाधारण रूप से सफल रहा

→ इसे 100% users तक scale करना बहुत बड़ा project है, लेकिन CEO ने project को approve कर दिया

• सभी नतीजे सकारात्मक नहीं थे, और कई tests असफल रहे।

→ slides में से एक उस test की व्याख्या थी जिसमें delivery fee अलग से charge नहीं की गई थी, बल्कि price में शामिल थी

→ CEO ने कहा, "हमने यहाँ क्या सीखा?"

→ इसके बाद follow-up experiments की एक श्रृंखला की planning पर बातचीत शुरू हुई

(घर जाकर champagne खोली जाती है)

[ क्या हुआ था? ]

• आपने कर दिखाया।

• आपने संगठन को एक सच्चे data-native रूप में बदल दिया।

• डेटा टीम विभिन्न stakeholders के साथ cross-functional तरीके से काम करती है।

• data और insights का उपयोग planning में होता है, और data का इस्तेमाल अस्पष्ट लक्ष्य वाले research के बजाय business value बनाने में किया जाता है।

• कंपनी तेज data-driven feedback loops का उपयोग करके बड़े "waterfall"-style plans के बजाय iterative तरीके से काम करती है।

• metrics इस तरह परिभाषित किए जाते हैं कि वे business value बना सकें और उसके लिए जवाबदेही भी तय हो सके।

• data culture ऊपर से (CEO द्वारा आगे बढ़ाया गया) और नीचे से (कर्मचारियों द्वारा) दोनों तरफ से मिलकर चलाया जाता है।

• अगर आपने कम-से-кम कुछ सीखा है, तो असफल होना भी ठीक है।

(बधाई हो। आप champagne उठाने के हक़दार हैं)

[hangnim]

शुरुआती हिस्सा पढ़ते हुए लगा जैसे ये हमारी ही कंपनी की बात हो,,,, T_T (हालांकि हमारे यहाँ तो data team भी नहीं है, हाहा)

[dajoa]

बहुत मज़े से पढ़ा। धन्यवाद~!

[shawn]

ऐसा लगता है जैसे इंजीनियरों को पसंद आने वाले tech startup ड्रामा के किसी एपिसोड को देख रहे हों। मज़ेदार है! 👍

[hangnim]

22222

[laeyoung]

लोग काफ़ी ज़्यादा दिख रहे हैं, तो क्या इसे mid-stage माना जाता है

[xguru]

शायद यहाँ देखे जाने वाले scale का आकार घरेलू संदर्भ से कुछ अलग होगा.

[xguru]

Opinionated* का साफ़-सुथरा अनुवाद करना आसान नहीं है, लेकिन मैं इसे आम तौर पर "अपनी राय के प्रतिबिंब के कारण पक्षपाती" वाले अर्थ में "पक्षपाती" के रूप में इस्तेमाल करता हूँ.

इस बारे में किसी और का लिखा हुआ एक लेख है, उसे संदर्भ के लिए देखें

• कंप्यूटर शब्दावली में opinionated (पक्षपाती) का अर्थ https://www.clien.net/service/board/cm_app/13558026

और, मूल लेख में सामग्री विस्तार से लिखी गई थी, लेकिन मैंने उसे थोड़ा अधिक पढ़ने में आसान बनाने के लिए संवादात्मक शैली में पुनर्गठित किया है.