[Techie Tuesday] स्टार्टअप सीटीओ को ध्यान में रखनी चाहिए ये 10 बातें

स्टार्टअप की दुनिया में Chief Technical Officer (CTO) शब्द ग्लैमरस है। यदि कंपनी के सीईओ सफलता के मार्ग को देखने के लिए अग्रणी हैं, तो सीटीओ प्रोडक्ट को अंतिम रूप देने तक पहुंचने के लिए आवश्यक प्रक्रियाओं को क्रियान्वित करने और लागू करने के लिए जिम्मेदार है।

स्टार्टअप सीटीओ को, कोड को डिबग करके समस्याओं को हल करना और उनसे प्रोडक्ट बनाना होता है। उन्हें न केवल स्केलेबिलिटी के संदर्भ में सोचना होगा, बल्कि लिमिटेड रिसॉर्सेज के साथ अलग-अलग डिपार्टमेंट्स, हायरिंग, टीम ग्रोथ, क्वालिटी मैनेजमेंट, वेंडर रिलेशनशिप्स आदि के साथ सहयोग करने की भी आवश्यकता है।

यह कहना अतिशयोक्ति नहीं होगी कि एक सीटीओ आसानी से कंपनी बना या बिगाड़ सकता है। तो यहां कुछ बातें हैं जो आपको स्टार्टअप सीटीओ के रूप में ध्यान में रखनी चाहिए -

Tech debt: प्रत्येक सॉर्स कोड में tech debt होता है, इसलिए इसे स्वीकार करने में संकोच न करें। इसे ठीक करने में सक्रिय रहें। इसे संभालने के लिए इसके बढ़ने से पहले इसे ठीक करें। छोटे स्मॉल debt ठीक है, लेकिन यदि आप फीचर रिलीज से ठीक पहले ही एक बड़ा debt देखते हैं, तो रिलीज को रोक दें।

Engineering + product: आप हमेशा कम से कम दो टोपी पहनेंगे (एक और है - ग्राहक सफलता, लेकिन हम इसके बारे में बाद में बात करेंगे)। पहले यूजर के बारे में सोचें जिसका अर्थ है पहले प्रोडक्ट और फिर इंजीनियरिंग।

"इन दोनों को डिस्कनेक्ट करना बहुत मुश्किल है, लेकिन जितनी जल्दी आप सीखते हैं, उतना ही कम दर्दनाक होगा क्योंकि प्रोडक्ट / प्लेटफॉर्म बढ़ता है।"

Code culture: कोड स्मेल टूल्स शुरू करने में बहुत देर न करें (हमने यह गलती की है)। इंजीनियरिंग टीम जितनी छोटी होगी, कोड कल्चर को लागू करना उतना ही आसान होगा।

Scale is relative: अपने स्पेस को गहराई से समझें और अपने यूज केस के आधार पर लाखों या अरबों का निर्माण करें। प्रत्येक प्रोडक्ट को पहले दिन अरबों लेनदेन का समर्थन करने की आवश्यकता नहीं है।

No-code tools solely cannot make your company successful: प्रोडक्ट बनाना एक सफल कंपनी बनाने के कारकों में से एक है। हायरिंग, प्रोडक्ट मार्केट फिट और गो-टू-मार्केट जैसे अन्य महत्वपूर्ण क्षेत्र हैं जो अधिक मायने रखते हैं।

There’s never enough bandwidth: आपके पास हमेशा डेवलपमेंट बैंडविड्थ की कमी होगी (भले ही आप कल अपनी इंजीनियरिंग और प्रोडक्ट टीम का आकार दोगुना कर लें)। फीचर रोल आउट में देरी न करें, मिनिमम वायेबल फीचर को आगे बढ़ाएं और फिर पुनरावृत्ति जारी रखें!

Business priorities change: व्यावसायिक प्राथमिकताओं में कुछ स्तर के बदलावों के साथ शांति बनाएं जो प्रोडक्ट रोडमैप को संचालित करते हैं।

Developers with user first mindset: प्रत्येक इंजीनियर में प्रोडक्ट मैनेजर पर्सनैलिटी का 10 प्रतिशत टीम में अधिक प्रोडक्ट मैनेजर होने से कहीं अधिक मूल्यवान है।

Read ‘The Phoenix Project’: टेक्नोलॉजी फील्ड में करियर बनाने वालों के लिए यह एक मोस्ट रिकमेंडेड बुक है। तेज-तर्रार और मनोरंजक शैली में, DevOps मूवमेंट के तीन दिग्गज एक ऐसी कहानी पेश करते हैं जिसे आईटी में काम करने वाला कोई भी व्यक्ति पहचान लेगा। आप न केवल यह सीखेंगे कि अपने स्वयं की आईटी ऑर्गेनाइजेशंस को कैसे सुधारें, वे आईटी को फिर कभी उसी तरह नहीं देखेंगे।

Enjoy and have fun while building: हमेशा फीचर में देरी, प्रोडक्शन में कमी, इंजीनियरों के नौकरी छोड़ने, कैंडिडेट्स के जॉइनिंग डेट पर नहीं आने समेत कई बातें हो सकती है। इसके साथ शांति बनाएं, आप अकेले नहीं हैं!

इस पोस्ट को पहले लेखक के अकाउंट से ट्विटर थ्रेड के रूप में प्रकाशित किया गया था और अनुमति के साथ पुन: प्रस्तुत किया गया है।

ALSO READ

कभी Dell में करते थे 7500 रुपये की नौकरी, आज हैं 18 मिलियन डॉलर की कंपनी के मालिक: Ambee के फाउंडर मधुसूदन आनंद की कहानी