FDE: एआई-संचालित इंजीनियरिंग भूमिकाओं में नया सीमांत

पिछले एक महीने में, मुझे चार दोस्त मिले जो अपना करियर बदलने की योजना बना रहे थे—फ्रंटएंड डेवलपर, सॉल्यूशन आर्किटेक्ट, प्रोडक्ट मैनेजर और पारंपरिक एल्गोरिदम इंजीनियर—उनकी पृष्ठभूमि, उम्र और शहर अलग-अलग थे, लेकिन सभी ने एक ही अंग्रेजी संक्षिप्त रूप पूछा: क्या FDE [2] मेरे लिए योग्य है?

FDE, जिसका पूरा नाम Forward Deployed Engineer [2] है। यह दो साल पहले Palantir के भीतर एक आंतरिक शब्द था, लेकिन आज यह अचानक हेडहंटर्स की शुरुआती बात, भर्ती विज्ञप्तियों में आम नौकरी, और सोशल मीडिया पर "AI युग की सबसे मूल्यवान नौकरी" के उम्मीदवारों में से एक बन गया है। OpenAI ने 2026 के मई में सीधे इस नाम से Deployment Company [3] की स्थापना की, जिसमें प्रारंभिक निवेश 40 अरब डॉलर का था, और स्पष्ट रूप से कहा गया कि वे इंजीनियरों को ग्राहकों के स्थानीय कार्यस्थलों पर भेजेंगे, जहाँ वे ग्राहकों की कार्य प्रक्रिया में शामिल होंगे; Anthropic की Applied AI टीम भी चार समय क्षेत्रों में FDE की भर्ती कर रही है। यह मुद्दा, जो केवल एक साल से भी कम समय में, आंतरिक शब्द से स्पष्ट शब्द में बदल गया।

मेरे पिछले लेख, "सुपर इंडिविजुअल्स के लिए" [4], में "मनुष्य का इंजन" — जिज्ञासा, स्व-अध्ययन, स्व-प्रेरणा और हाथों से काम करने की क्षमता — के बारे में चर्चा की गई थी कि ये पूरे Closed-loop के भीतर कैसे जागृत होते हैं। लेकिन मनुष्य निलंबित नहीं होते; उन्हें एक विशिष्ट नौकरी के निर्देशांक प्रणाली द्वारा समर्थित होना चाहिए। यदि सुपर इंडिविजुअल AI युग के उत्पादन संबंधों का "कच्चा माल" है, तो FDE इस साल बाजार में उभरने वाली सबसे स्पष्ट "नौकरी की आकृति" है।

मेरे विचार में, FDE परामर्श वाले बॉक्स में नहीं है, और आउटसोर्सिंग वाले बॉक्स में भी नहीं है। यह सुपर इंडिविजुअल के बहुत करीब है—अंतर केवल यह है कि FDE, "मॉडल कंपनी × क्लाइंट" के बीच की खाई में संगठित सुपर इंडिविजुअल है।

क्या आप जानते हैं—Forward Deployed शब्द कहाँ से आया? यह मूल रूप से अमेरिकी सेना का शब्द Forward Deployed Forces था, जो विदेशों या आगे की रेखा पर तैनात, निकट से प्रतिक्रिया देने में सक्षम सैनिकों को संदर्भित करता था, जबकि पीछे की ओर स्थित सैनिकों को घरेलू बेस पर रखा जाता था। Palantir ने 2000 के अंत में इस शब्द को सॉफ्टवेयर उद्योग में लाया, जिसका अर्थ "इंजीनियरों को हेडक्वार्टर से भेजकर ग्राहक के स्थान पर रहने के लिए मजबूर करना" था, और आंतरिक टीमों को सैन्य अक्षरों के साथ Delta और Echo के नाम दिए गए। अब इसे OpenAI और Anthropic द्वारा पुनः संभाला जा रहा है—यह संयोग नहीं है—इंजीनियरों को आगे की रेखा पर भेजने की मूलभूत प्रक्रिया कभी नहीं बदली।

इस लेख में लेखक द्वारा हाल ही में उन चार दोस्तों द्वारा पूछे गए तीन विशिष्ट सवालों का जवाब दिया जा रहा है:

क्या FDE एक AI के बाह्य आवरण वाली परामर्श कंपनी है? इसकी पारंपरिक परामर्श से सीमा क्या है?

क्या FDE एक उन्नत सॉफ्टवेयर आउटसोर्सिंग है? इसका मेरे वर्तमान में किए जा रहे बाइफ़ैंक्टर कार्य से क्या अंतर है?

क्या मैं FDE के लिए उपयुक्त हूँ? इस पद के लिए कौन से प्रकार के लोग बढ़ जाएंगे और कौन से नष्ट हो जाएंगे?

लेखक का दृष्टिकोण सावधानी से आशावादी है: FDE वास्तव में विकसित हो रहा है, लेकिन यह सभी के लिए एक परिवर्तन का रास्ता नहीं है। इसे शोर मचाने के बजाय, इसे स्पष्ट करना अधिक महत्वपूर्ण है।

अगर केवल एक घटना के माध्यम से FDE के इस चक्र के पुनर्जागरण का समय निर्धारित किया जाना चाहिए, तो लेखक 11 मई, 2026 को चुनेगा—उस दिन OpenAI ने Deployment Company की स्थापना की [5], COO Brad Lightcap ने अपने पूर्व व्यावसायिक टीम से अलग होकर special projects के लिए समर्पित हो गए और सीधे Sam Altman को रिपोर्ट करने लगे, जिन्होंने इस मामले की पूरी जिम्मेदारी संभाली। उसी सप्ताह, OpenAI ने ब्रिटिश AI परामर्श कंपनी Tomoro का अधिग्रहण किया, जिससे 150 Forward Deployed Engineers और Deployment Specialists नए कंपनी में शामिल हो गए।

ध्यान देने योग्य बात यह है कि OpenAI की भर्ती पेज पर एक साथ दर्जनों FDE पद उपलब्ध हैं: सैन फ्रांसिस्को, न्यूयॉर्क, वाशिंगटन, और Life Sciences, Semiconductor, Gov जैसे उद्योग-आधारित ऊर्ध्वाधर दिशाओं के साथ, यहां तक कि FDE भर्ति अधिकारी [6] का पद भी खाली है। विश्लेषकों का अनुमान है कि यह टीम तीन साल में 2000–4000 लोगों तक विस्तारित हो जाएगी। यह एक अनुसंधान समूह का आकार नहीं है, यह एक नियमित सेना है।

एंथ्रोपिक की ओर से लगभग एक दर्पण जैसी कार्रवाई हो रही है। एप्लाइड एआई टीम के अंतर्गत फॉरवर्ड डिप्लॉयड इंजीनियर पद [7] बोस्टन, न्यूयॉर्क, सीएटल, सैन फ्रांसिस्को, वाशिंगटन और लंदन में छह स्थानों पर उपलब्ध है, जिसमें 25%–50% ग्राहक स्थल पर यात्रा की आवश्यकता है। हाल ही में एक बार-बार संदर्भित उदाहरण फिनटेक कंपनी FIS है—जिसने अपनी घोषणा में सीधे लिखा है कि "एंथ्रोपिक की एप्लाइड एआई टीम और फॉरवर्ड-डिप्लॉयड इंजीनियर FIS में समाहित हो चुके हैं, जहां वे फाइनेंशियल क्राइम्स एआई एजेंट का डिज़ाइन कर रहे हैं और FIS को ज्ञान स्थानांतरित कर रहे हैं, ताकि वह भविष्य में अधिक एजेंट्स को स्वतंत्र रूप से विस्तारित कर सके।"

इस वाक्य में FDE के काम की वास्तविक छवि छिपी हुई है। यह प्रारंभिक आर्किटेक्ट नहीं है, न ही SDR, और न ही ग्राहकों को प्रशिक्षण देने वाला एवांजेलिस्ट। यह मॉडल लेकर ग्राहक के कोडबेस में रहने वाला इंजीनियर है। ब्रैड लाइटकैप स्वयं और सीधे कहते हैं: "हमारे ग्राहक हमें बताते हैं कि उन्हें pilot से production तक पहुँचने की क्षमता की आवश्यकता है। Deployment Company हमारे इंजीनियरों को उनकी टीम में भेजता है और उन्हें प्रदान करने के लिए पर्याप्त संसाधन प्रदान करता है।"

इस बात को एक चित्र के रूप में दर्शाएं, तो तीनों पक्षों का संबंध बहुत स्पष्ट हो जाएगा:

इस चित्र में सबसे अधिक जानकारी वाली दो रेखाएँ FDE द्वारा दोनों दिशाओं में भेजे जा रहे प्रतिक्रिया हैं। ग्राहक की ओर, FDE मॉडल को SaaS के रूप में नहीं बेचता, बल्कि ग्राहक के डेटा, अधिकार, अनुपालन और आंतरिक प्रणाली को एक ऐसे पाइपलाइन में जोड़ता है जो मॉडल को चला सके; मॉडल कंपनी की ओर, FDE ग्राहक के वास्तविक समस्याओं और विफलता के नमूनों को product और research में लौटाता है, जिससे roadmap पर प्रभाव पड़ता है—एक बार-बार गलती करने वाला tool calling पैटर्न, SDK के अगले बिल्ट-इन अमूर्तीकरण में बदल सकता है।

इसीलिए FDE को इस चक्र में दो शीर्ष मॉडल कंपनियों द्वारा एक साथ पुनः शुरू किया गया, और इसके पीछे केवल “हमें भी Palantir की तरह कंसल्टिंग करनी है” जैसी सरल बात नहीं है। यह मॉडल कंपनियों का एक सिग्नल कलेक्शन डिवाइस है—सबसे घने क्लाइंट पीड़ा बिंदुओं को पकड़ने के लिए, अपने लोगों को सीधे मौजूद होना आवश्यक है; साझेदारों के माध्यम से प्राप्त आवश्यकताएं हमेशा एक स्तर दूर होती हैं। Anthropic एक मिश्रित पथ पर चल रहा है: एक ओर FDE को स्वयं संचालित करते हुए, दूसरी ओर कंसल्टिंग कंपनियों और PE विशालकायों के साथ संयुक्त रूप से डिप्लॉयमेंट नेटवर्क बना रहा है। एक स्वयं संचालित पर आधारित है, दूसरा परितंत्र पर, लेकिन दोनों का मूल समान है: मॉडल कंपनियाँ केवल API आपूर्तिकर्ता नहीं रहीं, वे अपने इंजीनियरों को सीधे क्लाइंट के उत्पाद में भेजने लगी हैं।

अगले दो सबसे आम प्रश्नों के उत्तर दिए जा रहे हैं—FDE और पारंपरिक परामर्श (मैकिन्से, एक्सेंटर जैसे) के बीच की सीमा क्या है? और क्या यह हमारे परिचित सॉफ्टवेयर आउटसोर्सिंग से एक ही बात है?

जब लोग पहली बार FDE के जॉब डिस्क्रिप्शन को सुनते हैं, तो उनकी पहली प्रतिक्रिया होती है: "यह तो नया मैकिन्से, एक्सेंचर नहीं है?"

मैं इस तरह की तुलना समझता हूँ। सूट पहनना, ग्राहक स्थल पर यात्रा करना, ग्राहक के मीटिंग रूम में बैठकर व्हाइटबोर्ड पर ड्रॉ करना, C-लेवल एक्जीक्यूटिव्स के साथ एलाइन करना—दृश्य के आधार पर, FDE और कंसल्टिंग कंसल्टेंट वास्तव में एक जैसे दिखते हैं। लेकिन जब आप इसे थोड़ा गहराई से देखते हैं, तो दोनों का कार्य संरचना पूरी तरह से अलग होती है। कंसल्टिंग प्रक्रिया की सीमाओं को बेचती है, जबकि FDE मॉडल की सीमाओं को बेचती है।

इन दोनों को एक टेबल में पार्श्वक्रम में रखें, तो अंतर तुरंत स्पष्ट हो जाएगा।

इस तालिका में सबसे अधिक ध्यान देने योग्य पंक्ति "संपत्ति का अवमूल्यन" है।

पारंपरिक परामर्श का सबसे लाभदायक तरीका संपत्ति का पुनःउपयोग है—एक बैंक के लिए बनाई गई योजना को थोड़ा संशोधित करके अगले ग्राहक को बेच देना; एक खुदरा क्षेत्र का डिजिटल प्लेबुक तीस ग्राहकों पर बार-बार लागू किया जा सकता है। यही पिछले तीस वर्षों में Accenture, Deloitte, McKinsey Digital के विकास का मूल आर्थिक मॉडल है।

FDE के पास ऐसा संपत्ति नहीं है। मॉडल क्षमताएँ तेजी से बदल रही हैं—आज के लिए ध्यान से डिज़ाइन किए गए प्रॉम्प्ट चेन की आवश्यकता होती है, लेकिन अगले संस्करण में शायद एक ही वाक्य से काम चल जाएगा। इस गति के सामने “विधि संचय” का परामर्श तेजी से मूल्यहीन हो जाएगा। इसलिए FDE को संपत्ति पुनःउपयोग मॉडल का उपयोग नहीं करना चाहिए, बल्कि प्रत्येक बंद चक्र को पुनः चलाना होगा—मॉडल की सीमाओं का पुनःमूल्यांकन करना, टूलस्टैक का पुनःचयन करना, और उत्पाद आकृति को पुनः जोड़ना। यह दिखने में कम कुशल है, लेकिन मॉडल की गति के साथ चलने का एकमात्र तरीका है।

क्या आप जानते हैं—प्रोडक्ट ओवरहैंग क्या है? लेखक ने पिछले लेख “सुपर इंडिविजुअल के लिए” [4] में इस शब्द की व्याख्या की है: मॉडल क्षमता मौजूदा प्रोडक्ट फॉर्म के ऊपर है, लेकिन इसे एक प्रोडक्ट में बदलने के लिए कोई प्रवेश बिंदु, अधिकार या संदर्भ नहीं है। FDE पद का मूल्य, मूल रूप से, ग्राहक के स्थिति में लटके हुए Overhang को एक वास्तविक, कार्यरत प्रोडक्ट में बदलना है। ग्राहक मॉडल API कॉल की कोटा नहीं, बल्कि “कोई ऐसा है जो इन Overhang को मेरे व्यवसाय में वास्तविक रूप से लागू कर सकता है” की क्षमता खरीदता है।

यह “प्रोजेक्ट स्ट्रक्चर” पंक्ति में अंतर को भी समझाता है। परामर्श प्रोजेक्ट की मानक संरचना SOW (Statement of Work) + WBS (Work Breakdown Structure) + चरणगत स्वीकृति है: अनुबंध में स्पष्ट रूप से लिखा जाता है कि क्या डिलीवर किया जाना है, कब डिलीवर किया जाना है, और किस मानदंड के आधार पर स्वीकृति दी जाएगी। यह संरचना इस परिकल्पना पर आधारित है कि लक्ष्य अनुबंध पर हस्ताक्षर करने से पहले पहले से ही स्पष्ट हो चुका है।

FDE के प्रोजेक्ट इस तरह काम नहीं करते। ग्राहक सबसे अधिक यही कहते हैं: "मुझे पता है कि AI मुझे कुछ करने में मदद कर सकता है, लेकिन मुझे नहीं पता कि क्या।" लक्ष्य स्वयं प्रोजेक्ट का हिस्सा है। इसलिए FDE SOW नहीं लेता, बल्कि mission लेता है—एक अपेक्षाकृत अस्पष्ट दिशा; फिर iteration के माध्यम से धीरे-धीरे दिशा को स्पष्ट करता है; और अंत में, किसी एक iteration में, जमा किए गए मॉडल की समझ को एक उत्पाद रूप में प्रकट करता है।

“डिलीवरेबल” लाइन को भी विस्तार से समझना चाहिए। FDE चले जाने के बाद, ग्राहक सिस्टम में एक कार्यरत कार्यक्षमता बच जाती है—शायद छोटी, शायद असुंदर, शायद कोई उपयोगकर्ता इंटरफ़ेस नहीं है, लेकिन यह हर दिन वास्तव में किसी द्वारा कॉल की जाती है, किसी द्वारा बदली जाती है, और किसी द्वारा आलोचित की जाती है। परामर्श का डिलीवरेबल PPT और परिवर्तन प्रबंधन रिपोर्ट होता है, भले ही प्रोजेक्ट में कोड लिखा गया हो या ERP कॉन्फ़िगर किया गया हो, अंत में ग्राहक के उच्च प्रबंधन के पास अभी भी एक विधि दस्तावेज़ ही रहता है।

“व्यापारिक लाभ” का पंक्ति सबसे सूक्ष्म है। FDE का व्यापारिक लाभ मॉडल क्षमता की सीमाओं के बारे में वास्तविक अनुभव है—आपने इस महीने कितने वास्तविक ग्राहक परिदृश्यों को चलाया है, आपको ही यह जानने का अनुभव है कि Claude 4.7 क्या कर सकता है और क्या Claude 5 का इंतजार करना होगा। यह अनुभव PPT में नहीं लिखा जा सकता और न ही ज्ञान भंडार में डाला जा सकता है; यह केवल पिछले 90 दिनों में काम करने वाले इंजीनियर्स के मस्तिष्क में ही विकसित होता है।

इसलिए अगली बार जब कोई कहे "FDE तो नया Accenture है", तो ऐसे जवाब दें: Accenture के इंजीनियर्स ग्राहकों की प्रक्रियाओं को पुनः डिज़ाइन करने जाते हैं, जबकि FDE मॉडल की सीमाओं को पुनः खोजने जाता है। पहले के संपत्ति दस साल तक स्थिर रह सकती है, जबकि दूसरे की संपत्ति 90 दिनों के बाद पुनः उगनी पड़ती है।

अगर "FDE नया एक्सेंटर है" पहला गलत अर्थ है, तो "FDE महंगा सॉफ्टवेयर आउटसोर्सिंग है" दूसरा है। यह अर्थ अधिक भ्रमित करने वाला है, क्योंकि बाहरी साक्ष्य बहुत मजबूत लगते हैं: FDE वास्तव में ग्राहक के स्थान पर कोड लिखता है, वास्तव में ग्राहक के व्यवसाय के अनुसार कार्यक्षमता को कस्टमाइज़ करता है, और वास्तव में ग्राहक द्वारा कार्य समय के दौरान कॉल किया जाता है। पहली नज़र में, यह आउटसोर्स्ड इंजीनियर से कोई अंतर नहीं लगता।

लेकिन फीडबैक लूप को देखते ही अंतर साफ़ दिख जाता है।

इस चित्र में सबसे महत्वपूर्ण अंतर यह नहीं है कि चित्र का ऊपरी हिस्सा कितना सरल है, बल्कि इसका निचला हिस्सा मॉडल कंपनी की ओर एक प्रतिक्रिया श्रृंखला जोड़ता है। यह श्रृंखला सजावट नहीं है, यह FDE पद के अस्तित्व का वास्तविक कारण है। इस अंतर को अलग-अलग करके देखें, तो कम से कम चार जोड़े की तुलना होती है।

जो कुछ जुड़ा है, वह अलग है। बाहरी दल SOW को जोड़ता है—एक ऐसी आवश्यकता सूची जो अनुबंध पर हस्ताक्षर करने से पहले ही स्पष्ट रूप से परिभाषित कर दी गई होती है: कौन से फ़ंक्शन बनाए जाएंगे, किस तकनीक स्टैक का उपयोग किया जाएगा, किस मानदंड के आधार पर स्वीकृति दी जाएगी, और अनुबंध का उल्लंघन होने पर क्या मुआवजा दिया जाएगा। FDE mission को जोड़ता है—ग्राहक स्वयं भी नहीं जानता कि वह क्या चाहता है, बस इतना जानता है कि "AI मुझे कुछ करने में मदद करना चाहिए।" SOW की पूर्वशर्त निश्चितता है, mission की पूर्वशर्त खोज है। दोनों पूरी तरह से अलग प्रोजेक्ट स्टार्टअप की मानसिकता हैं।

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

बिलिंग मॉडल अलग होता है। यह सबसे अनुमान के विपरीत बात है। एक मॉडल कंपनी FDE को क्लाइंट के स्थान पर भेजती है, और उसकी सबसे बड़ी चिंता केवल इस प्रोजेक्ट से कितना कंसल्टिंग फीस मिलेगी, यह नहीं है, बल्कि यह है: इस क्लाइंट द्वारा आगे कितने token खपते जाएंगे? क्या यह एक retention क्लाइंट बनेगा? क्या यह अधिक बिजनेस लाइन में विस्तार करेगा? FDE का वास्तविक KPI, प्रोजेक्ट हस्ताक्षर पत्र पर दिखने वाला नंबर नहीं, बल्कि मॉडल token की लंबी अवधि की खपत का वक्र है।

फीडबैक का गंतव्य अलग है। यह चार समूहों में सबसे गहरा समूह है। आउटसोर्स्ड प्रोजेक्ट्स में, क्लाइंट का फीडबैक केवल आउटसोर्सिंग कंपनी तक ही सीमित रहता है और उस कंपनी द्वारा भविष्य में दूसरों को बेचे जाने वाले उत्पादों पर कोई प्रभाव नहीं डालता। इसके विपरीत, FDE का फीडबैक मॉडल कंपनी के रोडमैप में वापस आता है—ग्राहक द्वारा वास्तविक परिदृश्यों में अनुभव किए गए हर समस्या, हर प्रॉम्प्ट विफलता, हर टूल कॉल बग, अगले संस्करण के ट्रेनिंग डेटा, अगले संस्करण के टूल डिज़ाइन और अगले संस्करण के प्रोडक्ट फीचर्स के लिए इनपुट बन जाते हैं। अर्थात, प्रत्येक FDE डिप्लॉय किए गए ग्राहक, मॉडल कंपनी के लिए एक प्राकृतिक design partner के रूप में कार्य करते हैं।

यही कारण है कि मॉडल कंपनियाँ FDE को उच्च वेतन देने के लिए तैयार हैं। वे केवल एक सेवा बेच रही हैं, बल्कि अपने ग्राहक स्थलों पर वास्तविक दुनिया के उत्पाद रूप के संकेत एकत्र कर रही हैं। ये संकेत खरीदे नहीं जा सकते, न ही पकड़े जा सकते, न ही प्रश्नावली सर्वेक्षण से निकाले जा सकते—ये केवल एक विशिष्ट इंजीनियर द्वारा, एक विशिष्ट ग्राहक के कार्य प्रवाह में, कुछ बार दीवारों से टकराने के बाद ही प्राप्त किए जा सकते हैं।

क्या आप जानते हैं—OpenAI और Anthropic के FDE कुल पैकेज कितना हो सकता है? Levels.fyi पर Anthropic के सॉफ्टवेयर इंजीनियर के उपलब्ध डेटा [8] के अनुसार, अनुभवी SDE का कुल पैकेज मीडियन पहले ही \$710K पर पहुँच चुका है। FDE पद का जोखिम अधिक है—यह मॉडल क्षमता, ग्राहक व्यवसाय, और उत्पाद रूप की अनिश्चितता सभी का सामना करता है, इसलिए उद्योग समीक्षा [9] में बताया गया है कि अग्रणी AI प्रयोगशालाओं में FDE के मध्यम से उच्च स्तर के कुल पैकेज आमतौर पर 350K - 550K के बीच होते हैं, जबकि Staff स्तर से ऊपर के पदों पर \$630K+ तक पहुँच सकते हैं। यह कीमत “बाहरी समय” के लिए नहीं, बल्कि “उत्पाद + ग्राहक + मॉडल” तीनों जोखिमों को संयुक्त रूप से संभालने वाले के लिए भुगतान किया जा रहा है। > 2006 की याद करें, जब मैंने अपना करियर शुरू किया, मैं किसी केंद्रीय सार्वजनिक क्षेत्र की कंपनी में काम कर रहा था, जहाँ हमारी संस्था डिजिटल परिवर्तन में लगी हुई थी; उस समय हमारे समूह ने एक्सेंचर के परामर्शदाताओं को स्थानीय रूप से भेजा, और हमें प्रतिदिन 3500 रुपये का परामर्श शुल्क देना पड़ता था, जो कई सालों तक जारी रहा, और मीडिया ने उन्हें “गोल्डन कॉलर” कहा। मैंने बाद में जर्मन SAP कंपनी में कदम रखा, SAP ने परामर्श क्षेत्र में एक नया नाम परिभाषित किया, और SAP परामर्शदाता “गोल्डन कॉलर” के प्रतीक बन गए। इसलिए, FDE का�ेतन कम से कम 24-36 महीनों तक बढ़ता ही रहेगा, और मांग स्थिर रूप से बढ़ती ही रहेगी।

आउटसोर्सिंग श्रम आर्बिट्रेज है, FDE फ्रंटलाइन सेंसर है। इन दोनों चीजों को भ्रमित करने से क्लाइंट को यह गलत धारणा हो सकती है कि वे FDE को SOW के माध्यम से भर्ती कर सकते हैं, और उम्मीदवार FDE के लिए आउटसोर्सिंग के दृष्टिकोण से काम कर सकते हैं। दोनों पक्ष जल्द ही दीवार से टकरा जाएंगे।

बहुत से लोग गलती से सोचते हैं कि FDE शब्द OpenAI द्वारा आविष्कृत है। वास्तव में ऐसा नहीं है। इसकी दो ऐतिहासिक जड़ें हैं, एक Palantir से और दूसरी 2023 के बाद की नवीन मॉडल कंपनियों से। इन दोनों जड़ों को एक साथ देखने से FDE पद के वास्तविक कार्य को अधिक स्पष्टता से समझा जा सकता है।

समयरेखा देखें।

पहली जड़ पालेंटिर है।

पालंटिर की स्थापना 2003 में पीटर थील, एलेक्स कार्प, जो लॉन्सडेल आदि द्वारा की गई थी, और इसके पहले ग्राहक अमेरिकी सूचना संगठन थे। कार्प के पास सीएस का पृष्ठभूमि नहीं था—वह फ्रैंकफर्ट में दार्शनिक यूर्गेन हैबरमास के साथ डॉक्टरेट कर रहे थे, और अमेरिका लौटने के बाद ही थील ने उन्हें सीईओ के रूप में शामिल किया। FDE नामक इस पद का जन्म ठीक इसी "असामान्य सीईओ + अत्यधिक गुप्त ग्राहक" के संयोजन से हुआ: 36Kr के समीक्षा [10] में स्पष्ट रूप से लिखा गया है कि Palantir को शुरुआत में सूचना संगठनों द्वारा कड़ी आलोचना का सामना करना पड़ा, क्योंकि इंजीनियरों को वास्तविक व्यावसायिक परिदृश्य प्राप्त नहीं हो पा रहे थे, और आवश्यकताओं के प्रत्येक स्तर पर परिवर्तन के कारण वे विकृत हो गईं। बाद में Palantir ने एक मुद्दा सुलझाया—अपने इंजीनियरों को सीधे ग्राहक के स्थल पर भेजना, जहाँ वे सूचना विश्लेषकों के साथ मिलकर काम करते। इस मॉडल को श्याम संकर ने प्रणालीगत ढंग से सुव्यवस्थित किया, जिससे FDE का प्रारंभिक रूप बना।

2009 तक, FDE व्यावसायिक क्षेत्र में विस्तारित हो गया। जेपी मॉर्गन ने Palantir के Metropolis प्लेटफॉर्म को लागू करते समय, 120 FDE आंतरिक खतरा निगरानी के लिए स्थानांतरित किए गए। इस समय से, FDE केवल "इंजीनियरों को बिजनेस साइट पर भेजना" नहीं रहा, बल्कि एक व्यवस्थित ग्राहक-एम्बेडेड दृष्टिकोण बन गया: Foundry / Gotham को ग्राहक के व्यावसायिक प्रवाह में वास्तविक रूप से एकीकृत किया जाने लगा, और केवल एक लाइसेंस देकर चले जाने की बजाय।

Palantir के FDE भर्ती में एक अनपेक्षित मानदंड है—CS की डिग्री की आवश्यकता नहीं है। यह बात “क्या आप जानते हैं?” में शामिल की जा सकती है।

क्या आप जानते हैं—Palantir FDE को CS की डिग्री की आवश्यकता नहीं है? SkillScouter द्वारा संकलित Palantir भर्ति मानदंड [11] और Palantir की आधिकारिक careers पेज [12] के अनुसार, Palantir स्पष्ट रूप से non-CS बैकग्राउंड के उम्मीदवारों का स्वागत करता है, और हाल के FDE भर्तियाँ मैकेनिकल इंजीनियरिंग, अर्थशास्त्र, दर्शन जैसे क्षेत्रों से आई हैं। इसके लिए वास्तविक रूप से महत्वपूर्ण दो बातें हैं: अपूर्ण जानकारी में कार्य करने की क्षमता, और C-लेवल के क्लाइंट्स के साथ सीधे बातचीत करने की क्षमता। CS डिग्री एक प्लस है, लेकिन प्रवेश पत्र नहीं। Karp स्वयं इस मानदंड के पहले उदाहरण हैं—एक दर्शन का छात्र, जिसने भौतिकी, गणित और दर्शन के छात्रों की एक टीम को नेतृत्व दिया।

दूसरी जड़ 2023 के बाद की नई पीढ़ी की मॉडल कंपनी है।

ChatGPT के 2022 के अंत में लॉन्च होने के बाद, OpenAI ने जल्द ही एक बात का एहसास किया: मॉडल API को डॉक्यूमेंटेशन पर लगाकर ग्राहकों को खुद कनेक्ट करने के लिए छोड़ देना, पूरी तरह से काम नहीं कर रहा था। ग्राहक इसका उपयोग नहीं करना नहीं चाहते थे, बल्कि वे नहीं जानते थे कि इसका उपयोग कैसे करें—उनके पास व्यावसायिक समस्याएं तो थीं, लेकिन उत्पाद का कोई रूप नहीं था। इसलिए OpenAI, Anthropic, Cohere, Scale, Glean, Sierra, Hebbia, Decagon जैसी कंपनियां, FDE की बड़े पैमाने पर भर्ती करना शुरू कर दी।

इस लहर में FDE Palantir के playbook को सीख रहा है—इंजीनियरों को ग्राहक स्थल पर भेजकर एक एंड-टू-एंड वर्कफ्लो को चलाया जाता है। लेकिन उत्पाद वाहक पूरी तरह से बदल चुका है: Palantir के समय में FDE डेटा एकीकरण और UI कस्टमाइजेशन करता था, जबकि नई पीढ़ी के FDE Prompt डिज़ाइन, Agent ऑर्केस्ट्रेशन, टूल कॉल और वर्कफ्लो एम्बेडिंग करते हैं।

Pragmatic Engineer के FDE के बारे में लिखे गए लेख [13] में इस नए संस्करण को "embedded with enterprises to make Claude solve real, specific, high-value problems" कहा गया है—यह व्यक्ति Palantir के समय के लगभग समान है, केवल "डेटा" को "मॉडल" से बदल दिया गया है।

When you look at these two roots together, you can see a clear set of commonalities and differences.

सामान्य बात: ग्राहक सॉफ्टवेयर नहीं, बल्कि "मेरी समस्या हल करने वाले इंजीनियर + उपकरणों का संयोजन" खरीद रहे हैं। पिछले तीस वर्षों के उद्योग सॉफ्टवेयर के इतिहास में यह असामान्य था। SAP, Oracle, Salesforce ने सॉफ्टवेयर को ही बेचा—इंजीनियर केवल "ग्राहक को इस सॉफ्टवेयर को सस्ता बनाने" के लिए सहायक संसाधन थे। Palantir इसके विपरीत है: उपकरण केवल "FDE को ग्राहक के पास समस्या हल करने में सक्षम बनाने" के लिए एक लीवर हैं। नई पीढ़ी की मॉडल कंपनियाँ इस उलटी संबंध को आगे बढ़ाती हैं—OpenAI GPT-4 की लाइसेंस नहीं, बल्कि "हमारे FDE GPT-4 का उपयोग करके आपके कस्टमर सपोर्ट को स्वचालित कर सकते हैं" बेचती हैं।

अंतर: पैलेंटिर काल ऑप्स एकीकरण पर केंद्रित है—मुख्य ध्यान डेटा एकीकरण, ओंटोलॉजी मॉडलिंग और अधिकार प्रबंधन पर है। नवीन पीढ़ी मॉडल क्षमताओं के कार्यान्वयन पर केंद्रित है—मुख्य ध्यान प्रॉम्प्ट डिज़ाइन, एजेंट ऑर्केस्ट्रेशन और रिटेंशन अनुकूलन पर है। पहला सिस्टम एकीकरणकर्ता का उन्नत संस्करण है, जबकि दूसरा उत्पाद इंजीनियर का विस्तारित संस्करण है।

एक अंतिम दिलचस्प तथ्य: पैलेंटिर के प्रारंभिक FDE, बाद में कई उद्यमी बन गए या सीधे नवीन मॉडल कंपनियों में शामिल हो गए। एंथ्रोपिक, ओपनएआई, सिएरा, हेबिया की प्रारंभिक टीमों में, ex-Palantir के नामों की लंबी सूची मिलती है। यह संयोग नहीं है—FDE पद स्वयं एक व्यक्ति को उत्पाद जोखिम, ग्राहक जोखिम और इंजीनियरिंग जोखिम सभी एक साथ संभालने के लिए मजबूर करता है, जो लगभग एक उद्यमी की प्रशिक्षण कक्षा के समान है। लेखक पैलेंटिर को एक अदृश्य उद्यमी प्रशिक्षण शिविर के रूप में देखना पसंद करता है: यह केवल इंजीनियर ही नहीं, बल्कि अपूर्ण जानकारी में किसी चीज को शून्य से एक तक आगे बढ़ाने का तरीका जानने वाले लोगों को प्रशिक्षित करता है। दो मूल, 2023 के बाद मिल गए।

दो मूलों का संगम मुख्य रूप से विदेशों में होता है। घरेलू रूप से, FDE शब्द का उपयोग हाल ही में शुरू हुआ है, लेकिन इसके संबंधित कार्य अचानक उभरे नहीं हैं। घरेलू FDE को समझने के लिए, पहले इसके दो स्थानीय पूर्वजों को समझें, और फिर इसके अमेरिकी संस्करण से तीन जलवायुगत अंतरों को समझें।

दो स्थानीय पूर्ववर्ती

पहला पूर्ववर्ती क्लाउड प्रदाता के समाधान आर्किटेक्ट था। अलीबाबा क्लाउड, टेंसेंट क्लाउड और हुआवेई क्लाउड ने पिछले दशक में ग्राहकों को आर्किटेक्चर समझाने, POC लिखने, माइग्रेशन योजनाएँ बनाने और लॉन्च तक के डिलीवरी में सहयोग करने के लिए एक पूरी समाधान आर्किटेक्ट (SA) टीम विकसित की है। हुआवेई के अंदर “डिलीवरी इंजीनियर” श्रेणी भी है, जो प्रोजेक्ट को कस्टमर के डेटासेंटर में लागू करने के लिए जिम्मेदार है। यह प्रणाली FDE कार्य का 80% पहले से ही कर रही है, लेकिन इसका ध्यान अभी भी प्रारंभिक बिक्री और डिप्लॉयमेंट पर है—एंड-टू-एंड उत्पाद अपडेट की जिम्मेदारी SA के हाथ में नहीं है, आवश्यकता में परिवर्तन होने पर परिवर्तन प्रक्रिया से गुजरना पड़ता है, मॉडल बदलने पर हेडक्वार्टर के समय सूची का इंतजार करना पड़ता है।

दूसरा पूर्ववर्ती AI स्टार्टअप में नए ढंग से विकसित अनुक्रम है। MiniMax, BOSS जॉब पोर्टल पर "AI प्रारंभिक समाधान विशेषज्ञ" के पद के लिए भर्ती कर रहा है, और मून एटीएम, ज़हीपु, टोन्गयी, हुनयुआन जैसी मॉडल कंपनियाँ भी इसी तरह के पदों को लिस्ट कर रही हैं। नाम में हल्का अंतर है, लेकिन JD की सामग्री अत्यधिक समान है: ग्राहक के स्थिति को समझना, डेमो बनाना, Prompt अनुकूलित करना, RAG चलाना, डिलीवरी समाधान लिखना, और ग्राहक के इंजीनियरिंग टीम के साथ लाइव करने तक संपर्क करना। यह पद समूह वास्तविक अर्थों में "भारतीय FDE" हैं।

Three water and soil differences

प्राइवेट डिप्लॉयमेंट + डेटा कॉम्प्लायंस, सिर्फ मॉडल कॉल के मॉडल को दबा देता है। भारतीय B2B ग्राहकों की डेटा आउटसाइड डोमेन न जाने, मॉडल वेट्स पर नियंत्रण रखने और ऑडिट के लिए ट्रेसेबिलिटी की आवश्यकता, संयुक्त राज्य अमेरिका के बाजार की तुलना में कहीं अधिक है। एक FDE प्रोजेक्ट में, सिर्फ API कॉल और प्रॉम्प्ट चलाने का काम सिर्फ 30% हो सकता है, शेष 70% मॉडल को कस्टमर के डेटा सेंटर में स्थानांतरित करने, ऑथेंटिकेशन को सेटअप करने, डेटा मिडलवेयर से जोड़ने और कॉम्प्लायंस रजिस्ट्रेशन पूरा करने पर खर्च होता है।

मॉडल क्षमताएँ अभी भी SOTA के पीछे भाग रही हैं, और इसका विकास स्थान केवल इंजीनियरिंग स्तर तक सीमित हो गया है। अमेरिका के OpenAI और Anthropic मॉडल क्षमताओं को ही ग्राहकों को प्रभावित करने के लिए उपयोग कर सकते हैं; जबकि भारतीय टीमों जैसे Tongyi, DouBao, Kimi, GLM, DeepSeek की क्षमताओं में अंतर कम है, इसलिए ग्राहकों का निर्णय Agent ऑर्केस्ट्रेशन, RAG रिट्रीवल क्वालिटी, टूल एकीकरण और Workflow डिज़ाइन जैसी इंजीनियरिंग क्षमताओं पर आधारित होता है। भारत में FDE की प्रतिस्पर्धा “हमारा मॉडल कितना शक्तिशाली है” नहीं, बल्कि “क्या मैं इस बिजनेस को वास्तव में सफलतापूर्वक चला सकता हूँ” पर है।

B एंड की भुगतान की इच्छा और मूल्य निर्धारण गति अमेरिका से अलग है। पैलेंटिर का "पहले FDE को तैनात करें, फिर उच्च मूल्य वाली सदस्यता शुल्क लें" का मॉडल सीधे नकल नहीं किया जा सकता। देशी ग्राहकों का बजट वार्षिक खरीदारी के साथ जुड़ा है, भुगतान परियोजना-आधारित होने की प्रवृत्ति है, और FDE का व्यावसायिक मॉडल अक्सर सदस्यता + निजीकरण लाइसेंसिंग + परियोजना डिलीवरी का मिश्रित रूप होता है।

एक अनूठी स्थिति: आंतरिक FDE

कई बड़ी कंपनियों के आंतरिक AI टीमें "आंतरिक ग्राहकों" को सेवा प्रदान करने के लिए FDE मॉडल का उपयोग शुरू कर रही हैं। अलीबाबा क्लाउड PAI ने टैobao में इंजीनियरों को भेजा है, और टेंसेंट हुनयुन ने वेचेट और विज्ञापन बिजनेस के साथ जुड़ने के लिए समान मैकेनिज्म अपनाया है। JD पर "उद्योग लागू इंजीनियर", "AI अनुप्रयोग इंजीनियर" और "स्मार्ट बिजनेस विशेषज्ञ" दिखाए गए हैं, जो मूल रूप से आंतरिक FDE हैं—जो मॉडल टीम की क्षमताओं को बिजनेस साइड तक एंड-टू-एंड ले जाते हैं। इससे बड़ी कंपनियों के लीडर्स को एक नया विचार मिलता है: कुछ आंतरिक FDE बिजनेस साइड पर स्थित हों, पहला demo चलाएं, और ROI के डेटा को बिजनेस के प्रबंधकों के हाथ में सौंपें, तो दस मीटिंग्स से अधिक प्रभावी ढंग से विभागीय दीवारें गायब हो सकती हैं।

पिछले लेख, “सुपर इंडिविजुअल्स के लिए” [4] में, मैंने सुपर इंडिविजुअल्स के पांच इंजनों के बारे में बताया था: उत्सुकता, खोज और नवीनता की भावना, स्व-अध्ययन क्षमता, स्व-प्रेरणा और हाथों से काम करने की क्षमता। ये पांच बातें FDE के लिए प्रवेश पत्र हैं, लेकिन सब कुछ नहीं। FDE पद के लिए पांचों इंजनों के अलावा, कुछ बहुत विशिष्ट अतिरिक्त विशेषताएँ होती हैं, और कुछ प्रकार के व्यक्तित्व स्पष्ट रूप से उपयुक्त नहीं हैं। मैंने कई उत्कृष्ट इंजीनियर्स को FDE में बदलने के बाद समस्याओं को देखा है, और समस्याएँ अक्सर क्षमता में नहीं, बल्कि व्यक्तित्व और कार्य प्राथमिकताओं में होती हैं।

FDE के लिए पाँच गुण

बिना किसी आपत्ति के बिक्री और संचार करें। FDE का दैनिक कार्य कोड लिखने में बंद दरवाजों के पीछे नहीं, बल्कि ग्राहकों के CTO, व्यापार प्रमुखों, खरीदारों, अनुपालन और IT टीमों के साथ सीधे संपर्क करने में होता है। एक आम गतिविधि: ग्राहक CTO demo के बीच में आपको रोक देता है, FDE की प्रतिक्रिया “मैं वापस जाकर एक नया संस्करण बना कर अगले सप्ताह आता हूँ” नहीं होनी चाहिए, बल्कि वह तुरंत IDE खोलकर Prompt बदलकर पुनः चलाकर दिखाता है। “ग्राहक मौजूद है, मैं बदल रहा हूँ” FDE की सामान्य स्थिति है।

अस्पष्टता का आनंद लें। FDE को स्पष्ट PRD नहीं, बल्कि एक वाक्य मिलता है: “हम AI का उपयोग करके कुछ करना चाहते हैं।” ग्राहक खुद भी नहीं जानता कि वह क्या चाहता है, इसलिए FDE को उसके साथ इस अस्पष्ट अपेक्षा को विशिष्ट आकार देना होता है। अगर आप केवल स्पष्ट आवश्यकताओं के साथ ही काम कर पाते हैं, तो FDE आपको हर दिन चिंतित करता रहेगा।

इंजीनियरिंग क्षमता मजबूत होनी चाहिए, लेकिन 10x की आवश्यकता नहीं है। FDE को आपको कंपनी का सबसे साफ़ कोड लिखने वाला या सबसे गहरा एल्गोरिथम बनाने वाला व्यक्ति नहीं चाहिए, बल्कि इसे एंड-टू-एंड काम करने वाला चाहिए: फ्रंटएंड एक क्लिक करने योग्य पेज बना सके, बैकएंड एक चलने वाली सेवा स्थापित कर सके, और मॉडल बिजनेस डेटा स्रोत से जुड़ सके। FDE की दुनिया में, "लगभग काफी है" एक कमी नहीं, बल्कि एक गुण है।

प्रतिक्रिया से बेहतर बनना पसंद करते हैं। FDE के काम में कई ऐसे क्षण होते हैं जहाँ ग्राहक द्वारा आपको आलोचना करके फिर से काम करने को कहा जाता है: आज का डेमो कल बिजनेस टीम द्वारा “यही मेरा मतलब नहीं था” कहकर खारिज कर दिया जाता है; पिछले हफ्ते समझाई गई योजना, इस हफ्ते ग्राहक के एक नए एचआई के आने पर फिर से करनी पड़ती है। FDE के लिए उपयुक्त व्यक्ति इस प्रतिक्रिया को ईंधन की तरह लेते हैं, पूरी प्रक्रिया की जिम्मेदारी संभालते हैं और “आवश्यकता स्पष्ट नहीं कही गई” का बहाना बनाकर दोष नहीं फेंकते।

मॉडल की सीमाओं के प्रति संवेदनशील हों। यह सबसे तकनीकी और सबसे अदृश्य नियम है। FDE को यह जानना चाहिए कि कौन से कार्य LLM के लिए उपयुक्त हैं और कौन से नहीं, और किस प्रकार का fallback अपनाया जाए—इस संवेदनशीलता को पढ़कर नहीं, बल्कि विफलता के मामलों से ही सीखा जा सकता है। विफलता के नमूनों के संचय से FDE को मॉडल की सीमाओं के प्रति मांसपेशियों की याददाश्त विकसित होती है: किस स्थिति में RAG का उपयोग करें, किस स्थिति में नियमों का पालन करें, और किस स्थिति में मानवीय fallback प्रवेश द्वार अनिवार्य है।

FDE के लिए अउपयुक्त चार प्रकार के लोग

कोड के पीछे छिपना चाहने वाले शुद्ध तकनीकी लोग। FDE लगभग 50% समय कोडिंग के बजाय ग्राहक बैठकों, आंतरिक समन्वय, उत्पाद चर्चाओं और अनुबंधों की प्रगति पर व्यतीत करता है। यदि आपकी खुशी लगातार चार घंटे तक किसी के बिना कोडिंग करने में है, तो FDE आपको लंबे समय तक मानसिक थकान में डाल देगा।

OKR के बिना काम नहीं करने वाले लोग। FDE के लक्ष्य आपके प्रदर्शन टेबल पर नहीं, बल्कि ग्राहक के पास होते हैं। कार्य की प्रगति ग्राहक के प्रोजेक्ट नोड्स, मॉडल की क्षमता में परिवर्तन और अपने स्केनरियो के प्रति आपके निर्णय द्वारा निर्धारित होती है। "पहले OKR होना चाहिए, तभी पता चलेगा कि क्या करना है" की आदत वाले लोग अपना आधार खो देंगे।

जो लोग "उन्नति" को "कार्य" से अधिक महत्व देते हैं। FDE के लिए बड़ी कंपनियों की उन्नति प्रणाली में कोई फायदा नहीं है—ग्राहक संतुष्टि, प्रोजेक्ट ऑर्डर, पुनः उपयोग दर जैसे सूचकांक, कोड की मात्रा या लॉन्च आवृत्ति की तुलना में रैंकिंग समीक्षा में कमजोर होते हैं। यदि आपके कार्य के प्रेरणा में उन्नति पहले स्थान पर है, तो FDE अच्छा विकल्प नहीं है।

व्यावसायिक संदर्भ से दूर रहने वाले। FDE को ग्राहक के P&L, ROI, खरीद प्रक्रिया, अनुपालन आवश्यकताओं को समझना होगा। यदि आप स्वभाव से पैसे, अनुबंध और व्यावसायिक तर्क की बात करने से घृणा करते हैं, तो FDE का कार्य आपको लगेगा कि आप अपनी तकनीकी आदर्शों को बेच रहे हैं।

स्व-जाँच सूची

FDE के एक वास्तविक कार्य स्थिति के लिए 7 प्रश्न। 5 से अधिक "हाँ" के उत्तर देने पर FDE को गंभीरता से विचार करें, 3 से कम के उत्तर देने पर सावधानी से निर्णय लें।

क्या आप अपना दिन का 50% समय कोड से हटाकर ग्राहक बैठकों, संदेशों और फोन कॉल्स पर लगाने के लिए तैयार हैं?

2. जब ग्राहक आपको बताता है "यह काम नहीं कर रहा है, मैं नहीं बता सकता कि क्यों", तो आपकी पहली प्रतिक्रिया जिज्ञासा होती है, या असहनशीलता?

3. कोई आपके लिए PRD नहीं लिख रहा है, क्या आप एक हफ्ते में Claude Code के साथ एक कस्टमर के लिए दिखाने योग्य प्रोटोटाइप चला सकते हैं?

4. एक ही डिलीवरी के लिए, ग्राहक ने आपसे 8 वर्जन बदलने को कहा, क्या आप अभी भी अपनी निर्णय क्षमता बनाए रख सकते हैं, और केवल मशीनी रूप से कार्य नहीं करते?

5. जब मॉडल गलत उत्तर देता है, तो आपकी पहली प्रतिक्रिया फॉलबैक डिज़ाइन करना है या मॉडल की आलोचना करना है?

6. क्या आप अनुबंध पर हस्ताक्षर करने, रिपोर्ट लिखने, ग्राहक स्वीकृति के लिए भाग लेने और कानूनी टीम के साथ अनुपालन शर्तों पर चर्चा करने के लिए तैयार हैं?

7. क्या आप त्वरित प्रोटोटाइप और त्वरित विफलता स्वीकार कर सकते हैं?

पाँच विशेषताएँ, चार प्रकार के विपरीत चित्र, सात प्रश्न, अंततः एक ही प्रश्न: क्या आप अपनी उत्पाद संवेदनशीलता, इंजीनियरिंग क्षमता और व्यावसायिक निर्णय को एक ही कार्य प्रवाह में एक साथ विकसित करने के लिए तैयार हैं?

पिछले लेख में मैंने "मानव इंजन" पर चर्चा की थी: जिज्ञासा, अन्वेषण की भावना, स्व-अध्ययन क्षमता, स्व-प्रेरणा और हाथों से काम करने की क्षमता—ये सभी बड़ी कंपनियों के अंदर कैसे पूर्ण बंद चक्र के रूप में प्रेरित होते हैं। इस लेख में मैं एक अलग बात पर चर्चा कर रहा हूँ—पद का रूप। FDE AI औद्योगिक क्रांति में पहला ऐसा नया पद है जिसका नाम है, वेतन बैंड है, भर्ती JD है, और ग्राहकों के भुगतान से सत्यापित है। यह "सुपर इंडिविजुअल" अवधारणा का समानार्थी नहीं है, बल्कि इस नवीकरण के दौरान पहला ऐसा सूचक है जो काल्पनिक से वास्तविक में स्थापित हुआ है।

FDE अंत नहीं है। लेखक का मानना है कि FDE केवल नए विभाजन में पहला नाम पाने वाला रूप है। आगे Forward Deployed PM, Forward Deployed Designer, Forward Deployed Researcher आदि आएंगे—जो सभी ग्राहक के संदर्भ के साथ घनिष्ठ रूप से जुड़े होंगे और अस्पष्ट क्षेत्र में उत्पाद को विकसित करने की आवश्यकता होगी, उन सभी को अपना “फॉरवर्ड डिप्लॉयड” संस्करण मिलेगा। पदों के नाम बदलेंगे, लेकिन नींव का तर्क समान होगा: मॉडल क्षमता आगे चलती है, उत्पाद रूप पीछे भागता है, और पद संरचना कार्य प्रवाह के साथ पुनः विभाजित होती है।

तीनों पाठकों के लिए एक-एक वाक्य छोड़ें।

टेक्निकल लोगों के लिए: FDE आपसे यह नहीं मांगता कि आप कंपनी में सबसे अच्छे कोडर हों, लेकिन यह आपसे यह मांगता है कि आप अपना आधा समय कोडिंग से ग्राहकों की ओर स्थानांतरित करने को तैयार हों। अगर आपका जवाब "हां" है, तो बाजार का खिड़की अभी खुली है, और देश की शीर्ष मॉडल कंपनियाँ, क्लाउड फर्म और बड़ी कंपनियों के आंतरिक AI टीमें भर्ती को तेज कर रही हैं। अगर आपका जवाब "नहीं" है, तो कोई बात नहीं, नए विभाजन में आपके लिए अन्य पद भी उभरेंगे।

एचआर और ओडी के लिए: "नाम और वास्तविकता में अंतर" के प्रति सावधान रहें। आपकी कंपनी में पहले से ही कुछ FDE काम कर रहे हो सकते हैं, लेकिन उनके पद विवरण में "समाधान विशेषज्ञ", "उद्योग आर्किटेक्ट", "AI अनुप्रयोग इंजीनियर" लिखा हुआ है। उन्हें पहचानें, पुनर्वर्गीकृत करें, और उन्हें उनके कार्य के अनुरूप एक विकास मार्ग प्रदान करें—यह शून्य से नए कर्मचारी भर्ती करने की तुलना में अधिक कुशल है।

प्रबंधकों के लिए: FDE मॉडल केवल बाहरी नहीं, बल्कि आंतरिक रूप से भी उपयोग किया जा सकता है। कंपनी के अंदर कुछ "आंतरिक FDE" रखें जो बिजनेस साइड पर बैठें और मॉडल टीम की क्षमताओं को बिजनेस प्रक्रियाओं में एंड-टू-एंड एम्बेड करें—यह एक नया AI विभाग बनाने और दस बार क्रॉस-टीम अलाइनमेंट मीटिंग्स करने की तुलना में कहीं अधिक कुशल हो सकता है। विभागीय दीवारें संगठनात्मक डिज़ाइन से नहीं, बल्कि एक कामकाजी डेमो से हटाई जाती हैं।

AI के युग में पेशेवर रूपांतरण शुरू हो चुका है, FDE इसका पहला संकेत है, जो हमें बताता है कि मॉडल क्षमताओं में परिवर्तन की गति इतनी तेज हो चुकी है कि नए पदों का उदय हो रहा है। लेखक आपके लिए एक विशिष्ट प्रश्न छोड़ना चाहता है—अगर तीन साल बाद आपकी कंपनी के संगठनात्मक संरचना आरेख में तीन नए पद जुड़ जाएँ, तो आपका अनुमान है कि वे कौन से होंगे? इस प्रश्न को स्पष्ट करना, इस लेख को पढ़ने से अधिक उपयोगी है।

👦🏻 लेखक: हेनरी (डीरफ्लो टीम) [1]