Смена работы тимлидом: как готовиться, как онбордиться, и что дальше04.06.2021 09:01

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

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

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

Содержание.

Что изучить еще до выхода на работу

Блог Уилла Ларсона

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

Книга «Первые 90 дней» Майкла Уоткинса

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

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

Также я изучал отзывы на книгу, и нередко они сводятся к мысли: «за первые 90 дней нужно показать успех любой ценой». Лично я такого посыла не увидел, но, даже если он есть, вот две статьи Уилла Ларсона для баланса:

• The rush to «show value» — поясняет, как не наломать дров в стремлении быстро показать результат.

• Your first 90 days as CTO or VP Engineering — статья для лидеров уровнем выше, но полезна как карта — куда направить внимание в первую очередь.

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

На старте. Собираем контекст и ожидания

Тимлид — это агент изменений. Его задача — принимать решения, которые сделают жизнь команды и бизнеса лучше. Но чтобы принимать верные решения, а не ломать дрова, нам нужно верное понимание ситуации (контекст) и регулярная обратная связь по ходу действий. 

Ниже я опишу, как на старте собирал контекст и устанавливал нужные коммуникации.

Сразу зарезервируйте время на обучение

Когда-то давно я прочитал про такое явление как спираль сделанной работы (к сожалению, не помню, где читал). Смысл этой спирали в том, что чем больше работы вы делаете, тем больше работы вам придется делать в дальнейшем.

Какие-то активности в принципе требуют постоянной поддержки. В других активностях мы с каждым шагом понимаем, как сделать еще лучше и, естественно, хотим продолжать. Наконец наше окружение (и мы сами) очень редко снижаем ожидания к себе — после каждого успеха хочется продолжать с тем же или даже большим темпом. 

Если мы не следим за балансом обязательств и копим незавершенку, то мы становимся все больше «должны». Спираль может закрутиться до состояния, когда без нас уже ничего не может быть сделано, и мы вынуждены крутиться, как белка в колесе, чтобы поддержать хотя бы текущие обязательства. Еще это печальное состояние известно как «bus factor = 1».

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

Понаблюдайте, как идет работа в компании

Мне никогда не казалось хорошей идеей «врываться» в новую команду с готовыми идеями, которые дали профит в прошлом. Совсем не факт, что они сработают здесь. 

Первое время я решил побыть «тихим наблюдателем», вникнуть в традиции компании и как люди взаимодействуют друг с другом. А к активным действиям переходить позже, когда сформируется понимание ситуации. 

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

Daily sync с командой

Классический stand up meeting. Здесь я понял текущие боли проекта, настроение команды, кто в чем профи, есть ли тлеющие или явные конфликты. 

Также этот митинг — отличное время, чтобы «легализовать» себя в команде. Расскажите о своем прошлом опыте, чем вы увлекаетесь в жизни, как планируете действовать. Например, я рассказал, что не намерен «крушить и строить заново», что сначала буду просто наблюдать. Что постепенно поговорю с каждым на 1-to-1, но только когда наберусь контекста, чтобы разговор был предметным.

Lead sync

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

Статус-митинг с PM и вице-президентом

Это митинг уже конкретно по нашему проекту — как идут дела сейчас, и какие планы на ближайшие недели. Здесь я узнал про текущие вызовы проекта, «протокол» взаимодействия с топ-менеджментом, принятую степень открытости в обсуждении проблем. Открытость оказалась максимальной, и это очень помогло в дальнейшем действовать уверенно.

Meet & Greet

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

Хорошо. Мы понаблюдали, изначальное представление о происходящем составили. Что дальше?

Проведите несколько встреч сами

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

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

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

Вот какие я провел встречи и что мы на них обсуждали.

1-to-1 с PM проекта

Эту встречу я провел в конце первой недели. Мы проверили мои первые предположения об основных вызовах на проекте и восполнили пробелы в моем понимании ситуации. Также советую обсудить с PM, кто из вас чем занимается в повседневной работе. Это поможет избежать двух ситуаций:

• Вы оба не сделали что-то, ожидая, что это сделает другой.

• Вы залезли «на чужую территорию» без спроса. Люди болезненно реагируют на такие ситуации. Особенно если вы станете менять или критиковать то, над чем ваш коллега уже давно и кропотливо работает. 

1-to-1 с непосредственным руководителем

Эту встречу мы провели в начале второй недели. 

У нас в компании плоская структура, поэтому мой руководитель — это вице-президент, то есть топ-менеджер. Это позволило убить сразу двух зайцев по части набора контекста.

Подход тот же: заранее подготовить вопросы, проверить гипотезы, пополнить контекст. После встречи извлечь список возможных действий. 

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

Также очень рекомендую статью Уилла Ларсона Partnering with your manager. Она поможет построить с руководителем продуктивные отношения, а не просто приносить ему проблемы, с которыми он должен будет вам помогать.

1-to-1 с каждым участником команды

В отличие от предыдущих 1-to-1, с этими встречами торопиться не стоит. Вы будете иметь дело не только с проектными, но и с личными вопросами, поэтому важно приходить с максимумом контекста и минимумом домыслов и предвзятостей. 

В моем случае предстояло провести девять встреч, и на них ушло полтора месяца.

Вот советы по подготовке к 1-to-1:

• Прочитайте (или перечитайте) раздел про 1-to-1 в Team Lead Road Map.

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

• Записывайте любые положительные отзывы о коллегах. На 1-to-1 поделитесь с коллегой, что о нем говорит команда.

• Запишите и негативные отзывы. Но в формате «Вася считает, что Петя делает задачи медленно», а не «Петя делает задачи медленно». На 1-to-1 предложите коллеге рассказать о той или иной ситуации, которую вы наблюдали и внимательно выслушайте. А потом извлеките действия, которые помогут снять напряжение сейчас и избежать подобных ситуаций в будущем.

• До общения с коллегой не читайте его HR-карточку и историю решения «сложных» вопросов. Фрейминг существует и это штука очень сильная. Даже если вам кого-то представили как low performer-а, сначала поговорите с ним лично и разберитесь с его мотивацией.

• На первый 1-to-1 заложите часа два и оставьте свободным календарь после. Мало что будет хуже, чем в разгар личной беседы убежать на другой митинг.

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

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

Итог по проведенным 1-to-1

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

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

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

Что полезного сделать, пока вы собираете контекст

Как я писал выше, я не сторонник идеи «врываться» с первого дня с революционными идеями — сначала стоит собрать контекст, чтобы действовать более взвешенно и точно. 

Однако это не значит, что в первые неделю-две нельзя сделать ничего полезного. Это отличное время, чтобы «зачистить» все, обо что вы сами споткнулись.

Запишите, как проходил ваш найм 

Комфортны ли были интервалы между собеседованиями и их количество? Было ли по ходу собеседований понятно, какой и когда следующий шаг? Получили ли вы оффер в виде красивого брендированного письма или это был просто неформатированный текст? Легко ли было найти офис и кабинет HR в первый день?

Запишите все, что было неудобно или вызвало вопросы. Оформите список идей и поделитесь в виде фидбека с HR и руководителем. Но именно в виде фидбека, а не критики. Не касайтесь личностей. Вместо «что плохо», опишите «как можно сделать хорошо».

Запишите, как проходили первые дни в компании

Был ли у вас buddy? Достаточно ли было информации о компании на старте? Может, слишком много информации, и голова пухла? Как быстро вы получили технику? Был ли полезен корпоративный мерч, который вам выдали в первый день? Запишите все, за что зацепился ваш мозг, каждую мелочь. 

Моя адаптация была очень комфортной, но через три недели я отправил коллегам из HR список из 30 небольших идей. Большинство они воплотили в жизнь, а позже, на Новый Год, подарили мне крутой рюкзак:)

Автоматизируйте/задокументируйте первые шаги на проекте

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

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

Я решил сделать это в виде mindmap в miro, который базируется на Team Lead Road Map, но дополнен следующими моментами:

• Моим опытом тимлида и пониманием, что важно в этой роли.

• Ссылками на любимые статьи, курсы, книги.

• Ссылками на документы и инструкции компании, релевантные роли тимлида.

• Какие обязанности я забрал с предыдущего лида, а что еще предстоит забрать.

• Какие из лидерских активностей я делегировал.

• Какие активности относятся к категории muda, и я их постепенно истребляю.

Далее я поделился этим mindmap со всеми тимлидами, с нашим тим-коучем (да, у нас есть такой человек) и с вице-президентом. Также я делюсь им со всеми, кому интересна прокачка в тимлида, как инструкцией: что есть тимлид, что можно прокачать и где взять информацию для прокачки. 

Приступаем к действиям

Итак, прошли первые недели. Теперь у нас есть некоторое понимание проекта, список ожиданий от нас, противоречия сторон в понимании проекта и вашей роли. 

Это уже хорошие ориентиры для дальнейших действий. Вот еще парочка:

• Статья Work on what matters  поможет определить, куда направить свои усилия после того, как вы снимете все «низко висящие фрукты». Как избежать «жевания чипсов», то есть выполнения легкой и видимой, но не особо полезной работы.

• Статья Good process is evolved, not designed в паре со статьей Managing technical quality in a codebase  помогают постепенно вывести оптимальный процесс для команды и проекта, вместо декларирования «с завтрашнего дня мы Agile» и затевания революций.

И еще один совет. Чтобы помочь самому себе в будущем, систематизируйте весь получаемый сейчас опыт. Записывайте, что сработало, а что нет. Как вы внедряли изменения, с каким сопротивлением сталкивались. Например, можно вести brag document. Вот чем он будет полезен:

• Систематизация полученного опыта

• Если вдруг загрустили — перечитаете и вспомните, сколько всего вы уже сделали

• Можно найти темы для статей или докладов из своего же опыта — эта статья так и родилась. 

• Поможет при пересмотре зарплаты — это готовый список ваших достижений

• Поможет в подготовке резюме в следующий раз

В общем, практика полезная и непыльная.

А мы переходим к списку того, что я делал в первые месяцы.

Станьте «клеем»

Метафора с клеем, на мой взгляд, очень удачна и выражает собой 90% ценности лидера в команде и компании. Очень рекомендую посмотреть доклад Tanya Reilly на эту тему. Здесь же приведу примеры того, что можно и нужно «склеить», придя в новую команду.

Склейте развалившиеся коммуникации

Например, когда-то топ-менеджмент ожидал, что наш проект поедет в облако. Но команда этим не занималась и выглядела как прокрастинаторы. На самом же деле команда давно взвесила все «за» и «против», после чего приняла аргументированное решение — не переезжать в облако. Но с руководителями это явно не проговорили.

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

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

Сформулируйте единое понимание, зачем существует ваш проект

На каждом 1-to-1 я задавал один и тот же вопрос: «Каков общий ландшафт проекта и ключевые ценности для бизнеса?». И я получил очень разные ответы.

Позже мы с командой сформулировали нашу ценность следующим образом:

«Мы поставляем данные для принятия стратегических решений, поэтому наши данные должны быть абсолютно корректны, и система должна работать 24×7, чтобы избежать потерь». Сейчас с этой формулировкой знакомы все: ребята в команде, кандидаты на собеседованиях, даже CEO.

Зачем это нужно? Имея емкую и понятную цель, мы легко решаем, куда прокачивать архитектуру, какой технический долг устранять сейчас, какие задачи имеют право «растолкать» другие и получить внимание вне очереди.

Отдайте процедурные долги

Тут примеры простые:  

• Согласуйте закупки железа или лицензий, которые давно нужны.

• Обновите зарплаты тем, кому их давно не обновляли.

• Согласуйте найм специалистов, которых не хватает в команде.

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

Все это стоит сделать пока у вас есть свободное время, и это поможет оживить много инициатив.

Выгоните «призраков»

Речь про любые застарелые убеждения из категорий «здесь так принято», «так исторически сложилось», «мы не релизим по пятницам», «этот митинг долгий, но он обязательно должен быть».

Такие призраки есть в любой компании. Не стесняйтесь спрашивать «почему так?». Возможно это застарелая и ненужная привычка, бесполезность которой уже никто не замечает, а вы ее видите пока вы новенький.

Ниже примеры того, каких «призраков» мы с командой разогнали в начале работы:

«Нам нужно лучше оценивать задачи»

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

Если у вас не аутсорс и не fixed price проекты, попробуйте понять:, а бизнесу вообще нужны точные оценки в часах? По моим наблюдениям, чаще нужно четкое понимание как идут дела сейчас, примерные сроки и понимание следующих шагов. Говоря проще, бизнесу нужна уверенность, что вы делаете то, что надо. Чтобы дать такую уверенность, нужны не высеченные в камне оценки, а постоянная коммуникация и выравнивание ожиданий если обстоятельства изменились. И бизнес отлично понимает, что обстоятельства просто не могут не меняться.

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

«Бизнес не дает нам заниматься техдолгом, мы постоянно загружены задачами»

Еще один классический призрак.

Дэвид Аллен в книге «Getting things done» очень удачно сравнивает обязательства, которые мы берем на себя, с кредитной картой. Если мы берем новую задачу не зная, где граница наших возможностей — это все равно, что сделать покупку в кредит, не зная ни кредитного лимита, ни текущего баланса.

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

На момент моего прихода команда была в очевидном перегрузе, и мы начали с поиска границы наших возможностей (см. раздел «Визуализация загрузки команды» ниже). 

Определив наш WIP limit и показав его топ-менеджменту, я получил очень прямой и честный ответ — «Вы сами следите за своей нагрузкой. И вы не можете, а должны заниматься техническим долгом. Довод про перегрузку бизнес-задачами — это просто нелепая отмазка. Если задач больше, чем вы можете сделать за раз, просто сообщайте об этом, и будем договариваться».

Так мы изгнали призрака «бизнес плохой, и не дает нам делать работу хорошо». 

Устраните болевые точки и незавершенку

Почти на каждом проекте есть застарелые боли, которые команда уже привыкла «терпеть». В каждой команде есть классные начинания и идеи, которые почему-то завалились на полпути.

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

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

Это было болью, поскольку мы теряли данные, и это ставило под угрозу основную цель существования нашего проекта — консистентные данные в режиме 24×7. 

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

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

Главная мысль — приложите с командой сознательные усилия для завершения, а не «терпите» проблемы, которые давно пора решить.

Создайте общедоступные артефакты

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

Проект «с высоты птичьего полета»

Какое место мы занимаем в бизнесе компании, в чем наше назначение, какие у нас основные челленджи. Мы сделали это в формате презентации, Miro так умеет. С этой презентацией я рассказывал про проект нашему CEO и ее же показываю новым сотрудникам при онбординге.

Высокоуровневая архитектура проекта

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

Хорошую помощь в построении понятных и простых диаграмм может оказать нотация C4 Model, статья Thinking Like An Architect Part 5 и опыт в прохождении system design interview.

Технический роадмап проекта

По сути это временная шкала, отражающая что мы уже сделали, что в фокусе прямо сейчас, что планируем следующим шагом. Отдельным «облаком» — что будем делать дальше, но еще не проработали в деталях (unshaped). Мы не планируем дальше пары шагов вперем, не тратим время на декомпозицю и проработку архитектуры далекого будущего — это наша реализация принципа defer commitment. Засчет этого мы всегда сфокусированы на том, что делаем сейчас и действительно заканчиваем большие задачи, а не попеременно хватаем и бросаем самые горячие картошки.

Визуализация стратегических задач (эпиков)

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

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

С помощью этих визуализаций мы проводим синки и внутри, и вне команды. 

Визуализация загрузки команды

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

Сейчас наше состояние отображается на доске с цветовой кодировкой. «Температура» в команде определяется самым «горячим» из цветов, на котором есть хотя бы один человек.

• Зеленый — задачи долгосрочного технического развития. Снижение/предотвращение рисков, снижение operational costs, прокачка observability, testability и прочих »…ility»

• Желтый — бизнес-задачи со стандартным приоритетом.

• Оранжевый — те самые эпики, упомянутые выше. Работая с такими задачами, мы находимся в режиме «выталкивания» задач вместо «затягивания» новых. То есть если к нам сейчас прийти с еще одним эпиком, он встанет в очередь пока мы не закончим.

• Красный — авария, например, падение на проде. Мы не берем ничего, пока не разберемся с текущей ситуацией.

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

Впрочем, не факт, что другие команды и стейкхолдеры будут смотреть сюда. Но формирование новых коллективных привычек это тема отдельной статьи. А артефакты в любом случае помогут вам и команде.

Что шло не по плану

Я все еще не пишу код

На эту тему я переживал еще на этапе собеседования. Я привык работать, не отрывая руки от кода. Тут же выглядело так, что будет не до кода, поскольку много высокоуровневых задач и people management да еще и новый стек надо освоить.

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

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

Однако со временем это становится проблемой — команде трудно видеть лидера в человеке, который принимает лишь отстраненные решения и не в состоянии «впрягаться» в решение проблем вместе со всеми (могу поделиться на эту тему интересным исследованием).

Сейчас я близок к тому, чтобы взяться за код. Вот что я могу посоветовать здесь:

• Устраняйте муду, которая пожирает ваше время. Заменяйте митинги на общедоступные артефакты. Устраняйте ручные действия, вызванные несовершенством процессов и инструментов. Очень много работы можно просто взять и выбросить.

• Делегируйте. Например, найм, онбординг, коммуникации со стейкхолдерами. Многое из того, что для вас рутина, для вашего коллеги будет точкой роста.

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

Мою систему работы с задачами разнесло в щепки

Да, это был момент настоящей паники… 

В один вовсе не прекрасный день я понял, что моя система работы с задачами перестала работать. Изначально она базировалась на техниках Максима Дорофеева, и я не один год ее «дотачивал». Она идеально работала больше пяти лет, но с текущим количеством и уровнем задач мою систему разнесло в щепки

© Habrahabr.ru