Как построить найм студентов

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

Ребята из МойОфис рассказывают, как запускали два потока студенческих стажировок и с какими сложностями столкнулись. По цифрам результат такой:

👉50 собеседований на входе воронки, 5 наймов спустя 3 месяца.
👉4 из 5 нанятых остались в компании после испытательного срока.

Пост для всех, кто любит новогодние подарки с пользой

Грейд клуб от Яндекс Практикума запустил адвент-календарь для руководителей цифровых команд.

Грейд Клуб — сообщество для нетворкинга цифровых лидеров и площадка для поиска решений о том, как драйвить рост IT-команд.

На протяжении трех недель пользователи будут получать классные подарки от клуба и его партнеров. А их собралось внушительное количество: Эйч, МИФ, Ясно, Кинжал и топовые эксперты индустрии.

Внутри вас ждут:
🎁Полезные фичи для мессенджеров
🎁Билеты на отраслевые конференции
🎁Гайды по эффективному лидерству и другие полезные подарки.

Переходите в бот адвент-календаря, чтобы не пропустить подарки!

ООО Яндекс. ИНН 7736207543

Бреслав и Ложечкин про обратную связь

Вышел новый эпизод дочернего проекта Подлодки – подкаста для менеджеров "Бреслав и Ложечкин". В этот раз разговор идет про обратную связь: когда и кому она нужна, сколько времени на нее тратить и с какими подводными камнями можно столкнуться.

Как запрашивать фидбэк на свою работу

Типичная история – вы работаете над какой-то идеей, запрашиваете у коллег фидбэк, и вместо чего-то полезного получаете поток обратной связи про несущественные аспекты и косметику. Чтобы этого избежать, надо заранее проговаривать, фидбэк какого типа вы ожидаете. Вот одна из моделей:

👉Работа завершена на 5%: "Согласны ли вы с проблемой, которую я решаю?"
👉Работа завершена на 30%: "На правильном ли пути я нахожусь с моим решением проблемы?"
👉Работа завершена на 60%: "Является ли решение разумным, достигнем ли мы с ним наших целей?"
👉Работа завершена на 90%: "Пропустил ли я что-нибудь?"
👉Работа завершена на 100%: "Что в следующий раз надо сделать по-другому?"

Обязательные знания для тимлида

Сегодня вечером пишем выпуск Подлодки, в котором будем вместе с Виталием Шароватовым разбираться, что должен знать настоящий тимлид. Чтобы выпуск получился более живым, мы хотим собрать побольше мнений сообщества.

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

Как убедить всех замедлить разработку

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

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

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

Универсальное правило для продуктивной работы

Держи голову свободной! Тебе никогда не придёт в голову гениальная идея, если она всегда забита операционными мелкими задачами. Помнишь, как ты придумывал что-то перед сном или в отпуске? А сколько из этих идей моментально забывались?

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

О том, как система тайм-менеджмента может помочь достичь такого состояния расскажут на вебинаре 16 декабря в 20:30 по мск. Участие бесплатное, надо лишь зарегистрироваться в боте

Навигаторы как замена архитектурным комитетам и командам

Про проблемы, вызываемые в компании наличием централизованной функции архитекторов, в канале мы обсуждали уже много раз (как минимум вот). При этом польза от них тоже есть, как минимум в том, чтобы любые технические вопросы не эскалировались до СТО. Один из вариантов замены – навигаторы.

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

Как деливерить быстрее

Набор принципов, некоторые из которых показались мне интересными:

👉Protect momentum. Чем чаще вы что-то релизите, тем выше получается держать уровень мотивации и энергии в команде. Длинные циклы разработки приводят к выгоранию и потере контакта с пользователем.
👉Beware of prioritization. Бессмысленно тратить много времени на приоритизацию, когда все, что действительно важно – это какую задачу делать прямо сейчас, а какую – следующей.
👉Only doers can plan what you work on. Как только за планирование начинают отвечать оторванные от разработки люди, появляется искуственное раздувание сроков разработчиками, которые не хотят промахиваться в оценках. А работа занимает все выделенное на нее время.
👉There is no quality vs speed tradeoff. Плохое качество кода замедлит вам работу в будущем. Любой компромисс такого рода – в долгую вреден. При достаточном уровне культуры разработки и скиллов инженеров можно достичь обеих целей.

Почему вы увольнялись с менеджерской работы

Я увольнялся с менеджерских позиций два раза. Первый раз был в 2016 году в Rambler&Co. У нас одним днем сменился весь менеджмент технического подразделения на каких-то очень эффективных ребят из Инновы. Первое, что они сделали – собрали всю нашу команду и начали рассказывать про Scrum и другие великие изменения, которые планируют внедрить. На любые разумные вопросы про эти изменения отвечали чем-то типа "Да я уже пять успешных бизнесов построил, когда сделаешь столько же, вопросы и задавай". После этой встречи мы завели встречи для всего iOS отдела, на которых совместно стали готовиться к интервью. Спустя пару месяцев уволился и я, и процентов 70 всей команды. Мораль, которую я для себя вынес – даже если вас нанимают ради внедрения изменений, не стоит врываться с ними с порога без внятной стратегии их исполнения.

Второй раз был уже из Авито. В какой-то момент количество скучных менеджерских задач на монй позиции стало перевешивать интересные. В частности, смешно получилось с перфоманс ревью. Еще в 2017 году я начал его внедрять в компании. Со временем он эволюционировал, превращаясь во все более сложную машину. Два года спустя, сидя поздно вечером на калибровке, на которой мы несколько часов до хрипоты спорили о том, кто из двух незнакомых мне инженеров заслуживает +0.05 к оценке, я понял, что это совсем не то, на что я хочу тратить свою жизнь.

А теперь ваша очередь! Расскажите в комментариях, почему вы увольнялись с менеджерской работы.

Как в Google работает code review

Интересный разбор особенностей code review в Google – от гайдлайнов и до разбора Critique, внутреннего инструмента для ревью. Среди заметных фич:

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

Гайд по переходу к асинхронным коммуникациям

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

Тест для сборки инструкции к менеджеру

В конце года принято ретроспективно смотреть на все проекты, процессы и коммуникации. Ребята из SETTERS Media запустили тест-конструктор инструкции к себе как к менеджеру.

Как работает:
👉 Отвечаете на десять вопросов про свой стиль постановки целей, делегирования и коммуникаций
👉 Рассказываете о своих увлечениях и грузите фотку, чтобы вас ни с кем не спутали

На выходе получаете красиво сверстанную пдф, в которой подсвечены ваши основные менеджерские черты. Можно (и даже нужно) пошэрить файл с командой, потому что подтянуть коммуникации = подтянуть вообще все процессы. Пробуйте и рефлексируйте перед Новым годом!

Реклама. ООО "СЕТТЕРС МЕДИА"

Выпуск Подлодки про то, кто такой engineering director

Руководить другими менеджерами – совсем не то же самое, чем линейными сотрудниками. Записали выпуск Подлодки с Евгением Котом про то, в чем заключаются основные особенности работы инжиниринг директором от обычной менеджерской роли, и поговорили, какие знания и навыки будут обязательными.

Кому и зачем надо становиться менеджером

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

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

Тестовая неделя как способ найма

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

Неделя оплачивается. Кандидату дают доступ ко всем необходимым инструментам и ставят четкую задачу. Например, реализовать фичу, которая поможет триажить входящие тикеты. Через эту систему проходят все нанятые люди, включая топ-менеджеров. Говорят, что ретеншн-рейт команды на протяжении 4 лет составил 96%.

Как СТО развалить компанию

Представьте, что вас наняли как СТО в компанию, которую по какой-то причине вы хотите разрушить. За явный саботаж вас, конечно, уволят, поэтому нужно действовать в социально-приемлемых рамках. Вот мои любимые советы из статьи:

👉Внедрите сложный процесс приемки изменений, оправдывая его требованиями безопасности и комплаенса.
👉Требуйте вносить все задачи в трекер, а после этого проводить через ревью и приоритизацию группой не меньше 5 человек.
👉Чтобы избежать вендор-лока, настаивайте на том, чтобы реализовывать все самим вместо покупки готовых решений.
👉Поддерживайте коллективное владение кодом.
👉Наймите архитекторов и требуйте прохождения архитектурного ревью для всех изменений.
👉Привяжите зарплату к должности, а должность к размеру команды.
👉Отправляйте хай-перформеров на R&D проекты без четкой судьбы и целей.

В статье советов еще больше. Накидайте в комменты других полезных тактик незаметного развала компании.