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

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

Про аллокацию ресурсов на задачи Приходилось ли вам когда-нибудь распределять приоритеты работы, управляя процентом выделяемых ресурсов на несколько направлений? Например, 20% времени планировать тратить на техдолг, 50% – на новые фичи, а еще 30% – на поддержку существующей функциональности. Если да, то у меня новости – такой подход работает не очень оптимально. 👉Такой подход прячет за собой реальное определение приоритетов. Мы тратим на техдолг 20%, потому что это наименее важное для нас направление, или потому что нужно обслуживать более срочные задачи? 👉Помимо приоритетов, он прячет и наши ожидания от вложенных ресурсов. Что именно мы ожидаем от вложения 20% ресурсов в техдолг? Точно ли этого достаточно? Как вообще определяется достаточность? Альтернативный подход требует немного переключить модель мышления. Распределение ресурсов должно быть следствием выбранной вами стратегии, а не самой стратегией. Один из вариантов научиться думать в такой модели – продвинутая матрица Эйзенхауэра с пятью типами работы. Попробуйте сначала определить, чего вы хотите добиться в каждом из них, а уже из этого понимания сформулируйте гипотезу о том, сколько ресурсов на каждое направление надо выделить для достижения успеха.

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

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

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

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

Underperformers Я много раз сталкивался с ситуацией, когда разработчик, который совсем не справлялся с работой в текущей команде и заметно отставал от всех остальных, полностью менялся при переходе в другую часть компании. Поэтому, мне кажется, очень важно помнить, что лоуперформеров на самом деле не бывает. Перфоманс сотрудника зависит не только от его личных качеств и уровня навыков, но и от окружения, в которое его поместили. Поэтому всегда старайтесь использовать следующую модель рассуждений: "Перфоманс Васи в команде Х в работе над проектом У ниже ожиданий" вместо "Вася – лоуперформер". Казалось бы, формулировка меняется незначительно, но при этом вы оцениваете человека с учетом окружения. А что еще важнее – принимаете часть ответственности за его низкий перфоманс на себя, ведь именно менеджер отвечает за окружение.

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

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

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

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

Как проводить осмысленные карьерные разговоры Одна из моих любимых частей книги Radical Candor – фреймворк карьерных разговоров. Основная идея простая – обсуждая со своими сотрудниками карьерное развитие, нужно в первую очередь руководствоваться тем, кем они видят себя в идеальном будущем, даже если оно вообще никак не связано с вашей компанией. Статья по ссылке раскручивает эту идею чуть подробнее, объясняя ее пользу не только для сотрудника, но и для компании. В чем суть – если при планировании карьеры руководствоваться только четко описанной матрицей компетенций, и фокусироваться только на следующем шаге, вы рискуете свалиться в локальную оптимизацию. Вместо того, чтобы думать о реальном улучшении навыков и о приносимом импакте, вы мотивируете людей искать пути побыстрее получить следующую лычку, закрыв синтетические галочки из документа с описанной карьерной лесенкой. Вместо этого попробуйте сместить фокус на то, чтобы выбирать следующие шаги развития, оптимизируя их под то самое видение идеального будущего, тем самым переключившись на глобальные оптимизации. Вот какие вопросы могут помочь это видение определить: 👉Представь себе точку своей карьеры, в которой ты занимаешься чем-то макимально классным, не хочешь ничего менять, чувствуешь полное удовлетворение от работы. Из чего в таком случае состоит твоя ежедневная рутина? 👉Какие конкретно навыки помогают тебе ощущать себя успешным в этой точке? 👉Решением каких проблем ты занимаешься в этой точке карьеры? Автор предлагает еще одну простую модель, которая помогает в таких разговорах – обсуждать два измерения роста, скоуп и импакт. 👉Скоуп показывает широту вашей зоны ответственности, размер вашей песочницы. Это количество людей, которым вы можете управлять, бюджет, которым можете распоряжаться. 👉Импакт – глубина вашей зоны ответственности. Он покрывает результаты вашей собственной работы, вашей команды, и эффективность принятых вами решений. Эта моделька скоуп/импакт удобна для того, чтобы добавить деталей каждому следующему карьерному шагу, который вы прорабатываете вместе с сотрудником.