Должна ли работа быть свободной от политики

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

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

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

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

Советы по организации сообществ

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

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

Может ли QA замедлять работу

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

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

Голосуем в исследовании тимлидов

Большой опрос руководителей разработки закрывается уже вот прямо на днях. Если вы еще не успели его пройти, самое время! А пока несколько фактов, которые видны уже по сырым данным:

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

🔗Опрос можно пройти вот тут, результатами поделюсь в канале

Подкасты про переговоры

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

Держите два наших недавних подкаста, которые помогут вам узнать и попробовать новые тактики:

👉Выпуск Подлодки про зарплатные переговоры с Ильей Синельниковым
👉Выпуск Бреслава и Ложечкина про сложные переговоры со всякими топ-менеджерами

Pioneers – Settlers – Town Planners

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

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

Три важных софт-скилла при найме

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

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

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

Про скип-левел встречи

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

Зачем нужны скип-левелы вверх:

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

Зачем нужны скип-левелы вниз:

👉Вы можете заметить начинающие таланты
👉Вы можете сравнить то, что говорит про климат в команде менеджер, и то, что считают сами члены команды

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

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

Кратко про 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

Еще про перегрузку менеджеров

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

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

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

20% на техдолг не работают

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

Подборка вопросов для референс чека

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

По ссылке – хорошая подборка вопросов, которые стоит задавать при сборе рекомендаций. Вот некоторые из них:

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

Расскажите в комментариях, какие вопросы обычно задаете вы!

Инструкция по организации онбординга

Я уже как-то делился подкастом про онбординг, который мы записывали с Женей Антоновым. Теперь его классную инструкцию про то, как максимально сгладить первые рабочие недели новичка, можно прочитать и в виде статьи. Рекомендую!

Для затравки, некоторые тезисы:

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

Почему советы часто не работают

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

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

Как работать с кандидатами после того, как они приняли оффер

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

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

Что происходит с рынком джунов в России

Я не очень сильно доверяю зарплатной статистике Хабра, но картина все равно интересная:

👉2024 год не стал хуже в сравнении с 2023. Конкуренция за вакансии стажеров и джунов осталась на том же уровне, где-то 80 откликов на каждую.
👉Больше всего джуновых вакансий среди бэкендеров. За ними идут, понятное дело, фронтендеры, и, удивительно, системные аналитики. Близких моему сердцу мобильных разработчиков нет даже в топ-10.
👉Зарплаты за год чуть-чуть подросли, примерно на 7%.
👉Джунов часто берут на удаленку, доля таких вакансий – 60%.

Как быть одновременно поддерживающим и требовательным

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

Новые выпуски тимлидских подкастов

Лучше регулярных походов в спортзал только регулярные походы туда под хорошие подкасты. И я вам принес сразу пачку новых тимлидских выпусков:

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