Правило бойскаута для тимлида

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

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

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

Как в разных компаниях сотрудники получают доменный опыт

👉Uber – выделяет сотрудникам несколько сотен долларов в месяц на использование своих сервисов. Похожая схема, кстати, точно есть и у Bolt.
👉Carta, платформа для equity management, оплачивают получение своими сотрудниками соответствующей профессиональной сертификации. А для топ-менеджеров работает другая программа – каждый из них назначается "спонсором" одного из крупных B2B клиентов. Это значит, что он находится в постоянном контакте с ним, знает все про его проблемы и сценарии, и адвокатирует за него при обсуждениях роадмапа.
👉Stripe – все читают книгу про работу платежек в США, а многие еще и поднимают свой собственный магазин.
👉Intercom – на всех тимбилдингах команды пытаются проходить типичные пользовательские сценарии и встраивать формы интеркома в разные сайты.

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

Очередь задач вместо сторипойнтов

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

Как AI команда может замедлять компанию

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

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

Тимлид не спит: новый проект нашего канала

Не прошло и полугода с момента быстрого теста идеи в этом канале, и проект практически готов к старту! "Тимлид не спит" – наш новый тимлидский канал, в котором каждую неделю несколько экспертов будут разбирать различные менеджерские кейсы: про работу с людьми, построение процессов разработки, решение конфликтов, выстраивание стратегии. Экспертов будем краудсорсить, чтобы собирать людей с очень разным опытом и бэкграундами. Кейсы – тоже, потому что интересно разбирать не синтетику, а реальные рабочие проблемы.

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

А пока помогите проекту запуститься:
👉Если у вас есть интересные кейсы, которые вы хотели бы закинуть на разбор, присылайте их через бота @TeamleadDoNotSleepBot.
👉Если вы хотите выступить в роли эксперта, заполняйте форму. Сразу предупрежу – брать будем не всех и не сразу, начнем с маленького количества людей и будем постепенно расширяться.
👉Подписывайтесь на канал @tlsleep и готовьтесь к обсуждению первых кейсов!

Как разговаривать с топами

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

Результаты Stack Overflow Survey 2024

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

👉Разработчики все еще учатся программировать, читая документацию (84%), копируя ответы со Stack Overflow (80%), читая туториалы (69%), блоги (61%) и образовательные видео (54%). AI помогает только трети опрошенных.
👉Расклад по популярным языкам и технологиям в целом не очень поменялся. JS/TS, Python и Java – в самых популярных, а Rust – в самых любимых.
👉Atlassian стек тоже остается самым популярным для асинхронной коммуникации. Jira пользуется какое-то безумное количество разработчиков, половина всех опрошенных.
👉Telegram тоже удивительно популярен, его использует аж 20% разработчиков.
👉76% опрошенных используют или планирцют использовать в работе AI. При этом в сравнении с прошлым годом удовлетворенность упала – это что же получается, прошли пик перегретых ожиданий?
👉43% опрошенных доверяют точности AI, 31% – нет.
👉70% профессиональных разработчиков не считают, что AI отнимет у них работу. Среди начинашек таких меньше, всего 58%.

Рекомендации тимлидских каналов

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

Чтобы вам было удобнее их читать, я собрал их все в одну папку. Вот несколько моих любимых каналов оттуда:

👉Логриды от Макса Страхова про то, как инженерному менеджеру строить карьеру в FAANG
👉Канал Виталия Шароватова, где он делится цитатами из научных статей и книг про менеджмент
👉Авторский канал Жени Антонова с наполненными мудростью пятничными постами

🔗Ссылка на папку

Должна ли работа быть свободной от политики

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

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

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

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

Советы по организации сообществ

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

👉Короткие таймслоты упрощают подготовку спикеров и поддерживают бодрый темп мероприятия. Например, семиминутные живые демо вместо длинных докладов.
👉Автоматическая ротация хостов в маленьких сообществах. Вам не придется тащить все самостоятельно, если вы настроите систему, при которой все участники регулярно сами становятся хостами.
👉Unconference. Это, кстати, офигенный формат. Я его впервые попробовал в прошлом году, когда мы вывезли всю команду Котлина на тимбилдинг. В чем суть – вместо заранее определяемой повестки вы даете людям возможность самим выбрать темы, про которые они готовы что-то рассказать, или просто хотели бы послушать. Все клеят стикеры со своими идеями, потом за них голосуют, и из самых заплюсованных и выстраивается сетка.
👉Гейткипинг. Не бойтесь включать строгую модерацию участников ваших мероприятий. Если вы подозреваете, что кто-то не очень подходит по профилю, либо просто кажется вам неприятным человеком, вы как организатор имеете полное право не пускать его.

Может ли QA замедлять работу

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

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

Голосуем в исследовании тимлидов

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

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

🔗Опрос можно пройти вот тут, результатами поделюсь в канале

Подкасты про переговоры

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

Держите два наших недавних подкаста, которые помогут вам узнать и попробовать новые тактики:

👉Выпуск Подлодки про зарплатные переговоры с Ильей Синельниковым
👉Выпуск Бреслава и Ложечкина про сложные переговоры со всякими топ-менеджерами

Pioneers – Settlers – Town Planners

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

👉Pioneers. Инноваторы, которые любят работать в условиях неопределенности, пилить кучу прототипов, исследовать новые идеи.
👉Settlers. Практики, которые умеют брать прототипы и продуктизировать их, доводя до пользователей в надежном виде.
👉Town Planners. Те, кто умеет оптимизировать уже существующие рабочие системы, делая их более надежными, стабильными и дешевыми.

Три важных софт-скилла при найме

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

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

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

Про скип-левел встречи

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

Зачем нужны скип-левелы вверх:

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

Зачем нужны скип-левелы вниз:

👉Вы можете заметить начинающие таланты
👉Вы можете сравнить то, что говорит про климат в команде менеджер, и то, что считают сами члены команды

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

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

Кратко про social loafing (эффект, когда в группе люди прикладывают меньше сил к труду по сравнению с тем же трудом в одиночку):

основными причинами этого эффекта являются:
- излишне крупные группы
- ощущение несправедливости, возникающее от того, что люди видят, что кто-то “мало усилий прикладывает”
- “неинтересные задачи”

это что ж получается такое удивительное — людям внезапно становится скучно и неинтересно если увеличивать команды до дурных размеров а потом реальные проблемы по-барски эдак декомпозировать и раскидывать между людьми (продакт умнее пусть придумывает чо делать а тимлид умнее пусть и придумывает как делать)

кто бы мог подумать?

Рефы:
- https://journals.sagepub.com/doi/10.1177/0146167284101011
- https://psycnet.apa.org/doiLanding?doi=10.1037/0022-3514.37.6.822
- https://www.researchgate.net/publication/228608182_Social_Loafing_A_Field_Investigation
- https://journals.sagepub.com/doi/10.1177/0022002183014003009
- https://journals.sagepub.com/doi/10.1177/001872679504800603

Еще про перегрузку менеджеров

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

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

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