Результаты опроса про увольнения

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

😱Больше всего тимлиды боятся накосячить при увольнении по culture fit.
💬Самые сложные аспекты увольнения связаны с проведением разговора с сотрудником и чувством вины.
🤔Самые частые причины увольнений – плохое качество работы и непрохождение испыталки.
👉95% тимлидов сами разговаривают с человеком про увольнение, но вот обсуждает его условия только половина из них.

Не всем нужен 99.99% аптайм

Почти любой инженер, который занимается обеспечением стабильности сервиса или его проектированием, по умолчанию будет стремиться к тому, чтобы обеспечить его бесперебойную работу в 99.99% времени. Автор статьи напоминает, что не стоит гнаться за индустриальными стандартами, и к каждому сервису нужен свой подход. В каких-то случаях аптайм в 99.5% или меньше будет вполне адекватным. К этому вопросу нужно подходить не с технической, а с бизнесовой стороны, и внимательно сравнивать ожидаемые затраты на обеспечение SLA, и вред от даунтайма.

Как вести себя с неадекватно реагирующими людьми

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

Автор статьи предлагает следующий алгоритм:

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

Предсказание сроков с оглядкой на Канемана

☁️Два основных фактора, снижающих точность прогнозирования – предвзятость, которая включает систематические искажения, и шум, он же непоследовательность в суждениях.
☁️The Good Judgement Project, большое исследование ученых-бихевиористов, показал, что людей, лучше всего справляющихся с предсказаниями, отличают способность структурировать и декомпозировать проблемы и умение смотреть на задачу с разных углов и учитывать накопленные статистические данные.
☁️В контексте разработки прогнозы часто смещены в сторону оптимизма из-за давления со стороны заинтересованных сторон или недооценки рисков. Шум появляется из-за несогласованности между оценщиками или самого процесса оценки.
☁️Вместо того, чтобы давать единую оценку сроков, лучше придерживаться вероятностной модели, предлагая ряд результатов и вероятность их наступления. Например, так: “Есть 80% вероятность, что мы выпустим следующий релиз в течение 12 недель”.

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

Управляйте проектами команд разработки

Yandex Tracker — сервис для совместной работы. Он поможет легко управлять процессами команды разработки: тимлид сможет планировать проекты и анализировать работу, а команда — общаться с коллегами и следить за приоритетами по задачам.

Tracker поможет эффективно выстроить процессы:

— управляйте задачами: настраивайте типы, статусы, параметры, используйте шаблоны, декомпозируйте;

— работайте по гибким методологиям (Agile) с помощью досок задач;

— контролируйте сроки и формируйте календарный план с помощью Проектов и диаграммы Ганта;

— приоритезируйте задачи в бэклоге и планируйте их выполнение с помощью спринтов;

— автоматизируйте рутинные действия с помощью триггеров, автодействий, макросов;

— подключайте репозитории исходного кода и привязывайте коммиты к задачам;

— интегрируйте системы для сборки, тестирования, развёртывания приложений.

Вы можете легко перенести процессы в Tracker с помощью API или инструмента миграции.

Попробуйте Yandex Tracker прямо сейчас➡️

Чем опытные сотрудники опасны для бизнеса

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

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

🤔Процессы и системы проектируются таким образом, чтобы снизить роль отдельных личностей, и сделать их легко заменяемыми. Все вот эти наши любимые истории про bus factor.
🤔Чем больше сотрудник “рок-звезда”, что часто коррелирует с продолжительностью его работы, тем больше проблем он приносит – спорит с руководителями, противится внедрению эффективного менеджмента, да еще и денег много просит. Для не очень компетентных менеджеров такой сотрудник может восприниматься как проблема и личный враг.

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

Короче говоря, что думаете про тейлоризм в современном IT? Винтики ли мы, или ценность имеем?

Папка каналов для тех, кто интересуется продакт-менеджментом

Рост в продакта – одна из довольно частых веток развития тимлида. Мотивация чаще всего примерно одна и та же. Ты устаешь быть тем, кто отвечает на вопрос “как нужно что-то сделать” и быть фичепроводом, в который другие люди закидывают вещи, с которыми ты принципиально не согласен. Логичный выход – перейти в роль того, кто отвечает на вопрос “что и зачем нужно делать”. Примерно так я сам и реролльнулся в продакты (выгорание от скучных бюрократических процессов, связанных с пипл-менеджментом, тоже свою роль сыграло, конечно же). И я знаю, что очень многие из подписчиков тоже думают про похожий карьерный путь.

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

А я начинаю собирать похожую папку, но с каналами непосредственно про пипл-менеджмент, управление людьми и командами. Если вы ведете такой канал, и в нем больше 1000 подписчиков – пишите мне в личку @etolstoy!

Жизненный цикл инфраструктурных проектов в Slack

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

Они выделяют следующие стадии:

1️⃣Alpha: экспериментальный проект, который никому не рекомендуется использовать в проде.
2️⃣Beta: проект, который точно будет стабилизироваться, но еще не дошел до финальной стадии, поэтому гарантий стабильности особо никаких нет.
3️⃣Active: полноценный продакшн проект с обязательным саппортом и гарантиями на то, что его внезапно не закроют.
4️⃣Maintenance: устаревшие технологии, замена которых сейчас находится где-то в стадии Beta.
5️⃣Deprecated: устаревшие технологии, для которых есть замена в стадии Active. Могут использоваться проектами, которые их уже заадоптили, но запрещены к адопшну в новых местах.
6️⃣Retired: проекты, от которых полностью отказались, без каких-либо гарантий и поддержки.

Бреслав и Ложечкин

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

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

Что отличает хорошие и плохие цели

Использовать SMART для постановки целей – хорошо, но не всегда достаточно. Держите список признаков хороших и плохих целей.

Ключевые признаки хорошей цели:

👍Сужает фокус команды, и подталкивает к тому, чтобы делать больше хороших вещей, и иеньше плохих.
👍На нее можно заметно повлиять своими силами. При этом неважно, какой путь ее достижения вы выберете – любой из них должен быть сонаправлен с ее смыслом.
👍Формулировка помогает команде легче говорить «нет» тем инициативам, которые ее не поддерживают.
👍Ее формулировка включает в себя весь необходимый контекст, она понятным образом вписывается в общую картину.
👍Может подстраиваться под меняющиеся обстоятельства, сохраняя при этом свой основной смысл.
👍Способствует развитию чувства единства в команде и наличию общего смысла существования.
👍Не приносит смысл в жертву простой измеримости и понятным метрикам.

При этом для плохих целей характерно следующее:

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

Папка тимлидских каналов

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

Простой алгоритм разрешения рабочих конфликтов

1️⃣Если кто-то замечает, что у него есть разногласия с кем-то в команде, он в первую очередь должен поговорить с ним лично и попробовать разрешить конфликт вдвоем.
2️⃣Если вдвоем решить не получается, к разбору привлекается медиатор. Медиатором может быть любой коллега, которому доверяют оба человека. Медиатор не принимает решение сам, он только помогает договориться и дает советы.
3️⃣Если конфликт все еще не решен, собирается группа экспертов. Они выслушивают обе стороны, и, так же, как и медиатор, помогают в принятии решения.
4️⃣Если дискуссия дедлочится, то из группы экспертов выбирается арбитр, который принимает итоговое решение.

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

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

Хотим порекомендовать новый продукт от Soft Skills Lab — тестирование коммуникативных навыков.

📌 Будет полезно тем, кто:

▫️ чувствует, что у него есть проблемы в коммуникации, но не понимает, в чем именно;
▫️ знает свои проблемы, но не знает, как их решать;
▫️ засиделся в одной компании и не понимает свой уровень навыков относительно рынка специалистов.

📌 Команда экспертов поможет:

▫️ выявить пробелы в навыках коммуникации;
▫️ понять, как они влияют на отношения с подчиненными, руководством и стейкхолдерами;
▫️ выстроить план развития в зависимости от целей.

Тестирование навыков — это часовая онлайн-встреча с экспертом, во время которой вы поучавствуете в нескольких ситуационных кейсах.

После созвона вы получите 3 страницы анализа ваших навыков: оценку по 5 сферам компетенций, разложенную на 37 поднавыков. Эксперт определит ваш уровень по каждому поднавыку и даст рекомендации, над чем нужно поработать.

👉🏻 Стоимость тестирования — 1499 рублей. Заявку можно оставить на лендинге, переходите, чтобы забронировать время.

Выпуски Подлодки про делегирование и письменную культуру

В Подлодке за последние недели вышло сразу два крутых выпуска для менеджеров – про делегирование с Евгением Котом и про письменную культуру с Александром Ложечкиным.

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

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

Короче, обязательно послушайте!

Стоит ли читать резюме кандидатов

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

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

Как стартовать новые команды при росте компании

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

Выбор новых технологий для компании

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

Несколько советов из статьи про то, как подходить к таким решениям:

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

В том, чтобы построить рабочие процессы, поддерживающие системное принятие решений, могут помочь:

👉Фреймворк принятия решений, который говорит, какие решения могут прмниматься командой, а какие должны подниматься на уровень всей компании
👉Внутренний технический радар, который определяет, что можно адоптить, а что – нельзя
👉Процесс RFC для оценки и обсуждения новых технологий
👉Architecture Decision Records, которые помогут не забывать причин принятия решений

⬆️ На курсе «Профессия Архитектор ПО» вы вырастете как разработчик и повысите свой доход. Разберёте реальные кейсы от ведущих разработчиков «Альфа-Банка» и сможете проектировать масштабируемые и отказоустойчивые приложения.

За 4 месяца вы научитесь:

✅ применять архитектурные стили и паттерны проектирования — API Gateway, CQRS и «Сага»;
✅ выявлять и проверять нефункциональные требования и характеристики систем;
✅ строить распределённые системы на основе микросервисов и создавать cloud-native-приложения;
✅ принимать архитектурные решения исходя из контекста;
✅ учитывать вопросы кибербезопасности при проектировании.

Навыки отточите на реальных задачах, а в конце курса презентуете итоговый проект.
Спешите приобрести курс со скидкой!

Майские скидки до 60% по промокоду «TechLead» по ссылке https://epic.st/_kQnL

Почему автокомплит кода по выходным работает быстрее

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

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

Ошибки начинающих лидов и способы их преодолеть

😞Просадка уровня дофамина: в отличие от инженерной работы, ты не получаешь быстрого фидбэка о том, что ты молодец и делаешь что-то ценное.
💻Попытка совмещать менеджмент и программирование приводит к тому, что не получается успевать ни одно, ни другое.
👉Отсутствие контроля работы подчиненных из-за боязни скатиться в микроменеджмент.
🙈Прокрастинация сложных и неудобных вопросов в надежде на то, что все как-то само собой порешается.
📆Откладывать важные, но не срочные задачи в угоду ежедневной рутине и пожарам.