[Перевод] Каково положение отдела по взаимодействию с разработчиками (DevRel) в организационной структуре?
Пришло время переосмыслить «местоположение» отдела по взаимодействию с разработчиками (DevRel) в структуре организации.
Краткое изложение: Отдел по взаимодействию с разработчиками — не совсем инженерный, а также не полностью маркетинговый, и зачастую далек от сферы продаж. Итак, если ваша компания ищет подходящее место для своей только что созданной (или уже существующей) команды DevRel, то куда ее следует поместить?
Давайте в первую очередь рассмотрим некоторые из традиционных мест, где обычно размещают отдел по взаимодействию с разработчиками (DevRel).
Инженерный отдел
На первый взгляд, кажется, что самое подходящее место для команды по взаимодействию с разработчиками — это, безусловно, инженерный отдел. Ведь зачастую адвокаты разработчиков (Dev Advocates) сами из инженерного сообщества, большая часть деятельности из области DevRel так или иначе связана различными способами с кодом, и, к тому же, их целевая аудитория обычно трудится в инженерных отделах. Так что… Это должно быть правильным местом для них, верно?
К сожалению, хотя таким может быть один из приемлемых вариантов, он далеко не идеален. Суть успеха работы инженерной команды заключается в эффективной доставке результатов, причем в «больших масштабах». Эта установка часто распространяется и на команду по взаимодействию с разработчиками (DevRel), что направляет ее усилия для создания разнообразных материалов, таких как статьи в блоге, примеры кода и другие ресурсы. Проблема в том, что акцент на «масштабировании» (подразумевает расширение воздействия и охвата как можно большего числа людей или компонентов системы) приводит к ситуации, когда инженерное руководство концентрирует внимание на действиях, которые достигают наибольшего числа получателей, независимо от качества связи. Необходимо установить постоянный обмен информацией между DevRel и внешними разработчиками, в виде цикла, который поддерживает взаимодействие и сотрудничество в обоих направлениях. Этого нельзя добиться, если всякое общение ограничивается односторонним потоком информации, с минимальной или отсутствующей обратной связью. Только через установление эффективных, взаимных отношений команда DevRel сможет служить своей цели полноценного и продуктивного взаимодействия с разработчиками. Таким образом, при масштабировании может снижаться качество взаимодействия и глубина понимания.
«Но как же документация, примеры, учебные пособия и так далее?» Это все хорошие и нужные вещи, особенно если компания продвигает свой продукт или API (будь то основной товар на продажу или нет). Но подобные задачи могут быть взяты на себя специалистами по техническому контенту (Technical Content Creators), такими как технические писатели (Technical Writers), специализирующиеся на создании документации.
DevRel в отделе по маркетингу
Размещение команды по взаимодействию с разработчиками (DevRel) внутри отдела маркетинга — распространенная практика, особенно в компаниях, предлагающих инструменты/продукты/услуги для разработчиков. Логика в этом случае довольно проста: если компания хочет наладить контакт с разработчиками, чтобы убедить их купить/использовать «вещь» (инструмент/продукт/услугу), поместите команду в отдел маркетинга и позвольте им заниматься маркетинговыми действиями для привлечения внимания. Посещайте конференции, пишите блоги, но, что более важно, выходите на рынок и демонстрируйте «вещь», чтобы вызвать интерес разработчиков.
Однако по целому ряду причин располагать здесь команду не совсем оптимально.
Маркетинг часто представляет собой «однонаправленное» мероприятие, цель которого — создать осведомленность о продукте и привлечь внимание к «верху воронки» (подразумевая «воронку продаж» — эвфемизм для совокупности людей, которые проходят через процесс приобретения продукта). Однако «взаимоотношения» с разработчиками означает наличие отношений и сотрудничества с сообществом разработчиков, а не просто общение с ними.
На практике цели маркетинговой команды часто существенно отличаются от того, что требуется от команды DevRel. Например, метрики маркетинга сводятся к «просмотрам страниц», «посещениям» или «привлекательности сайта», и все они ориентированы на количество людей и время, проведенное на веб-сайте или стенде, чтобы получить больше информации. Глубина взаимодействия практически не измеряется, и еще меньше внимания уделяется обратной связи с сообществом разработчиков.
Важно также отметить, что линии коммуникации между маркетинговой командой и инженерами часто остаются весьма «дистантными». Если команда DevRel не в состоянии получить обратную связь от разработчиков за пределами организации и передать эту информацию внутри компании, то она теряет свою способность действительно «взаимодействовать» с разработчиками. Она рискует превратиться в команду, занимающуюся технологическим маркетингом (Technology Marketing) или маркетингом для разработчиков (Developer Marketing). Когда команда по взаимодействию с разработчиками (DevRel) становится слишком ориентированной на технологический маркетинг, она может потерять уникальные черты взаимоотношений с разработчиками. Типичные акценты технологического маркетинга включают в себя привлечение внимания к техническим характеристикам продукта, демонстрацию его возможностей и создание стратегий продвижения. Необходимо найти баланс между технологическим маркетингом и глубоким взаимодействием с разработчиками, чтобы поддерживать долгосрочные и взаимовыгодные отношения.
САЙДБАР: Чем больше расстояние между любыми двумя узлами в дереве организационной структуры, тем сложнее поддерживать регулярное общение. Я имею в виду следующее: если Алиса и Боб оба подотчетны Мэри, то их расстояние друг от друга равно 0; если же они оба не подчиняются никому, пока не дойдут до генерального директора на оргсхеме, то они, по существу, находятся на другом краю Земли друг от друга. Такое расстояние делает практически невозможным наладить постоянный диалог, потому что повседневная жизнь этих двух структур настолько сложна и многообразна, что создает множество организационных барьеров для общения. Попробуйте сами, если мне не верите — организуйте регулярную встречу один на один с кем-то из юридического отдела, производственного цеха или другого подразделения, которое находится от вас на большом удалении в оргсхеме, и посмотрите, как долго продлится ваш диалог.
Хотя команде DevRel имеет смысл постоянно общаться и согласовывать свою работу с командой маркетинга, DevRel должна быть достаточно независимой, чтобы не зависеть от «показателей верхней части воронки», и вместо этого нести ответственность за те действия, которые способствуют полноценному взаимодействию с разработчиками.
DevRel и отдел продаж
В некоторых организациях, особенно в тех, которые продают продукты/услуги разработчикам, возникает естественная тенденция поместить команду DevRel в отдел продаж, поскольку она связана с разработчиками, а целевая аудитория, покупающая продукт или услугу, — это разработчики, а участники DevRel тоже разработчики, так что… Вполне подходящее место, верно?
О господи, конечно, нет.
Начнем с того, что разработчики на протяжении многих лет испытывают патологическое недоверие, а то и откровенную неприязнь, ко всему, что так или иначе связано с продажами. Не будем скрывать, во многом это поведение, усвоенное от их предшественников (включая меня и мое поколение), что не совсем верно. (Наверное, это несправедливо, если честно). Отчасти такая неприязнь обусловлена низкопробной тактикой продаж, которой подверглось мое поколение. Я до сих пор помню тот день, когда появилась Java IDE от Symantec и их продавцы хвастались — без тени сомнения или колебаний — что их IDE обеспечит »400-% прирост производительности», если использовать ее вместо любых других конкурентов. Это была чистейшая выдумка, не имеющая под собой никакой реальной основы. Но это не первый и, наверное, не последний раз, когда рекламная кампания использовала слова вроде «продуктивность», «масштабируемость» или «экономия» в качестве конкретных причин для приобретения продукта. Продавцы заслужили дурную репутацию: они скажут или сделают все, что угодно, чтобы «заключить сделку», независимо от достоверности их обещаний.
Когда команда DevRel обращается к сообществу, чтобы наладить с ним контакт, она должна строить отношения на основе взаимного доверия: Я, как представитель DevRel, тоже разработчик, и прекрасно понимаю, о чем вы говорите, и хочу помочь вам стать лучше в своем деле. Теоретически продавцы должны исходить из аналогичной точки зрения и во многих других областях; именно поэтому мы видим рекламные ролики, в которых люди непосредственно на камеру рассказывают о продукте — предполагается, что вы сопереживаете им, поскольку они такие же, как вы, или хотите стать таковыми. При разрушении этого доверия общение полностью теряет смысл. Фактически, если это доверие разрушается слишком сильно, оно само становится препятствием для реализации продукта; в течение многих лет я советовал избегать Symantec IDE только по причине глубокого разочарования от их тактики продаж.
Во многих сценариях разработчик может участвовать в продажах в качестве вспомогательного персонажа на встрече с продавцом. Речь идет о сфере технических продаж (Technical Sales), и во многих случаях их используют для разъяснения деталей продукта и/или получения гарантий того, что продукт сделать в состоянии или нет, особенно если он технически сложен. В случае гармоничного взаимодействия тандема продавца и технического специалиста по продажам (TechSales) присутствие TechSales, поддержание «честного» разговора и откровенность в деталях способствуют созданию более глубокого чувства доверия между покупателем и продавцом и позволяют заключать выгодные сделки тогда, когда в противном случае они могли бы сорваться. Адвокаты разработчиков (Dev Advocates) могут временно принимать роль технического специалиста на таких встречах. Однако это не является основной частью их работы, и она никогда не должна быть чем-то большим, чем просто вспомогательная роль в процессе продаж.
Если рассматривать показатели, то продавцы часто руководствуются своей главной метрикой — комиссионными. И в том случае, когда ваша команда DevRel подпадает под данный критерий, они не будут заботиться об укреплении доверия в сообществе (и облегчении продаж), а будут стремиться к повышению своей собственной прибыли. Это начисто подрывает их способность выстраивать нормальные отношения и сводит всё к транзакционному мышлению, которое так глубоко проникло в организации продаж. И большинство таких связей, будь то профессиональные или личные, распадаются даже при малейшем напряжении, когда их полностью переводят на денежную основу.
DevRel внутри отдела по работе с персоналом
Верите вы в это или нет, но есть группа людей, которые считают, что команда DevRel должна располагаться в той же структуре, которая занимается рекрутингом. «Если DevRel выстраивает отношения с технологическими сообществами», — считают они, — «тогда имеет смысл рассматривать ее как дополнение к другому отделу, который обеспечивает кадрами компанию».
С одной стороны, в этом аргументе есть доля правды. Зачастую самой сильной командой по подбору персонала в компании является DevRel — они постоянно находятся в сообществе, говорят на одном языке с программистами, которых привлекает организация, и пользуются доверием коллег-разработчиков, которого рекрутерам (к сожалению) не достает в этой аудитории.
Такая реклама очень сильна! На конференции посетитель только что видел, как Dev Advocate выступил с потрясающим докладом, и подумал: «Вот он, настоящий крутой парень!». После чего, подойдя к стенду организации, выяснил, что они набирают сотрудников, и подумал: «Я хочу работать именно в этой компании, где такие крутые парни!». Есть много историй о том, как известных разработчиков программного обеспечения с открытым исходным кодом нанимали в одну из компаний FAANG (*акроним, составленный из первых букв названий крупнейших американских технологических компаний: Facebook, Amazon, Apple, Netflix и Google), после того как изначально разговор завязался на конференции с одним из Dev Advocates, который смог «провести» их к нужному менеджеру по найму или рекрутеру.
Кроме того, если команда DevRel следует своей концепции, она стремится наладить контакты не только с разработчиками за пределами компании, а также и внутри нее. В некоторых организациях команда DevRel берет на себя часть работы по взаимодействию с внутренними разработчиками, например, планирует и устраивает конференции или встречи в компании, а также выступает в качестве контактного лица по вопросам приобретения обучающих курсов для сотрудников фирмы. (В конце концов, Dev Advocates активно взаимодействуют с сообществом, общаются с теми, кто пишет книги и создает видеоконтент. Именно поэтому они наилучшим образом осведомлены о том, кто из этих людей является наилучшим выбором, в случае когда нам нужны «только лучшие» ресурсы для внутренних образовательных потребностей. А ведь мы, безусловно, стремимся к использованию только самого лучшего, верно?)
К сожалению, хотя оба эти аспекта важны для команды DevRel, мы по-прежнему сталкиваемся со многими из предыдущих аргументов: показатели службы управления персоналом (HR) часто совершенно «не соответствуют» тем, которые мы хотели бы видеть для DevRel. HR-команда слишком далека от инженерии, маркетинга или продаж, что мешает DevRel быть более эффективной в достижении других своих целей.
Что еще хуже, во многих компаниях HR-команда является статьей расходов, то есть предприятие стремится свести затраты на нее к минимуму. Деятельность DevRel требует бюджета — спонсорство конференций, участие в них, хостинг для блогов, и времени — на образцы, учебники, посты, видео и так далее. Эти аспекты критически важны для успешной работы команды DevRel, но они не вписываются в традиционные цели отдела кадров. С течением времени команда DevRel постепенно теряет свой «технический» характер, становясь всё более ориентированной на «организационные» вопросы, а ее участники превращаются в специалистов по обучению технологическим вопросам (Technology Trainers) или технических рекрутеров (Technical Recruiters).
DevRel в офисе технического директора
Компании, которым не удалось добиться должного успеха с командой DevRel в любом из трех вышеперечисленных мест, часто пребывают в некотором замешательстве — куда поместить специалистов, чьи задачи и деятельность не совпадают ни с инженерией, маркетингом или с продажами? Сколько еще отделов осталось?
Во многих случаях, особенно в более молодых компаниях (так называемых «стартапах», хотя большинство из них уже давно оставили в прошлом период своего становления), технический директор (CTO) проявляет личный интерес к созданию и утверждению команды DevRel. Технический директор курирует целый ряд вопросов, каждый из которых связан с «технологиями», поэтому представляется вполне логичным, что команда должна быть частью «отдела по реализации частных проектов» CTO, часто известного как «офис технического директора» (или OCTO). Это также может быть способом для компании активно вовлекать сотрудников в поиск новаторских решений или продуктов
И, по правде говоря, на первых порах команда неплохо справляется со своими обязанностями. У них есть прямая связь с инженерами через технического директора, и он может способствовать их вовлечению в мероприятия, обеспечивающие их близость к маркетингу и продажам; маркетинговые команды часто нуждаются в консультациях с техническим директором по продвижению технологических разработок компании, а отдел продаж часто обращается к CTO за технической поддержкой продаж, которая требуется во время сложных коммерческих операций. Они также могут тесно сотрудничать с отделом подбора персонала, чтобы содействовать успешному набору сотрудников.
Кажется, это идеальный вариант!
По иронии судьбы, та свобода и гибкость, которую OCTO предоставляет команде DevRel, в долгосрочной перспективе зачастую подрывает ее успех. Пока технический директор лично вовлечен в успех команды, она может добиться замечательного результата. Но без постоянной поддержки CTO она начинает терять темп и позиции, и в конечном итоге чахнет, потому что остальные сотрудники компании не знают, как в данном случае правильно наладить с ней сотрудничество на организационном уровне.
Каждый отдел внутри организации должен знать, как взаимодействовать с коллегами, и часто это достигается (несколько опосредованно) с помощью создания определенных процессов и метрик. Благодаря им отделы несут косвенную (а иногда и прямую) ответственность друг за друга: маркетинг нуждался в функциональной возможности, поэтому он использовал внутренний процесс, чтобы поместить ее в бэклог инженера, который затем связался с отделом продаж, желая узнать, как она была воспринята. Все это описывается и измеряется с помощью различных метрик, помогающих принимать решения. Когда команда DevRel является «специальным проектом» технического директора, эти процессы и метрики обычно замыкаются в интересах удовлетворения потребностей CTO. Она не интегрирована в общие процессы и метрики компании так, как это обычно бывает с другими подразделениями.
А затем, что неизбежно случается, когда технический директор больше не включает команду DevRel в свой «шорт-лист» личных проектов, или потому, что команда существует уже достаточно долго, и ей кажется, будто она должна выжить «сама по себе», либо по причине смены CTO, у нового генерального теперь в приоритете другие вещи, команда DevRel теряет своего куратора. Внезапно перед ней встает непростой выбор, где и как в дальнейшем ей следует интегрироваться в организационную структуру.
Что делать с DevRel… куда дальше?
Цели DevRel не совпадают с задачами инженерного отдела, а также не совсем подходят для маркетинга или продаж. Когда-то давно маркетинг и продажи были единым целым, пока не пришло осознание того, что у них разные роли. То же самое зачастую происходит и с командой по связям с общественностью (сейчас ее обычно называют «Communications» («Коммуникации») или «Comms»), которая имеет тесные контакты с маркетингом, продажами, а также с юридическим отделом и кадровой службой. Ранее юридическое подразделение находилось внутри операционного отдела. И так далее. Каждая организация высшего уровня в корпоративной иерархии должна (обладать возможностью) добиваться своих целей независимо от других. Лидер, стоящий во главе этой организации, в свою очередь может встречаться с коллегами для достижения этой цели.
Если цель команды DevRel не полностью совпадает с инженерными задачами, маркетингом или продажами, то где же ей место в организации? Вывод, который напрашивается, на самом деле неудивителен, если задуматься. Отдел по работе с разработчиками заслуживает того, чтобы стать самостоятельной организацией высшего уровня в компании.
Аналогично тому, как компании оценили преимущества наличия «директора по маркетингу» (Chief Marketing Officer, CMO), «директора по коммуникациям» и «директора по информационной безопасности» (Chief Information Security Officer, CISO), «директор по связям с разработчиками» (Chief Developer Relations Officer, CDRO), подчиненный непосредственно генеральному директору и обеспечивающий координацию и управление группой вышеуказанных руководителей CxO (Chief x Officer) в сфере культуры и искусства отношений с разработчиками, выглядит вполне логично. В качестве альтернативы, если название «CDRO» кажется несколько претенциозным, а в компании нет CMO или CISO, то, вероятно, уместнее назвать его «VP, Developer Relations» (вице-президент по связям с разработчиками). Подчиняясь непосредственно генеральному или техническому директору, он будет на одном уровне с вице-президентами по маркетингу, продажам и инженерным вопросам. (Кто кому подчиняется, зависит от организации, но обычно все вице-президенты собираются вместе, поэтому их статус не играет большой роли).
Это не означает, что команда по взаимодействию с разработчиками (DevRel) когда-либо будет такой же по размеру, как и другие отделы — трудно представить себе DevRel, состоящую из сотен, а тем более тысяч человек. Но то же самое можно сказать и о большинстве отделов в организации. Например, юридический отдел, как правило, не может включать в себя сотни человек, за исключением самых крупных компаний. PR (связи с общественностью) тоже может насчитывать дюжину человек, отвечающих за тысячи или десятки тысяч.
Нахождение команды DevRel на уровне, подчиняющемся непосредственно C-Suite (высшему руководству), означает, что теперь CDRO или вице-президент DevRel определяет высокоуровневые цели и метрики, соответствующие задачам команды, но в сочетании с общими для всей компании планами. Если компании необходимо провести большую маркетинговую акцию в связи с выпуском новой версии, DevRel может скорректировать цели, чтобы предоставить учебные материалы и образцы, а также работать напрямую с маркетингом, привлекая Dev Advocates на конференции и подкасты, для обсуждения нового релиза и возможностей. Он может выделить время для сотрудничества с отделом продаж, чтобы помочь продать новую версию. И так далее. Позволяя команде DevRel определять свои собственные цели и задачи — не говоря уже о том, чтобы отстаивать свой собственный бюджет и численность персонала вместе с этими командами — при непосредственном взаимодействии со своими коллегами из отделов разработки, продаж, маркетинга, управления персоналом, а также с генеральным и техническим директорами, команда DevRel утверждается на позиции командного игрока с четкой миссией и хорошо понятным набором мероприятий и критериев.
Каждой компании необходима команда DevRel, и нам давно пора понять, что сообщество разработчиков уже стало достаточно многочисленным, чтобы заслужить собственную организацию, призванную взаимодействовать и развиваться вместе с ним.
На открытом уроке 16 января мы подробнее рассмотрим отношения между деврелом, HR и разработчиком. В результате мы:
— Узнаем, какие команды DevRel может задействовать для реализации деврел активностей.
— Сможем оценить эффективность совместной работы.
— Овладеем инструментами проджект-менеджмента, которые смогут применять для слаженной и эффективной кросс-командной работы.
Записаться на открытый урок можно на странице курса «DevRel».
