Говорят, у менеджеров никогда нет времени — у них постоянные созвоны и миллион разных дел. Свободный слот в их расписании найти сложнее, чем билеты на концерт твоей любимой группы. Создаётся впечатление, что чем выше твоя должность, тем больше времени в сутках тебе нужно, чтобы всё успевать. И начинает казаться, что помочь тут может только маховик времени из мира волшебства. Так вот, это не так. Если к вашему тимлиду нужно записываться за 2 недели, или вы сами менеджер, и у вас постоянно не хватает ни на что времени, то знайте — это не норма.
Чаще всего мы просто не умеем управлять своим временем. Пытаемся быть везде, делать всё. Но через какое-то время должно прийти понимание простого факта — невозможно решать проблему нехватки времени простым масштабированием рабочих часов. В такой тупик часто упираются менеджеры-новички, но к некоторым понимание, как быть более эффективным, не приходит ещё очень долго. У новоиспеченного тимлида может сформироваться ощущение, что он обязан обрабатывать весь поток входящей информации и как-то на него реагировать, — помогать, решать их проблемы и т.п., т.е. тратить на все это время. Ведь он теперь тимлид, на нем всё держится! И вообще, хочется показать коллегам, что не зазнался и не превратился в небожителя, который теперь игнорирует все проблемы “простых смертных”, а наоборот всё ещё бывший коллега-разработчик, весь в доску свой и небезразличный. Но с такой загруженностью у него просто не остается времени на высокоуровневый взгляд на работу, при котором видны проблемы всего проекта. Когда же планировать стратегические — кадровые, архитектурные и коммуникационные — решения?
У начинающих тимлидов пухнет голова от того, что им нужно делать. И тут легко не заметить, что более важный вопрос — чего, наоборот, делать не следует. В этой статье разберем, как выявить подобные вещи, почему за них не стоит браться и куда их девать.
Взгляд со стороны тимлида
Меняя роль с разработчика до тимлида, ты меняешь характер деятельности. Как рассказывал мой коллега в предыдущей статье, ты уже не можешь себе позволить работать в потоке целый день над одной задачей. Тебе постоянно кто-то пишет, закидывает созвоны, обращается с быстрыми вопросами.
Казалось бы, задача тимлида — делать те вещи, которые нужны для команды, но почему-то никем не охвачены. Он прикрывает тылы, т.е. одновременно и чтец, и жнец, и на дуде игрец. Но на самом деле всё чуть сложнее: хороший руководитель понимает, когда тылы на каких-то участках фронта нужно прикрыть, а когда — нет. Не надо увлекаться и прикрывать все подряд. Это мешает превратиться из начинающего тимлида в продвинутого. Много стягивая к себе, ты не даешь себе же расти дальше, утопая в куче операционки. На решение стратегических вопросов времени не остаётся.
Завязывая все на себя, ты не только себе, но и другим оказываешь медвежью услугу: закрываешь все бреши и ложишься на амбразуру, пока твоя команда чилит на пляже под зонтиком с ноутбуком. Мало того, что команда в такие моменты не разделяет с тобой боевые трудности, и это мешает им лучше понять проект и ощутить его потребности, так ты ещё и не даешь им прокачиваться, расширять свою зону ответственности и продвигаться по карьере. Плюс без тебя такая команда будет неспособна поддерживать проект, ведь они банально не в курсе многих вопросов, а значит ты плохой руководитель, т.к. не следишь за бас фактором, в данном случае своим.
Чтобы не переусердствовать, стоит в голове иметь некоторый фильтр, через который проходит весь входящий поток вопросов, проблем и жалоб. Уделять свое внимание и время стоит только тем вещам, которые прошли этот фильтр. Мой такой фильтр состоит из нескольких вопросов, которые я задаю применительно к каждому делу, которое мне прилетает.
Стоит ли это твоего или вообще чьего-то внимания (или это чей-то эмоциональный всплеск, который имеет совершенно иные корни)?
Допустим, у вас упал сервак. Он падает пятый раз за месяц. И каждый раз какой-нибудь условный Вася нажимает кнопку, чтобы его поднять. В определенный момент Васю может взбесить, что отпуска не было уже полгода, он выгорел на сложном проекте, а надо опять поднимать сервер. Он придет жаловаться, и будет делать это довольно эмоционально.
Но это не значит, что прямо сейчас нужно бежать и переделывать кластер на Kubernetes, который всех устраивает по отказоустойчивости. Этот займет полгода, а результат никак не отразится на проекте. Особенно если на падающем серваке крутится только один сервис, который даже не в проде и был нужен в последний раз несколько месяцев назад. Скорее имеет смысл один на один выслушать Васю, выяснить его видение и в диалоге прийти к оптимальному решению. Вероятно, оно будет заключаться в том, чтобы оставить сервер как есть. Решать тут надо скорее ситуацию с выгоревшим Васей, пока он вконец не разнес себя и попавших под руку его эмоциональных всплесков.
Если ты, как тимлид, видишь в выполнении какой-то задачи ценность, то действительно следует уделить ей внимание. Но сотрудники на самом деле генерируют много вещей, которые вообще не нуждаются в реакции, или нуждаются, но не в той, которая предполагается изначально.
Готов ли коллектив к тому, чтобы решать проблему?
Любая проблема должна вызреть. Если все видят, что что-то не так, но пока не могут сформулировать, в чем же именно загвоздка, значит время для решения проблемы еще не настало.
Как говорится, дорога ложка к обеду. Может быть такое, что ты, тимлид, уже понял, в чем проблема, а команда — еще нет. В таком случае коллеги просто не будут готовы получить решение.
Помогать надо ровно в той мере, в какой люди готовы эту помощь принять. Нужно вести коллег по шагам, а не километровыми прыжками: сначала осознание и формулирование, потом решение. Невозможно пройти часть этих шагов за других, чтобы все ускорить.
Часто начинающий лид пытается сделать все за команду. Ты же уже видишь проблему, уже понимаешь, как ее решить. И решить ее зачастую проще, чем погружать команду в понимание её сути. Но такой подход имеет свои последствия — команда начинает думать, что в любой ситуации, когда что-то не так, тимлид придет и спасет положение. А если он по каким-то причинам не приходит прямо сейчас, то это тимлид плохой. Вся проактивность коллектива на этом заканчивается — они больше не считают, что это у них проблема, с которой нужно что-то делать. Они знают: придет тимлид и расскажет, как поступить (а сама команда при этом его ещё и покритикует).
Самое главное, что подобные решения тимлида будут ощущаться для команды “искусственными” — их будут не готовы принять. Даже наоборот, скорее всего коллеги встанут в оппозицию и будут искать любые причины, чтобы их не исполнять, просто потому что это решение сгенерировали не они. Люди не любят такие вещи, даже если объективно это единственный и правильный выход.
Люди — существа социальные, их мотивация всегда растет изнутри. И нужно уметь с ней работать — вдохновлять на то, чтобы они делали свою работу сами и самостоятельно принимали решения. За такие решения они смогут и отвечать самостоятельно.
Должен ли я делать это прямо сейчас или неопределенность еще слишком высока?
Бывает, что проблема существует, но у цепочки событий есть миллиард возможных веток развития. И никому пока не понятно, что делать, потому что ни у кого из участников процесса просто не было схожего опыта.
Заходить в решение такой проблемы — часто значит долго сидеть, чесать репу, пожечь ресурс команды и в итоге ничего не надумать. В подобной ситуации обычно принимаются очень плохие решения, а команда по итогам находится в весьма неуверенном состоянии. Что-то надумали, а что и почему — не очень понятно (был же еще миллион вариантов).
В таком случае полезно бывает просто подождать. Либо проблема у кого-то настолько заболит, что он будет очень замотивирован её решить, будет готов пробовать любые решения и смотреть, какое сработает. Тогда степень неопределенности уже не так важна. Главное, что есть какое-то решение. Либо в будущем появится новая информация и вырастет экспертиза, туман рассеется и внезапно откроются новые горизонты. Обычно так бывает, если в команду приходит новый человек или происходит какое-то внешнее событие, меняющее положение вещей. Вместо миллиона вариантов остается два-три, из которых выбрать гораздо легче.
Попытка решить вопрос раньше времени съест много сил тимлида и команды, а в итоге все будут не уверены в принятых решениях. А главное, не будет четкого понимания, зачем все это сейчас делается. Из-за этого команда начнёт “плавать” по ходу реализации выбранного решения. Если у разработчика возникнет какая-то сложность, которая мешает сделать так, как планировали, он вернётся в команду и будет предлагать “передоговориться” на другое решение, которое теперь будет ему казаться более простым в реализации. И так может случаться по ходу выполнения задачи несколько раз. А после реализации решения любая возникшая с ним проблема будет заставлять команду думать: “блин, это было неправильное решение, надо было делать по-другому”, — даже если проблема на самом деле не серьезная.
Почему бы не делегировать это?
У каждого человека в команде есть своя зона ответственности. Тестировщики отвечают за качество, DevOps-ы и SRE-шники — за отказоустойчивость и надежность решений, разработчики — за технологичность. Как тимлид, ты можешь быть в это частично завязан, но вообще говоря это не обязательно.
Когда приходит информация о проблеме, надо спросить себя, ты ли должен ей заниматься? Допустим, если постоянно падает продакшен, нужно спросить SRE-шника, не кажется ли ему это странным и не нужно ли с этим что-то сделать, а не бежать самостоятельно копать логи и ставить миллион задач.
В целом логично, чтобы разбором проблемы занимался тот, рядом с чьей зоной ответственности находится — в этом случае человек за счет этого вырастет. Тот же SRE-шник может считать, что это не его проблема — тогда надо пойти и объяснить, что этот вопрос находится в его компетенции.
Если же задача такова, что не ясно, кому ее отдавать, можно подобрать коллегу, у которого сейчас есть время и явно наблюдается некое “болото” вокруг. Рандомный запрос в этом случае может вывести его из этого неприятного состояния. И заодно он поможет команде.
Самое главное — не просто выдать задачу, но и накинуть прав на ее решение, дать свободу действий. Тогда человек действительно пойдет бороться с проблемой. Тимлиду останется только его гайдить, чтобы он не наломал по пути дров, но ни в коем случае не делать работу за него.
Кстати, что касается дров. Многие думают, что задача тимлида — сделать так, чтобы никто никогда не косячил. Но на самом деле это не так. Его задача — дать каждому человеку право на свои собственные ошибки, чтобы он получил опыт и набил собственные шишки. Тимлид же при этом остается страховкой, которая в случае проблем может поддержать и помочь вырулить из неприятной ситуации.
Отдавая работу кому-то другому, ты на самом деле одновременно показываешь коллегам, где у вас в команде проходят границы зон ответственности — кто за что отвечает и к кому можно обратиться с определенным вопросом. Это уже про налаживание внутрикомандных взаимодействий. Тимлид же не должен завязывать на себе все коммуникации.
Предположим, пишут ему: “Скажи адрес базы данных для такого-то сервиса”. Тимлид не должен открывать конфиги и выяснять ответ на этот вопрос. Он может отправить к SRE-шнику, который владеет всей необходимой информацией. И в следующий раз с аналогичным вопросом пойдут уже напрямую к нему. Т.е. перенаправив 5-минутный вопрос, тимлид себе сэкономил час с дюжины таких обращений в будущем. А запросы, которые приходят к SRE-шнику, возможно, сподвигнут того сделать какую-то справочную страничку — так он разовьет и свою работу, тоже сэкономив время. А пока тимлид, как прокси, ограждает его от подобных запросов, ему и в голову это не придёт.
Бывает так, что нестандартную задачу отдать действительно некому. В этом случае тимлид может взять ее сам. Но это должна быть исключительная ситуация. И это нужно явно продемонстрировать команде — что есть такая-то задача, подобных еще не решали, по таким-то причинам тимлид сейчас будет ее ковырять. Также следует погрузить команду в суть принятого решения. Иначе у коллег будет создаваться ощущение, что тимлид занимается чем-то своим, себе на уме, пока команда пилит задачи. Умозрительно это отрывает лида от команды. Если же команда в курсе активностей лида, разрыва не возникает, а кроме того в будущем будет проще делегировать аналогичные задачи кому-то из команды.
В целом задача тимлида — делать мета-работу, т.е. думать над тем, как должна совершаться работа (но не делать эту работу самому). Допустим, у нас проблемы с продакшеном. Тимлиду нужно понять, стоит ли вызвать какого-то профессионала, если у команды не хватает компетенций. Или экспертизы на самом деле хватает, но мы не уделяем этому достаточно внимания — тогда нужно перераспределить на это больше ресурсов. Если понятно, что проблему не получится решить одной задачей, можно организовать рабочую группу, которая будет заниматься этим и постепенно поднимать качество прода.
Как при этом мотивировать сотрудников на выполнение задач, на то, чтобы они брали на себя ответственность, — это отдельная большая часть работы тимлида. На тему этого есть много материалов.
Взгляд со стороны развития команды
Как руководителю, тебе интересно растить команду, с которой работаешь. Логично, что члены команды постепенно учатся и набирают опыт, их возможности растут, и значит можно и даже нужно расширять их зону ответственности (в пределах разумного). Но во многом именно от тимлида зависит, насколько команда сама будет к этому стремиться.
Некоторые руководители любят тыкать всех носом в каждый косяк (при этом вокруг у всех действительно дела валятся из рук). Это тешит их самолюбие. Получается, что руководитель в такой команде — самый крутой: всех лечит, тушит пожары и так далее.
Проблема в том, что в целом для организации такая схема не эффективна. Люди от такого режима работы демотивируются, а суммарный выхлоп от команды меньше.
Важно, чтобы руководителя не стало слишком много. Сотрудникам хочется делать прикольные штуки. Хочется чувствовать свой участок, на котором они круты. И вот это как раз выгодно компании. В этот момент растет личная ответственность каждого специалиста, а все проблемные зоны находятся под присмотром.
Чтобы команда существовала в таком режиме, руководителю иногда надо что-то не делать. Главная функция тимлида — в лидерстве, а не в операционной деятельности. А главный смысл работы — организовывать все так, чтобы команда была способна сама заниматься текущей деятельностью: чтоб задачи двигались по доске, коммуникация работала, баги заводились и решались, проект жил. Чтоб можно было вернуться через месяц-другой, а все заняты делом, бэклог уменьшается, система развивается.
Но стоит идти и дальше — делать лидерами всех членов команды. И отдавать часть управления внутрь команды, строить такие процессы, чтобы развитие продукта происходило устойчиво и не требовало лида вообще. Такая команда сможет пережить и уход кого-то из сотрудников, и смену лида, будет гораздо устойчивей к переменам во внешнем мире, а сотрудники будут расти как в понимании продукта и потребностей компании, так и по карьерной лестнице.
Человек, который не следует этой идеологии и берет на себя некие обязанности навечно, обречен быть не очень хорошим тимлидом, по крайней мере в довольно крупных компаниях и больших командах. Такой подход работает только в командах, где от силы три человека, и один из них тимлид, который все тащит. Но если команд несколько, а компания растет, одному лиду физически это все не вытащить. Он быстрее сломается, нежели вывезет на себе всю эту историю.
В целом задача тимлида — указывать команде путь развития. Помогать, мотивировать людей. Искать, что и где плохо устроено, где висит ничейная ответственность. Находя такие моменты, он налаживает рабочий процесс и отдает его команде, а сам идет искать дальше.
А что в итоге
На самом деле развитие команды связано с развитием руководителя. Если ты хочешь уйти на повышение и руководить более масштабными и сложными вещами, тебе стоит в первую очередь заняться не своим ростом, а развитием подчиненных. Когда они вырастают и разгружают тебя, появляется время на саморазвитие и участие в более масштабных активностях. Да и более высокое руководство видит, что команда без тебя не развалится — можно думать о повышении. Или что у тебя появилось свободное время, которое можно потратить на другие интересные проекты.
В итоге рост команды — залог твоего собственного роста.
Автор статьи: Дмитрий Литвин, Максилект.