Олег Придюк о профессии internal evangelist и митапах developer relations

Три месяца назад Олег Придюк, известный по своей работе в  Unity и King, подробно рассказал December32 о задачах и вызовах в работе евангелиста. Сегодня мы обсуждаем митапы developer relations (термин, вбирающий в себя широкую аудиторию трудящихся в рамках задач техно-пиара, управления комьюнити разработчиков, технического евангелизма, developer advocacy и прочих новомодных профессий, балансирующих между программированием и гуманитарными задачами разного рода), которые Олег с коллегами проводили в Стокгольме и Вильнюсе, а также  профессию internal evangelist внутреннего или, точнее, внутренне-ориентированного евангелиста в мультикультурных компаниях.

Олег Придюк на карантине =)

О DevRel Events.

Олег, когда будут devrel events? У тебя же был sold out, верно?

Да, у меня был sold out. Я хотел проводить ивенты в трех разных форматах, и каждый из них собирал под 200 человек. Наверное, можно было бы взять и сказать: смотрите, вот онлайн-ивент, выслать всем ссылку на имейл. Но я провел опрос, чтобы узнать, кто хочет онлайн-ивент, и только человек 12-15 проголосовали “за”. Еще человек 20 ответили, что посмотрят ивент в записи.

Я думаю, что все сейчас сильно устали от постоянных созвонов по работе плюс сказывается общая депрессивность. Людям очень сложно получать fun онлайн, потому что они и так все время онлайн. Их работа идет через чаты, все рабочие митинги тоже в чатах. И то, что всем придется снова быть онлайн и еще раз выходить в чаты, —  я не вижу, чтобы людям было очень прикольно.

Конечно, есть люди, работа которых заключается в том, чтобы ходить по конференциям, может быть, потому что они так продают, что-то маркетят, что-то рекламируют в партнерстве, вот они ходят. У таких людей есть потребность выступать. Что же касается людей, которые хотят чему-то научиться, я не вижу, чтобы их очень сильно тянуло на онлайн-ивенты.

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

Если бы у меня было стабильное оффлайн комьюнити, у него была бы потребность встречаться, увидеться со своими знакомыми, с которыми они не могут больше видеться на карантине, но этого стабильного комьюнити еще нет. Из 500-600 человек, которые хотели бы прийти на мои оффлайн-ивенты, на онлайн-ивент придет человек 20-30, я думаю. Это очень низкая конверсия. Делать онлайн-ивент ради онлайн-ивента смысла нет, надо либо делать хорошо, либо никак.

С другой стороны, глупо сесть ничего не делать. В среду 15 апреля пройдет первый тестовый онлайн-ивент по developer relations. Пробуем собрать подобие unconference в онлайновом формате. Когда найдем хорошо работающую формулу, попробуем и остальные наши ивенты делать онлайн.

О внутреннем евангелизме.

Я сейчас разрабатываю программы developer relations на заказ и занимаюсь внутренним евангелизмом, помогаю настраивать компаниям внутренние процессы. В Америке есть такое понятие как internal evangelism, в Европе его почти нет, в развивающихся странах совсем нет. Internal evangelism скорее можно перевести как внутренне-ориентированный евангелизм. Это набор практик и процессов для мотивации собственных технических сотрудников. Представьте, что ваш директор по разработке занимается HR-задачами.

Internal evangelism направлен только на программистов?

Как правило, да. Ну, девопсов (DevOps) еще приписывают к программистам.

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

У программистов могут быть разные потребности и пожелания по изменению рабочих процессов, софта, сервисов. И наоборот — у разных частей компании могут быть свои мнения, что надо делать, как и кому. Задача internal developer advocate заключается в том, чтобы настроить все процессы и отношения на всех уровнях — от индивидуального до корпоративного, чтобы, например, директор по продажам мог вести продуктивный диалог (я подчеркну: не монолог, а диалог) с отделом разработки, отдавать фидбэк, делиться впечатлениями пользователей. И наоборот оно тоже должно работать.

Как правило, internal developer advocate подчиняется кому-то из топов, например, коммерческому директору, который не готов углубляться в особенности разработки софта , но у него есть бюджет, возможности и желание сильно улучшить эффективность работы своей компании.

О мотивации программистов.

Представь 20 программистов, все разбросаны по миру, все разного возраста, никогда друг друга не видели, как им работать вместе как одна команда? Как им быть мотивированными? Как им хотеть работать вместе?

Внутренний (внутренне-направленный?) евангелизм — это очень актуальная тема, потому что все сидят по домам и пытаются работать онлайн. Например, у King была проблема культуры. Жили-были шведы и испанцы, к ним пришли американцы и из Лондона заставляли всех быть американцами. Все сопротивлялись, потом включилось разное эго, старая гвардия забрала свои бонусы и убежала, приходит новая гвардия и насаждает свои порядки, но все получается очень медленно и спорно.

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

Что делать? Первое — это выстроить эмоциональные связи людям, у которых сейчас эмоциональных связей нет. Самое простое — активный #random, или как там ваш внутренний чат для шуточек называется? Там можно делиться фоточками кота, рассказать, у кого выпал весенний снег, рассказать про свой аудиофильский патефон и пластинки.

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

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

У всех людей разное расписание. Кому-то нужно отвести дочку в детский садик утром, кому-то забрать, кому-то выгулять собаку, у кого-то что-то уже запланировано сегодня. На удаленке рабочие часы — понятие теоретическое. У кого то они могут начаться в 6 утра, потом человек работает до 8, потом 4 часа перерыв, потом снова работает. Кто-то пытается с 9 до 6 работать из дома, потому что так удобней.

Но рабочий коллектив так или иначе должен иметь точки синхронизации, иначе это не коллектив, а набор людей. Коллектив работает вместе, и надо выделять время каждый день, когда все знают, что в это время все доступны, сделать 2-3 часа, когда все люди онлайн, и со всеми вопросами ты приходишь именно в эти два часа. Это обязательная точка синхронизации, чтобы процесс двигался куда-то, чтобы что-то происходило.

Когда ты не видишь друг друга и не слышишь друг друга, то сидишь весь в своих проблемах, не спрашиваешь совета. Часто проговаривание проблемы вслух помогает тебе принять еще лучшее решение, поэтому нужно чтобы все происходило лучше, иначе все будет происходить плохо. Человек будет закапываться в себе. У тебя что-то не получается, а в чате кто-то запостил котика, и ты такой злой на этого человека: “Я тут работаю, а человек постит котика, пойду я погуляю вместо этого или как-нибудь нагажу этому человеку”.

О проблемах программистов.

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

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

Например, у человека три ребенка, и он хочет больше быть дома с семьей. Дополнительный отпуск мотивирует его больше, чем прибавка к зарплате. Кто-то хочет работать не с 9 до 6, а в пятницу работать из дома, а корпорации очень сложно объяснить, почему кто-то внезапно работает не из офиса. Вот эти процессы нужно строить.

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

А как ты объясняешь популярно? Бывает ли так, что они не понимают?

Все может быть очень по-разному. Как правило, я пытаюсь настроить мосты между разными департаментами. Самый простой пример: у нас есть ежеквартальный, ежемесячный звонок, на нем, допустим, 30-40 минут разные люди из корпорации рассказывают, что они делают. Менеджер по продажам рассказывает, что он делает и как делает, директор по персоналу рассказывает, как курьеры, допустим, в карантин взаимодействуют и решают проблемы. Нужно придумать процесс, чтобы программисты могли общаться с руководством компании, а руководство компании могло общаться с программистами.

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

Как ты борешься с дедовщиной?

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

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

Потом в чисто мужских компаниях шутки могут уходить в моменты, которые могут быть кому то обидны или могут ставить в неловкое положение. Сюда же идут шутки и вопросы национального или политического характера. То, что смешно одной нации, может быть вообще не смешно другой. Это необязательно последние проблемы между братскими народами, это могут быть еврейские мотивы, что-то из Советского Союза и т.д. Тут нужно все объяснять, что смотрите, это может быть смешно, но шутки про русского немца и еврея не обязательно могут быть смешными всем. Нужно всегда думать, что ты пишешь, что ты говоришь, и очень важно это доносить не как ругань, а как фидбэк.

При этом в одной культуре фидбэк — это фидбэк, а в другой культуре “меня наругали”. Допустим, в Восточной Европе сказать “У тебя код говно” — это нормально, но если такое сказать шведу или американцу, то у человека травма. Со стороны коллеги такой фидбэк расценивается как харрасмент, прямое нападение, а если со стороны руководства, то как четкий знак: меня сейчас уволят, потому что я что-то плохо сделал. Нужно все объяснять, помогать мультикультурному общению и взаимодействию. Нужно, чтобы коллеги уважали друг друга, старались нечаянно не обидеть, не задеть и не устраивать драмы на ровном месте.

Как ты пришел к такому набору кейсов, который используешь в работе? Ты же не был эйчаром?

Я не был эйчаром, но я работал в King-e, мультикультурной корпорации. Были задачи, мне давали их решать, было очень много примеров по этому поводу. Эти проблемы есть всегда и у всех, но ими чаще всего никто не занимается, и если есть большой конфликт, то занимается им кто-то из руководства просто потому, что больше некому.

О конкурсах.

Как-то в King мы проводили внутренний конкурс, где главным призом была поездка куда-то в Лас-Вегас или Лос-Анджелес, не помню точно. Были еще утешительные призы, футболки, например. Конкурс был про то, что нужно поиграть во внутреннюю игру, которая доступна во внутреннем мобильном магазине, и набрать максимальное количество очков. В какой-то момент кто-то отправил прямо главному директору письмо: “Этот конкурс мне мешает работать, потому что я не могу не думать про этот конкурс, и все свое рабочее и нерабочее время я трачу на то, чтобы выиграть в этом конкурсе”. Если ты делаешь конкурсы для внутренних комьюнити, нужно быть готовым к тому, что у этих людей будет свое мнение про то, кто как кого рассудил, что оценки неправильные. Это огромное количество поводов для ссор, и заранее их очень сложно предугадать. За мои 4 года в King разные люди пытались внедрить активности, и каждый раз была беда, потому что много разных культур, обо всем сложно подумать и предугадать. У кого-то Рамадан, у кого-то Ханука, у кого-то еще что-то, а кому-то это всё мешает работать.

Так есть ли польза в инициативах для мультикультурных команд?

Польза от мультикультурных команд в том, что у такой команды разные взгляды на продукт. Когда ты делаешь продукт для всего мира (хотя понятно, что ты его запускаешь постепенно), то чем больше у тебя представителей этого самого мира, тем больший фидбэк ты получаешь.

Например, есть 100 программистов из разных стран с разными культурами и разным опытом. Они не только как программисты вкладываются, но могут сказать: здесь написано не так, на китайском андроиде не работает, таким цветом нельзя, потому что он приносит неудачу.

Что касается конкурсов, то всё просто: не надо их делать с призами денежными. В качестве призов нужно дарить маечки-кепочки. Нужно, чтобы конкурсом занималось больше 1 человека, чтобы в организационной группе были разные представители каких-то разных мультикультурных команд, все, у кого есть свое мнение.

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

А если это не программисты? Как быть, например, с маркетологами?

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

Про онбординг сотрудников.

Как ты лично как internal evangelist относишься к онбордингу? Есть там что-то такое, что надо делать обязательно, или что-то такое, что точно не надо делать?

Онбординг — это вообще очень сложная штука. Это очень важно, и очень грустно, что почти нигде его нет. Обычно онбординг — это просто: “Смотрите, это Маша, она будет сидеть здесь, работать с вами, прошу любить и жаловать”. Всё. По сути, новому сотруднику не дают платформы общения с коллегами, не дают возможности раскрыться, показать себя, влиться в коллектив. Это влияет и на атмосферу в команде, и на эмоциональное состояние сотрудника.

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

Кто этим занимается? Ты занимаешься онбордингом сотрудников или это все-таки задача эйчаров?

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

Об эмоциональных связях.

Что тебе сейчас больше всего нравится в работе?

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

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

В данном случае менять работу — это необязательно плохо. Человек построил дом, вот он готов, дом построен — это хорошо или плохо? Ну, хорошо, наверное, дом построен. Так и тут. Дальше приходят маляры, сантехники, которые тоже сделают свою работу и уйдут. Это не плохо. Плохо, если они не уходят.

Получается, ты объединяешь коллектив, но сам не становишься частью этого коллектива?

Моя задача — не стать лидером в команде, моя задача — помочь выявить лидеров в этой команде. Поэтому если я становлюсь частью команды, это значит, что я сделал свою работу плохо. Это значит, что я демотивировал натурального лидера, не дал ему/ей выделиться, проявиться.

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

Зеркалолук от Олега Придюка

Следующий шаг твоей профессиональной эволюции — своя компания?

Мне нравится то, что я делаю сейчас. Мне нравится работать на разные компании, помогать разным командам и решать очень разные задачи. Мне нравится, что мои задачи и мои контракты конечны. Я чувствую, что приношу пользу и делаю мир и людей немножечко лучше. Это, пожалуй, не звучит, как идея для стартапа-единорога, а что-то меньших масштабов делать, наверное, для меня не имеет смысла. =)

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Следующая публикация

Результаты исследований польского рынка лайв-стриминга за 2019 год. Портрет аудитории, которая смотрит стримы

Ср Апр 15 , 2020
Сервис streamerzy.pl с 2016 года проводит исследования рынка лайв-стриминга в Польше. Предлагаем посмотреть результаты исследований за 2019 год. Из 2449 респондентов 88,8% смотрят стримы, 11,2% респондентов сами являются стримерами. 94% опрошенных среди тех, кто ответил, что смотрят стримы, —  мужчины, больше всего среди них представителей возрастной категории 15-18 лет. Чаще ...