Архив недели @jbaruch
Вторник
Всем привет, с вами Барух. Будем говорить про DevRel - зачем эти все бездельники нужны, раз код они не пишут. Или пишут? Плана нет, но вывезем за счет срачей (ну как обычно).
Внезапно (как обычно) оказалось, что сегодня выходной, так что я продолжаю разбирать коробки после переезда вместо того, чтобы торчать за компом. В связи с этим сегодня количество твиттов (и срачей) снижено, но вы не переключайтесь!
Ну, давайте про ДевРел. Как нас учат SMM-щики и прочие макретологи, надо вовлекать аудиторию. Итак, DevRel это:
Ну, давайте про ДевРел. Как нас учат SMM-щики и прочие макретологи, надо вовлекать аудиторию. Итак, DevRel это:
Как и ожидалось, большинство проголосовали за правильный ответ. Но шутки в сторону, DevRel, как и DevOps, это не человек. В случае с Developer Relations это очевидно из названия - "relations" это так себе должность (пиарщики, молчать!). Что же это такое?! twitter.com/itunderhood/st…
Ну, это, конечном, отрасль деятельности, у которой следующие задачи (по мере важности):
Улучшать Developer Experience.
Принимать фидбэк разработчиков и инженеров.
Помогать разработчикам и инженерам более эффективно использовать продукт/платформу.
Налаживать связи в комьюнити.
Улучшать репутацию продукта/бренда в комьюнити.
Продвигать личный бренд разработчиков и инженеров организации.
Всякое по-мелочи.
Ну, это, конечном, отрасль деятельности, у которой следующие задачи (по мере важности): Улучшать Developer Experience. Принимать фидбэк разработчиков и инженеров. Помогать разработчикам и инженерам более эффективно использовать продукт/платформу.
Чот как-то получилось дофига (в один твит даже не поместилось). Очевидно, что тут требуются скиллзы явно больше, чем одной специализации. Давайте посмотрим на основные профессии в ДевРел (по книге @mary_grace The Business Value of Developer Relations). twitter.com/itunderhood/st…
Developer Advocate: это инженер, у которого хорошо получается слушать и объяснять. Первые три пункта - на них: послушать разработчиков и понять что им надо, это объяснить организации, чтобы сделали что надо, показать разработчикам что сделали и объяснить на нормальном языке.
Community organizer: это массовик-затйеник, который умеет собрать тусу для того, чтобы запустить туда developer advocate. Организовать митап, найти контакты правильного митапа, подобрать конференции, найти как опубликовать guest post в хорошем блоге, вот это всё.
Специалист по UX. Весь DevRel это про developer experience. Это вообще что? Ну это user experience, где user – разработчик. Можно взять толкового UX специалиста, посадить их с developer advocate, и получится хорошая машина по улучшению developer experience!
Технарь SSM-щик. Кто-то должен годные шуточки в твиттере шутить, но тут есть проблема, аудитория для нормального SSM-щика шутника непонятная. Нужен такой, который сможет в мемы, но на технические темы.
Developer at DevRel. В какой-то момент из за бесконечного context switch продуктивность разработки developer advocates падает настолько, что они могут только писать примеры, демки и прочие небольшие программы.
Для более сложных проектов - интеграций с другими продуктами, наипример, имеет смысл иметь в команде разработчика на полную ставку. Они, конечно, тоже будут многостаночники (языки, фреймворки, инструменты, но хоть будут сосредоточенны на коде)
Project Manager и Developer Relations Manager. Ну, кто-то же должен этим зоопарком управлять и координировать этот детский сад?
Developer Advocate: это инженер, у которого хорошо получается слушать и объяснять. Первые три пункта - на них: послушать разработчиков и понять что им надо, это объяснить организации, чтобы сделали что надо, показать разработчикам что сделали и объяснить на нормальном языке.
Получилась толпа народу, которая непонятно зачем вообще существует. Давайте ответим на главный вопрос - ЗАЧЕМ?
Мой ответ таков: У вашей организации есть developer relations, и вы - часть их. Всегда, с первого дня, вне зависимости от вашего желания. twitter.com/itunderhood/st…
Вопрос теперь, хочет ли организация, чтобы эти relations были осмысленными, или оставит она их на самотёк. Команда Developer Relations это как раз осмысленное управление этими relations (а не создание их).
Конечно, чтобы управлять developer relations не нужна команда из шести человек. На самом деле можно вообще не иметь отдельной команды. Совершенно нормально, например, когда в маленьком стартапе developer relations занимаются сами фаундеры.
Дальше, когда у фаундеров заканчивается время специально заниматься developer releations, можно бросить всё на самотёк (нет), а можно нанять первого человека в DevRel (это developer advocate, который выполняет остальные роли тоже по началу). Вторым будет community organizer.
На этой паре можно вывезти годами, их можно скалировать, а можно специализироваться дальше, нанимая дополнительные роли.
Как уже написали в реплаях, Барух это тот человек, который настолько увлёкся личными брендом, что мы все уже забыли какую компанию он адвокатит 🤷🏻♂️ twitter.com/itunderhood/st…
С грустью констатирую, что снова you can't win. Если рассказываешь про компанию - "суёт везде маркетинг своих продуктов ебучих", если рассказываешь не про компанию - "увлёкся личным брендом".
Ну всё как всегда, впрочим. twitter.com/baltachtan/sta…
@itunderhood а при чем тут Spring? Под своего косить?
Отличный вопрос, "а причем тут ${не связанная напрямую с продуктом/сервисом/платформой технология}?"
Полезный рассказ про Спринг помогает в пунктах 2,3,4,5 и 6 из этого списка: twitter.com/itunderhood/st… twitter.com/VladVA/status/…
@lightdelay @itunderhood @VladVA Видимо бывают, но так как они ничего не делают, то никто и не замечает этого. Думают что они просто у кофемашин тусят.
Вот тут я ответил, что они как минимум должны делать. Если ваши этого не делают, пора их менять.
twitter.com/itunderhood/st… twitter.com/Ivan_Trechyoka…
Если не очевидно как, спрашивайте :)
@itunderhood @dbg_nsk Ну раз начал, может расскажешь уж тогда, как продвигать личный бренд не в ущерб продукту и vice-versa.
Это хороший и сложный вопрос. В несуществующем плане на неделю есть раздел про личный бренд, и я обязательно на него отвечу. twitter.com/baltachtan/sta…
Отличный вопрос, "а причем тут ${не связанная напрямую с продуктом/сервисом/платформой технология}?" Полезный рассказ про Спринг помогает в пунктах 2,3,4,5 и 6 из этого списка: twitter.com/itunderhood/st… twitter.com/VladVA/status/…
Нужно поподробней:
Рассказ про Spring помогает собрать фидбэк о нашем продукте, потому что он 1. собрал много народу (Спринг тема популярная, а доклад хорош), 2. растопил лёд между докладчиком и аудиторией, 3. настроил на техническую дискуссию. Самое время спросить фидбэк! twitter.com/itunderhood/st…
Рассказ про Spring помогать разработчикам и инженерам более эффективно использовать продукт/платформу, потому что в нашем примере при более правильном использовании Спринга наш продукт/платформа пригодятся, это win-win.
Рассказ про Spring помогает наладить связи в комьюнити, потому что Spring популярен и вовлекает очень много инженеров, а у вас создаётся положительная техническая репутация.
Рассказ про Spring продвигает личный бренд разработчиков, потому что либо они сами рассказывают про Spring (как докладчики или со-докладчики), либо вы популяризуете те крутые штуки, которые они сделали со Спрингом.
@itunderhood В рамках вброса. ;) tech-pr. Вброс - очевиден (вкину потому что все равно придут с этим). Реквестирую раскрыть полезность для гейна денег бизнесом и для процесса производства.
Очень годный вброс! Наверное, проще всего рассказать маме, что такое devrel именно так - тех-пиар. Это будет примерно такое же обобщение как программист чинит принтеры, но в целом аналогии есть. Давайте про деньги и про процесс, да. twitter.com/vfedorov/statu…
В зависимости от продукта/сервиса, DevRel контрибьютит бизнесу по разному. Вот пара примеров:
Мы стартап вокруг опенсорс технологии. Наша задача на первом этапе - максимизировать использование этой опенсорс технологии. DevRel несет технологию в массы, обратно принося фидбэк как её улучшить, а инвесторы смотря на adoption несут нам деньги.
Дальше нам надо конвертировать этих пользователей в клиентов. Найти, кому будут полезны платные фишки, и показать, как именно эти фишки будут полезны для developer experience пользователей - работа DevRel. Обратно опять несем фидбэк как улучшить продукт, получаем win-win.
Или, например, мы корпорация, которая традиционно имеет сложности с adoption среди разработчиков. DevRel может помочь, показав разработчикам, что всё давно уже хорошо с developer experience у компании, и сломав устаревшие стереотипы. Обратно несём фидбэк, как сделать ещё лучше.
Ну или мы другая корпорация, которую девелоперы ненавидят за дело. Тут сначала надо собрать очень много фидбэка, потом всё исправить, и только потом можно намекнуть разработчикам, что можно посмотреть ещё раз в нашу сторону.
Среда
🎉 У нас теперь новый архив, читать прошлые недели стало ещё удобнее!
it.underhood.club
На этой неделе crowd-аккаунт @itunderhood ведет Барух Садогурский @jbaruch. И рассказывает он, ни много ни мало, про тот самый мистический и недосягаемый DevRel! Добро пожаловать в Дивный Новый мир, г-да выгоревшие разработчики :)
Спасибо на добром слове, Лекс, но про выгорание в ДевРел - отдельный топик. Не то, чтобы прямо интересно вне нашей ДевРельной тусы, но вкраце - всё очень плохо у нас с этим. twitter.com/iamitbeard/sta…
@itunderhood Так чем это отличается от продажи интернета по квартирам? Обходит чел весь подъезд, стучится: хотите подключить Ростелеком, у нас скорость и технологии ОГО! Только деврелов любят, а продаванам из РТК под жопу пендель дают :)
Ну продаванам из корпораций которые холодными обзвонами промышляют тоже под жопу пендель дают. Об этой тонкой разнице, собственно, всё направление DevRel. twitter.com/olegchir/statu…
Developer Advocate: это инженер, у которого хорошо получается слушать и объяснять. Первые три пункта - на них: послушать разработчиков и понять что им надо, это объяснить организации, чтобы сделали что надо, показать разработчикам что сделали и объяснить на нормальном языке.
Давайте про Developer Advocate поговорим (ето йа).
Откуда такие люди берутся? Обычно это разработчики, которым скучно сидеть и писать код для одного проекта. Меня, например, всегда привлекала смена технологий/задач/людей в работе консультанта/фрилансера. twitter.com/itunderhood/st…
Не надо копаться в старом коде/чинить баги/подставлять костыли. Пришёл на чистое поле (ну по крайней мере для тебя), нанёс пользу, дальше сами. В этом есть недостатки, слишком частый context switch, например, или отсутствие удовлетворения от созерцания твоего детища в проде.
Так что это не для всех. Но если вы такой, что вам интересней каждый раз что-нибудь новенькое, чем доводить до конца начатое, то потенциал хороший :)
Второй аспект это экстравертность. Сейчас будет Теория Баруха об экстравертности, открывайте блокнотики.
По моим ощущениям (чувствуете, научность пошла?) интровертность/экстровертность это не бинарное значение, а шкала. Причем шкала не между двумя экстримами, а сколько времени человек может выдержать с вывернутым на определеную позицию сеттингом экстравертности.
Например, если его вывернуть на максимум (доклад+общение на огромной конфе), кто-то может выдержать 12 часов, а другой - пару часов. Что интересно, что после этого периода, любой из нас хочет выключить этот сеттинг нафиг и просто побыть в тишине.
Ну так вот, если у вас толерантность к экстравертности высокая, то вы нам подходите. Ну то есть в ДевРел вы подходите по-любому, там ведь даже есть full time разрабочики, как вы помните, так что я сейчас конкретно о DA. Это те ребята, которые любят выкрутить на полную.
@itunderhood Не работа а мечта, а когда будут недостатки?
Тут мы подходим к вопросу @TiPok о недостатках: twitter.com/TiPoK/status/1…. Как и любой sex drugs and rock-n-roll, частое выкручивание сеттинга экстравертности на максимум и постоянное переключение контекста (часто DA исполняет почти все роли в команде DevRel годами), приводит к...
Тут я ожидал ответ "ВЫГОРАНИЕ" лесенкой от фанатов в реплаях, конечно, ну да ладно, придётся самому.
Для меня, по крайней мере, нет никаких сомнений что DA – работа мечты. С одной стороны - техническая и инженерная. С другой стороны - с людьми и в лучах славы (хе-хе). Но!
Где-то пробегало какое-то исследование (найду, добавлю), про то, что в ДевРеле выгорают за пол-года. Для человека, который в этом деле 9 лет это может выглядеть странно, но с другой стороны я понимаю, откуда берется пол-года.
Как нас учат коучи по веллбеингу (хи-хи), чтобы не выгорать надо разделять работу и остальную жизнь. Когда у тебя 50% времени (а в сезон и все 70%) - разъезды по конференциям, ни про какое разделение речи не идет.
Ты целый день фигачишь на конфе с вывернутой на максимум экстравертностью, а потом вместо того, чтобы умереть до утра внезапно надо делать всю остальную работу ДевРел отдела - написать блог, подумать над новым материалом, договориться с тремя митапами на следущий месяц, и т.д.
А, еще есть рабочий инбокс. В рабочем инбоксе есть взаимоотношение ДевРела с другими отделами. Кажется, пора перестать ныть, поэтому давайте про это лучше.
А, еще есть рабочий инбокс. В рабочем инбоксе есть взаимоотношение ДевРела с другими отделами. Кажется, пора перестать ныть, поэтому давайте про это лучше.
Взаимоотношения ДевРела с другими отделами это одна из самых клёвых фишек ДевРела. Мы полезны ВСЕМ (и это очень з̵а̵ё̵б̵ы̵в̵а̵е̵т̵ клёво). twitter.com/itunderhood/st…
В первую очередь, как я уже говорил, от нашей работы выигрывают product и маркетинг. Продакт получает живой нефильтрованый фидбэк, причем не уровня воплей "ваш продукт - говно" в Твиттере, а подробный, разжёваный DA-ми технический фидбэк developer experience от девелоперов.
Не всегда продакт готов этот фидбэк принять, мы слышим "plural of anecdote is not data" - то, что вам двое разрабов на конфе пожаловались не значит, что нам это немедленно надо чинить, да и вообще это ваши знакомые, которым вы хотите угодить.
Тут, как и во многом, когда речь идет о работе с людьми, возникает вопрос доверия - считает ли product, что DevRel добросовестно работает во благо организации. Если да, они будут рады этому фидбэку. Если нет, у нас есть большая проблема.
Маркетинг. С маркетингом тоже всё понятно, и сложно. Мы общаемся с разной аудиторией. Наша аудитория или ещё не аудитория маркетинга, или никогда ей не станет.
То есть это либо разработчики, которые пока не готовы покупать продукт, либо такие, кто в принципе не целевая аудитория для продажи. Например, какие нибудь individual contributors, у которых нет полномочий на решения о покупке ПО или сервиса.
Тут приходит маркетинг, и вопрошает - нахрена вы тогда нам вообще сдались, если ваш коммьюнити никак в нашу воронку не заманить? А мы объясняем:
С некоторыми надо не спешить. Давайте разберемся, нужен ли им наш продукт? Станет ли их developer experience лучше?
Другие вообще про нетворкинг и сообщество. Всё, что мы хотим, это чтобы они знали про нас, пользовались нашими бесплатными продуктами, и хорошо о нас думали.
Хороший отдел маркетинга это всё понимает, и не предлагает "а давайте мы устроим твоему комьюнити email рассылку с нашим уникальным предложением?! Отличное же, вот скидосик!"
А плохой надо дрессировать пока не поймут, да.
Дальше, рекрутинг. Тут всё ПРЕДЕЛЬНО ясно, настолько, что в некоторой части света ДевРел является синонимом рекрутерства. По этой теме есть примерно 100% докладов ДевРелКонфа от @Ontico_Russia вот тут devrelconf.ru и идея простая:
мотивируем разработчиков рассказывать как классно у нас в компании, другие разработчики верят, и приходят к нам работать (за меньшие деньги). Профит.
Ну, всё так и работает. Если HR понимает ценность ДевРела, то он его использует. А если нет, то сам себе злобный буратино.
Дальше сейлзы. С сейлзами примерно та же история, как и с маркетингом, основной вопрос - вы нам лиды не передаёте, нахрена вы, дармоеды нужны?
И тут ответ примерно такой-же - мы вообще не для вас работаем. Мы от вас еще дальше, чем от маркетинга, за лидами идите к ним. Но!
Мы всё ещё можем и будем рады быть вам полезными. Например, у нас есть связи. Мы познакомить вас с очень важными и нужными людьми. Мы с удовольствием поможем вам в присейлах в компаниях где у нас есть знакомые на технических позициях.
Мы сделаем доклад о продукте в компании, которая только что купила. Мы передадим вам фидбэк о ваших процессах продаж. От нас масса пользы сейлзам. Просто это не лиды.
Кого еще не упомянул? Ну конечно, R&D. Казалось бы, какая им-то польза? Только и делаем, что отрываем их от работы для того, чтобы заставить написать блог или выступить на конфе? Но и тут всё не так просто. Для будущего автора/спикера профит от таких интервенций очень велик.
Да, я про тот самый персональный бренд, который доклады, блоги, твиттер и всё остальное помогают вам развить. Он нужен вам - чем вы более узнаваемы, тем вы дороже. Он нужен компании - чем больше в компании "звезд", тем легче сконтактировать с комьюнити, и лучше у компании имидж.
Приходите на мой тренинг по персональному бренду! (шучу, но доклад на #SnowOne никто не отменял): snowone.ru/speakers/baruc…
Четверг
@itunderhood Может ты или другие ДевРелы писали что-то про ваши метрики эффективности? Как компания оценивает результаты, на что опираетесь в планировании?
Да, много кто из ДевРела писал про метрики эффективности. Целая серия конференций @devrelcon состоит из докладов "как же всё таки померять" практически полностью. Это потому что как померять непонятно совсем. twitter.com/lightdelay/sta…
Мерять имеет смысл в трех целях: 1. улучшать свою работу, 2. прогнозировать что-то там, 3. показать return on investment. Из всего, что я видел про метрики в ДевРел, можно достаточно неплохо делать 1.
Но давайте по-порядку. Проблема в том, что импакт ДевРела во-первых опосредованный, а во-вторых отложенный:
Удачи вам скоррелировать цепочку DA выступил на конференции о крутом техническом решении в продукте, один из слушателей притащил похожее решение в проект, рассказал коллеге, где он про это услышал, коллега запомнил название компании в категории "делают крутые штуки",
потом он сменил работу, но когда ему понадобился продукт класса, который делают в компании, он предпочёл его, потому что их делает компания, которая делает крутые штуки, попробовал, рассказал начальнику, и тот купил.
Ну ладно скоррелировать, вы попробуйте убедить руководство, что даже если это действительно произошло, это оправдывает расходы того самого DA на поездку на конференцию. Причем произошло это через год, и узнал про это DA никак.
Ну то есть иногда повезет, и вам скажут "Чувак, я тут год назад смотрел твой доклад про решение, которое вы используете в R&D, a теперь вот использую ваш продукт, прикинь, совпадение?!"
Ну то есть даже тот, на кого влияние произошло сам не понимает, что оно произошло,
а от нас требуется доказать цифрами факт массовости этого влияния. Рассказ об этом разговоре бестолковому руководству будет встречен аргументами "correlation doesn't mean causation" и "plural of anecdote is not data".
То есть в принципе любые попытки завести разговор о ROI для ДевРел надо сразу пресекать посылом в пень. Вот отличные рекомендации от великолепного @TheSteve0 как это делать с огоньком: devrel.net/strategy-and-m…
Ну ок, но можно же проверить, на какой площадке блоги заходят лучше и писать там, да?! Ээээ, что значит "лучше заходят"? Если писать про выращивание листьев салата в средней полосе, то это заходит лучше, чем про имлементацию http client в блоге садоводов. И что?
Для того, чтобы знать, что оптимизировать, надо понять, что лучше работает. А что лучше работает понять, как мы только что выяснили, ТЯЖЕЛО. Ну хорошо, бог с ними с листьями салата. Можно хотя бы выяснить, лучше писать про фичи продукта, или про то, какой у нас R&D умный?
Ха, за "фичи продукта" вас загнобят "задрали со своим маркетингом", а если про какой R&D умный, то непонятно, у скольки работает переход "R&D умный -> продукт хороший".
И это мы так и не добавили различные площадки. Может на хабре вас загнобят "задрали с маркетингом", а на реддите наоборот все прочитают про фичи и побегут покупать? (на самом деле нет).
То есть из за сложности корреляции и отложенности деятельности, даже такая простейщая, казалось бы, метрика, как эффективность блога, становится совершенно недоступной, что уж там говорить про эффективность, например, доклада.
Эти вообще непонятно как мерять, ведь даже переходы из зала на сайт не померять никак, так что даже понять, что доклад про садоводство был более вовлекающим, чем доклад про крутые штуки в R&D невозможно, не говоря уже про дальнейшие шаги по конвертации.
В этом плане "ДевРелу ради рекрутинга" легче. У них во-первых нет дилеммы "про продукт или про R&D", во вторых у них нет опасности быть заклейменными маркетингом, а в третьих, у них как раз plural of anecdote is data", потому что количество ответов на "откуда пришёл" - 100%.
(хотя там тоже не всё очевидно, ибо касаний может быть множество, и не факт, что кандидат укажет именно деврельские активности). Но в целом, конечно, намного легче, чем продуктовом ДевРелу.
Итак, что же мы имеем в итоге? Cost center, немаленькие расходы которого оправдать невозможно. Красота! Как раз то, что любит руководство и инвесторы. Не удивительно, что в худые времена ДевРел попадает под нож одним из первых.
Взаимоотношения ДевРела с другими отделами это одна из самых клёвых фишек ДевРела. Мы полезны ВСЕМ (и это очень з̵а̵ё̵б̵ы̵в̵а̵е̵т̵ клёво). twitter.com/itunderhood/st…
Так что же делать? Выход, как ни странно, как раз в тех самых anecdotes, которые, может быть и не data, но истории, которые так любят люди. Особенно, если их рассказываете не вы. ПОмните пользу, DevRel-а другим отделам (мы это обсуждали здесь: twitter.com/itunderhood/st…)? Это ключ.
Когда все остальные отделы в любой момент могут перечислить огромный список пользы, которой вы им нанесли, вы не просто не первые на выход, вы НЕЗАМЕНИМЫ. И никаких цифр ROI для того, чтобы этого доказать не требуется.
Попробуйте-ка уволить тех, кто помог подписать самых крупных клиентов, познакомив ключевыми людьми в нужный момент, помог нанять технический лидершип компании, создав правильный имидж компании, снимает нагрузку с саппорта, работая на stack overflow, и так далее.
Когда все остальные отделы в любой момент могут перечислить огромный список пользы, которой вы им нанесли, вы не просто не первые на выход, вы НЕЗАМЕНИМЫ. И никаких цифр ROI для того, чтобы этого доказать не требуется.
После того, как я рассказал вам что мерять 1. невозможно 2. бесполезно 3. не нужно, самое время упомянуть парочку инструментов для метрик :D twitter.com/itunderhood/st…
Шучу, нужно мерять. Просто нужно помнить об ограничениях. Итак, первый у нас orbit.love.
Модель орбиты была представлена, обсуждена, и полюблена на тех самых devrelcon–ах. Очень приятно видеть, как ребята смогли её продуктизировать и поднять денег на реализацию.
Orbit отслеживает сплочённость комьюнити вокруг вашего продукта/сервиса, и тех, кто на орбитах вокруг них крутится. Отслеживая людей, которые перемещаются между орбитами вы обнаруживаете ключевых для вас персон в комьюнити. Очень круто!
Второй инструмент, который хочу посоветовать это weavr.ai. Это немного более "традиционный" инструмент мониторинга, но очень удобно сводит всё в один дашборд.
Пятница
@itunderhood @dbg_nsk Ну раз начал, может расскажешь уж тогда, как продвигать личный бренд не в ущерб продукту и vice-versa.
Ну и напоследок поговорим вот об этом: как поженить личный бренд и бренд продукта.
Откуда вообще проблема?
Организация нанимает DA, чтобы они продвигали продукт, а не безликий маркетинг организации, потому что они близкие инженерам по духу инженеры, и доверия им больше. twitter.com/baltachtan/sta…
Но доверия им больше как раз потому что они не согласны заниматься "маркетингом" и тупо "продвигать продукт".
Вместо этого, они хотят делать то, чем и положено заниматься DevRel – помогать разработчикам быть более продуктивными с помощью продукта, в том числе говорить не только о продукте, и даже говорить когда продуктом не надо пользоваться. И тут в организации может возникнуть батхёрт.
"Почему наш DevRel прокачивает свои личные бренды рассказывая всякую ерунду, вместо того, чтобы продвигать продукт, продажи которого платят им зарплату?!" может спросить организация, не понимающая DevRel.
Этот батхёрт имеет прямое отношение к конфликту "зачем вы это делаете, если это не наполняет нашу воронку" и как померять вашу эффективность в деньгах с продаж", но он даже ещё хуже, потому что подразумевает не просто безделье, а личную выгоду за счет организации.
Ну то есть "ты чего в твиттере и на сцене жопой крутишь и фолловеров набираешь, вместо того, чтобы продукт продвигать?! Ты такой популярный благодаря нам, конфу оплачиваем тебе мы, и весь выхлоп который мы видим, это как ты на афтерпарти бухаешь и в твиттере шитпостишь".
Причем, ладно организация, мы уже обсуждали, как с этим бороться, но и самому себе похожий вопрос задаешь: насколько твой прокаченный бренд действительно 1. существует только благодаря организации/продукту 2. возвращает вложения организации/продукта в него.
То есть буквально:
Стал бы я ведущим @itunderhood если бы не JFrog?
Как моя неделя тут помогла JFrog?
Ответы на эти вопросы колеблются в строгом соответствии с уровнем моей самовлюблённости сегодня с утра, ну то есть ответ "понятия не имею".
Причем, я даже не уверен, насколько это публично обсуждается (по крайней мере я не видел обсуждений), и достаточно понятно, почему обсуждать какие нибудь метрики конверсий намного более удобно, чем это. Тут без переходов на личности не обойдешься ну никак.
Очевидно, что это шкала (привет @ligolnik), и что правильный ответ не "всего добился сам, без JFrog может даже лучше бы было" и не "посади на твоё место бота который копи-пейстит JFrog–овские пресс релизы и напиши и был бы тот же результат"
С другой стороны тоже понятно, что у JFrog завтра не появится 4320 новых пользователей, но некоторые пойдут таки глянуть, что это за балалайка, и глядишь, оно может оказаться им полезным.
Но это примерно всё, что можно сказать по этому поводу, что, конечно, печально.
И всё же, как сделать так, чтобы к тебе не пришли спросить за персональный промоушн за счет компании?
Два совета:
Рассказывай истории
Будь скромнее
Коллекционируй истории, в которых твой личный бренд помог компании. Не то, чтобы тебе часто нужно было их кому-то в лицо кидать, но одно их наличие и количество помогает более уверенно утверждать, что да, наношу пользу через личный бренд.
Не выпячивай бренд перед коллегами и начальством. Ответ "я лучше знаю, у меня фолловеров больше" - так себе.
Это я шучу, конечно, но если серьезно, то не оперируй размером и блеском бренда как метрикой для оправдания чего либо. Единственное, чего ты добьешься это что тебе напомнят, что он существует не только благодаря тебе.
Тут мы подходим к вопросу @TiPok о недостатках: twitter.com/TiPoK/status/1…. Как и любой sex drugs and rock-n-roll, частое выкручивание сеттинга экстравертности на максимум и постоянное переключение контекста (часто DA исполняет почти все роли в команде DevRel годами), приводит к...
Пакет с пакетами (© @dbg_nsk):
– Зачем нужен DevRel: twitter.com/itunderhood/st…
twitter.com/itunderhood/st…
– Специалисты в DevRel: twitter.com/itunderhood/st…
– Про Developer Advocate: twitter.com/itunderhood/st…
- Про выгорание (привет @vkozulya): twitter.com/itunderhood/st…
1/2
Ну и напоследок поговорим вот об этом: как поженить личный бренд и бренд продукта. Откуда вообще проблема? Организация нанимает DA, чтобы они продвигали продукт, а не безликий маркетинг организации, потому что они близкие инженерам по духу инженеры, и доверия им больше. twitter.com/baltachtan/sta…
– Взаимоотношения с другими отделами: twitter.com/itunderhood/st…
- Как мерять: twitter.com/itunderhood/st…
- Инструменты: twitter.com/itunderhood/st…
- Личный бренд vs бренд продукта: twitter.com/itunderhood/st…
2/2
