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

Чем бы вы ни занимались в наступающие выходные, вы можете сделать их еще немного лучше, послушав что-то из новых выпусков менеджерских подкастов!

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

Десять причин для увольнения

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

👉Отсутствие нормальной системы онбординга
👉Любое изменение условий труда
👉Отсутствие карьерного или профессионального роста
👉Отсутствие понятных процессов
👉Постоянное изменение приоритетов в работе
👉Состояние собственного здоровья или здоровья родственников

Вопросы к работодателю при трудоустройстве топ-менеджером

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

👉Какой бюджет у организации, которой предстоит управлять? Насколько этим бюджетом можно распоряжаться?
👉Если роль не новая, почему с нее ушел предыдущий человек?
👉Рассматривали ли вы на роль внутренних кандидатов, и если нет, то почему?
👉Является ли моя команда profit или cost center?
👉Что происходит с бизнесом: что с финансами, насколько быстро они сгорают, есть ли стратегия экзита?
👉Кто входит в команду топов, вхожу ли в нее я, как эта команда работает друг с другом и с остальной компанией?

Что делает инженера хорошим

Автор предлагает такое определение:

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

Оно раскладывается на несколько конкретных идей:

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

А что вы считаете отличительными чертами хороших инженеров?

Качество – ответственность тестировщиков

Кажется, в блоге Qase не было еще ни одной статьи, которой мне не захотелось бы поделиться в канале. В этот раз Виталий Шароватов разбивает миф про то, что качество – ответственность тестировщика.

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

Оргдизайн от конфликтов

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

Структурируйте команду так, чтобы до вас доходили только нужные конфликты.

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

Бюджетирование в продуктовых компаниях

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

Нанимаем продактов в JetBrains

На канал, помимо тимлидов, подписано еще и очень много продакт-менеджеров, поэтому расскажу вам о вакансиях к нам в JetBrains.

Самая критичная лично для меня – сеньорный продакт в Kotlin Multiplatform. Мы делаем технологию, которая позволяет очень гибко делать кроссплатформенные приложения, супер-просто интегрирующиеся с нативным кодом. KMP официально рекомендует Google для шаринга бизнес-логики между iOS и Android, а в своих продакшн проектах используют крупняки вроде Netflix, McDonalds, Forbes и Bolt. Так вот, наша цель – сделать KMP дефолтным решением для создания кроссплатформенных приложений. Нам очень сильно нужен продакт, который будет отвечать за стратегию, рост и монетизацию всего большого value stream, связанного с KMP. Технический бэкграунд важен, но опытным программистом быть не обязательно. Гораздо важнее богатый продуктовый опыт, хорошая чуйка и сильные продуктовые харды.

Помимо вакансии ко мне в команду, мы ищем продактов и в другие департаменты. Вот некоторые из них

👉Head of Product в YouTrack – вывести наш таск-трекер на новые вершины
👉Head of Product в .NET – отвечать за развитие наших IDE и других девтулов для разработчиков из Microsoft экосистемы
👉Lead Product Manager в IntelliJ IDEs – управлять группой продактов, которые отвечают за IDE на базе IntelliJ
👉Lead Product Manager в AI Enterprise – делать лучшее B2B решение для использования AI ассистента

Нанимаем в кучу локаций: Нидерланды, Германия, Кипр, Сербия, Армения. Гораздо больше деталей есть в описании вакансий, но смело пишите мне в личку, расскажу все, что знаю!

Предупреждайте, а не просите разрешения

Проще сделать, и попросить прощения, чем получать разрешение.

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

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

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

Как проводить skip level митинги

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

Вот несколько советов, как вытащить максимум пользы из этих встреч:

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

Парадокс Тога

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

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

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

Про найм сеньоров

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

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

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

Моделируем рост инженерной команды

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

Автор строит довольно простую модель, в которой можно покрутить несколько вещей:

👉Частота найма для каждого грейда
👉Частота повышения между грейдами
👉Частота увольнений на каждом грейде

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

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

Как менеджерам не попасть под сокращения

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

Какие категории сотрудников обычно попадают под сокращения:

👉Accodentally Invisible. Работа, которую они делают, не видна топ-менеджменту, даже если она важная
👉Faded Glory. Когда-то сделали важный проект, но в последнее время он перестал быть кому-ьо интересен.
👉Needs Auxiliary Management. Есть заметные со стороны проблемы с качеством работы, коммитментами, софт-скиллами, так что для работы с ними требуется прилагать больше усилий.
👉Kingdom of None. Если всю или значимую часть команды сокращают, то менеджер попадает туда же под раздачу. Это касается не только прямого менеджера, но и любых технических лидов.

Вот несколько советов, как тимлиду и его команде уменьшить свои шансы попасть под лэйофф:

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

Опасность и вред метрик в менеджменте

Самая важная цитата Питера Друкера, которую вам надо помнить:

What gets measured gets managed—even when it's pointless to measure and manage it, and even if it harms the purpose of the organization to do so.

Вторая самая важная цитата:

It is the relationship with people, the development of mutual confidence, the identification of people, the creation of a community. This is something only you can do… It cannot be measured or easily defined.

Откуда берется вред измерений:

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

Как группа становится командой: фаза нормализации

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

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

Исправляем недостаток стратегического фреймворка Румельта

Продолжаю топить за то, что лучшая книга, которая может вас научить тому, что такое стратегия – "Good Strategy, Bad Strategy". Ключевая идея автора книги, Ричарда Румельта, в том, что хорошая стратегия должна строиться вокруг челленджей, которые компании требуется преодолеть, чтобы достичь своих целей. Вокруг этих челленджей выстраивается ядро стратегии – набор "направляющих политик" – принципов, по которым вы работаете, и конкретных усиляющих друг друга действий.

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

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

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

Ошибки начинающих техлидов в принятии решений

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

Как пример – техлид может затащить автотесты в проект, в котором они только мешают, тем самым саботировав их использование командой в будущем в других местах.

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

Про приоритизацию в больших компаниях

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

Про системное моделирование

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