Разработчики — как котята: выстраиваем DevRel-процессы самоотверженно и с заботой

В преддверии нового сезона DevRelConf #9 Шефред Тпрогер Маша Даровская побеседовала с Наталией Макаровой, консультантом компаний, стартапов, преподавателем и ментором.

Уже 24 сентября Наталия совместно с ведущим специалистом в области конфликтологии Андреем Кёнигом проведут воркшоп с разбором типичных и нестандартных конфликтов в работе DevRel-менеджеров, включая истории самих участников.

Мы же побеседовали о том, почему вообще возникают конфликты, как договориться или прийти к компромиссу, как уговорить разработчиков выступать и писать статьи и можно ли убедить тимлида поддерживать такую активность в команде.

— Наталия, расскажи пару слов о себе.

— В настоящий момент я консультирую компании по стратегии DevRel и специалистов по карьерным вопросам. Ещё преподаю на курсе OTUS и помогаю стартапам, чьи продукты ориентированы на разработчиков. Когда узнала про новый сезон конференции Онтико, предложила тему, и программный комитет принял мой воркшоп в программу.

— Расскажи, о чём будет твой доклад. Что вообще ждёшь от конференции?

— У меня противоречивая тема. Многие не любят говорить про конфликты или стараются считать себя неконфликтными людьми. Я к ним тоже отношусь. Но наша работа связана с взаимодействием с очень большим числом людей, в том числе из смежных подразделений. Хочешь ты или нет, конфликтные ситуации неизбежны. И многие страдают из-за этого. Но мало кто знает, что на самом деле далеко не каждая критическая ситуация конфликт. А ещё меньше людей знает, что на самом деле конфликты могут быть очень полезны.

Наш воркшоп будет именно о том, какие конфликты бывают в работе со смежными подразделениями. Мы разберём типичные кейсы и те ситуации, что предложат участники. Выясним, какие бывают причины конфликтов и как с ними справиться. Мы дадим полезные алгоритмы, как разговаривать со смежниками, чтобы работать эффективно.

— То есть речь идёт именно о конфликтах со смежными подразделениями в нескольких компаниях?

— Не совсем так. Например, DevRel-менеджер часто выступает в роли проектного менеджера по коммуникациям. Для организации любого проекта или мероприятия ему приходится взаимодействовать с большим числом смежных подразделений. Это могут быть разработчики, тимлиды, дизайнеры, юристы, финансисты, hr-ры, маркетологи — в зависимости от структуры компании.

— И именно на стыке этих взаимодействий возникают трудности?

— Да. Здесь могут быть самые разные конфликты; рабочие, но сложные ситуации — от несовершенства в системе до личностного недопонимания: кто-то что-то не успел, кто-то кого-то неправильно понял. При этом очень часто мы сами становимся не исполнителями, а менеджерами, и отвечаем за процессы. И очень часто — за такие, на которые напрямую повлиять сложно. Поэтому конфликты в этой работе неизбежны.

— Приведешь примеры наиболее типичных конфликтов?

— Например, спор с PR, чей Хабр :)

Это один из главных инструментов DevRel. Пиар-служба тоже понимает, что это важный канал коммуникации, и считает, что он должен быть под их контролем. Но у них есть своё видение — исходят из логики массовых коммуникаций, работы с журналистами, внешнего имиджа компании. А мы в DevRel-направлении настаиваем, что для аудитории разработчиков важно быть максимально открытыми. Надо публиковать не только статьи, которые соберут десятки тысяч просмотров, но и узко-специализированные полезные профессиональные материалы от наших коллег. Важно говорить не только о позитивных сторонах, но и прорабатывать негативные стереотипы или признавать ошибки. Мы этого не боимся, а вот PR боится. Именно на этой границе часто возникает конфликт.

Конфликты случаются и с дизайнерами, и с маркетингом, и с разработкой. Взаимодействие с разными подразделениями часто несёт риск недопонимания — и это нормальная часть работы. Например, у нас был интересный кейс с маркетингом, который мы тоже разберем на воркшопе. Для работы с сообществом разработчиков нам иногда нужен нестандартный мерч. Но у маркетинга есть строгий брендбук: там прописано, что можно и что нельзя. Например, на логотипе компании нельзя сидеть, лежать и так далее.

Предположим, мы строим сообщество или сотрудничаем с независимым сообществом. Хотим укрепить идентичность, приверженность комьюнити к бренду, ценностям, общим элементам культуры; способствовать самовыражению; повышать вовлеченность участников. Мы обратили внимание на то, что в сообществе родился и хорошо разлетелся мем про «свод код ближе к телу» и пожелание сделать «трусы с символикой сообщества». Да, культура сообществ может быть очень «разной». Но маркетинг это категорически не пропускает, потому что для них это нарушение правил бренда. В итоге такие ситуации становятся источником конфликта: мы хотим быть ближе к сообществу, а маркетинг стоит на страже имиджа.

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

— А бывают ли подобные ситуации и с другими подразделениями?

— Конечно. Например, наша работа предполагает коммуникацию между разработчиками компании и внешним сообществом. Мы готовим специалистов к выступлениям, помогаем им писать статьи, участвовать в профильных активностях. Но и тут может возникнуть сопротивление. Представьте: сверху приходит задача — «пусть разработчики выступают». А тимлид отвечает: «Я не хочу, чтобы они выступали. Это отвлекает их от основной работы — написания кода». В результате появляется конфликт интересов: мы настаиваем на публичной активности, а руководитель команды считает её лишней нагрузкой.

Наша задача — мотивировать и поддерживать разработчиков, которые сами хотят писать статьи. Но бывает, что тимлид против. Ситуация может оказаться и более острой, когда тимлид чувствует угрозу бизнес-процессу, где конфликт заложен системой KPI, когда у тимлидов и DevRel-менеджера совершенно разные и взаимоисключающие цели. Появляется угроза авторитету, если руководителю кажется, что его сотрудник станет “звездой” и “подсидит его” или уйдет. Или есть уже недоверие к работе DevRel, так как в прошлый раз не было быстрого результата и пр.

В таких ситуациях нам важно не доводить до эскалации, а найти компромисс, чтобы и сотрудники могли развиваться, и процесс в команде оставался стабильным.

— А как вообще объяснять разработчикам и их лидам, что оно того стоит — выступать, писать статьи? Как аргументировать, на какой профит делать акцент?

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

В таком случае важно правильно описать задачу и объяснить, зачем всё это делается. Мы можем исходить из того, что это пиар компании. А дальше включаются разные мотивационные «ключи». Например, если руководителю нужно нанимать людей, то наши аргументы к его мотивации: публичные выступления команды помогают привлечь кандидатов и сделать задачи команды более заметными. Если же у лида найм не стоит на повестке, ищем другие аргументы. Главное — подобрать тот мотив, который для человека будет значимым.

— А какая мотивация выступать или писать статьи может быть у разработчиков?

— Можно сказать: «слушай, во-первых, это помогает структурировать знания. Во-вторых, это вклад в личный бренд — и внутри компании, и во внешнем профессиональном сообществе». Если в команде уже есть люди с таким опытом, они понимают ценность и соглашаются быстрее. Для новичков это шанс проявить себя и получить поддержку от команды.

— Но ведь многим сложно начать, особенно если это первый опыт.

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

— А что делать, если разработчик вроде бы не против написать статью или подготовить доклад, но сам не знает, о чём?

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

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

— У тебя есть какой то пайплайн, как готовить спикера, который ещё не выступал на конференции?

— Если человек хочет выступить, но никогда этого не делал, я всегда стараюсь предложить разработчику разные варианты, как безопасно подготовиться. Разработчик в этом смысле похож на котёнка, которого выпускают в большой мир: ему интересно, но основная проблема — это страх. Если он почувствует себя в безопасности, поверит, что ему помогут, он с радостью согласится попробовать.

Здесь важно определить, чего именно он боится. Мы можем вместе посмотреть доклады прошлых лет, чтобы появились идеи. Обсудить с его командой, накидать возможные темы. У меня часто есть контакт с программными комитетами конференций — я могу уточнить у них, интересны ли такие темы, стоит ли их подавать. Это снимает лишнюю тревогу.

Мы объясняем: будет несколько прогонов, будет шаблон презентации и помощь дизайнеров. Если есть ресурсы в компании, то для спикеров проводятся тренинги по публичным выступлениям и подготовке презентаций. Никто не кидает человека сразу на большую сцену. Можно начать с внутреннего доклада, небольшой встречи или даже модерации панели. Постепенное вхождение даёт уверенность и делает процесс менее пугающим.

— А если вернуться к конфликтам: часто ведь руководство не хочет отпускать людей на конференции. Это же командировка, выпадают несколько дней, плюс время на подготовку. Как с этим быть?

— Здесь опять же важен процесс и работа с руководителями. Они должны понимать, что участие в конференциях — это элемент мотивации. Для кого-то важно просто поехать и послушать, для других — выступить и прокачать личный бренд. И если этому мешать, то есть риск, что человек уйдёт в другую команду или даже в другую компанию, где ему дадут такую возможность.

Сначала руководители могут сопротивляться, но постепенно меняют мнение. Когда они видят, что коллеги разрешают выступления, их сотрудники становятся более мотивированными и довольными, а сами команды — более заметными и привлекательными, то понимают, что это работает на результат. Тогда у CTO или команды постепенно начинает меняться мышление в эту сторону. Это не всегда происходит быстро — иногда требуется время, но результат заметен.

— А если посмотреть шире — какие компании более открыты к таким практикам, а какие менее? Есть разница между стартапами и крупными корпорациями?

— Зависит от ситуации. Если это, предположим, небольшая современная компания, которой нужно нанимать разработчиков, они понимают важность публичности и готовятся к этому. Или я сейчас работаю со стартапом, который делает инструменты для разработчиков. Там просто невозможно обойтись без DevRel, где важны и комьюнити, и выступления, и технические статьи — все прекрасно это понимают и идут в этом направлении.

С крупными компаниями, особенно из реального сектора, которые пришли к цифровой трансформации относительно недавно, ситуация сложнее. Некоторым компаниям может потребоваться несколько лет, чтобы наладить процесс. Сначала придется преодолевать сопротивление со стороны служб безопасности и PR, которые категорически не готовы пускать простых разработчиков к публичным коммуникациям. Но постепенно накапливается пул собственных успешных кейсов, приходит понимание, что пользы больше чем опасности, присматриваются к успешным референсам с рынка и конкурентов и … закрытая вчера корпорация приносит 10-15 докладов на конференцию для разработчиков.

Даже компании тяжёлой промышленности начинают понимать, что если они будут закрытыми, то не смогут нанимать людей.

— Ты говорила про конфликты с PR, брендом, маркетингом. Как их разруливать? Особенно когда они упираются и не хотят, например, выделять бюджет или делать то, что тебе нужно. Как донести свою позицию?

— Очень сложно говорить абстрактно, каждая ситуация разная. Когда речь заходит о бюджете, факторов всегда много. Но есть рабочая формула: нужно действовать в связке с людьми, принимающими решения, или с теми, кто может на них влиять. Есть более авторитетные заказчики, есть менее авторитетные — и это всегда надо учитывать.

Если ты понимаешь, что твою работу и запрос поддерживает авторитетный заказчик или топ-менеджер, то сопротивление PR или бренда снижается. Можно прямо сказать: «Это нужно не только мне, это нужно вот этому человеку». И тогда вопрос решается быстрее. Бывают ситуации, когда после слова ключевого руководителя все тут же меняют позицию и делают то, что до этого категорически отвергали.

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

Если приходишь в компанию, где раньше этим не занимались, придётся долго перестраивать процессы. И это нормально. Не стоит думать, что проблема в тебе. Просто система может быть сложной, «тягучей», ей нужно время. В одной компании изменения идут быстрее, в другой — медленнее. Иногда бывает так, что два года приходится спорить по поводу бюджета, доказывать свою приоритетность, преодолевать сопротивление или даже конфликтовать. Но происходит эффект накопления, когда все понимают: бюджет надо выделить, и можно сразу в распоряжение DevRel, а не в маркетинг или HR-бренд.

— А как быть, если один топ-менеджер полностью тебя поддерживает, а другой — равного уровня — наоборот, против? И начинается конфликт уже между ними?

— Это очень хороший вопрос. У меня был похожий кейс: два сильных руководителя, и между ними возник серьёзный конфликт. Здесь важно понимать, что это не твой конфликт — это их конфликт, в который тебя пытаются втянуть.

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

— Звучит логично. А можешь посоветовать какие-то книги или ресурсы для тех, кто только начинает работать? Может, что-то по конфликтам или коммуникациям? Какие навыки вообще нужно прокачивать?

Начнем с последнего вопроса. Нужно быть:

– психологами, чтобы успешно взаимодействовать с разными людьми, уметь вдохновлять и поддерживать, убеждать и соглашаться, задавать правильные вопросы,

– проджект-менеджерами: уметь поставить правильно задачу, планировать ресурсы и бюджет, выстроить процесс и организовать мероприятие, владеть разными методологиями проектного управления.

– маркетологами и пиарщиками, потому что надо использовать маркетинговые инструменты, каналы, форматы, приемы и аналитику.

А еще любить технологии, писать или редактировать тексты, не бояться сцены, придумывать креативные форматы, быть открытыми к новому, иметь насмотренность и анализировать, почему коллеги из компании N сделали так, какие цели ставили, получилось ли у них задуманное.

— А как прокачивать коммуникации, особенно в части договорённостей и конфликтов?

— Здесь важно общее понимание конфликтологии. Например, у моего содокладчика Андрея Кёнига есть отличный четырехдневный тренинг. Там не просто рассказывают теорию, а глубоко отрабатывают ситуации на практике: что такое конфликт, что им не является, какие бывают уровни и причины конфликтов, когда стоит отстаивать позицию, а когда нет.

Например, бывает так: спрашиваешь себя, почему не можешь найти общий язык с человеком. А он просто не хочет его находить — потому что понимает, что он сильнее по уровню и может продавить. В такой ситуации стратегия другая: не тратить нервы и когнитивные усилия там, где это нерешаемо. И такие тренинги как раз помогают это осознать.

— А в каких случаях всё-таки стоит идти в конфликт? Ты говорила, что иногда конфликты бывают полезны.

— Конфликт — это противостояние двух или более сторон, когда им выгодно оставаться в этом состоянии. Есть несколько признаков. Во-первых, у каждой стороны должна быть своя выгода от противостояния. Во-вторых, ни одна из сторон не готова выйти из него. В-третьих, у сторон есть что делить. И, наконец, в-четвёртых, у сторон есть что терять.

— Вот для меня DevRel — это когда ты всегда на стороне разработчиков, отстаиваешь их интересы в любом случае?

— Абсолютно. Те, кто работает с инженерами, должны отстаивать их интересы, иначе принцип взаимодействия ломается. И ещё важнее, чтобы людям было комфортно с тобой работать.

Возьмём конфликт с дизайном. Дизайнеры требуют, чтобы презентация была готова минимум за две недели до конференции. Но чаще всего разработчик готовит и отдает презентацию за три дня до конференции (многие деврелы со мной согласятся). В итоге: дизайнер относится с пониманием, входит в положение, открыто не выражает негатива, быстро всё доделывает, вроде бы все довольны, мы его от всего сердца поблагодарили. Но потом на ревью появляется негативный отзыв: дескать, менеджер плохо организовал процесс. Вот и дилемма. Мы, как деврелы, должны стремиться к идеальному процессу, но реальность такова, что приходится лавировать между интересами команд.

В итоге, виноват деврел. Хотя объективно это несправедливо. Это системный конфликт: дизайнер может снизить оценку на ревью, потому что якобы деврел не сумел выстроить процесс так, чтобы избежать форс-мажора. С другой — процесс должен учитывать реальность: дизайнеру может действительно придётся работать в последний момент. Потому что разработчики часто отдают презентацию в последний момент — так это работает.

Часто лучший вариант — нанимать дизайнеров прямо в DevRel-команду или хотя бы именно на ваши задачи. Тогда дизайнер понимает специфику: его роль не в том, чтобы «творить», а в том, чтобы быстро доработать презентацию разработчика перед выступлением. Такой процесс честнее и эффективнее.

— Насколько, на твой взгляд, DevRel-специалисту важно выстраивать личные хорошие отношения со всеми контрагентами, с которыми работаешь?

— Всё зависит от стиля человека. Есть те, кто любят со всеми пить кофе, быть «котиками», и вроде все их любят. Но потом они недоумевают, почему на ревью вдруг появляется негативный отзыв. А бывают люди очень системные, которые не тратят время на неформальные отношения, зато у них всё чётко выстроено, и даже при минимуме общения с разработчиками работа идёт отлично.

Хорошие отношения, конечно, важны — я всегда за них. Но если конфликт назревает, а это пока не ваш конек, то полезно подключить медиатора, и это работает быстрее.

У меня была история: мой менеджер так ругался с контрагентом, что стало очевидно — ситуация тупиковая. В таких случаях приходится менять менеджера. Если после этого конфликт уходит, значит, дело было в человеке. Если же нет — значит, проблема глубже и нужно подключать третью сторону.

— Получается, хорошие отношения всё же важны?

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

— Мне казалось, что в профессиях с Rel в названии, отношения — это ключ.

— Тут важно различать два контекста. Одно дело — отношения как часть коммуникации. Когда мы выстраиваем диалог с разработчиками вовне, речь идёт о прозрачности, честности, постоянстве в коммуникации. Мы должны давать качественный контент, пользу, быть последовательными — и это тоже про отношения.

А другое дело — личные, «дружеские» отношения: когда всем нужно давать социальное поглаживание, поддерживать в неформальном ключе. И вот тут уже многое зависит от культуры компании. Где-то это уместно, где-то корпоративный стиль более сдержанный. Поэтому отношения не стоит понимать исключительно как дружелюбие. Это прежде всего правильная коммуникация.

Если хотите глубже разобраться в работе DevRel, научиться выстраивать взаимоотношения с техническими специалистами и зажечь в них жажду выступать и появляться в сообществе — приходите на DevRelConf #9.Там будем разбираться со всеми аспектами работы DevRel, чтобы приносить пользу инженерам и классно делать свою работу!