Джунов нельзя заменять на AI

Шикарное эссе про то, почему даже с повышением качества и предсказуемости работы AI вам нужно нанимать джунов.

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

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

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

Почему data-driven подход неоптимален

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

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

Что почитать тимлиду

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

👉Dr. James Stanier «Become an Effective Engineering Manager»
👉David Marquet. «Turn the Ship Around»
👉Ю. Гиппенрейтер. «Большая книга общения с ребенком»

Обеспечение качества зависит от контекста

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

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

👉Essential domain complexity – неотъемлимая сложность предметной области, в которой работает программа. У интернет-магазина диванов она не очень высокая. У HFT системы, скорее всего, наоборот.
👉Scalability complexity – сложность, создаваемая большим количеством пользователей системы
👉Team maturity – уровень навыков команды и знания предметного контекста

В зависимости от того, попадает ли ваш продукт в ситуацию "low essential domain complexity, high scalability complexity, low team maturity" или "high essential domain complexoty, low scalability complexity, high team maturity", подходы к тому, как обеспечивать качество, будут очень сильно отличаться. Поэтому слепо копировать успешные кейсы других компаний, не понимая, чем их ситуация отличалась от вашей, нельзя.

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

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

Сбор тем и вопросов для большого исследования тимлидов

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

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

👉Сколько зарабатывают тимлиды в зависимости от размера команды
👉Что замотивировало тимлидов уйти из разработки в менеджмент
👉Средний срок жизни сотрудника в команде

Интересы тимлида и рекрутера не совпадают

На Хабре выложили аналитику по зарплатам рекрутеров. И все бы ничего, но есть там несколько интересных моментов:

👉Зарплаты линейных рекрутеров почти всегда зависят от KPI, которым выступает количество закрытых вакансий
👉24% опрошенных считают, что для повышения зарплаты им надо закрывать больше вакансий. Только 12% – что нужно улучшать сорсинг кандидатов.

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

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

Как общаться прямо, но не быть грубым

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

Про эффект Линди

Эффект Линди говорит о том, что чем дольше что-то существует, тем больше вероятность, что это что-то будет существовать и дальше. Например, если какой-5 фреймворк был популярен 5 лет, то он, скорее всего, будет популярен и следующие 5 лет.

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

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

Метрики в работе технической поддержки

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

👉Время реакции на запросы и процент разобранных обращений
👉Корректность разбора алертов
👉Загруженность саппорта

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

Принцип "No Known Bugs", он же "Zero Bug Policy"

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

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

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

Один из главных плюсов такого подхода – повышение мотивации команды инвестировать в практики, ведущие к повышению качества: лучшее понимание пользователя, автоматизация, architecture decision records, грамотная декомпозиция.

Подробный гайд про то, как работают опционы

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

Но, как и всегда, все работает сильно сложнее:

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

Короче, в статье разобрано огромное количество таких аспектов. Но еще интереснее – статистика!

📈СЕО обычно получает 5-10% акций, VP 1-2%, директор 0.4-1.25%, сеньор 0.33-1%, менеджер или мидл 0.2-0.33%.
📈Выход планировать стоит на через 10 лет, и быть готовым к 15 годам. При этом надеяться можно и на 5, но это очень оптимистично.
📉Присоединяясь к стартапу seed стадии с долей 1% ваш шанс заработать хотя бы $1М – всего 3.2%. Детальные расчеты есть в англоязычной версии статьи.

Где у руководителей точки роста

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

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

1️⃣Low Focus, Low Autonomy

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

2️⃣Low Focus, High Autonomy

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

3️⃣High Focus, Low Autonomy

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

4️⃣High Focus, High Autonomy

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

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

Про ошибку планирования

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

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

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

Как измерять качество

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

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

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

Как проводить осмысленные карьерные разговоры

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

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

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

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

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

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

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

Как читать бизнес-книги

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

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

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

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

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

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

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

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

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

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

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

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

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

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