Перевод статьи «Promoted From Dev To Team Lead: 8 Things They Didn’t Tell Me».
Мне было всего 24 года, а моей карьере разработчика — всего три.
Жизнь была прекрасна. Я жил в маленькой квартирке в Бостоне. У меня была отличная работа в технологическом стартапе под названием «CloudLock». Я писал код по 12-14 часов в день. Порой я забывал о времени, и начальникам приходилось буквально выпихивать меня домой. В свободное время я играл в спортивные игры с друзьями или спал. И ничто меня не беспокоило. Но тут грянул гром.
Однажды мой босс, наш вице-президент по разработке, отвел меня в сторонку. Он рассказал, что наша команда очень быстро растет. А когда больше 15 разработчиков по всем вопросам обращаются к нему лично, это уже сложно. Нам были нужны тимлиды, чтобы мы могли масштабировать свою организационную структуру и чтобы каждый разработчик получал должное внимание. Будет ли мне это интересно?
Не буду врать: хотя я был удивлен, но о подобном задумывался и раньше.
«CloudLock» был второй моей компанией после колледжа. Сначала я работал в «Nuance Communications». И когда мой босс ушел на две недели в отпуск, я имел шанс побыть лидером команды. За эти две недели у меня расширилась сеть знакомств в компании. Звонки клиентов поступали в первую очередь ко мне. Я имел возможность прочувствовать, каково это: отвечать не только за свой код. Было очень интересно, и даже вроде бы хорошо получалось!
Этот опыт я и припомнил в тот день, когда Майкл заговорил со мной о повышении. Мне хотелось согласиться, но у меня был миллион вопросов. Не помню уж, что именно я сказал, но Майкл уверил меня, что я справлюсь, а он мне поможет. Майкл — отличный парень, я доверяю ему и уважаю его. Так что его слова были именно тем, что мне нужно было услышать.
Мои первые несколько месяцев в новой роли
Оглядываясь назад, я понимаю, что в то время совершенно не разбирался в своей новой работе. Я просто старался подражать действиям других тимлидов, с которыми был знаком.
Не поймите меня неверно: многое я делал хорошо. Но были и проблемы.
Для начала, каждый раз при возникновении проблем технического характера я включал режим супермена. Сразу кидался в бой, чтобы пофиксить все одной левой. В конце концов, я был отличным программистом и хорошо разбирался в нашей системе. Мне прекрасно удавалось помогать другим разработчикам решать возникающие у них проблемы. Именно поэтому меня и повысили, так ведь?
Поначалу части команды это нравилось. Они уважали меня за то, что я не боюсь запачкать руки, стараюсь помогать и быть отзывчивым.
Но кому-то это НЕ нравилось. Мои действия можно было воспринять и как чрезмерный контроль. Да и люди, которым поначалу все подходило, со временем изменили свою точку зрения. Они совершали одни и те же ошибки снова и снова, и не прогрессировали. Наши слабые разработчики оставались слабыми, а сильные не росли.
Были у меня и другие ошибки. Например, я слишком долго ждал, чтобы уволить плохого разработчика, чье поведение вредило всей команде.
8 вещей, о которых мне забыли сказать
Я думаю, что лидерство это бесконечное путешествие. Всегда есть, чему поучиться. К счастью, у меня были хорошие наставники. Но к некоторым открытиям я пришел путем проб и ошибок. Вот список вещей, насчет которых я жалею, что не знал их с самого начала.
1. Многие из ваших навыков непереносимы
Жестокая ирония: сильные навыки разработчика и тимлида находятся в обратной зависимости. Чем лучше вы как разработчик, тем сложнее вам будет начинать свой путь в менеджменте.
75% проблем, с которыми сталкивается тимлид, — не технического плана. Мы больше работаем с людьми и процессами. Когда я это понял, все встало на свои места.
В нашей кодовой базе я мог исправить практически что угодно. У меня отлично получалось находить креативные решения проблем, с которыми сталкивались другие разработчики. Но эти и другие мои характеристики больше не были релевантны для должности.
Комплекс супермена
Если команда сталкивается с технической проблемой (баг, блокер), хороший разработчик зачастую инстинктивно в ту же секунду бросается ее решать. Когда я поступал так, будучи разработчиком, коллеги были мне благодарны, а руководство считало меня хорошим командным игроком. Но когда вы делаете то же самое, будучи менеджером, это как раз означает, что вы НЕ хороший командный игрок.
Мы должны не решать проблемы, а предоставлять нашим людям возможность решать их. Даже если поначалу так будет дольше. Даже если другие разработчики будут допускать ошибки. И даже если они не сделают все так же хорошо, как сделали бы вы.
Когда вы не решаете проблему самостоятельно, а помогаете команде разобраться, вы получаете много преимуществ. Ваши люди увидят, что вы им доверяете. Они большему научатся. Со временем они станут более самодостаточными. Также они научатся помогать друг другу, а это сближает команду.
Дополнительный совет
Всеми силами старайтесь никого не осуждать. Когда ваши люди чувствуют, что могут выйти из зоны комфорта и совершать ошибки, не боясь критики, это высвобождает их истинную креативность. Вы удивитесь, увидев, на что они способны.
Еще один дополнительный совет
Обучая свою команду, вы можете «масштабироваться». Объясняйте, почему считаете правильным то или иное решение. Озвучивайте свой мыслительный процесс при диагностике проблемы. Рассказывайте, как вы находите подходящие варианты решений.
Глубокая концентрация
Еще один навык, который не пригодился мне как менеджеру, — умение глубоко фокусироваться. Когда вы разработчик, вам нужно входить в «зону». Мне хорошо удавалось отключаться от всего и фокусировать все свои силы на решении конкретной задачи. Но когда вы тимлид, это для вас смерти подобно.
Хорошие лидеры умеют быстро переключать контекст. Они постоянно в движении, они общаются со множеством людей. Если вы обнаруживаете, что на несколько часов увязли в технической проблеме, вероятно, это знак, что нужно побольше делегировать полномочия.
Когда можете позволить себе роскошь глубоко сфокусироваться на чем-то, подумайте о стратегических инициативах. Например, о том, как убедить совет директоров пойти на новые нефункциональные вложения или нанять еще троих разработчиков.
2. Не отказывайтесь от своих инстинктов. Меняйте свое поведение
У хороших разработчиков хорошие инстинкты. Ваша интуиция, происходящая из вашего опыта, ваше знание системы и понимание всех процессов позволяют вам чувствовать, что происходит. Вы ощущаете, где в коде что-то пошло не так. Вы ощущаете, когда итерация команды выбивается из расписания.
Продолжайте доверять своим инстинктам. Но действовать при этом нужно по-другому, не так, как вы привыкли.
Ваше шестое чувство теперь необходимо вам даже больше, потому что нужно определять, что кто-то нуждается в вашей помощи. Это чувство пригодится, когда услышите на стендапе что-то, что покажется вам неправильным. И когда у кого-то не получится найти причину проблемы в продакшене. И когда будете помогать с ревью кода.
Но если нельзя выскакивать, как супермен, и решать проблемы, то что же делать?
Во-первых, глубоко вдохните. Мы привыкаем действовать быстро, но для менеджера это скорее недостаток. Продолжайте слушать и дайте себе время на обработку информации.
Если не услышали достаточно, задавайте вопросы. Собирайте как можно больше сведений, прежде чем давать советы. Порой даже постановка правильных вопросов может помочь вашему разработчику взглянуть на проблему под другим углом и самостоятельно найти решение.
3. Больше говорите о «почему», чем о «что» и «как»
Как разработчики мы привыкли иметь дело со «что» и «как». Для менеджеров это тоже имеет значение, но куда важнее фокусироваться на «почему». Причин для этого несколько:
Равнение на пользователя
Менеджеры продуктов скорее всего изложили проблемы пользователей и use cases в историях. Но разработчики все равно могут не увидеть леса за деревьями. Если вы будете постоянно напоминать команде о проблеме, которую они решают, и о пользовательском опыте, вы гораздо чаще будете выпускать высококачественные продукты.
Дополнительный совет
Когда разработчику случается застрять, я спрашиваю его: «Можешь ли ты описать, что твой пользователь будет делать до, после и во время использования этой функции?». Если он не может этого сказать, значит, ему нужно предоставить больше информации.
Еще один дополнительный совет
Поощряйте разработчиков заниматься поддержкой пользователей. По своему опыту могу судить, что во многих командах об этом только говорят, но по факту не делают. Мы взяли себе за правило, что каждый разработчик отвечает как минимум на два звонка пользователей в месяц.
Равнение на бизнес
Значительная часть работы лидера состоит в том, чтобы доносить решения руководства до разработчиков и настраивать команду работать для достижения целей бизнеса. Я верю, что за каждой строкой кода стоит бизнес-решение. Наша главная цель — привлечь побольше пользователей и принести прибыль? Или попытаться повысить удовлетворенность пользователей? Мы делаем стратегические инвестиции в не-функциональную работу, чтобы сэкономить деньги и получить большую прибыль? Чем больше ваши люди понимают влияние общей картины на их работу, тем в большей мере они смогут мыслить стратегически и принимать лучшие решения при написании кода.
Миссия и мотивация
Большинство людей хотят быть частью чего-то большего. Когда вы делитесь со своей командой ответами на все «почему», это помогает связать их с остальной частью компании. Также, независимо от того, чем занимается ваша компания, у вас есть пользователи, которые зависят от вашего продукта. Живые люди. Когда вы рассказываете разработчикам, «почему?», это помогает им заниматься чем-то большим, чем решение задачи текущего спринта. А это, в свою очередь, делает их более счастливыми и ведет к построению более сильной командной культуры.
Карьера
Лучшие менеджеры, с какими я работал, настраивали меня на успех на новом рабочем месте. Независимо от того, захочет ваш разработчик развиваться по технической части или перейти на путь менеджмента, ему нужно будет научиться видеть крупный план картины и объяснять все «почему» другим людям. У меня были наставники, которые учили меня этому, и я стараюсь «вернуть долг», обучая других.
4. Культура это реальная вещь. И за нее отвечаете вы
Что касается культуры, это нечто вполне реальное, и именно на вас лежит ответственность за ее формирование.
Можно ли дать определение культуры? Ну, ее легче описать, чем определить. Но это не означает, что культура — нечто придуманное. Я думаю, она сродни гравитации. Нечто невидимое, не дающее нам разлетаться во все стороны.
Что я точно знаю насчет культуры, это то, что она помогает разделению ценностей. Также помогает, когда вы эти ценности записываете, используете в ежедневной работе и повторяете время от времени.
Еще я знаю, что культура перетекает сверху вниз и снизу вверх. Если вы сами в эту культуру не верите, ваши разработчики это поймут. Они увидят, что вы не живете ею. Поэтому все должно быть натурально.
Что касается меня, в деле построения культуры мне помогают три вещи:
- проявление доброты и эмпатии к каждому,
- слова, не расходящиеся с делом,
- скромность и концентрация на команде.
5. Расчищайте путь для своих людей
Одна из моих проблем на менеджерской позиции связана с тем, что образ действий людей и компьютеров отличается. Серьезно.
Код детерминирован. Вы говорите ему что-то сделать. Он делает. Если код делает что-то не так, как задумано, вы исправляете его, и он начинает делать это правильно.
Но люди устроены совсем иначе! Вы не можете просто сказать им, что делать. Это не сработает. Сегодня вы получите один результат, а завтра можете получить совершенно другой.
Работая с людьми, вы можете только настраивать их на успех и доверять. И если вас окружают хорошие разработчики, лучшее, что вы можете сделать — расчистить им путь и отойти в сторону.
Я знаю, что занявшись разблокировкой команды, потрачу время с умом. Еженедельно мы сталкиваемся с блокерами трех видов.
1. Технические
Об этих нам все известно. Старайтесь не решать технические проблемы лично. Поощряйте разработчиков делать это самостоятельно или помогать друг другу.
2. Зависимости
Как разработчик вы тоже имели дело с этими блокерами, но теперь вы в лучшем положении и можете предугадать, когда и где возникнет проблема. Это позволяет начать решать проблему на более ранних стадиях.
3. Приоритеты
Проработав некоторое время в роли тимлида, я осознал основную причину, по которой у команды случаются неудачи с итерациями. Это происходит либо потому, что разработчики не поняли, какая задача имеет наивысший приоритет, либо потому, что были вынуждены отвлекаться на другие задачи. В конечном итоге я стал контролировать, чтобы каждый разработчик работал над самыми большими задачами, решение которых поможет нам уложиться в сроки.
Дополнительный совет
Не стоит тратить время на озвучивание того, кто на каком этапе работы находится: это можно сделать в сообщении в Slack. Лучше говорите о приоритетах. Дайте вашим разработчикам рассказать о том, каковы их основные приоритеты, и не мешает ли им что-то заняться этой работой. Я уверен, что это существенно повысит вовлеченность вашей команды в процесс и в результате вы будете куда чаще укладываться в сроки.
6. Определение приоритетов и эстимейты занимают до 50% вашего времени
Когда вы разработчик, вас часто спрашивают, на каком этапе ваша работа. Когда вы становитесь тимлидом, вас спрашивают об этом в 10 раз чаще.
Определение приоритетов и оценка времени, необходимого для выполнения задач, отнимает у меня как минимум половину времени. Эти задачи для меня интересны и мне нравится работать над ними.
О том, как правильно делать эстимейты, уже написано много статей, так что я не буду подробно на этом останавливаться. Поделюсь лишь несколькими советами.
- Когда речь заходит об эстимейтах, будьте честны и не играйте в игры. Не говорите людям то, что они хотят услышать. Если бизнес говорит «Я уверен, вы сможете сделать это быстрее», — стойте на своем. В противном случае вам придется расхлебывать последствия.
- Как можно больше прислушивайтесь к своим разработчикам. Старайтесь ставить на первое место их нефункциональные запросы, потому что в конечном итоге это позволит вам ускорить работу над тем, что нужно кому-то еще. Опять же, на вас будет давить начальство и вынуждать фокусироваться в первую очередь на разработке функционала для пользователей. Вы должны доказать, что если займетесь нефункциональными требованиями сейчас, то в будущем сможете создать куда больше пользовательского функционала.
- Попробуйте подружиться с лидерами продукта и просветить их насчет того, что нефункциональная работа, которой вы хотите заняться, в конечном итоге поможет им получить желаемый функционал гораздо быстрее. Объединив усилия с менеджментом продукта, вы с большей вероятностью сможете убедить остальных.
7. Инвестируйте в свою экосистему
Когда мы получаем повышение, наш круг знакомств увеличивается в 3-5 раз.
Мы привыкли работать с разработчиками из нашей команды, собственником продукта и порой с разработчиками из других команд.
И тут внезапно оказывается, что нужно иметь дело со всеми остальными менеджерами, многими из их разработчиков, со всеми людьми, ответственными за продукт, с техподдержкой, отделами продаж и HR. Не говоря уже о вышестоящих менеджерах в нашем собственном отделе.
Эти отношения имеют очень большое значение. У вас не получится добиться успеха на новом поприще без помощи всех этих людей. Как и подняться на новый уровень карьеры. Поэтому инвестируйте в отношения с этими новыми знакомыми. Узнавайте, что для них важно, и старайтесь как-то облегчить их жизнь.
Например, общаясь с людьми из отдела продаж, поинтересуйтесь, что может помочь им в проведении демо. Поработайте над чем-нибудь для них на своем следующем хакатоне.
8. Переводите разработку на язык цифр
Ваш новый босс (директор, вице-президент, технический директор) будет интересоваться не теми вещами, о которых вас спрашивали, когда вы были разработчиком. Скорее всего он будет куда более сосредоточен на данных и показателях, потому что именно этим интересуется его собственный начальник. Дайте ему эти данные.
Отличные воспоминания
Мне нравилось быть тимлидом. Удовольствие от этого было не таким, как когда постоянно создаешь что-нибудь сам. Но помогать людям раскрывать их потенциал приятно. Тимлид — одна из позиций, на которых у вас больше всего возможностей. Вы можете и тактически воплощать что-то в жизнь, и влиять на стратегию.
Два года спустя меня повысили до директора. Позже — до вице-президента по разработке. Я всегда стремился к прогрессу и решению новых задач. Но годы, проведенные в роли тимлида, вспоминаю с большой теплотой.
Чем выше вы поднимаетесь по карьерной лестнице, тем более одиноко там бывает.
Я скучаю по решению проблем в команде. По ночным переработкам, чтобы успеть к дедлайну. По шуткам «для своих». Нет ничего, что сравнится с работой в маленькой дружной команде.
Наслаждайтесь этим. Это не будет длиться вечно.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]