Teamlead Good Reads – тимлиды, архитектура, менеджмент людей и разработки

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

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

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

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

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

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

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

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

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

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

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

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

@vkhosla/how-to-hire-a-ceo-2912354ceca5' rel='nofollow'>Как нанять СЕО

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

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

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

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

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

Underperformers

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

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

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

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

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

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

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

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

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

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

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

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

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

4 года холакратии

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

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