Результаты большого исследования тимлидов

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

👉Основные обязанности руководителя: собеседования, развитие людей и оценка перфоманса.
👉Напрямую зарплатами своей команды управляет только половина линейных тимлидов.
👉Большинство руководителей тратит на написание кода не больше 30% своего времени.
👉Самыми важными навыками считают умение работать с людьми и командами. А вот, например, обеспечение качества болтается где-то в самом низу списка, что заставляет где-то грустить одного Виталия Шароватова.
👉Самая разочаровавшая всех книга – "Как пасти котов" 😅
👉Основной критерий выбора компании для работы – зарплата.

Friction logs

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

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

Публикуем новый кейс + разбор от экспертов канала!

👉 Кейс #9 Политический конфликт

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

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

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

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

❔Поделитесь, решали ли что-то подобное. Может кто-то медиацию пробовал или что-то похожее?

💬Разбор от экспертов

Кейс разбирали:
👉 Александр Орлов @eagleson77, автор книги "Джедайские техники конструктивного обшения", управляющий партнер Школы менеджмента Стратоплан
👉 Миша Шляхов @tehaleph - техлид из Tutu.ru

Как техдолг влияет на AI

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

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

Как доводить до успеха проекты в бигтехе

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

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

👉Иметь четкое представление о том, какую пользу компания хочет получить от вашего проекта. Это могут быть как явные вещи, вроде денег и пользователей, так и менее явные, например, личная заинтересованность какого-то VP.
👉Поддерживать доверие к вам заинтересованных в проекте менеджеров. Ни у кого из них не будет технического контекста происходящего, поэтому во всем, что касается сроков и рисков, они будут полагаться на ваше суждение. Если доверие пропадет, шансы проекта на успех резко снизятся.
👉Оставлять себе достаточно свободного времени, чтобы иметь возможность быстро среагировать на неожиданные проблемы и сомнения каких-то соседних команд и стейкхолдеров.
👉Пытаться предугадать возможные будущие проблемы и заранее продумывать, как митигировать эти риски. Хороший способ делать это – регулярно задавать себе вопрос "Что мне могло бы помешать выпустить проект прямо сегодня?"

Как договариваться о росте хедкаунта

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

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

Как формулировать проблемы с помощью теории ограничений

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

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

👉НЖЯ — это проблема, которая регулярно повторяется
👉НЖЯ — это проблема, на которую мы можем повлиять
👉НЖЯ не субъективно
👉НЖЯ не является предполагаемой причиной 
👉НЖЯ не содержит завуалированное решение
👉НЖЯ — не содержит обвинение
👉НЖЯ не требует пояснения, какой негативный эффект оказывает

Примеры из статьи переформулировки довольно абстрактных проблем в НЖЯ:

Не найти ответственных ➡️ Мы заметно срываем сроки по 70% задач

Хаос в бизнес-процессах ➡️ До 80% разработки не попадает на прод

Проблема с данными ➡️ Мы не можем использовать заметную часть данных

Тактики выживания в корпорации

Держите плейлист на выходные из 15 коротких видео про разные аспекты выживания в корпорации.

Я их еще не посмотрел, но за автора могу ручаться – я буквально недавно проходил его курс про product sense, и мне очень понравился и его опыт, и то, как он мыслит.

Последний этап превращения группы людей в команду

Невероятный цикл историй про группу монтажников, проходящую через фазы forming-storming-norming-performing, подходит к концу. В этой части разбирается:

👉Как после фазы острого кризиса растет производительность
👉Как ускорение и успешное выполнение работы влияет на доверие людей друг к другу
👉Как выглядит настоящая командная работа

А для тех, кто предпочитает смотреть видео – YouTube версия!

Как тимлиду поддерживать свой технический уровень

Если играть в "100 к 1", то самыми популярными ответами тут были бы: заниматься пет-проектами, брать задачи из глубины бэклога, от которых ничего не зависит, пилить внутренние инструменты и PoC. Главная проблема этих советов в том, что работа над ними никак не помогает вам справляться со своей основной работой – помогать команде достигать результатов и становиться со временем лучше.

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

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

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

Новые выпуски подкастов про менеджмент

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

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

Непопулярные мнения про продакт-менеджмент

👉За продукт отвечает не продакт-менеджер, а вся команда. Задача PMа – быть источником информации о нуждах пользователя, рынке и стратегии компании. А вот для генерации крутых идей, без которых результатов добиться сложно, нужны и инженеры, и дизайнеры, и остальные функции команды.
👉Умный продакт-менеджер – это плохо. У умных людей часто есть свое сильное мнение по любому вопросу, притом оно формируется довольно быстро на основе обрывочных фактов. Гораздо ценнее продакт, который вместо быстрой генерации кучи идей тратит время на общение с пользователями и получение большего количества информации об окружающем мире.
👉Конкретные артефакты продуктовой работы вообще не важны. Как именно вы пишете PRD, описываете стори и эпики не играет вообще никакой роли. Главное – последовательно шарить контекст с командой любым удобным всем способом, и постепенно уменьшать количество неопределенности.
👉Метрики важны гораздо меньше, чем умение понятно сформулировать, в чем заключается успех. Любая метрика будет не очень точной аппроксимацией смысла, поэтому слишком сильно привязываться к ним скорее вредно.

Технические собеседования поломаны

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

Если вы по какой-то причине уверены, что именно ваш процесс собеседования – полезный и объективный, расскажите, пожалуйста, о нем в комментариях!

Публикуем новый кейс + разбор от эксперта канала!


👉 Кейс #10 Чек-лист для тимлида

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


💬Разбор от эксперта


Кейс разбирал:
👉 Александр Орлов @eagleson77, автор книги "Джедайские техники конструктивного общения", управляющий партнер Школы менеджмента Стратоплан


А что вы бы добавили в чек-лист для тимлида? Делитесь в комментариях.

Обращусь с небольшой персональной просьбой. Если среди подписчиков есть менеджеры из Яндекса, близкие к Почте или к Яндекс 360, напишите мне пожалуйста (@etolstoy).

Там дурацкая ситуация – 10 лет назад я сделпл родителям почтовые ящики на кастомном домене. Сейчас с ними какая-то проблема, надо получить доступ к админке, а для этого – подтвердить владение доменом. Подтвердить я могу, но поддержка внезапно перестала отвечать, и вот уже третью неделю держит упорное молчание. Буду очень благодарен кому-то, кто сможет изнутри подвигать это дело ❤️

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

Upd: Всем спасибо, помогли!

Эффект Мертвого моря

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

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

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

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

👉Треть опрошенных накручивала опыт. Из них самые большие доли, ожидаемо, среди людей без опыта работы, джунов и мидлов.
👉Накрутка обычно не очень серьезная, 60% добавляют себе до года опыта, и еще 25% – до двух.
👉Практически всем накрутка помогла – 72% полностью достигли цели, 20% – частично. При этом, кажется, работодателям накрутка тоже не очень помешала, так как только 2% накрутчиков не прошли испыталку.
👉77% нанимающих менеджеров уверены, что сталкивались во время собеседований с обманом в резюме. При этом чаще всего это замечают на этапе технического собеса.
👉Среди менеджеров есть очень странные люди. На вопрос о том, что бы они сделали с сотрудником, о накрутке опыта которым они узнали после прохождения им испыталки, 10% уволили бы его, а 13% пересмотрели бы зарплату. Самый популярный ответ тут, конечно, тоже прекрасный – "Поговорить".

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

Грейды, основанные на импакте

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

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

Модель из статьи, как мне кажется, стоит на правильном пути. Вот ее основные принципы:

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

А сама линейка выглядит так (детальное описание каждого уровня есть в статье):

1️⃣Level 1 – Scoped Tasks
2️⃣Level 2 – Scoped Projects
3️⃣Level 3 – Unscoped Projects
4️⃣Level 4 – Team Force Multiplier
5️⃣Level 5 – Group Force Multiplier
6️⃣Level 6 – Company Force Multiplier

Геймификация на рабочем месте

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

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

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

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

Таксономия целей

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