Teamlead Good Reads – ежедневные советы про менеджмент людей и команд

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

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

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

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

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

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

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

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

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

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

Результаты 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%.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Манипуляции при увольнении

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

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

Как менялась корпоративная культура в России

Забавное микроисследование российских объявлений о работе за период с 90х по наше время, которое показывает, как менялись основные ценности корпоративной культуры, а рынок колебался от работодателя к работнику.

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

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

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

Как защищать свои идеи

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

Несколько советов из статьи:

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

Про аллокацию ресурсов на задачи

Приходилось ли вам когда-нибудь распределять приоритеты работы, управляя процентом выделяемых ресурсов на несколько направлений? Например, 20% времени планировать тратить на техдолг, 50% – на новые фичи, а еще 30% – на поддержку существующей функциональности. Если да, то у меня новости – такой подход работает не очень оптимально.

👉Такой подход прячет за собой реальное определение приоритетов. Мы тратим на техдолг 20%, потому что это наименее важное для нас направление, или потому что нужно обслуживать более срочные задачи?
👉Помимо приоритетов, он прячет и наши ожидания от вложенных ресурсов. Что именно мы ожидаем от вложения 20% ресурсов в техдолг? Точно ли этого достаточно? Как вообще определяется достаточность?

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

Исследование руководителей разработки

Недавно я собирал с вас вопросы для большого исследования тимлидов, которое проводят ребята из DevCrowd. Так вот, они наконец-то запустили сам опрос про условия работы, зарплату, важные навыки и сообщество.

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

Как нанять СЕО

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

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

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

Нерегулярная рубрика на канале – "Какие подкасты про тимлидство послушать". Погнали:

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

Антипаттерны в работе со сложными системами

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

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

Underperformers

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

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

"Перфоманс Васи в команде Х в работе над проектом У ниже ожиданий" вместо "Вася – лоуперформер".

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

Еще раз про то, насколько тяжело сейчас будет джунам

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

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

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

Короче, ничего нового – те же самые советы джунам давали и до AI. Отличие только в том, что раньше найти работу можно было и просто научившись работать с API пары фреймворков, а теперь этого будет совсем недостаточно.

Метод, методология и методика

Я постоянно путаю эти три термина, и меня не раз ругали за это. Недавняя статья на Хабре хорошо укладывает все три определения в понятную стстему:

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

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