20% на техдолг не работают

👉Вместо единого бэклога появляются два – продуктовый и технический. И в технический постепенно начинает попадать все, что не фичи – решение багов, автоматизация рутины, обновления библиотек и решение проблем безопасности. А тот факт, что эти задачи приносят ценность пользователям, начинает игнорироваться.
👉Перенос задач в технический бэклог без определения их business value приводит к тому, что они воспринимаются менеджментом как низкоприоритетные, и легко могут вытесняться важными продуктовыми задачами.
👉Так как время выделяется не на решение конкретной проблемы, а на широкий зонтик задач, очень легко размыть фокус, броситься одновременно исправлять много вещей, и не получить значимого прогресса нигде.
👉Как только организация выделяет под "технические задачи" 20% времени, становится очень легко начать их откладывать. Если раньше вы одновременно с реализацией какой-то фичи могли поправить связанную с ней техническую проблему, то теперь гораздо чаще будете встречать сопротивление этому со словами "сделаете в выделенные 20% времени".
👉20% времени – на самом деле не очень много. Если вашей системе требуется действительно серьезная переработка, она может растянуться на годы.

Подборка вопросов для референс чека

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

По ссылке – хорошая подборка вопросов, которые стоит задавать при сборе рекомендаций. Вот некоторые из них:

👉Были ли какие-то области, в которых вас удивило, что кандидат был не так хорош, как вы ожидали? А где он наоборот был выше ожиданий?
👉Есть ли разница в том, как кандидата опишут его руководитель, коллега и подчиненный? В чем она?
👉Что из того, что кандидат делал, часто оставалось незамеченным или недооцененным?
👉Расскажите про случай, когда кандидат поменял свое мнение о чем-то. С какого на какое мнение он поменял, что это вызвало?

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

Инструкция по организации онбординга

Я уже как-то делился подкастом про онбординг, который мы записывали с Женей Антоновым. Теперь его классную инструкцию про то, как максимально сгладить первые рабочие недели новичка, можно прочитать и в виде статьи. Рекомендую!

Для затравки, некоторые тезисы:

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

Почему советы часто не работают

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

👉Чтобы понять ваш совет, надо обладать вашим жизненным опытом, без него он неполный.
👉Люди могут просто не понимать ваш совет, особенно если он идет вразрез с их оценкой реальности.
👉В целом они согласны с вашим советом, но по какой-то причине в глубине души им кажется, что он не сработает. Например, потому что требует слишком много нестандартных усилий, а результат не гарантирован.
👉То, что сработало для вас, вообще не обязательно сработает и для других.
👉Людям может не хватать понимания контекста, чтобы оценить и принять совет.
👉У проблемы, на решение которой направлен ваш совет, и у того, почему ему не следуют, может быть один руткоз.

Как работать с кандидатами после того, как они приняли оффер

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

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

Что происходит с рынком джунов в России

Я не очень сильно доверяю зарплатной статистике Хабра, но картина все равно интересная:

👉2024 год не стал хуже в сравнении с 2023. Конкуренция за вакансии стажеров и джунов осталась на том же уровне, где-то 80 откликов на каждую.
👉Больше всего джуновых вакансий среди бэкендеров. За ними идут, понятное дело, фронтендеры, и, удивительно, системные аналитики. Близких моему сердцу мобильных разработчиков нет даже в топ-10.
👉Зарплаты за год чуть-чуть подросли, примерно на 7%.
👉Джунов часто берут на удаленку, доля таких вакансий – 60%.

Как быть одновременно поддерживающим и требовательным

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

Новые выпуски тимлидских подкастов

Лучше регулярных походов в спортзал только регулярные походы туда под хорошие подкасты. И я вам принес сразу пачку новых тимлидских выпусков:

👉Подлодка про корпоративное обучение: как строить внутренние и внешние программы обучения, оценивать пользу от них и откуда брать экспертов.
👉Бреслав и Ложечкин про переговоры с топами: как тимлидам защищать результаты своей работы, получать ресурсы и поддержку.
👉Три тимлида заходят в бар про оценку руководителей: как понять, хороший ли ты тиилид, или просто с командой повезло.
👉КОДА КОДА про конструктивные коммуникации и конфликты: про ошибки в общении, манипуляции и работу с эмоциями.

Тимлид не спит: команда двачеров

Спустя пару недель работы тимлидом в новой команде, вы понимаете, что попали в команду двачеров, которые обмениваются в закрытом чате мемами за гранью рабочей этики. Что делать – оставить все как есть, или выбрать душный, но этичный путь?

К чему все это – в нашем новом проекте "Тимлид не спит" мы запустили разбор первого кейса! Работает все так:

👉Сегодня собираем ответы подписчиков (не в этом канале, а вот тут)
👉Завтра публикуем разбор кейса несколькими экспертами
👉Подписчики выбирают самый лучший вариант разбора. Участвуют и эксперты, и ответы из комментариев!

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

Техники таймменеджмента, которые работают

Под большинством из этих техник я могу подписаться сам, потому что мне они очень сильно помогают.

👉Не просто набирать себе тудушки на день, а закидывать их слотами в календарь. Для меня это оказалось настолько полезно, что я даже пересел с любимого тудушника Things на NotePlan, который позволяет очень легко распределять твои задачи по календарю.
👉Если какая-то задача занимает меньше нескольких минут, сделать ее не откладывая. Я подхожу к этой рекомендации немного по-другому – откладываю вообще все задачи в инбокс, но гарантированно разбираю его утром следующего дня, и все микрозадачи оттуда делаю сразу же.
👉Поддерживать список "waiting for" – заблокированные кем-то задачи, или штуки, которые вы кому-то делегировали.
👉Каждый день выбирать 1-3 самых-самых главных цели, под которые вы в первую очередь будете оптимизировать свой день.
👉Выделяйте в календаре продолжительные слоты времени под deep work, сосредоточенную работу, во время которой вас не будут отвлекать митинги и переписки.
👉Постарайтесь никогда не ставить митинги раньше определенного времени. Утро – самая продуктивная часть дня, и лучше потратить ее на ту самую deep work.
👉Никогда не выходите из режима "Не беспокоить". Ну серьезно, на большинстве ролей никто не умрет, если вы не ответите на сообщение в Slack в течение пары часов.
👉Уводите как можно большую часть работы в асинхронный режим. Почти любую встречу можно с гораздо большим успехом заменить на подготовку документа и его асинхронное ревью.

Собирательство, рыбалка, золотоискательство

Мне понравилась предлагаемая в статье модель разделения всей работы, что делается в продуктовой компании, на три типа:

🍓Собирательство. Решение некоторых проблем настолько же прямолинейно, насколько сбор клубники с грядки. Нужно много раз проделать одно и то же заученное движение. Как ни старайся, значительно эту работу не оптимизировать. Но делать ее при этом надо, иначе клубника сама себя не соберет. Аналоги такой работы в продуктовой разработке – решение багов в продукте, разработка необходимых продукту фичей, оптимизация производительности.
🐟Рыбалка. Где-то в океане есть рыба, но вы точно не знаете, где она. Скилловый рыбак знает нужные споты, и умеет быстро ловить рыбу, поэтому может получить нужный улов за пару часов. Плохой или невезучий рыбак легко может вернуться с пустым ведром. Это работа, которая, скорее всего, даст результат при нужном уровне скилла и везения, но иногда может привести и к провалу. Аналоги в разработке – запуск новых продуктов на известную аудиторию с известными болями, добавление каких-то крупных фичей, которые дают вам конкурентное преимущество, поиск возможностей срезать косты.
⚱️Золотоискательство. Каким бы скилловым вы ни были, вы можете потратить всю жизнь, пытаясь намыть золото из речной воды. Это редкая удача, которая довольно слабо зависит от ваших усилий. Аналоги в разработке – запуск продуктов на незнакомых рынках, тестирование новых бизнес-моделей, поиск технологических прорывов.

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

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

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

Публикуем второй кейс!

👉Кейс #2: +40% к зарплате или провалить проект

Через полгода вам нужно запускать новый продукт, работы еще дофига, но по предварительным оценкам вы должны успеть. К вам приходит один из трех фронтендеров, и показывает оффер в другую компанию, где ему предлагают +40% к текущей зарплате. Если он уйдет, вам надо будет либо двигать сроки запуска проекта, либо менять его скоуп – а это и для бизнеса очень больно, да и с вашей премией придется попрощаться. Если вы согласитесь поднять ему зарплату до того же уровня – она станет существенно выше, чем у остальных фронтендеров, от которых он по скиллам и перфомансу не сильно отличается.

Что вы будете делать? Делитесь в комментариях! И не забывайте голосовать за лучший вариант 👍🏻

Если хотите разобрать ваш кейс, пишите в специальный бот @TeamleadDoNotSleepBot.

Алгоритм работы с людьми с плохим перфомансом

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

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

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

Founder Mode

Весь англоязычный твиттер на прошлой неделе обсуждал новое эссе Пола Грэхема, "Founder Mode". В чем суть – по умолчанию считается, что в успешных стартапах, которые вошли в фазу роста, фаундеры переходят в режим менеджеров. Они делегируют большие зоны ответственности нанятым топ-менеджерам, перестают сами погружаться в детали, и совсем забывают о продукте, который их компания разрабатывает. Из-за того, что нанятые менеджеры в первую очередь заинтересованы в личном успехе, а не в успехе компании, постепенно принимается ряд субоптимальных решений, которые делают когда-то эффективную команду чем-то медленным, неповоротливым, и постепенно проигрывающим конкурентам.

Альтернатива – режим фаундера. Вместо делегирования вообще всего, владелец компании активно погружается в детали, устраняет весь возможный буллшит, и принимает много самостоятельных решений. А главное – опирается не только на мнения топ-менеджеров, но поддерживает постоянный контакт с теми, кто на самом деле делает продукт.

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

Еще несколько связанных ссылок:
👉Твиттер-тред про то, в чем именно заключается полезный founder mode
👉Подкаст с фаундером Airbnb, где он рассказывает свой опыт трансформации компании в пресловутый founder mode

Кстати, мы выложили новый кейс в "Тимлид не спит". В этот раз разбираемся, как быть с лоу-перформером на испытательном сроке. Приходите обсуждать!

Коллаборативный подход к найму

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

Ловушка гибкой конфигурации

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

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

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

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

👉Избавиться от риска, минимизировав количество зависимостей. В целом, зависимости могут создаваться на трех уровнях: бизнес-требования, инженерный процесс и компоненты системы. Чтобы понять, что делать, вам надо определить, с каким из этих уровней вы столкнулись, и нужным образом пересобрать команду или границы ее области ответственности.
👉Митигировать риск, уменьшив негативные последствия, вызываемые зависимостями. В основном все крутится вокруг того, что команды, зависимые друг от друга, должны работать максимально тесно, с малым количеством переключений контекста и отвлечениями на другую работу. Помочь с этим могут практики вроде общих стандартов разработки, единого бэклога на все команды, организационные паттерны вроде платформенных команд, да и в целом распространение знаний.
👉Управлять риском, организовав координацию между такими командами. Тут помогает грамотный процесс планирования, в рамках которого зависимые команды могут работать как последовательно, так и параллельно.