Опрос подписчиков Teamlead Good Reads

Помогите мне разобраться с тем, как лучше вести канал – расскажите немного про себя, свой опыт в управлении, а главное – про то, какие темы канала вам интереснее всего! Опрос небольшой, минуты за 3 точно справитесь.

А чтобы обмен получился более честным, среди ответивших на опрос я разыграю несколько сертификатов на хорошие книги в МИФ! От себя могу посоветовать там как минимум Код, Азбуку системного мышления и Пять пороков команды – но и помимо них там есть много всего хорошего.

👉Пройти опрос

Как работает промо в Amazon

Я точно несколько раз уже закидывал материалы, связанные с тем, как в Amazon устроена карьерная линейка (раз, два, три). Но сегодня – прямо очень детальный разбор от их недавно вышедшего на пенсию VP of Engineering, который заседал во всяких комиссиях по повышениям инженеров. Что бросается в глаза:

👉Что считается признаками хорошего мидла: способен независимо решать проблемы и не ноет.
👉Что нужно мидлу, чтобы вырасти в сеньора: предлагать и затаскивать большие проекты, которые приносят ощутимую ценность команде. Причем важно затащить такой проект именно в соло, договорившись со всеми нужными людьми вокруг. Помимо этого нужно решать неочевидные, но важные проблемы – а еще лучше, если это проблема завтрашнего дня; иметь уникальную техническую экспертизу и быть "go-to person" по каким-то вопросам; менторить других разработчиков; иметь заметное влияние на других; уметь бороться с кризисами.
👉При этом с того момента, когда вас признали крепким мидлом (см пункт 1), и вы начали показывать признаки сеньора (пункт 2), ждать промо еще 1-2 года.

Сдаваться – не так и плохо

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

Поэтому в следующий раз, когда вам будут продавать OKR под соусом того, что challenging over-stretched goals – это хорошо, отнеситесь к этому со здоровым скептицизмом.

Никто не должен вам повышений

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

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

Собираем свой совет AI агентов

AI довольно неплохо помогает докручивать сырые идеи и находить в них слабые места. Я, например, всегда закидываю свои пропозалы в LLM, и прошу их покритиковать – иногда это помогает сделать их лучше.

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

Напоминаю про наш опрос – всего несколько ваших минут помогут мне разобраться с тем, что вам интереснее всего читать, и сделать канал еще круче, чем он есть сейчас❤️

Откуда (возможно) берутся переработки

Держите занятную теорию Максима Дорофеева о том, почему многие люди по собственному желанию загоняют себя в переработки:

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

Пять видов долга в продуктовой компании

1️⃣Technical debt – ну с этим в целом все понятно, и его мы миллион раз в канале обсуждали.
2️⃣Product debt – неэффективные продуктовые решения, которые, накапливаясь, ухудшают пользовательское качество продукта. Например, нормальный самостоятельный онбординг невозможен без подключения customer success команды.
3️⃣Organisatiomal debt. Чаще всего оргструктура развивается органически по жадному алгоритму. Никто не продумывает идеальную картину, а решения принимаются оптимальные для текущего момента. И в один прекрасный день вы просыпаетесь и видите, что вам пора заводить PMO, и все абсолютно проклято.
4️⃣Vision debt (не придумал хорошего перевода сходу). Стратегические решения, принятые для выживания компании, но которые расходятся с долгосрочным видением и миссией.
5️⃣Revenue debt. Накопленный набор частных решений и исключений, сделанных в погоне за отдельными клиентами – и по итогу не собирающихся в цельный продукт.
6️⃣Salary debt – долг по зарплате всем сотрудникам, когда компания обанкротится из-за того, что не управляла предыдущими пятью долгами.

Как внезапные встречи создают тревожность

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

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

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

Берегитесь охотников за вашим временем

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

Типичные примеры таких охотников за временем:

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

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

👉Заказчики не находятся в вашей менеджерской цепочке
👉Запросы неформальные, не проходят по стандартному процессу и не видны вашему менеджеру

Почему разработка замедляется

Кент Бек анализирует причины того, почему разработка новых проектов сначала идет быстро, но постепенно замедляется.

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

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

Плюс, в посте рекомендуют книгу Visual Display of Quantitative Information – выглядит кайф, забрал себе в список к прочтению.

И еще немного про то, как работает промо в Amazon!

Почему менеджеры увольняют лучших инженеров

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

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

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

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

Проблемы чаще всего не в коде, а в людях

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

Откуда вообще на самом деле берется технический долг:

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

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

Калькулятор шансов нормально поработать

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

У меня пока все грустенько получилось🫠

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