Личный опыт: как выстроить культуру в компании и избежать текучки
Уже на старте нужно брать в команду тех, кто подхватит ценности фаундеров и, если понадобится, будет выполнять функции сразу нескольких разноплановых специалистов. Это один из нескольких принципов, которыми мы руководствовались при запуске конструктора резюме Resume.io (летом 2021 года приобретен американским холдингом Talent Inc.). Рассказываем, как корпоративная культура помогает нам развивать продукт небольшой командой и что мы сделали для того, чтобы не потерять свои ценности при слиянии с корпорацией.
Найти «своих»
При сборе команды стартапа недостаточно найти квалифицированных людей с релевантным опытом. Фаундерам нужно лично пообщаться с каждым кандидатом и понять, что может пойти не так и смогут ли они сойтись во мнениях. Умение договариваться и быстро принимать решения — главное на первых этапах развития компании.
Собственно, для этого и нужна корпоративная культура — чтобы фаундеры могли определять «своих» людей. Они формулируют, что для них важно, а потом учитывают это при поиске кандидатов. Конечно, можно довериться своей интуиции, но когда положения культуры четко прописаны в документе, ее проще транслировать, поддерживать и использовать при найме.
Раньше мы следили за лучшими практиками в этой сфере, читали литературу и общались с основателями компаний, которые нам нравились. В результате вырисовалось несколько общих принципов, с которых можно начать формулировать культуру, — честная и регулярная обратная связь (например в формате звонков один на один с сотрудниками), максимальная прозрачность в процессах благодаря популярным фреймворкам вроде Scrum, профилактика выгорания сотрудников путем демонстрации адекватного рабочего режима на личном примере.
Но долго развиваться на этом базовом наборе ценностей не получится, поскольку они постоянно меняются. Например, Basecamp недавно запретила сотрудникам заниматься активизмом и разговаривать о политике на работе, после чего многие ее сотрудники уволились.
Кроме того, культура должна быть основана на фактах, а не на выдумках основателей. Прежде чем обновить список ценностей, мы вспоминаем и оцениваем события, случившиеся за год: какие релизы у нас прошли успешно и почему, в какие моменты команда получила наибольшее удовольствие от работы. Полезно также периодически спрашивать у сотрудников, что им нравится в компании. Их ответы мы записываем и смотрим, какие варианты часто повторяются. Если попадаются какие-то интересные ценности — думаем, как ускорить их внедрение в наши процессы.
Дженералисты с правом на ошибку
Культура — это про то, как вы нанимаете и как выстраиваете работу с нынешними сотрудниками. Всего за время своего существования мы взяли в российскую команду 20 человек. У нас небольшая текучесть — поэтому нет потребности постоянно искать новых людей.
Для планирования найма мы построили организационную структуру — по ней смотрим, в каких сотрудниках компания нуждается сейчас, а какие будут нужны в скором времени. Вот какими принципами мы при этом руководствуемся:
№1. Дженералисты — наши люди. Они готовы из любопытства запрыгнуть в совершенно новую для них сферу. Например, если разработчику нужно понять, как работает маркетинг, он пойдет читать статьи, пообщается с коллегами и разберется.
У нас даже одно из тестовых заданий рассчитано на дженералистов. Разработчику нужно создать маленькое самодостаточное приложение с упором на дизайн. Конечно, мы не требуем от кандидата безупречных навыков в UX/UI, но смотрим, как он справится с задачей.
№2. Заранее выстраиваем связи с потенциальными членами команды. Для этого часто заходим на GitHub, просматриваем проекты и добавляем в закладки новых интересных людей. Подписываемся на разработчиков и дизайнеров в Twitter, списываемся с ними и иногда встречаемся, — этот исследовательский процесс никогда не останавливается. Зато когда в команде появляется вакансия, мы уже знаем, кто нам нужен и где его искать.
№3. Мы осторожны в работе с рекрутинговыми агентствами. Большинство из них заточены на то, чтобы быстро снабжать крупный бизнес бесконечным потоком людей. Для нас же важно, чтобы агентство нашло кандидата, подходящего компании и по навыкам, и по культуре. Для этого оно должно провести качественный скоринг и прислать нам четыре-пять отобранных специалистов с нужными характеристиками.
№4. Берем людей, которые делают ошибки, но умеют их объяснять и признавать. Для этого предлагаем кандидату выполнить тестовое задание, а после — даем обратную связь. При этом делаем упор на функциональные правки, а не на стилистические. Комментарии «Мне не понравилось, как ты назвал переменную» или «А здесь можно было лучше» — не подходят. То, что человек допустил какие-то ошибки, еще не означает, что он не справился, — возможно, он недостаточно хорошо понял задание. Во время разбора выполненной работы смотрим, умеет ли кандидат аргументировать свою позицию и признавать свою неправоту.
№5. Мы не спешим с оффером. Бывает так, что попадается как будто бы «золотой» человек по уровню навыков. Но отлично выполненное тестовое задание еще не дает никаких гарантий. Поэтому, прежде чем брать кандидата в команду, мы стараемся с ним немного поработать, — обычно хватает двух-трех недель, чтобы понять, как человек мыслит, коммуницирует и какие решения предлагает. Такую «пробу» мы обязательно оплачиваем.
Тестируем, упрощаем и веселимся
Следующие аспекты культуры помогают нам долго работать одним составом без потерь сотрудников:
№1. Системно подходим к экспериментам. На втором году существования компании мы начали все замерять и тестировать. И за этот процесс ответственны не аналитики или продакт-менеджеры, которых у нас тогда даже не было, а сами разработчики. У них есть доступ к базе со всеми A/B тестами, фреймворк для тестирования и наша готовность купить любой необходимый инструмент.
Если тест не дает результатов, сотрудник должен сам предложить изменения в эксперимент. Причем не стоит целый месяц делать один функционал — правильно выпускать фичи до безумия короткими итерациями. Такой формат позволяет разработчикам увидеть, как их работа влияет на продукт.
№2. Фокусируемся на первоначальном запросе. Бывает, к продуктовой команде приходят из маркетинга и говорят: «Выполните вот такую задачу». В этот момент нужно остановиться и спросить: «Подождите, а какую проблему мы этим решаем? Давайте разберемся, что вам нужно починить». Чаще всего проблема оказывается не в том, чтобы написать код или поменять дизайн, — иногда достаточно просто с кем-то поговорить.
№3. Стремимся к минимальным усилиям. Выполняя любую задачу, спрашиваем себя, от каких этапов можно отказаться, а какую коммуникацию — упростить. Иначе велик риск выгорания. Мало в каких задачах уместен перфекционизм в процессах.
№4. Приходим к законченности на каждом этапе. Есть команды, которые делают проект на скорость, стремительно растут и привлекают деньги. А когда приходит время масштабироваться, оказывается, что продукт невозможно поддерживать, — он оброс legacy, документации просто нет или непонятно, как к ней подступиться. Приходится переписывать все с нуля и терять полгода-год, что непозволительно, — за такой срок можно упустить свои преимущества на рынке. Иногда большой рефакторинг заканчивается неудачей — получается хуже, чем было. Некогда популярный браузер Netscape «убило» как раз полное переписывание кода.
Наши сотрудники руководствуются принципом: что бы ты ни делал на скорую руку, подумай о том, как будешь это потом менять или поддерживать. В результате у нас получается легко «онбордить» сотрудников — им не нужны месяцы, чтобы разобраться в проекте, благодаря понятной документации и списку быстрых решений, которые в будущем нужно усовершенствовать.
№5. Не сводим работу к сухим алгоритмам. Мы любим веселиться. Например, когда переходили на новую версию редактора, решили празднично отправить предыдущий «движок» на пенсию. Переместили код в отдельный репозиторий, назвали его war machine или «машина-убийца», придумали историю про ветерана, который отслужил свое и теперь отправляется на покой. А потом отдавали ему честь в чате.
Кто-то подумает, что это пустая трата рабочего времени, а нам кажется, что без таких штук трудно получать удовольствие от процесса и работать над одним продуктом долго.
Культурное партнерство
Мы долго откладывали поиск партнера. Опасались, что при расширении штата, которое следует за слиянием, потеряем сформированную культуру. Сейчас страхи позади, потому что, оказалось, есть удобный способ сохранить ценности — оргструктура с делением продуктовой команды на поды. Похожий подход, к примеру, используют в Amplitude — эта компания разбивает 35 своих сотрудников на 6–10 подкоманд.
Легко соблюдать какие-то принципы в маленькой команде из пяти человек. Но когда вас становится 20, 50 или 100 — делать это намного сложнее. Зато можно легко масштабировать культуру на большой штат сотрудников через репликацию. Другими словами, создавать много маленьких команд и передавать лучшие практики от одной к другой: как мы планируем, как принимаем решения, как синхронизируемся внутри и между подами, какие метрики учитываем. Получается естественный процесс обучения, который также делает работу интересной для сотрудников, а значит — снижает текучесть. Например, наша оргструктура сейчас состоит из трех команд, — каждая отвечает за «минимальный продукт» с определенными метриками.
Отдельного обсуждения корпоративной культуры с Talent Inc. у нас не было — и в будущем мы его не планируем. Изначально мы искали партнера, который работает по принципам, схожим с нашими. Если со временем культура будет меняться (а это наверняка произойдет), изменения произойдут уже в новой, объединенной команде.
