Тимлид в центре бури: как удержать равновесие между командой, продуктом и бизнесом?

Нелинейный карьерный трек: почему шаг в сторону – это не даунгрейд

В моем карьерном треке с 2005 года были и переходы между компаниями и смена ролей. В нескольких точках кривая уходит вниз — со стороны это легко принять за даунгрейд. Однако я никогда не воспринимал такие переходы как шаг назад: каждый раз это было осознанное погружение в более масштабную инженерную культуру, новый стек процессов и кратный рост масштаба бизнеса — от локального интегратора на 15 человек до enterprise-структур со штатом свыше 10 000 сотрудников.

Кому будет полезна эта статья?

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

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

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

О чем статья?

• О собственных и чужих ошибках – фактически о моей профессиональной истории,

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

• О том, как проблемы в любой из этих частей создают дисбаланс во всей системе,

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

Кто такой TeamLead: ожидания и реальность

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

TeamLead в реальной жизни

А кто же такой TeamLead в реальной жизни. Узнаете себя? Дедлайны, смена приоритетов, множество задач, конфликты – вокруг все горит и полыхает.

Анатомия бури: как возникает системный дисбаланс

Почему в реальной жизни тимлид так часто ощущает себя героем мема «This is fine»?

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

Бизнес приходит с требованием: «Сделай это срочно». Сотрудники ждут постановки задач и помощи в сложных местах. Параллельно нужно выстраивать пайплайн поставки и развивать продукт. Как только продукт попадает в бизнес-среду, он генерирует новую волну запросов — водоворот закручивается и ускоряется. За что хвататься в первую очередь?

Первый элемент баланса: команда

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

Личный опыт. Первые шаги в руководстве

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

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

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

В какой-то момент я понял, что как инженер я уже не расту и не развиваюсь, да и как руководитель тоже не двигаюсь вперед.

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

Кейс авторитарного руководства

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

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

Анализ ошибок в управлении командой

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

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

• Часто делаешь сам вместо того, чтобы делегировать. Это мой опыт начинающего руководителя.

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

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

• Мало общения, дискуссий и споров. Открытая коммуникация в безопасной среде – это залог успеха в коллективной работе. Так формируется доверие, отсутствие которого является базовой дисфункцией команд.

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

Все это приводит к тому, что в команде возникает:

• Недостаток доверия и открытости,

• Недостаток мотивации,

• Отсутствие автономности,

• Низкий bus-factor, т.е. проблемы с взаимозаменяемостью.

Выводы

К каким выводам я пришел:

• Прежде всего, будь человеком. Эмпатия, коммуникация, поддержка, умение поставить себя на место другого – важнейшая составляющая в работе с командой.

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

• Стань «фанатом» своей команды: поддерживай, заряжай, мотивируй людей, прощай им неудачи.

• Развивай открытость и доверие. Вовлекай людей в дискуссии и споры, давай право на ошибку и давай регулярную честную обратную связь.

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

• Рефлексируй вместе с командой. Обязательно работайте над ошибками, но без обвинений. Разбирайте что стоит делать иначе, что прекратить делать, а что начать, либо продолжить и усилить.

• Найди ментора/стань ментором. Я бы сейчас тому себе 2005 года многое мог рассказать и многому научить, но тогда рядом не было человека, который мог бы помочь, направить, ответить на вопросы

Практики для развития команды

Переход к бизнесу: взаимодействие с заказчиком

Как вы думаете, спустя время, после того как я прошел по этим граблям сам и посмотрел на других, я больше не чувствую себя тем псом из мема «This is fine»? Конечно же нет. Теперь я чувствую себя вот так:

Согласитесь, немного получше.

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

Кейс: «Труба» между бизнесом и командой

Теперь перейдем к следующей составляющей баланса – бизнесу. Тимлид – мост между бизнесом и командой. Звучит круто, но что по факту? Всегда ли это так?

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

Расскажу другой свой кейс. Когда я перебрался в Москву и устроился в одну довольно крупную компаний в роли тимлида, то некоторое время работал с руководителем продукта (product owner), который ставил задачи командам. Он был даже не мостом и не канатом – он был трубой между бизнесом и командой.

Что это значит? Он шел к стейкхолдерам от бизнеса, собирал требования, заворачивал их в задачи в Jira, а потом просто сваливал все это в команду – вот вам, ребятам, бизнес сказал «надо».

Что в итоге? Команда перегружена – нет фокуса, постоянные переключения. Требования бизнеса не проходят валидацию, отсутствует даже минимальная приоритезация и сравнение задач по их бизнес-ценности.

Типичные ошибки во взаимодействии с бизнесом

Какие здесь типичные ошибки?

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

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

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

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

Не обмениваешься обратной связью. Ты не приносишь в команду информацию от бизнеса и не приносишь бизнесу фидбек от команды. Возникает разрыв: бизнес и команда оказываются на противоположных полюсах.

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

Последствия дисбаланса в работе с бизнесом

Какие возникают проблемы?

• Команда перегружена работой,

• Команда расфокусирована,

• Растягивается Cycle Time для важных изменений. Когда есть хаос и задачи влетают случайно, сложно сделать все быстро и вовремя,

• Отсутствует стратегия развития продукта. Ты рандомно берешь задачи, и непонятно, куда в итоге движется продукт.

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

Способы сближения команды и бизнеса

Как же сблизить команду и бизнес? Какие есть возможности?

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

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

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

Третий элемент баланса: продукт

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

Распространенный анти-кейс: «космический корабль»

Распространенный кейс. Бизнес приходит в ИТ и говорит: «Хочу качели»:

Руководитель ИТ-команды говорит «Окей, мы сделаем вот такие»:

.

Обо всем договорились, согласовали сроки бюджет. Команда идет работать и через некоторое время приносит вот это:

Причем бизнес считает, что ждал он столько и потратил в конечном счете столько, сколько нужно, чтобы построить это:

А вот реальная история из моей жизни.

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

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

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

Ключевые ошибки:

• Сооружаешь «космолеты».

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

• Мало взаимодействия с потребителем продукта. В моем случае взаимодействия с будущими пользователями продукта на этапе его создания не было совсем.

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

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

Какие проблемы возникают и как это влияет на баланс?

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

• Высокие затраты.

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

• Продукт не решает реальные проблемы бизнеса как итог. Ты увлекаешься, пилишь что-то, а продукта как не было, так и нет. Или он есть, но делает не то, что нужно.

Рекомендации по работе с продуктом

Какие выводы?

• Начинай с MVP – Minimum Viable Product, минимально жизнеспособного продукта.

• Проверяй гипотезы, получай обратную связь. Эти вещи знакомы всем, но почему-то часто забываются.

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

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

Итог: как достичь баланса

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

• Формируй, развивай и поддерживай команду. Нужно создать сильную, самостоятельную, замотивированную команду, которую не нужно постоянно подталкивать. Как это делается – я рассказал в начале.

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

• Пойми и транслируй бизнес-цели. Если ты сам не понимаешь, что делаешь и что важно бизнесу, ты не можешь донести это до команды и не можешь ее заинтересовать.

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

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

Философия баланса: доверие процессам

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

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

Это важно: не нужно пытаться удерживать баланс на своих плечах.

Заключение

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

Если кто-то захочет почитать полезные книги, я бы рекомендовал эти четыре. Здесь про команду, про Scrum – книга от одного из создателей Scrum, Джеффа Сазерленда. Это база для тех, кто работает по гибким методологиям. Там много про майндсет, про необходимость менять мышление.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAMLEAD&CIO EVENT.