स्टार्टअप्स में आधुनिक Staff Engineering

• स्टार्टअप परिवेश में DevOps, Staff Engineering, और Platform Engineering की अवधारणाओं को प्रभावी रूप से लागू करने के उदाहरण साझा किए गए हैं
• वक्ता Chad McElligott, Smartrr में Senior Staff Engineer हैं, जो Shopify-आधारित subscription और loyalty सेवाएँ प्रदान करने वाली कंपनी है
• स्टार्टअप की विशिष्ट संस्कृति और आवश्यकताओं के अनुरूप engineering methodology का प्रस्ताव

[मुख्य अवधारणाएँ]

DevOps

• DevOps की परिभाषा हर व्यक्ति के लिए अलग हो सकती है; किसी के लिए यह एक job title है, तो किसी के लिए काम करने का तरीका
• "DevOps as No Ops" की अवधारणा software engineer को Ops से जुड़ा सारा काम स्वयं संभालने पर मजबूर करती है
• DevOps का अर्थ है सहयोगी mindset, दोहराए जाने वाले और मैन्युअल काम ( toil ) का automation, और आधुनिक tools के उपयोग के ज़रिए ग्राहकों तक तेज़ी से value पहुँचाना
• cloud का उपयोग, infrastructure as code, और CI/CD pipeline बनाना जैसे तकनीकी तत्वों के साथ-साथ, communication और collaboration की बाधाएँ तोड़कर बेहतर परिणाम हासिल करना इसका मूल है

Platform Engineering

• Platform Engineering developer के cognitive load को कम करने का एक तकनीकी दृष्टिकोण है
• इसका लक्ष्य product development की गति और system stability दोनों को बढ़ाना है, और यह developer की गतिविधियों को समर्थन देने वाले बुनियादी building blocks उपलब्ध कराता है
• बड़ी कंपनियों में Platform Engineering team बनाकर efficiency बढ़ाने और developer experience सुधारने के उदाहरण बढ़ रहे हैं
• Manuel Pais और Matthew Skelton की किताब Team Topologies के माध्यम से यह अवधारणा लोकप्रिय हुई, और engineering enablement के उदाहरण विभिन्न माध्यमों में देखे जा सकते हैं

Staff Engineering

• Staff Engineering कोई खास mindset या skill नहीं, बल्कि संगठन के भीतर software engineer द्वारा निभाई जाने वाली भूमिका है
• यह Senior Software Engineer के बाद का career stage है, और इसे software engineering में servant leadership के रूप में भी समझाया जा सकता है
• Staff+ engineer केवल व्यक्तिगत काम तक सीमित नहीं रहते, बल्कि अपनी ज़िम्मेदारी पूरे संगठन तक बढ़ाते हैं, और managers या VP के साथ मिलकर व्यावहारिक execution और perspective प्रदान करते हैं
• Will Larson की किताब Staff Engineer में Staff role को चार archetypes—Architect, Right Hand, Tech Lead, और Fixer—में बाँटकर समझाया गया है

[स्टार्टअप संस्कृति]

• venture investment पर आधारित स्टार्टअप्स में growth के लिए खर्च अक्सर revenue से अधिक होता है
• निवेश से जुटाई गई पूँजी को "runway" की तरह इस्तेमाल कर तेज़ growth हासिल करने की कोशिश की जाती है, और runway खत्म होने से पहले growth और profitability हासिल करनी होती है
• यह माहौल दो महत्वपूर्ण सांस्कृतिक विशेषताएँ बनाता है
  • बर्बाद करने के लिए समय नहीं है
    • स्टार्टअप में समय की बर्बादी विशेष रूप से घातक होती है
    • development team को संगठन के strategic goals पर फोकस रखना होता है और runway के भीतर execution करना होता है
    • हर team member को बार-बार जाँचना चाहिए कि उसकी गतिविधियाँ लक्ष्यों के अनुरूप हैं या नहीं, और ज़रूरत पड़ने पर उन्हें फिर से समायोजित करना चाहिए
    • अगर कोई experiment विफल भी हो जाए, लेकिन सीखने के लिए संरचना मौजूद हो और वांछित सबक मिल जाए, तो वह बर्बादी नहीं है
  • हर कोई कई भूमिकाएँ निभाता है
    • छोटे संगठनों में काम बहुत होता है, लेकिन उसे करने वाले लोग कम होते हैं
    • उदाहरण के लिए, frontend developer product designer, technical writer, product manager, quality assurance, और third-party integration की भूमिका भी निभा सकता है
    • यदि customer experience सुधारने के लिए कोई नया विचार आता है, तो उसे प्रस्तावित करने वाला व्यक्ति स्वयं prototype बनाने या उसे साकार करने की ज़िम्मेदारी भी ले सकता है
• ये सांस्कृतिक विशेषताएँ product development group और विशेष रूप से software engineering leaders के लिए आवश्यक क्षमताओं को निर्धारित करती हैं
• साथ ही, ये इस बात के संकेत भी देती हैं कि DevOps, Platform Engineering, और Staff Engineering को स्टार्टअप परिवेश के अनुसार कैसे ढलना चाहिए

[स्टार्टअप संस्कृति में मेरे engineering tenets लागू करना]

स्टार्टअप में DevOps

• स्टार्टअप में process बदलना आसान होता है
  • लोगों की संख्या कम होने के कारण नए तरीके अपनाने में बड़े अवरोध नहीं होते
  • tools के अनुसार process को समायोजित करना सबसे बेहतर परिणाम देता है
  • अगर कठोर process बनाए रखे जाएँ, तो tools को customize करना या अतिरिक्त software बनाना पड़ता है, जिससे समय बर्बाद होता है
• custom tools से यथासंभव बचना चाहिए
  • serverless infrastructure, SaaS tools, और open source libraries का उपयोग करना बेहतर है
  • तकनीक की सामान्य दिशा के साथ चलना चाहिए, और जहाँ स्पष्ट competitive advantage न मिलता हो वहाँ technology को customize नहीं करना चाहिए
  • संदर्भ: Martin Fowler की Utility vs Strategic Dichotomy
• "boring technology" चुननी चाहिए
  • ऐसी solution पर बड़ा जोखिम नहीं लेना चाहिए जिससे team परिचित न हो या जिसकी community छोटी हो
  • ऐसी technology चुननी चाहिए जिसके साथ समस्या आने पर ऑनलाइन आसानी से समाधान मिल सके
  • Dan McKinley के boringtechnology.club में इस विचार को विस्तार से समझाने वाली talk देखी जा सकती है

स्टार्टअप में Platform Engineering

• Rebecca Murphey के Engineering Unblocked podcast में कही गई बात:
  • "किसी कंपनी का developer experience, चाहे उसे जानबूझकर design किया गया हो या नहीं, अपने आप में एक product है"
  • स्टार्टअप स्तर पर भी monitoring, deployment, error tracking, logs की जाँच, और feature flags toggle करने की आवश्यकता बनी रहती है
  • महत्वपूर्ण प्रश्न यह है: "क्या ये काम पीड़ादायक हैं?"
• Platform Engineering स्टार्टअप में एक part-time भूमिका है
  • शुरुआती चरण में integrated test environment की ज़रूरत हो सकती है, लेकिन बाद में यह priority list में नीचे जा सकता है
  • platform engineering की भूमिका केवल ज़रूरत होने पर निभाई जाती है
• लंबी अवधि के platform projects चलाने की गुंजाइश नहीं होती
  • इसके बजाय छोटे-छोटे कामों के माध्यम से मूल्यवान तत्वों को लागू करना चाहिए
  • बड़ी तस्वीर और vision को team के साथ साझा करना ज़रूरी है, साथ ही यह समझाना भी कि छोटे हिस्से आपस में कैसे जुड़ते हैं
• स्टार्टअप में platform work नई productivity और नए approaches का मार्ग खोलने की प्रक्रिया है
  • यह मौजूदा software से modern tools पर migration का काम नहीं, बल्कि अक्सर ऐसी चीज़ें बनाना होता है जो पहले थीं ही नहीं
  • क्या किया जा सकता है से अधिक महत्वपूर्ण है यह तय करना कि क्या किया जाना चाहिए
• ऐसे काम पर ध्यान देना चाहिए जो वर्तमान संगठनात्मक समस्याओं या निकट भविष्य की समस्याओं को हल करे
  • वास्तविक कार्य-अनुभव, engineers के साथ बातचीत, retrospective feedback, और SDLC (software development life cycle) metrics के विश्लेषण से आवश्यक काम की पहचान करनी चाहिए
  • कभी-कभी platform work को पीछे रखकर अन्य ज़रूरतों पर ध्यान देना बेहतर हो सकता है
  • लचीला दृष्टिकोण ही मुख्य है

स्टार्टअप में Staff Engineering

• Staff Engineer की भूमिका स्टार्टअप परिवेश के लिए उपयुक्त है
  • गहरी तकनीकी विशेषज्ञता, व्यापक प्रभाव की चाह, और business problems को हल करने के लिए जहाँ ज़रूरत हो वहाँ आगे बढ़ने का रवैया स्टार्टअप में अच्छी तरह फिट बैठता है
• बड़े संगठनों में एक कहावत है: "हमें पता है कि technical debt कहाँ दबी हुई है"
  • Staff Engineer ऐसे ज्ञान रखने वाले व्यक्ति को खोजता है, जानकारी को व्यवस्थित करता है, और आगे बढ़ने के लिए निर्णय निकालता है
  • स्टार्टअप में technical debt और समस्याएँ साफ़ दिखाई देती हैं
  • Staff Engineer इस अव्यवस्था को व्यवस्थित करके और लंबे समय में संगठन के लिए उपयोगी solutions बनाकर बड़ा प्रभाव डाल सकता है
• स्टार्टअप में Staff Engineer किसी एक archetype तक सीमित नहीं रह सकता
  • संगठन छोटा होने के कारण उसे hands-on execution सहित कई तरह की गतिविधियाँ करनी पड़ती हैं
  • architecture design, project leadership, और tactical work के अलावा सुधार के विचार स्वयं निकालकर उन्हें लागू भी करना होता है
  • लचीलापन और स्व-प्रेरित ज़िम्मेदारी स्टार्टअप के Staff+ engineer की अनिवार्य विशेषताएँ हैं
• Staff+ engineer की महत्वपूर्ण भूमिकाओं में से एक mentoring और sponsorship है
  • विशेष रूप से स्टार्टअप के junior talent को महत्वपूर्ण समर्थन और दिशा प्रदान की जाती है
  • Staff Engineer ऐसे समर्थन के माध्यम से team की growth को तेज़ करता है और संगठन की क्षमता को मजबूत बनाता है

[स्टार्टअप में आधुनिक Staff Engineering लागू करना]

स्टोरी 1 of 2 - "Improving DevEx by Removing a Merge Freeze"

समस्या की स्थिति

• मौजूदा QA process:
  • release से पहले 2-3 दिनों तक "merge freeze" लागू किया जाता था और QA टीम manual regression test करती थी
  • मिले हुए bugs को तुरंत fix करके main branch में merge किया जाता था
  • developer नए patch build करते थे, लेकिन merge request को release के बाद तक रोककर रखना पड़ता था
• कमियां:
  • manual regression test धीमे और अप्रत्याशित थे
  • merge में देरी के कारण merge conflict की आवृत्ति बढ़ जाती थी
  • developers की productivity और collaboration कम हो जाती थी

समाधान

• infra code को Monorepo में एकीकृत करना
  • Terraform project को application code वाले उसी repository में एकीकृत किया गया
  • इसे automated linting और dependency management tools से जोड़ा गया ताकि developers के लिए infra को संभालना आसान हो
• सभी environments को Terraform से manage करना
  • सिर्फ नए environments ही नहीं, बल्कि मौजूदा staging और production environments को भी Terraform से manage किया गया
  • एक ही infra definition पर अलग-अलग variables लागू करके environments के बीच consistency बनाए रखी गई
• CI/CD process को सरल बनाना
  • मौजूदा GitLab Auto DevOps template में बहुत अधिक customization होने से वह जटिल हो गया था
  • Auto DevOps हटाकर नई .gitlab-ci.yml file को स्पष्ट रूप से define किया गया
  • ज़्यादातर commands को Makefile में shift किया गया ताकि उन्हें manually भी चलाया जा सके
• Secrets management में सुधार
  • GitLab पर निर्भरता कम करने के लिए application secrets को Google Cloud Secrets Manager में move किया गया
  • deployment script को इस तरह बदला गया कि Kubernetes ConfigMap अपने-आप update हो सके
• scope से बाहर रखे गए काम
  • application monolith structure में Kubernetes पर चल रही थी
    • इसे बदलने का काम delay और risk बढ़ा सकता था, इसलिए इसे यथावत रखा गया
  • Terraform automation pipeline नहीं बनाई गई
    • infra changes अपेक्षाकृत कम होने के कारण manual process बनाए रखा गया
  • Kubernetes native secret access approach को भी फिलहाल टाल दिया गया

परिणाम और उपलब्धियां

• नया test environment deploy किया गया और QA टीम regression test स्वतंत्र रूप से कर सकी
• merge freeze हटने से developers main branch में बिना रुकावट changes merge कर सके
• release process सरल हुआ और पूरी team की speed में सुधार हुआ

लागू किए गए सिद्धांत

• Staff Engineering सिद्धांत
  • कई teams के साथ collaborate करते हुए project को lead किया
  • "Tech Lead" की भूमिका निभाते हुए project को completion तक पहुंचाया
  • CI/CD और infra improvements के ज़रिए team की समझ और accessibility बेहतर की
• Platform Engineering सिद्धांत
  • DevOps project को platform project तक विस्तारित किया
  • सभी infra को code के रूप में manage करके environments के बीच consistency सुनिश्चित की
  • व्यावहारिक trade-off के आधार पर project scope को समायोजित किया
• DevOps सिद्धांत
  • infra को code के रूप में manage करके cloud infra को consistently operate किया
  • release process में सुधार किया और नए tools के ज़रिए development speed बढ़ाई
  • RFC(Request For Comment) document format अपनाकर decision-making process को अधिक inclusive बनाया

निष्कर्ष

• QA टीम अब अधिक स्थिर environment में automated test चला सकती है
• developers merge freeze के बिना continuous development कर सके और collaboration मजबूत हुआ
• बेहतर tooling और process के माध्यम से organization की productivity में सुधार हुआ
• आगे preview environments बनाना या regression test automation जैसे अतिरिक्त काम करने की इच्छा है

स्टोरी 2 of 2 - "Iterating Towards a Productive Engineering Process"

समस्या की स्थिति

• मौजूदा process:
  • सभी team members एक ही board पर काम करते थे और हर दिन progress share करते थे
  • कई लोग अपनी बारी न होने पर ध्यान नहीं देते थे और "checkout" स्थिति में रहते थे
  • feature development की ownership बिखरी हुई थी, इसलिए अक्सर product manager को अंतिम जिम्मेदारी लेनी पड़ती थी
  • technical architecture की स्पष्ट समझ की भी कमी थी
• लक्ष्य:
  • बेहतर collaboration और software development process बनाने के लिए अलग-अलग experiments चलाना
• प्रयोग 1: अल्पकालिक feature teams(Short-lived Feature Teams)
  • उद्देश्य: engineers को feature development के पूरे lifecycle की ownership देना
  • तरीका:
    • हर feature के लिए एक leader तय किया गया, और backend, frontend, QA आदि से बनी team संगठित की गई
  • परिणाम:
    • team members की ownership बेहतर हुई, लेकिन हर कोई leader की भूमिका के लिए उपयुक्त या इच्छुक नहीं था
    • बाद में "स्थिर team model" में बदलकर "Squads" बनाई गईं, और हर team ने अपनी planning और retrospective खुद करना शुरू किया
• प्रयोग 2: Epic Kickoff Documents
  • उद्देश्य: requirements को स्पष्ट करना और project scope तथा approach पर team की सहमति बनाना
  • तरीका:
    • दिए गए template का उपयोग करके meeting में सभी team members ने document लिखा
  • परिणाम:
    • team communication बेहतर हुआ और project की शुरुआत से ही अधिक अच्छा collaboration होने लगा
    • team members ने इस meeting को समय का मूल्यवान उपयोग बताया
• प्रयोग 3: group code review(Group Code Review)
  • उद्देश्य: code review time कम करना, code discussion को सक्रिय करना, और engineers के बीच technical sharing बढ़ाना
  • तरीका:
    • सप्ताह में 2 बार Slack Huddle में 1 घंटे के code review sessions आयोजित किए गए
    • developer screen share करके PR समझाता था और participants feedback देते थे
  • परिणाम:
    • code review में लगने वाला समय काफी कम हुआ और Inbox 0 स्थिति बनाए रखी गई
    • code पर चर्चा के माध्यम से developers के बीच एक-दूसरे से सीखने और सम्मान देने की संस्कृति बनी
    • code review के अलावा pair programming के फायदे भी team तक पहुंचे

लागू किए गए सिद्धांत

• Staff Engineering सिद्धांत
  • engineering manager की अनुपस्थिति में process improvement को lead किया
  • continuous improvement की संस्कृति टीम में लाकर agile process के माध्यम से autonomous collaboration को मजबूत किया
  • team को जड़ हो चुकी process तोड़कर बेहतर तरीके खोजने में मदद की
• Platform Engineering सिद्धांत
  • सिर्फ tools ही नहीं, बल्कि process को भी platform का हिस्सा माना
  • inefficient process team productivity को प्रभावित करती है, इसलिए उसका सुधार महत्वपूर्ण है
  • waste को हटाने वाले process changes, tooling improvements जितना बड़ा प्रभाव डाल सकते हैं
• DevOps सिद्धांत
  • CALMS सिद्धांत: collaboration, automation, lean, measurement, sharing
    • lean process के माध्यम से waste हटाकर value को तेज़ी से deliver किया गया
  • agile process के ज़रिए team को लगातार सुधार करने के लिए प्रशिक्षित किया गया

निष्कर्ष

• team की process को प्रयोगात्मक रूप से सुधारते हुए productivity और collaboration में बड़ा सुधार हुआ
• कम लागत, उच्च प्रभाव वाले सुधारों से पूरी team का development experience बेहतर हुआ
• अपने process की आलोचनात्मक समीक्षा करके उसमें सुधार की संभावनाएं खोजने की ज़ोरदार सिफारिश की जाती है

[समापन]

• स्टार्टअप वातावरण में काम करते हुए विभिन्न समस्याओं को हल करने और solutions को साकार करने की प्रक्रिया में विशेषज्ञता और जुनून दोनों का पूरा उपयोग किया जा सकता है
• समय की सीमाएँ होने के कारण यह व्यावहारिक दृष्टिकोण विकसित करने का अच्छा अवसर होता है, और कंपनी के शुरुआती चरण में बड़ा प्रभाव डाला जा सकता है
• आधुनिक software engineering approaches को लागू करके कंपनी की सफलता की नींव रखी जा सकती है

• Staff Engineering और स्टार्टअप

  • Staff Engineer के लिए breadth और depth दोनों वाली experience की आवश्यकता होती है
  • स्टार्टअप Staff+ engineers को अपनी technical knowledge का विस्तार करने और नए क्षेत्रों को explore करने का अवसर देते हैं
    • उदाहरण: एक backend engineer, React या BigQuery जैसी technologies सीख सकता है

• Platform Engineering और स्टार्टअप

  • स्टार्टअप में Platform Engineering का स्वरूप उसके scale के अनुसार बदलता है
  • 1:1 communication के ज़रिए developers के pain points को समझा जा सकता है, और छोटे projects के माध्यम से developer experience (DevEx) बेहतर किया जा सकता है
  • तेज़ feedback loop बनाकर development process में सुधार करना चाहिए, और developers को भविष्य में अपनी समस्याएँ स्वयं हल करने में सक्षम बनाना चाहिए
  • software development lifecycle (SDLC) की बुनियादी ज़रूरतों को industry-standard tools और techniques से पूरा करना महत्वपूर्ण है
  • स्टार्टअप में Platform Engineering समर्पित भूमिका नहीं, बल्कि ज़रूरत के अनुसार अपनाया जाने वाला technical approach है
  • यह याद रखना चाहिए कि "किसी कंपनी का developer experience भी एक product है", और इसे design करने में समय देना चाहिए

• DevOps और स्टार्टअप

  • DevOps स्टार्टअप में भी बहुत महत्वपूर्ण भूमिका निभाता है
  • culture, process, और tools के माध्यम से ग्राहकों तक value को तेज़ी से पहुँचाना और बेहतर कार्य वातावरण बनाना इसका मूल है
  • DevOps के ज़रिए कंपनी की efficiency बढ़ाना और collaboration culture को स्थापित करना बेहद संतोषजनक काम है
  • स्टार्टअप में DevOps के प्रति जुनून रखने वाले engineers अपनी skills और experience के माध्यम से बड़ा योगदान दे सकते हैं
• स्टार्टअप का वातावरण नए challenges और सीखने के अवसरों से भरा होता है, और इसके माध्यम से engineers अधिक विकसित हो सकते हैं और सार्थक परिणाम ला सकते हैं

[jhj0517]

1. अगर कम्युनिकेशन ठीक से नहीं हो रहा हो, तो monorepo में बदलाव पर विचार करें
2. सभी टीमों को यह साझा करने के लिए समय देना चाहिए कि वे कौन-सी वैल्यूज़ को आगे बढ़ाना चाहती हैं (Epic Kickoff Documents)

[xguru]

DevOps पर एक शोकलेख
DevOps इंजीनियर से ज़्यादा कमाने वाले Platform Engineer
Staff Engineer क्या होता है?

[ragingwind]

लगता है कि इसने आगे चलकर startup में ज़रूरी engineering roles को अच्छी तरह परिभाषित किया है। पहले जो engineering बिना किसी स्पष्ट विभाजन के की जाती थी, उसे इसने अच्छे से व्यवस्थित किया है। इससे शायद लोग खुद भी अधिक ठोस रूप से समझ पाएंगे कि वे किस तरह की engineering की ज़िम्मेदारी लेते हैं और आगे किसमें बेहतर करना चाहते हैं। startup में भी इससे अधिक व्यवस्थित engineering culture बनाया जा सकेगा और ज़रूरी engineers को बेहतर तरीके से चुना जा सकेगा।