Постоянная борьба с пожарами – это плохо

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

Observability: monitoring, alerting, tracing

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

Новый сезон Techlead Crew как раз помогает тимлидам вкатиться в то, как предотвращать инциденты до того, как они случатся. Архитекторы и SRE из Booking, Авито, Bolt и Datadog проведут кучу воркшопов и докладов про то, как выстраивать систему мониторинга, выбирать правильные метрики, оценивать доступность и внедрять SRE практики.

Старт – в следующий понедельник, 17 октября. Можно и участвовать вживую, и смотреть записи сессий позже, если не успеваете прийти.

Подробная программа уже есть на сайте!

Затраты на синхронизацию в команде и способ их уменьшить

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

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

Тимлидов и архитекторов хлебом не корми, дай только задокументировать какой-то процесс или архитектуру в виде sequence диаграммы, или построить Ганта для очередного проекта.

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

Что болит у тимлидов

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

🤝Взаимоотношения с командой (как работать с саботажниками; как делегировать)
🤩Мотивация, развитие и перфоманс (как оценивать, тащит человек или нет; как и надо ли хвалить тех, кто работает хорошо)
👀Найм и увольнение (как нанимать подходящих людей в команду; как и когда правильно увольнять)
📈Улучшение работы команды (как понять, какие практики полезны, а какие – карго-культ; как расставлять приоритеты в решении проблем)
🛠Выстраивание процесса разработки (как правильно распределять задачи в команде; как построить процесс решения техдолга)
💬Взаимодействие с руководителем, стейкхолдерами и организацией (как заработать авторитет внутри компании, как убедить поднять сотруднику зарплату)

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

Результатами поделюсь в канале, а всем прошедшим подарю плейлист Teamlead Crew про проблемы начинающих тимлидов!

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

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

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

Именно это разберут на бесплатном онлайн-митапе "Эффективная коммуникация между IT командами" сегодня в 19:00, который проведут технический директор GameDev студии и коммерческий директор OTUS.

Что разберут:
– Какие форматы взаимодействия лучше использовать с разными IT-командами;
– Какие существуют особенности составления технических требований для команды;
– Познакомитесь с кейсами спикера из GameDev индустрии в формате "было - стало", опираясь на работающие практики.

👉Подробнее: https://otus.pw/wLlo/

Кому точно стоит быть:
– Руководителям команд разработки и техлидам
– Разработчикам, которые хотят рости и лидировать свои проекты
– Проджектам и продактам, особенно из GameDev индустрии

📅 Старт сегодня,19 октября, в 19:00 по Москве. Приходите по ссылке и приглашайте коллег!

Как организовывать долгосрочное планирование

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

⭐️Чем больше неявных целей вы прячете под определение-коробочку «планирование», тем сложнее и хуже будет работать процесс.
🤷🏻‍♂️Bottom up планирование в чистом виде не помогает достичь целей компании и приводит к локальной оптимизации.
🆕Смешивать вместе планирование существующих проектов и решение о старте новых – плохая идея, так как это требует разных режимов мышления и подготовки.

Как управлять департаментом

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

Переход тимлида в новую команду или компанию

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

Вот несколько правил перехода тимлидом в другую компанию, которые я сформулировал для себя:

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

Если вы подумываете о переходе в другую команду или компанию, приходите на нашу конференцию Podlodka Teamlead Crew. Всю неделю с 7 ноября мы проводим воркшопы и доклады про то, как тимлиду онбордиться таким образом, чтобы быстрее стать полезным на новом месте. Вы получите полезные навыки и памятки, которые помогут вам не совершить чужих ошибок в самый чувствительный момент своего жизненного цикла в компании!

Performance Improvement Plan

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

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

Еще один гайд по управлению конфликтами

На Хабре вышла еще одна статья про управление конфликтами, предлагающая довольно дельный алгоритм:

1. Решите, надо ли вообще вам, как тимлиду, вмешиваться в конфликт, и что будет, если вы не вмешаетесь. Если все-таки надо, то подготовьтесь – вникните в потребности каждой из сторон.
2. Обозначьте проблему, которая возникает в команде из-за конфликта. Выслушайте позицию каждого. Дождитесь, пока обе стороны признают проблему.
3. Помогите участникам найти решение проблемы, задавая им наводящие вопросы, но не предлагая решения самому. Важно, чтобы оппоненты относились к предложенному решению как к своему.
4. Зафиксируйте и проконтролируйте исполнение принятого решения. Не забывайте отмечать позитивные исходы соблюдения договоренностей.

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

Мартин Фаулер про Закон Конвея

- Закон Конвея звучит так: “Организации проектируют системы, которые копируют структуру коммуникаций в этой организации”. Иначе говоря, архитектура крупного проекта определяется структурой команд, которые этот проект разрабатывают.
- Этот закон работает даже тогда, когда вы в него не верите. Поэтому любой архитектор должен учитывать структуру коммуникаций в команде и компании, когда проектирует систему.
- Закон можно использовать и в своих целях с помощью “Обратного маневра Конвея”. При разработке продукта с нуля организуйте команды таким образом, чтобы их структура повторяла желаемую архитектуру продукта. Важно – такой прием не работает для продуктов с уже устоявшейся архитектурой и большой кодовой базой.

Почему сотрудники уходят из компании

Уметь удерживать людей – важнее, чем уметь их нанимать. Если вы сомневаетесь, перечитайте недавнюю статью от Виталия Шароватова. В ней он подсчитал, что стоимость ухода сотрудника может достигать его 2х годовых оплат.

Основные причины, по которым сотрудники решают уйти из компании:
1️⃣Отсутствие возможностей и перспектив для роста и обучения
2️⃣Компания не готова предлагать гибкий график работы (гибрид офис/удаленка, 4-дневная неделя)
3️⃣Слабый компенсационный пакет (зарплаты, бонусы, плюшки)

Что происходит с релокацией российских айтишников

Результаты исследования Хабр.Карьеры. Интересные, но относитесь к ним аккуратно – в статье ничего не сказано ни про размер выборки, ни про известные погрешности в данных.

- 50% не планирует уезжать, 13% уже уехали, 6% уедут совсем скоро.
- 15% уехавших выбрали Европу, 12% – Казахстан, 7% – Турция.
- Четверть работодателей готовы к работе сотрудников из разных стран, еще четверть – против.

Проблемы начинающих тимлидов

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

Топовые проблемы:
👹Работа с проблемными сотрудниками в команде
🤝Проведение полезных 1-1
💬Продажа идей команде и внедрение новых практик
📆Личная продуктивность – перегруз встречами и задачами

Ссылка на подробный майндмэп

Как performance review вредит командной продуктивности

Новая статья Виталия Шароватова, в которой он доказывает вред практики индивидуальных перфоманс ревью, подкрепляя свои аргументы выдержками из исследований:

- Performance review субъективны и подвержены куче когнитивных искажений и эффекту сломанного телефона. Из выводы часто воспринимаются людьми как нечестные. Нечестность влечет за собой падение мотивации и текучку.
- Performance review сфокусированы на индивидуальном успехе сотрудника, хотя для продукта важнее успех всей команды. Приоритет начинает отдаваться заметным активностям, в противовес ценным.

Влияние культуры компании на результаты

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

Гайд по организации платформенных команд

🚏Стадии развития платформенных команд
🤔Инструменты определения болей, которые надо решать
📊Подходы к приоритизации
🤝Раскатка и адопшн платформенных продуктов

Изменение роли СТО по мере роста стартапа

СТО – роль с еще более размытыми границами и ожиданиями, чем тимлид. Автор статьи рассказывает, как менялась его роль на протчжении лет по мере роста стартапа от 1 до 200 человек.

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