Teamlead Good Reads – ежедневные советы про менеджмент людей и команд

Подборка вопросов для референс чека Сбор рекомендаций на кандидата при найме – потенциально самый ценный этап всего процесса. Результаты прохождения собеседования, все-таки, довольно синтетические, и имеют мало общего с тем, как кандидат будет вести себя в реальности. А вот конкретные примеры от тех, кто с ним работал – другое дело. По ссылке – хорошая подборка вопросов, которые стоит задавать при сборе рекомендаций. Вот некоторые из них: 👉Были ли какие-то области, в которых вас удивило, что кандидат был не так хорош, как вы ожидали? А где он наоборот был выше ожиданий? 👉Есть ли разница в том, как кандидата опишут его руководитель, коллега и подчиненный? В чем она? 👉Что из того, что кандидат делал, часто оставалось незамеченным или недооцененным? 👉Расскажите про случай, когда кандидат поменял свое мнение о чем-то. С какого на какое мнение он поменял, что это вызвало? Расскажите в комментариях, какие вопросы обычно задаете вы!

20% на техдолг не работают 👉Вместо единого бэклога появляются два – продуктовый и технический. И в технический постепенно начинает попадать все, что не фичи – решение багов, автоматизация рутины, обновления библиотек и решение проблем безопасности. А тот факт, что эти задачи приносят ценность пользователям, начинает игнорироваться. 👉Перенос задач в технический бэклог без определения их business value приводит к тому, что они воспринимаются менеджментом как низкоприоритетные, и легко могут вытесняться важными продуктовыми задачами. 👉Так как время выделяется не на решение конкретной проблемы, а на широкий зонтик задач, очень легко размыть фокус, броситься одновременно исправлять много вещей, и не получить значимого прогресса нигде. 👉Как только организация выделяет под "технические задачи" 20% времени, становится очень легко начать их откладывать. Если раньше вы одновременно с реализацией какой-то фичи могли поправить связанную с ней техническую проблему, то теперь гораздо чаще будете встречать сопротивление этому со словами "сделаете в выделенные 20% времени". 👉20% времени – на самом деле не очень много. Если вашей системе требуется действительно серьезная переработка, она может растянуться на годы.

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

Про то, как менеджеры игнорируют свои команды В индустрии сейчас все не супер хорошо. Массовые послепандемийные сокращения продолжаются, конкуренция давит со всех сторон, а акционеры публичных компаний требуют релизов и инноваций. Значимая часть давления при этом сваливается на мидл и линейных менеджеров, которые выгорают под грузом новых задач, и, что еще хуже, дают этим задачам вытеснять свою самую важную роль – работу со своей командой. Вот несколько показателей из релевантных исследований: 👉Только 20% респондентов получают регулярный фидбэк от своих менеджеров. При этом половина менеджеров уверяет, что этот фидбэк приносит. 👉40% сотрудников ощущают себя полностью брошенными и игнорируемыми своим менеджером. Причем "брошенный" сегмент респондентов в 67% случаев больше перерабатывает и в 60% случаев более выгоревший, чем тот, который чувствует поддержку менеджера. 👉При этом 67% менеджеров признаются, что иногда забывают отвечать своим сотрудникам. Половина из них делает так потому, что перегружена, а треть – потому что теряются в потоке входящих сообщений. 👉Ожидаемо, среди брошенных сотрудников гораздо больший процент активно ищет работу и планирует уволиться. В Твиттере к статье хороший комментарий оставил Brian Goetz, главный за Java: Resiliency requires something that resembles inefficiency, and we suck at prioritizing future resiliency in the face of unknown crises over present efficiency. A seemingly unlearnable lesson. Чистая правда.

Кратко про social loafing (эффект, когда в группе люди прикладывают меньше сил к труду по сравнению с тем же трудом в одиночку): основными причинами этого эффекта являются: - излишне крупные группы - ощущение несправедливости, возникающее от того, что люди видят, что кто-то “мало усилий прикладывает” - “неинтересные задачи” это что ж получается такое удивительное — людям внезапно становится скучно и неинтересно если увеличивать команды до дурных размеров а потом реальные проблемы по-барски эдак декомпозировать и раскидывать между людьми (продакт умнее пусть придумывает чо делать а тимлид умнее пусть и придумывает как делать) кто бы мог подумать? Рефы: - https://journals.sagepub.com/doi/10.1177/0146167284101011 - https://psycnet.apa.org/doiLanding?doi=10.1037/0022-3514.37.6.822 - https://www.researchgate.net/publication/228608182_Social_Loafing_A_Field_Investigation - https://journals.sagepub.com/doi/10.1177/0022002183014003009 - https://journals.sagepub.com/doi/10.1177/001872679504800603

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

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

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

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

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

Голосуем в исследовании тимлидов Большой опрос руководителей разработки закрывается уже вот прямо на днях. Если вы еще не успели его пройти, самое время! А пока несколько фактов, которые видны уже по сырым данным: 👉Тимлиды постепенно уходят с полной удаленки, процент снизился с 44% до 35%. Основные причины возврата в офис – желание сменить обстановку, проведение встреч с командой и возможность быстрого решения вопросов. 👉Самым сложным в работе за последний год был слишком большой завал разными задачами и чересчур масштабные цели. 👉Треть тимлидов не получает поддержки от своих компаний в вопросах обучения – нет внутренних курсов, не оплачиваются внешние. 🔗Опрос можно пройти вот тут, результатами поделюсь в канале

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