Универсальное правило для продуктивной работы

Держи голову свободной! Тебе никогда не придёт в голову гениальная идея, если она всегда забита операционными мелкими задачами. Помнишь, как ты придумывал что-то перед сном или в отпуске? А сколько из этих идей моментально забывались?

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

О том, как система тайм-менеджмента может помочь достичь такого состояния расскажут на вебинаре 16 декабря в 20:30 по мск. Участие бесплатное, надо лишь зарегистрироваться в боте

Навигаторы как замена архитектурным комитетам и командам

Про проблемы, вызываемые в компании наличием централизованной функции архитекторов, в канале мы обсуждали уже много раз (как минимум вот). При этом польза от них тоже есть, как минимум в том, чтобы любые технические вопросы не эскалировались до СТО. Один из вариантов замены – навигаторы.

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

Как деливерить быстрее

Набор принципов, некоторые из которых показались мне интересными:

👉Protect momentum. Чем чаще вы что-то релизите, тем выше получается держать уровень мотивации и энергии в команде. Длинные циклы разработки приводят к выгоранию и потере контакта с пользователем.
👉Beware of prioritization. Бессмысленно тратить много времени на приоритизацию, когда все, что действительно важно – это какую задачу делать прямо сейчас, а какую – следующей.
👉Only doers can plan what you work on. Как только за планирование начинают отвечать оторванные от разработки люди, появляется искуственное раздувание сроков разработчиками, которые не хотят промахиваться в оценках. А работа занимает все выделенное на нее время.
👉There is no quality vs speed tradeoff. Плохое качество кода замедлит вам работу в будущем. Любой компромисс такого рода – в долгую вреден. При достаточном уровне культуры разработки и скиллов инженеров можно достичь обеих целей.

Почему вы увольнялись с менеджерской работы

Я увольнялся с менеджерских позиций два раза. Первый раз был в 2016 году в Rambler&Co. У нас одним днем сменился весь менеджмент технического подразделения на каких-то очень эффективных ребят из Инновы. Первое, что они сделали – собрали всю нашу команду и начали рассказывать про Scrum и другие великие изменения, которые планируют внедрить. На любые разумные вопросы про эти изменения отвечали чем-то типа "Да я уже пять успешных бизнесов построил, когда сделаешь столько же, вопросы и задавай". После этой встречи мы завели встречи для всего iOS отдела, на которых совместно стали готовиться к интервью. Спустя пару месяцев уволился и я, и процентов 70 всей команды. Мораль, которую я для себя вынес – даже если вас нанимают ради внедрения изменений, не стоит врываться с ними с порога без внятной стратегии их исполнения.

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

А теперь ваша очередь! Расскажите в комментариях, почему вы увольнялись с менеджерской работы.

Как в Google работает code review

Интересный разбор особенностей code review в Google – от гайдлайнов и до разбора Critique, внутреннего инструмента для ревью. Среди заметных фич:

👉Использование AI для того, чтобы в одну кнопку применить предложения из комментария.
👉Автоматическая генерация комментов-саджестов для ревьюеров кода на основе работы статических анализаторов.
👉Есть специальные дэшборды, которые показывают, какие ревью на ком зависли.
👉Если PR содержит и стилистический рефакторинг, и изменения бизнес-логики, Critique отфильтровывает только значимый код.

Гайд по переходу к асинхронным коммуникациям

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

Тест для сборки инструкции к менеджеру

В конце года принято ретроспективно смотреть на все проекты, процессы и коммуникации. Ребята из SETTERS Media запустили тест-конструктор инструкции к себе как к менеджеру.

Как работает:
👉 Отвечаете на десять вопросов про свой стиль постановки целей, делегирования и коммуникаций
👉 Рассказываете о своих увлечениях и грузите фотку, чтобы вас ни с кем не спутали

На выходе получаете красиво сверстанную пдф, в которой подсвечены ваши основные менеджерские черты. Можно (и даже нужно) пошэрить файл с командой, потому что подтянуть коммуникации = подтянуть вообще все процессы. Пробуйте и рефлексируйте перед Новым годом!

Реклама. ООО "СЕТТЕРС МЕДИА"

Выпуск Подлодки про то, кто такой engineering director

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

Кому и зачем надо становиться менеджером

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

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

Тестовая неделя как способ найма

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

Неделя оплачивается. Кандидату дают доступ ко всем необходимым инструментам и ставят четкую задачу. Например, реализовать фичу, которая поможет триажить входящие тикеты. Через эту систему проходят все нанятые люди, включая топ-менеджеров. Говорят, что ретеншн-рейт команды на протяжении 4 лет составил 96%.

Как СТО развалить компанию

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

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

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

Книги, которые вы прочитали в этом году

У меня выдался очень ненасыщенный год на менеджерскую литературу, всего несколько книг, которые готов порекомендовать:

👉Radical Candor – про то, как давать открытый и честный фидбэк в моменте, а не тянуть с ним вечность.
👉The Culture Map – про особенности работы с людьми разных культур.
👉Team Topologies (ее еще не дочитал, но пока нравится) – про осознанный подход к организационному дизайну.

Расскажите, а что в этом гожу прочитали вы? Что понравилось, а что – не очень?

Процессный долг

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

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

Анализ различных видов премий

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

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

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

👉Онбординг с Евгением Антоновым про то, как построить простой и качественный процесс ввода в работу новых людей в вашей команде.
👉Организация стажировок со Стасом Цыгановым про то, как расширить воронку найма за счет кандидатов вообще без опыта работы, и как построить их отбор и обучение.
👉Письменная культура с Александром Ложечкиным про то, как развивать скилл написания полезных и понятных текстов и как эта кудьтура выстроена в Microsoft и Amazon.
👉Делегирование с Евгением Котом про самый важный навык любого руководителя.
👉Холакратия с Андреем Кузнецовым про то, как в Точке построена организация команд и процессы их работы.
👉Engineering Director с Евгением Котом про то, что меняется, когда от руководства командой вы переходите к руководству большим департаментом.

Если вам понравились эти или другие выпуски – напишите нам что-то хорошее в отзывах в Apple Podcasts, или прямо в чатике подкаста!

Чего ожидать от девелопер адвоката

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

👉Семплы кода
👉Блог посты
👉Презентация или видео с лайвкодингом
👉Hands-on воркшоп
👉Сообщения в социальных сетях с широкими охватами
👉Фидбэк по продукту
👉Улучшение отношений с коммьюнити и партнерами

Инцидент-менеджмент и recency bias

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

Пример Manager's Readme

Я уже выкладывал в канале несколько материалов про то, что такое Manager's Readme. Если концепция заинтересует, посмотрите на них в поиске. Если кратко – это небольшой документ, в котором описываются ваши основные менеджерские принципы и ожидания от своей команды. Он особенно хорош, когда вы только вкатываетесь в новую команду, и не выстроены неявные модели ожиданий и рутина.

В статье по ссылке из заголовка тимлид небольшой команды показывает свой readme в сыром виде. Мне нравится там следующее:

👉Явно прописаны основные ожидания от роли самого менеджера.
👉Очень простыми словами объясняется, зачем нужны 1-1, и они не смешаны с проектными синками.

Что мне не очень нравится:

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

Как DORA метрики помогли легаси проекту

Тимлид проекта с 25-летней историей развития, частично утерянными знаниями о его работе и повышенным количеством дефектов, делится тем, как фокус на улучшении характеристик, подсвечиваемых DORA метриками, помог за несколько лет существенно улучшить положение дел. Если вы не следили за хайпом вокруг DORA в среде DevOps, вот что это такое:

👉Deployment frequency: как часто команда релизит свою систему
👉Commit delivery lead time: время, за которое сделанный коммит доезжает до прода
👉Deployment failure rate: процент релизов, закончившихся поломкой
👉Mean time to recovery: среднее время на восстановление после поломки