So You Want to Hire a Forward Deployed Engineer

Сооснователь и CEO Palantir Alex Karp как-то сделал наблюдение о том, почему французские рестораны так славятся своим качеством: официанты там — продолжение кухонной команды. Они понимают работу кухни не хуже поваров, поэтому могут порекомендовать пэйринг или индивидуальное блюдо, подстроенное под уникальный вкус гостя.

Именно это кулинарное вдохновение лежит в основе роли forward deployed engineer, придуманной в Palantir почти два десятилетия назад. FDE встраивается непосредственно в команду клиента, чтобы достроить «последнюю милю» продукта для работы в проде. Но в отличие от классического solutions consultant или sales engineer, FDE остаётся настоящим инженером, который пишет и отлаживает production-код. FDE в Palantir буквально проводили дни на площадке клиента (отсюда и «deployed» в названии) — в самых разных крупных организациях, от муниципальных госструктур до гигантов здравоохранения и операторов цепочек поставок.

Скептики годами списывали FDE как «приукрашенный консалтинг», уверенные, что настоящий софтверный бизнес не должен нуждаться в таком трудозатратном процессе внедрения. Но феноменальный успех Palantir в последние годы — рыночная капитализация компании превысила $300 млрд — вернул прожектор на роль, которую она впервые ввела.

Если сейчас зайти в раздел вакансий любого стартапа, скорее всего вы наткнётесь на объявление FDE. Количество ежемесячных вакансий на эту роль взлетело на 800% с января по сентябрь 2025 года.

FDE приобрёл новый смысл для ИИ-стартапов, целящихся в enterprise (даже OpenAI собирает собственный отряд). Основатели обращаются к модели FDE, чтобы развернуть высокотехнологичные ИИ-продукты в обвешанных бюрократией legacy-процессах: FDE может включиться и обойти препятствия, которые мешают adoption в таких компаниях, — от запутанных кодовых баз до compliance-барьеров.

Jake Stauch, сооснователь и CEO Serval (ИИ-платформы для IT), который сейчас строит FDE-команду для своего стартапа, говорит, что модель закрепляется в ИИ-стартапах, чтобы их enterprise-клиенты получали ценность от агентов. «Софтверные платформы стали настолько мощными, что их возможности больше не являются ограничивающим фактором для клиента, — говорит он. — ИИ открыл все эти long-tail возможности, поэтому теоретически он может сделать всё, что угодно. Но кто-то должен направить продукт в нужное русло».

Учитывая весь спрос на FDE со стороны стартапов, мы решили глубже разобраться, что на самом деле делает эту роль успешной. Как мы выяснили, FDE могут быть очень мощными при осознанном применении, но это далеко не ответ для каждой компании или каждого клиента, и нужно очень внимательно проектировать роль, чтобы получить ROI.

«Forward deployed engineering сейчас подаётся как панацея. Но всё гораздо сложнее», — говорит James Honsa, сооснователь компании Genera (агенты для развёртывания), который ранее построил и масштабировал в Ironclad аналог FDE-команды, называвшийся «legal engineering». «Есть моменты в жизненном цикле компании, когда это имеет смысл, и есть сегменты клиентов, где это уместно, но как универсальный инструмент для всего бизнеса это довольно грубо».

Поэтому мы поговорили с теми, кто успешно масштабировал FDE-команды, чтобы выяснить точные системы и стратегии, которые сработали: бизнес-особенности, оправдывающие столь крутые инвестиции; стратегии найма, которые приносят звёздных FDE; и скоуп, максимизирующий impact роли.

Помимо Honsa и Stauch, вот наш состав:

Shilpa Balaji, которая пришла в Palantir как FDE, затем возглавила рекрутинг FDE, а сейчас строит FDE-команду в Promise, платёжной платформе для госсектораFrank Bien и Lloyd Tabb, бывший CEO и сооснователь Looker соответственно, которые вместе построили и масштабировали прото-FDE командуTiffany Siu, Head of Talent в First Round и бывший рекрутер Palantir

Поехали.

Где forward deployed engineers создают ценность

Сегодня FDE часто путают с ролью имплементатора — но это уже отход от истоков Palantir, говорит выпускница Shilpa Balaji. «Глубоко понимать клиента и реализовывать для него продукт через имплементацию или конфигурацию важно, но это не forward deployed engineering. Модель FDE требует пространства для креативности и инноваций. Это про открытие нового в контексте клиента и децентрализацию разработки продукта», — говорит она.

Сооснователь Serval Jake Stauch согласен, что FDE — это гораздо больше, чем имплементационные лиды. «Я вижу FDE как полноценного члена команды разработки. Не нужно загонять их в имплементацию. Дайте им строить софт, потому что именно они весь день разговаривают с клиентами, — говорит он. — FDE реально делают продукт лучше и привлекательнее для нашего ICP, при этом снижая трения в процессе внедрения».

Задачей FDE в Palantir могла быть работа бок о бок с производственным клиентом для снижения числа бракованных изделий на конвейере или развёртывание софта для распределения помощи при стихийных бедствиях. В Serval, которая строит ИИ-ITSM, FDE отгрузили много реального продукта, вдохновлённого временем, проведённым на месте у enterprise-клиентов: они построили более 60 интеграций со сторонними приложениями, систему обратной связи для оценки работы агентов и SLA-систему внутри продукта.

Самые impactful кейсы использования FDE обычно делятся на следующие группы — как продуктовые, так и бизнесовые.

Дожать крупную сделку

Подключение FDE к процессу продаж может помочь закрыть VIP-контракты. Именно так делал Looker: давали потенциальным клиентам бесплатный триал и проводили мощную пресейл-имплементацию, используя их реальные данные в демо.

«Мы думали, что выбираем между продуктом и сервисом, но отказ от выбора открыл третий путь: продавать как продукт и forward-deploy во время бесплатного триала так, чтобы это ощущалось как кастомный сервис», — рассказывает сооснователь Lloyd Tabb. «Продавая продукт, мы использовали демо как шанс построить proof of concept, поэтому у нас не было выхолощенной питч-версии — мы всегда просили у клиента реальный датасет для работы. И если удавалось максимально вовлечь клиента в использование продукта во время триала, потом мы могли спокойно просить деньги».

Shilpa Balaji делится похожей историей из своих дней в Palantir. «У нас было три или четыре forward deployed engineer, работавших с клиентом из энергетического сектора, и они просто полностью вручную собрали что-то, чтобы выиграть бизнес — под конкретное проблемное пространство, создав что-то реально ценное, — говорит она. — И они совершенно не думали о том, какой там роадмап и есть ли согласование с центром. Задача — просто построить продукт и сгенерировать ценность».

Найти неочевидные, но жирные продуктовые возможности через погружение в работу клиента

«Deployed»-природа роли приводит к более глубоким инсайтам, которых сложно достичь за 30-минутный Zoom-звонок по customer discovery. Balaji говорит, что FDE в итоге должны быть креативными решателями задач в поле — теми, кто умеет мыслить без ограничений роадмапа.

«Жить на площадке клиента — ключевая часть работы FDE. Ты не просто проводишь user interview. Ты встраиваешься в их жизнь. Сегодня прототипируешь то, что услышал, а завтра показываешь результат», — говорит она.

Именно такое расширенное погружение приводит к самым интересным продуктовым кейсам. «Что действительно мощно в модели FDE — то, что они могут быть креативными. FDE изобретают что-то не через синтез с большим продуктом и не через перестановку приоритетов в роадмапе. Они настолько scrappy привязаны к клиенту и его проблеме, что даже не думают, что такое “продукт”, — говорит Balaji. — Некоторые из самых успешных FDE-историй за моё время в Palantir не имели ничего общего с основным продуктовым предложением».

Ценность модели forward deployed engineering в том, что инженеры встроены напрямую в работу клиента. И когда они видят то, чего не видят другие, они должны делать выводы, которых другие не делают.

— Shilpa Balaji, бывший руководитель найма FDE в Palantir

Риск здесь в том, что FDE могут штамповать кучу случайных фичей, которые не улучшают основной продукт. Поэтому у FDE должно быть чутьё на проблемы, которые в итоге могут пригодиться и другим клиентам. «Если у вашей forward deploying команды действительно сильное product sense, шансы велики, что почти всё, о чём попросит клиент, будет решать проблему, которая есть у многих других», — говорит Jake Stauch.

Масштабировать scrappy энергию CTO

Ещё одно преимущество, которое Stauch обнаружил, выстраивая FDE-команду, — оно воссоздаёт ранние дни, когда сооснователь в одиночку отгружал код для клиентов.

В Serval разница между FDE и обычным инженером невелика: FDE должны тратить около 20% времени на работу с клиентами и сфокусированы на построении продуктовых возможностей, а не на инфраструктуре, говорит Stauch.

«Если ваши forward deployed engineers — лучшие инженеры команды, вы воссоздаёте ту самую раннюю энергию сооснователя, когда CTO слышит фидбэк напрямую от клиента, тут же чинит и делает продукт лучше. FDE — это способ это масштабировать», — говорит Stauch.

Модель FDE работает гораздо быстрее традиционного цикла «фидбэк → продукт», потому что убирает «посредников». «В любой компании есть solutions engineers, customer success, account execs. Возможно, solutions engineer услышал хорошую идею и передал её product manager. Product manager поговорил с инженерным менеджером, и потом это попадает в спринт квартального плана, — говорит он. — Но между фразой клиента “я бы хотел, чтобы это работало вот так” и решением проблемы лежит огромный разрыв. Это может занять месяцы даже в отличной компании. Поэтому гораздо лучше, если инженер слышит этот фидбэк напрямую, возвращается за стол и строит».

FDE воссоздают то, что происходит в ранние дни стартапа, когда есть всего пара основателей, спрашивающих клиентов: «Чего вы хотите? Окей, мы построим». А потом возвращаются на следующий день и говорят: «Это решило вашу проблему? Что ещё нужно?»

— Jake Stauch, сооснователь и CEO Serval

Разобрать «гараж фичей»

Более плотный feedback-цикл, ведущий к росту скорости отгрузки, позволяет FDE строить менее приоритетные, но всё равно полезные фичи, которые иначе застряли бы в чистилище роадмапа.

До основания Serval Stauch был Product Lead в платформе физической безопасности Verkada. У команды продаж был Slack-канал под названием «Feature Garage», куда они скидывали запросы фичей от клиентов, которые в основном так и оставались без внимания. Но Stauch говорит, что с моделью FDE инженеры могут реагировать на такие запросы — не строя точно запрошенные фичи, а закрывая лежащую глубже потребность.

«Forward deployed играет огромную роль в продвижении бесспорных продуктовых возможностей. Никому не нужно проводить мозговой штурм или вставлять это в роадмап. Можно просто пойти и сделать», — говорит он.

Эти, казалось бы, мелкие продуктовые шероховатости накапливаются. «Гиперприоритизация — это ошибка, которую совершают по-настоящему хорошие продуктовые лидеры, — говорит Stauch. — Они никогда не трогают P2. Но P2 накапливаются, и если никто никогда не смотрит P2, у вас в итоге получится менее качественный продукт, даже если технически вы фокусировались на всём правильном. С моделью forward deployed P2 действительно начинают разбирать».

Пройдите этот диагностический тест перед тем, как нанимать forward deployed

Хотя эти преимущества заманят любого основателя, мечты об FDE могут оказаться ошибочными, если в бизнесе не хватает нескольких ключевых ингредиентов. «Когда сегодня люди стремятся построить FDE-команды, многое из того, что они на самом деле ищут — это просто более сильный сигнал от клиентов и более быстрая итерация. Но для этого не нужен целый флот FDE», — отмечает Shilpa Balaji.

Инвестиция в FDE-команду, особенно на самых ранних стадиях стартапа, — дорогая ставка, и может быстро сжечь много кэша, если математика не сходится.

Frank Bien получил задачу масштабировать scrappy модель продаж Looker, когда занял пост CEO. «Когда я пришёл, оставалось много неизвестных. Продавать ли за $500 в месяц или за $5 000? — рассказывал нам Bien. — Всё было в воздухе — и не было ни таблиц, ни презентаций. По моему ощущению, это было похоже на модель Marketo, то есть не пара сотен долларов в месяц. Мы должны были находиться где-то в районе $25 000 в год на клиента».

Подтверждение того, что отдача будет здоровой, дало Bien уверенность инвестировать в FDE-модель в ранние дни. «После расчётов мы увидели, что к моменту, когда у нас будет 2 000 клиентов, мы сможем делать $100 миллионов ARR и идти к IPO. Такова была модель с 2013 года», — говорит Bien.

«Вы должны знать свою модель назубок, чтобы делать такую ставку. Мы знали, что маржинальность затрат, которые мы вкачивали в пресейл-поддержку, имеет смысл, — говорит он. — Но если бы мы не были уверены, нужно нам 2 000 клиентов или 100 000, чтобы выйти на $100 миллионов run rate, это был бы невероятно рискованный шаг — мы вполне могли бы просто жечь деньги VC».

Если вы уверены в своей модели, вам не нужно беспокоиться, сможете ли вы прокормить все ресурсы, которые вкачиваете — можно просто посчитать и узнать.

— Frank Bien, бывший CEO Looker

Поэтому, прежде чем кинуть клич FDE, убедитесь, что в вашем бизнесе есть эти три черты.

1: Вы поймали (или охотитесь за) крупной рыбой

«Forward deployed engineering по определению — это upmarket-движение, — говорит James Honsa (бывший глава legal engineering в Ironclad). — Этим не стоит заниматься, если вы считаете, что конечная форма вашего продукта — это какой-то product-led growth freemium-fit».

Это не означает, что у вас не может быть клиентов с меньшими годовыми контрактами (ACV). Но верхняя часть вашей клиентской базы должна включать компании уровня Fortune 500 — именно туда должна вкладывать энергию forward deployed команда.

Honsa пришёл в Ironclad ещё до $1M ARR как первый специальный post-sales-найм. Он говорит, что ранняя команда Ironclad понимала: их лучший бизнес будет в юридических отделах огромных международных компаний — и для победы в этих контрактах потребуются специальные инженерные таланты. «Самая первая версия продукта Ironclad работала «из коробки». Но основатели знали, что вся «сочная», высокоценная юридическая работа потребует очень бесспоковых внедрений. Поэтому, чтобы зафиксировать эти enterprise-ACV, нам пришлось принять, что в продукте не может быть готовых стандартных блоков», — говорит он.

2: У вас нет жёсткого мнения о том, как клиенты должны использовать ваш продукт

Shilpa Balaji советует основателям задать такой вопрос, чтобы оценить потребность стартапа в FDE: Насколько у вас жёсткое мнение о том, каким должен быть ваш продукт в будущем?

Если у вас есть очень чёткое мнение о том, каким должен быть продукт, FDE может оказаться не лучшим выбором, потому что большая часть их ценности — в открытии новых продуктовых возможностей. «Если у вас есть сильное мнение или вы хотите его иметь, то когда вы говорите, что вам нужен FDE, на самом деле вы, вероятно, говорите, что вам нужно больше сигнала от клиентов или больше близости к ним для валидации гипотез. Это полезно, но это может сделать PM или инженер, умеющий говорить с клиентом», — говорит она.

Balaji объясняет, что на спектре «жёсткости продуктового видения» на одном краю находится Apple, а на другом — Palantir. Продукты Apple — эпитом «из коробки»: все более-менее пользуются iPhone одинаково. SaaS-бизнесы обычно тяготеют к этому же лагерю. Palantir же разрабатывает платформы, которые умеют видоизменяться под нужды очень разнородных задач и организаций.

Balaji говорит, что роадмап Palantir в ранние дни был шокирующе непроторённым. «На раннем этапе в Palantir мы редко говорили: “Вот таким должен быть продукт”. FDE помогали нам строить инкрементально всё более ценные продукты. Каждое наше нововведение мы выводили из конкретного use case и клиента, — говорит она. — Поэтому для более SaaS-ифицированного продукта, где у основателя сильное и непоколебимое видение того, каким должен быть продукт в будущем, FDE — не лучший вариант».

Думаю, главный урок, который индустрия вынесла из новой популярности FDE: «А, оказывается, нужно слушать клиентов!» Конечно, нужно — но FDE существуют для органического роста продукта.

— Shilpa Balaji, бывший руководитель найма FDE в Palantir

3: У вас нет однородного ICP

Мы здесь в The Review подробно описывали, как многие стартапы нашли product-market fit, фокусируясь на ультра-конкретном ICP. Но наличие детального списка критериев клиента на самом деле может сделать вас плохим кандидатом на FDE-команду, по крайней мере на раннем этапе.

«FDE имеют огромный смысл, когда ваш продукт можно развернуть на очень широком диапазоне use case. Palantir — экстремальная, канонична версия этого, но в Ironclad наша версия этой проблемы была в том, что мы могли продавать в любую индустрию мира с самых первых дней», — говорит James Honsa.

У ранних клиентов Ironclad было мало общего. «Среди наших первых 50 клиентов были публичные tech-компании, YC-стартапы, глобальные бьюти-бренды и профессиональные спортивные команды. Мы внедряли контрактные процессы для всех них, но потребности построить инфлюенсер-агрементный workflow на японском очень сильно отличались от продажи сезонных абонементов команды MLB», — говорит он.

Но единственная общая черта клиентских персон, которые оправдывают FDE, говорит Shilpa Balaji, — это технически сложные проблемы, которые нельзя решить готовыми «коробочными» продуктами. «FDE — это не просто sales engineers. Они должны заниматься действительно сложными проблемами, очень специфичными для клиента, проблемами, которые нужно решить, чтобы достичь результата, нужного и вам, и клиенту, — говорит она. — В Promise мы строим FDE-команду, потому что наша клиентская база — правительство США — гетерогенна. Каждый штат администрирует свои государственные программы по-своему, и клиентские и технические ландшафты сильно различаются. Поэтому нам нужно строить и учиться на краях».

Не запихивайте FDE в инженерную или post-sales роль

Tiffany Siu, Head of Talent в First Round, не раз начинала поиск с основателями, которые сначала говорили, что хотят FDE, а потом, при более глубоком разговоре, осознавали, что им на самом деле нужен либо чистый software engineer, либо post-sales роль — implementations consultant или customer success manager.

«Когда основатели нанимают FDE, они часто представляют человека «всё в одном», который умеет строить продукт, внедрять его, обучать клиентов, кастомизировать его и держать всех счастливыми. В масштабе это нереалистично, но это передаёт потребность в ком-то, кто на раннем этапе сможет соединить инженерное и клиентское», — говорит она.

Siu любит задавать эти вопросы, чтобы помочь основателям понять, нужно ли им нанимать именно FDE:

Что спровоцировало эту вакансию? Кто сейчас выполняет эту работу в вашей команде? Что произойдёт, если вы не наймёте этого человека? «Эти вопросы помогают основателям сформулировать реальный use case этой роли. На бумаге они иногда говорят: “Нам нужен человек, который будет делать это”, но это не сходится с тем, что реально вызвало необходимость найма», — говорит Siu.Как будет выглядеть день этого человека? Размышление о том, как вы выстроите расписание потенциального FDE, помогает понять, действительно ли это клиентоориентированный инженер, или просто лишние руки для GTM или операций. «Основателям бывает на удивление сложно подумать о расписании найма на гранулярном уровне. Иногда они говорят что-то расплывчатое вроде “я хочу, чтобы он работал с клиентами”, но более конкретный разбор недели бывает очень показательным», — говорит она.Как вы будете измерять успех этого человека? «Если этот человек справится или не справится — что он сделал бы? Мышление в числах и ключевых метриках помогает чётко понять, какая роль вам нужна — например, квота, user adoption и usage», — говорит она.

Она делится примером основателя, который сначала думал, что хочет FDE, но в итоге пришёл к implementations lead — человеку, сфокусированному на запуске продукта у клиентов. «По мере того как мы разбирали, чем этот человек будет заниматься день за днём, стало ясно, что им не нужен кто-то, кто будет строить или расширять продукт, написав код. Им нужен был тот, кто способен исполнять повторяемые внедрения и тесно работать с продажами — кто-то, кто надёжно запустит клиентов на существующем продукте», — говорит она.

Если основатель говорит: «Я хочу, чтобы этот forward deployed engineer закрыл X сделок или провёл X демо», — то ему, вероятно, нужен кто-то ближе к продажам, а не FDE.

— Tiffany Siu, Head of Talent в First Round

Как нанять правильного forward deployed engineer

Итак, вы убедились, что FDE действительно нужен вашему стартапу. Как найти лучшего человека на эту роль?

Необязательно сразу искать кого-то, кто уже работал FDE. «Сейчас существует много разных версий forward deployed engineers. FDE в Palantir может сильно отличаться от FDE в стартапе ранней стадии. Поэтому основателям не стоит оптимизировать только по тайтлу — стоит потратить время и понять, как роль реально устроена в той компании, и спрашивать кандидатов, как на самом деле выглядит их рабочий день», — говорит Siu.

В некоторых случаях тайтлы и pedigree могут даже быть анти-сигналом. У самых выдающихся FDE, с которыми работали наши эксперты, были общие пять качеств.

Ищите эти пять черт

Они не приходят с готовым плейбуком (и часто находятся в начале карьеры). В Palantir выпускники колледжей составляли основную массу FDE. «FDE — это не тот, кто приходит со своим плейбуком. Они не сильно занимаются pattern matching. Они ориентированы на результат, мыслят независимо и верят, что любая проблема, с которой они столкнутся, может быть решена, — говорит она. — Свежие выпускники приносят свежий взгляд. Люди раньше по карьере обычно более открыты к проблемам, которые они решают, и к тому, как их решать».

Меньший уровень seniority не был жёстким требованием, но в целом, чем более специализированный опыт был у кандидата в FDE, тем менее вероятно, что у него будет тот же уровень независимого мышления. «Если человек приходил излишне догматичным или зашоренным в своих подходах, я считала это красным флагом для FDE. Поэтому те, кто провёл больше 10 лет в компании уровня FAANG, например, попадали в no-fly zone», — говорит Balaji.

Они упорны (grit). Balaji говорит, что grit — пожалуй, главное качество лучших FDE, с которыми она работала в Palantir. Если говорить прямо, у них была «готовность есть боль». «Forward deployed engineering — это больно. Так много проблемных пространств, в которых работали FDE, были крайне сложными, поэтому этим людям действительно нужно верить, что они могут сделать невозможное», — говорит она.

James Honsa согласен и говорит, что лучшие FDE в Ironclad были «пахарями». «В компании гипер-роста просто очень много работы. В деплойментах эта работа была необходимой, но не стратегической, и это был постоянный вызов в управлении по мере роста клиентской базы», — говорит он.

Эта энергия «пробивать стены» — черта, общая с основателями. Jake Stauch говорит, что FDE часто служат мини-основателями внутри организации. «У FDE сильное product sense и реальный интерес к продажам. Им должен нравиться сам факт того, что они работают над закрытием сделки. Эти люди часто бывшие или будущие основатели», — говорит он.

Они проходят высокую техническую планку. «Engineer» — всё ещё ключевая часть тайтла. Honsa подчёркивает, что многие из тех, кто становился лучшими FDE в Ironclad, могли бы стать staff engineer в топовой tech-компании. «Роль техническая. В ранние дни Ironclad legal engineers мерджили код в прод и каждую неделю делали code review с нашим CTO», — говорит он.

Siu согласна, что Palantir в своей FDE-модели не пошёл на компромисс с техническими навыками. «Думаю, почему Palantir был так успешен с FDE в ранние дни — потому что им нужно было проходить те же интервью-петли и грани, что и software engineers. Они могли бы быть классическими инженерами, если бы захотели, но у них были и другие навыки, делавшие FDE-роль притягательной», — говорит она.

Они не перестают отгружать. «Лучшие FDE, с которыми я работала, были компульсивными строителями, — говорит Balaji. — Такой человек просто не может не создавать. Они продуктивны — будь то построение инструмента, релиз приложения или вклад в open-source проект, у них просто беспокойство строить».

Они глубоко любопытны к тому, как устроен бизнес. «FDE врождённо любопытны к бизнесу, — говорит Honsa. — Это человек, который получает энергию от глубокого погружения в юридические риски инфлюенсер-маркетинга и в то, как создать высокопропускной процесс, защищающий наших клиентов. Мы твёрдо верили, что можем апскилить людей с правильным drive».

Хотите ли вы быть в окопах с этим человеком? Вот планка, которую я держу для действительно исключительного forward deployed engineer.

— Shilpa Balaji, бывший руководитель найма FDE в Palantir

Проверяйте на сырое умение решать задачи (но не пропускайте coding-тест)

Shilpa Balaji говорит, что Palantir отошёл от классического coding-интервью big tech. Вместо этого Palantir строил FDE-интервью вокруг реальных технических задач, которые компания пыталась решить для своих клиентов.

«Есть стиль Google: интервью, coding-тест, интервью, coding-тест, повтор. Но многие наши вопросы в Palantir были выстроены вокруг очень высокоуровневого problem solving, — говорит она. — Поэтому FDE hiring manager говорил: “Вот над чем работает один из наших клиентов. Никто ещё не смог решить эту проблему. Как бы вы её решили?”»

Balaji приводит пример сценария на problem-solving, который Palantir показывал на интервью: «Мы объясняли кандидату, что такое инсайдерская торговля, и просили придумать решение: какие данные ему понадобятся, какие вопросы он задал бы клиенту, что он искал бы? Мы хотели оценить и его бизнес-мышление, и техническое мышление», — говорит она.

Honsa говорит, что Ironclad похожим образом выстраивал интервью для оценки problem-solving навыков. «Самой эффективной нашей интервью-тактикой было попросить людей рассказать о проблеме из их карьеры и научить нас, как они использовали технологии для её решения, — говорит он. — Это было намеренно открытым, но вызывало потрясающие ответы. Один из наших основополагающих legal engineers сделал презентацию, где показал фотографии физической «deal room» из многомиллионной сделки авиационного финансирования и того, как он распечатал тысячи страниц и индивидуально обклеил их стикерами, а затем показал Excel-макросы, которые он создал для автоматизации будущих закрытий».

Мы искали forward deployed engineers, которые получают энергию от очень открытого промпта. Потому что часто наши клиенты приходили к нам с очень открытыми промптами.

— James Honsa, бывший Head of Legal Engineering в Ironclad

Скоупинг роли

Как только вы начали нанимать первых FDE, опирайтесь на эти три тактики, чтобы выстроить роль с максимальным impact — и для самих FDE, и для бизнеса.

Резервируйте FDE для самых сложных проблем крупнейших клиентов.

Ironclad не отправлял legal engineers онбордить каждого клиента. James Honsa говорит, что команда со временем научилась резервировать FDE только для VIP. «В ранние дни мы оправдывали модель для каждого клиента. Но по мере зрелости мы фактически разделили нашу post-sales команду на legal engineers, которых резервировали для high-ACV клиентов, — говорит Honsa. — Думаю, команды сегодня делают ошибку, считая, что вы либо целиком FDE-компания, либо нет. Ironclad преуспел в том, что мог предложить широкий спектр опций под потребности клиента и систематизировать downmarket-внедрения, делая их более шаблонными».

Одним из наших главных уроков в Ironclad было понять, как «посыпать» FDE на правильных клиентов в нужный момент по мере роста.

— James Honsa, бывший Head of Legal Engineering в Ironclad

Jake Stauch говорит, что скоуп FDE в Serval эволюционировал похожим образом. «Сначала они деплоились ко всем клиентам. Теперь мы приоритизируем наших крупнейших клиентов. Для нас это компании с более чем 1 000 сотрудников, где более вероятно, что им понадобится строить кастомные возможности», — говорит он.

FDE делают свою лучшую работу, когда они на площадке клиента.

Когда Shilpa Balaji сама была FDE, она говорит, что часть её самой impactful работы происходила во время длительных командировок на площадку клиента. «Однажды я провела недели в маленьком немецком городке вместе с двумя коллегами. Мы выезжали на цех завода клиента. Нам пришлось принять не только список требований, прописанных клиентом в контракте, но и провести время в их повседневной жизни. То, что вы открываете на месте, будет очень сильно отличаться от того, что было продано в контракте», — говорит она.

James Honsa говорит, что FDE Ironclad тоже приняли образ жизни в командировках. «Один из моих любимых моментов — когда General Counsel из Fortune 100 ласково назвал нас «Рюкзаками», когда мы пришли в их офис», — шутит он.

Принимайте scope creep, но опасайтесь бросать человеческий труд на продуктовую проблему.

Принятие сервисной природы FDE-роли — ключевая часть её impact, при условии, что вы не позволяете FDE утопать в бездонных часах ради решения, которое не принесёт пользы будущим клиентам.

«В ранние дни Ironclad мы считали, что если у нас scope creep, значит у клиента больше проблем, которые мы можем решить, — говорит Honsa. — Главное, что мы сделали правильно: наша софтверная экономика выигрывала от scope creep. Поэтому мы рано начали ценообразовывать по workflows. У второго нашего клиента мы встретили нового юриста, который сказал: “Кстати, я веду этот master services agreement workflow. Может ли Ironclad помочь и с этим?” Мы говорили «да», а наша команда продаж разбиралась, как это монетизировать».

Плохая версия scope creep, говорит Honsa, — это проведение n-ной итерации workflow с ограниченным объёмом пользователей. «Если мы оказывались в кейсах, где бесконечно итерировались, и не было ясного пути к software upside, нам нужно было найти способ отколоть эту работу», — говорит он.

Но Honsa говорит, что по-настоящему упорный FDE примет scope creep ради решения сложной проблемы. Разбираться со скоупом — это проблема менеджера; великому FDE даже в голову не придёт переступать контрактные границы.

«У нас была команда, настолько ведомая решением клиентских проблем, что они даже не замечали. Иногда я говорил команде: “Боже мой, сколько часов вы потратили, оптимизируя эту штуку?” и мне приходилось созваниваться с клиентом и перебалансировать скоуп. Но это была хорошая проблема».