Как техническому менеджеру не терять свои навыки

1️⃣Периодически проходитесь и по всем этапам пользовательского пути, и по этапам стандартного процесса разработки в вашей команде, выписываете все проблемы, составляете friction log.
2️⃣Почти во всех командах львиная доля времени уходит на различную операционку – закрытие мелких багов, инфраструктурные задачи, решение инцидентов. Регулярный глубокий анализ всего, что происходит в этих областях, и поиск возможностей их оптимизировать – как помогут команде, так и дадут менеджеру больше контекста о происходящем.
3️⃣Участвуйте в той же ротации дежурных по инцидентам, что и вся команда. Вы сможете буквально на кончиках пальцев понимать, где в вашей системе самые проблемные места, насколько хорошо все документировано, и чем весь процесс можно сделать лучше.
4️⃣Возьмите на себя подготовку различных документов – и техдокументации, и пострмортемов, и ADR.
5️⃣Попробуйте периодически брать "engineerication" (engineer+vacation) – несколько дней или недель непрерывного времени, когда вы занимаетесь только инженерными задачами. Это особенно хорошо работает, когда нужно быстро погрузиться в новый домен.

Интервью на СТО

Недавно я анонсировал открытое интервью на позицию СТО, где Александр Ложечкин собеседовал Андрея Бреслава. Так вот, все прошло классно, и, если вы опоздали на лайв, обязательно посмотрите запись на Youtube!

Важность – Решаемость – Запущенность

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

👉Решаемость (tractability) – насколько вообще выбранную проблему можно решить в разумное время.
👉Запущенность (neglectedness) – насколько уровень выделяемых ресурсов на проблему соответствует тому, который нужен, чтобы реально ее решить.
👉Важность (importance) – ну тут все по классике.

Так вот, при оценке всех проблем по этим критериям, вы можете увидеть довольно важные вещи. Самыми интересными выглядят вот эти два кластера:

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

Мои топ-5 кандидатов:

1️⃣ "Отсутствие бюрократии"
2️⃣ "У нас скрам с элементами вотерфолла"
3️⃣ "Мы стремимся в бирюзу"
4️⃣ "Мы тут делом занимаемся, а не процессами"
5️⃣ "Фаундеры очень вовлечены в процесс разработки"

Настольная книга СТО стартапа

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

👉Менеджмент людей: коучинг, деревья компетенций, continuous improvement, обучение менеджеров.
👉Жизненный цикл сотрудника: найм, онбординг, перфоманс менеджмент.
👉Управление технической командой: общая культура, техдолг, developer experience.
👉Технологии: архитектура, SDLC, DevOps, инцидент-менеджмент.

Что вынуждает топ-перформеров увольняться

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

Почему учить других – хороший способ учиться самому

1️⃣ Когда вы объясняете кому-то новую тему, вам приходится глубоко в ней разобраться. Если вы не можете ясно изложить материал, значит, вы сами еще недостаточно его поняли.
2️⃣ Чтобы доступно объяснить что-то другим людям, вам приходится упрощать информацию, искать понятные примеры и аналогии. В этом процессе вы и сами лучше понимаете суть изучаемого материала.
3️⃣ Когда вы только-только изучили что-то новое, вы еще помните, что это такое – не понимать материал. Это помогает вам предвидеть возможные вопросы, объяснять тему более доступно, и уметь так же объяснять ее и в будущем.
4️⃣ Необходимость обучить теме кого-то еще хорошо так пинает разобраться в теме глубже, и не откладывать это на последний момент.

На что влияют скиллы разработчика при работе с AI

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

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

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

Чем отличаются менеджер, директор и VP

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

👉Менеджеру платят за то, чтобы он достигал результатов, получая помощь по необходимости.
👉Директору платят за то, чтобы результаты достигались вообще без какого-то контроля.
👉VP платят за то, чтобы они придумывали планы, основанные на понимании бизнеса.

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

Как работают инженерные менеджеры в разных компаниях

Держите несколько хороших разборов того, в чем заключается работа engineering manager'ов в разных компаниях, и как они влияют на бизнес:

👉Amazon
👉Meta
👉Roots
👉Flo

Большое исследование продактов

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

Напомню, что сам я этими исследованиями уже не занимаюсь, но при этом супер рекомендую в них участвовать:

👉У команды нет какой-то повестки, которую им важно продвигать (уровня "ААА, рынок умирает, приходите к нам за консультациями!"), поэтому результаты довольно чистые.
👉Обычно в исследовании участвует 1000+ респондентов собранных как из публичных каналов, так и путем ручного обхода больших и маленьких компаний – так что срез получается довольно репрезентативный.
👉Опросы проводятся уже много лет, поэтому можно делать самое интересное – отслеживать, как самые важные сигналы меняются год к году!
👉Все результаты открыты для всех без всяких регистраций. Этот опрос откроют уже в мае!

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

Советы по управлению большими проектами

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

👉Фокус. Если вы отвечаете за такой проект, то освободите все свое расписание и бэклог от других задач. Даже если кажется, что на трекинг и управление происходящим должно хватать пары часов в день, не поддавайтесь этому чувству. Важно, чтобы этот проект всегда был для вас top of mind.
👉Всегда имейте на руках детальное текущее представление о том, какие шаги надо сделать для успешного завершения проекта. Чем раньше вы поймете, что не укладываетесь в сроки, тем быстрее сможете что-то предпринять.
👉Научитесь быстро пересматривать свой план на основе новой информации, и оптимизировать весь свой флоу под получение информации такого рода. Для этого как можно больше и чаще общайтесь со всеми участниками проекта, отслеживайте и приоритизируйте исследование самых больших открытых вопросов, регулярно пересматривайте ваше текущее понимание приоритетов.
👉Научите всех участников проекта принимать быстрые локальные решения. Для этого у них должно быть 100% понимание общих целей, и хорошее представление о текущем статусе проекта и о том, кто чем занимается. Для этого вам нужно делиться информацией как можно чаще и больше.
👉Декомпозируйте большой проект на маленькие, в идеале не на уровне скоупа, а на уровне независимой цели, которую надо достичь.

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

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

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

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

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

👉Если сотрудник не перформит, и положиться на него нельзя, конечно же вы снимите с него задачи, выполнение которых критически важно.
👉Занять его чем-то нужно, поэтому вы достанете nice to have задачи со дна бэклога – и не факт, что они идеально лягут в его привычные компетенции.
👉То, что вам кажется конструктивной обратной связью, сотруднику под угрозой увольнения может показаться давлением и неоправданной критикой.
👉Если провалы сотрудника были серьезными и вредили команде, остальные ее участники сами по себе не будут сильно рваться работать вместе с ним.

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

Частые ошибки в работе с бэклогом

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

Так вот, держите несколько конкретных антипаттернов, которые показывают, что вы сбились с пути:

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

Про вредные и полезные модели

Майянский календарь был основан на абсолютно неверной картине мира, но при этом со 100% точностью предсказывал солнечные затмения. Это делало его полезной моделью.

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

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

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

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

Про High Agency

Хорошего перевода для high agency я так и не нашел, если не считать буквального "высокая агентность". В статье его определяют через набор других качеств:

👉Ясное мышление
👉Ориентация на действие
👉Готовность идти против конвенционального мнения

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