Мы в современном контентоцентричном мире как-то привыкли, что «светиться» больше и чаще - это плюс. Хотя публичность для многих людей непривычна и некомфортна. А если на работе приоритетная коммуникация - «человек-машина»? Тогда «выход из тени» 100% будет стрессом. Почему «опубликуйте лучше от компании» и «пусть лучше тимлид выступит» до сих пор актуальны?
Нелюбовь к хайпу
Разработчик может оценивать свою работу критично и сверхкритично. С его точки зрения сервис, о котором его просят рассказать, ещё «сырой» и будет готов только через N итераций. Это часто входит в противоречие с маркетинговой стратегией компании - бывает важно заявить о начале разработки или новой фиче раньше конкурентов, чтобы «застолбить место» и закрепить лидерство за собой. С позиции разработчика это «опять наобещаем лишнего, а потом в мыле будем допиливать». Не хочется быть «обещатором» и получать косые взгляды от команды.
Что делать: реализовать (и отстоять перед руководством) версию статьи или доклада с верно заданными ожиданиями. Не выпускать промо-тексты без технического ревью - ведь спросить технарей о корректности формулировок обходится дешевле, чем терять клиентов или кадры.
Боязнь критики
Обратная связь далеко не всегда бывает позитивной. Комменты на Хабре и вопросы после выступления на конференции - отдельный стоппер для авторов и спикеров. При этом негатив от явного неадеквата легче отфильтровать и забыть. А вот обоснованное указание на пробел в знаниях может заставить специалиста надолго усомниться в собственной экспертности. Грустно, когда первая попытка поделиться опытом оказывается и последней.
Что делать: до выпуска материала отдавать его на вычитку экспертам, чтобы отловить большую часть каверзных вопросов и противоречий внутри. Аналогично с докладами - не пренебрегать внутренними прогонами, несмотря на всеобщую занятость. Постараться внедрить в компании общую культуру принятия (и формулирования) обратной связи. Разъяснить, что критика работы не равна критике личности и что уточнение или недопонимание не равно критике. Ну, и провести встречу со спикером/автором по обратной связи, чтобы понять его настроение - классика.
Риски безопасности
Любой вынос внутренней «кухни» вовне потенциально опасен. И недосогласованный кейс, и не замазанный кусок конфиденциальных данных на слайдах, и случайная «оговорочка по Фрейду», и старое ПО с известной уязвимостью - всё это потенциальные убытки или ущерб репутации. Авторам статей несколько проще - текст до выхода и после вычитывают много раз. Слайды тоже проверяют. А вот отвечать на вопросы надо сразу «набело», поэтому докладов многие избегают.
Что делать: иметь в компании простой и понятный чек-лист для сведений, которые точно конфиденциальны. Организовать flow согласований (тех.ревью, PR, в отдельных сложных случаях - безопасники). Тренировать ответы на вопросы с коллегами и ИИ, иметь готовые «ответы-заглушки» для ситуаций, когда дело касается NDA.
Психологический дискомфорт
Оказаться перед толпой скептически настроенных людей, среди которых точно есть конкуренты и специалисты с большей экспертизой - испытание на прочность. Страх публичных выступлений имеет древние корни. Наши далёкие предки тоже дрожали, если им почему-то приходилось противопоставить себя племени: изгнание означало смерть. Следуя этой аналогии, стать докладчиком - значит пройти путь от рядового члена племени до вождя или шамана. Кто-то сознательно отказывается от этой роли.
Что делать: понимать, что «продать» идею публичности можно не всем и не сразу. Начинать с форматов, где «племя» виртуально и обратная связь асинхронна, закрепляя каждый успешный шаг. Много и часто хвалить за маленькие победы. Обязательно рассказывать об успешных примерах коллег. Согласовать систему мотивации. И, самое главное, договориться оставить в покое тех, кто прекрасен в разработке, но скорее уволится из компании, чем пойдёт на сцену.
...продолжение следует...