К чему можно оказаться не готовым, став тим-лидом

http://dev-human.com/entries/2015/09/07/things-i-was-unprepared-for/
  • Перевод
imageОдин технический специалист нашей компании PayOnline, которая занимается автоматизацией приема платежей, предложил перевести статью автора Pascal de Vink, который проработал тим-лидом уже 2 года. Когда Pascal только занял эту должность, оказалось, что ко многим вещам он был просто не готов. Эта статья поможет избежать многих ошибок на пути от разработчика к лидеру команды. Ниже идет непосредственно перевод.

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

Меньше заниматься разработкой


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

Делегировать задачи


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

Распределять финансы и бюджет


Финансовая сторона дел обычно меня не интересует. Тем не менее, т. к. я теперь нес ответственность за команду и за то, чтобы он двигалась в верном направлении, деньги вдруг стали иметь большое значение. Я отвечал за то, сколько мы тратим и какую ценность создаем для компании. Мой опыт в финансах ограничивался домашним бюджетом, да и им я предпочитал особенно не заниматься и был рад, если кто-то составлял его за меня. В этот раз такой номер не прошел. Я отвечал за лицензии, которыми мы пользовались, расчеты с подрядчики, расходы на командировки, отпускные, прибавки и зарплаты новым сотрудникам. Особенно напрягали лицензии (Zend server и Oracle) и подрядчики. Каждый месяц надо было проверять, что все оплаченные по чекам часы потрачены, а лицензии актуальны. Многое я смог автоматизировать через Excel и Jira, но все равно каждый месяц тратил на это целый день.

Принимать на работу и увольнять


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

Создавать культуру


Лидер группы создает культуру своей группы. Часто говорят, что культура — это то, чему позволяешь и чему не позволяешь случаться. В этом отношении я был совершенно неподготовлен. Хоть роль лидера и была мне знакома, и я не боялся говорить вслух, если считал, что что-то делается неправильно, я все-таки привык высказываться как равный среди равных, или хотя бы заручившись поддержкой других лидеров. На новой позиции у меня не было «группы поддержки» — другие лиды были заняты созданием культуры в собственных командах. И я больше не был равным среди равных в команде — ведь я был ее лидером. Команда ожидала от меня лидерства, в том числе и того, чтобы я определял, что дозволено, а что нет. Конечно, это просто сделать, когда речь о неуместном замечании или очевидном косяке типа опоздания. Становится сложно, когда сотрудник опоздал по уважительной причине, например, из-за болезни жены или ребенка. Каждый раз, когда сотрудник обращался с исключительной просьбой (например, отпустить домой), приходилось делать выбор — позволить или нет. Более того, я должен был оценить, какой эффект мой выбор окажет на всю команду, и что потом делать с этим эффектом. Иногда это было легко: если быть открытым и честным с командой, ей легче понять и принять решения тим-лида. Но бывало и тяжело — когда дедлайны на носу, а сотрудники не ладят. Сложно создать культуру позитива, честности и прозрачности в атмосфере стресса и негативных эмоций.

Мотивировать


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

Менторствовать


Как хороший лидер я считаю своим долгом не только поддерживать команду в форме, но и помогать ей расти. Еще одна вещь, к которой я оказался не готов — менторство. Думаю, у меня естественная склонность слушать людей и помогать им расти, так что в целом удавалось импровизировать на ходу, но все равно хотелось бы иметь побольше опыта. Я всегда думал, что менторство работает сверху вниз: менеджеры обучают друг друга, а потом свои команды. В реальности это необязательно так. Думаю, будь у меня опыт менторства других людей на ранних этапах карьеры, я был бы более готов к позиции тим-лида. В этом отношении могут быть очень полезны проекты типа PHP Mentoring.

Собирать фидбек


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

Планировать


В зависимости от роли, зачастую именно лидера команды первым спрашивают «когда будет готово?» и «хватит ли времени на X?». В прошлом я много помогал отвечать на подобные вопросы, но мне никогда не приходилось отвечать на них непосредственно топ-менеджменту. Мне не приходилось «планировать ресурсы» (терпеть не могу это выражение; люди — не «ресурсы»), поэтому оценивать, сможет ли команда взяться за еще один проект, мне было некомфортно. Позже я узнал, что стоит больше доверять планирование команде и оценивать, достаточно ли у нее времени. Еще я узнал, что за изначальной задачей зачастую кроется другая, скрытая задача. Если докопаться до нее, получите дополнительное время на планирование ресурсов.

Общаться с людьми


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

Подавать пример


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

Решать личные проблемы


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

Оценивать KPI, цели и задачи


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

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

Выступать перед публикой


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

Мы рассказали о подводных камнях, к которым оказался не готов Pascal, и, надеемся, что вы извлечете урок из этих ошибок, подготовитесь и не наступите на те же грабли. Если вам нужно организовать прием платежей на сайте, обращайтесь. Подписывайтесь на наш корпоративный блог, впереди еще много интересного.
PayOnline 59,22
Система электронных платежей
Поделиться публикацией
Комментарии 27
  • +3
    Спасибо!
    • 0
      Позже я увидел, что если сосредоточиться на том, чтобы приводить новых людей и проводить с ними более короткие собеседования, пользы будет намного больше

      Не совсем понятно, вы рекомендуете максимально просто и быстро брать человека на работу или не углубляться в собеседование? Что значит «приводить новых людей»?
      • +1
        Это перевод, автор источника, насколько я понял, рекомендует проводить более короткие собеседования, но чаще, и уже по результатам выбирать сотрудников. В его случае это оказалось эффективней чем проводить долгие дотошные собеседования, которые не всегда конвертируются в найм.
      • +2
        Мне повезло, что лично не пришлось никого увольнять

        А мне не очень. Был случай, когда я вышестоящему начальству в марте четко и ясно сказал — этого человека надо уволить, вы даете добро? Начальство держало его до ноября (!), после он был со скандалом уволен. До сих пор не понимаю, зачем нужно было его столько держать?

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

          Видимо, многое зависит от компании и коллектива. Как показывает личная практика, есть тимлиды, которые непрочь обновить вверенный ему коллектив, а потом приступать к непосредственной работе. Но тут, скорее, ошибка вышестоящих управленцев.
        • +9
          вот так поработав лидом хотя бы несколько месяцев начинаешь до слез прямо любить тишину своего рабочего места и КОД. Как все же классно копаться в коде: где мои 18 лет :)!
          А ведь есть еще один очень важный аспект работы тим-лида здесь не упомянутый.
          это жуткое ощущение практической бесполезности всей этой работы: когда ты весь день занят тысячей мелких проблем а к вечеру кажется, что не успел фактически ничего. Очень важно понимать, что оценка работы тим-лида строится на совершенно иных критериях.
          Т.е. из всех перечисленных в статье пунктов, самый важный все же
          > Меньше заниматься разработкой
          НО, если двигаться дальше, в менеджмент, то там в плане «заниматься разработкой» все еще хуже :)
          • +8
            это жуткое ощущение практической бесполезности всей этой работы: когда ты весь день занят тысячей мелких проблем а к вечеру кажется, что не успел фактически ничего

            Я думал такое только у меня, оказывается нет…
            • 0
              Так у всех…
              • 0
                не у всех. лично я получал удовольствие от напряженного ритма. И как-то всё успевалось
            • +1
              это жуткое ощущение практической бесполезности всей этой работы: когда ты весь день занят тысячей мелких проблем а к вечеру кажется, что не успел фактически ничего.


              Самое тяжелое при этом потом распределять затраченное время если работаешь на почасовой оплате…
            • +1
              Слишком поздно я понял,

              Выгнали таки с работы? ;-)
              • +4
                думаю, все же, что он о том, что назад дороги нет :)
                «взялся за гуж» и все такое.
                Жалеет страшно
              • +7
                Большинство моментов в статье точно подмечены, но, читая некоторые, я недопонимаю, причем тут технический лидер. Разве обязанностью технического лидера является следить за финансами, расчетами с подрядчиками, а также решать вопросы с болезнями, опозданиями, отпусками членов команды, разруливанием конфликтов, личными проблемами? Разве это не менеджер проекта должен делать?
                • 0
                  Да, но частенько в небольших конторах на проектах типа «3 программиста да 2 тестировщика на 3 месяца работы» нет отдельных ролей техлида, тимлида и менеджера. Есть «главный» (называйте должность как хотите) и ему приходится заниматься всем вышеуказанным.
                • +2
                  Я делал чужие проблемы своими собственными, и вместо того чтобы держать необходимую дистанцию, позволял сочувствию взять верх

                  Однажды в 3 часа ночи мне позвонил сотрудник и слезно просил приехать с деньгами, что бы его машину не эвакуировали. У него паника: отработаю, расплачУсь. Поехал. Но урок получил. дружба-дружбой, служба-службой.
                  • 0
                    Спасибо за статью! Это, несомненно, личные ощущения. Кому-то одно кажется более важным и сложным, у кого-то другое вызывает стресс. Мои ощущения были, что огромное количество совещаний серьезно выбивает почву из под ног, особенно когда надо сконцентрироваться на какой-нибудь срочной задаче. Помимо совещаний важным испытанием для моей совести стало, что начинаешь узнавать вещи, о которых рядовым сотрудникам не всегда корректно говорить. В частности, о грядущих сокращениях.
                    • 0
                      Подпишусь под каждым пунктом статьи. Сам через всё это прошёл
                      • 0
                        Честно говоря, непонятно совершенно, что тут неожиданного. Чувак сидел и кодил где-то в дальнем углу за микроволновкой, задания брал из таск-листа, а с людьми не разговаривал? Перед тем, как стать тим-лидом, он ни разу не подходил к своему тогдашнему тим-лиду с личными вопросами или за советом, не получал от него команд, «мотивации» и не высказывал ему «фидбэки»? Не был на планерках, не понимал, что со смежными подразделениями общается в основном он? Или просто не понимал, что ему, как тимлиду, это тоже светит?
                        Из не вполне очевидного здесь разве что финансовые вопросы и планирование, и то…

                        Вот, что действительно может оказаться неожиданным, так это то, что тебя, как тимлида, могут при всей команде как кота помойного мордой по столу повозить за прокол. Что ни кнута, ни пряника не дадут — не сможешь дать подчиненным ни заметного поощрения, ни заметного наказания, только спасибо сказать или наорать. Что твоих подчиненных могут без твоего ведома перебросить на другую задачу. Что на планерку надо являться не в качестве тимлида за всю команду, а всей командой. Что выгнать человека, который больше мешает, чем работает, труднее, чем заставить себя уволить человека, а принять в команду вменяемого работника вообще нереально. Что личные отношения при решении профессиональных вопросов (да и не только) важнее профессионализма. Что если ты не понимаешь, как в таких условиях быть лидом какой-либо тим, то и не быть тебе тимлидом.
                        • 0
                          По поводу второго абзаца — проблема либо в том что тимлид не может донести информацию руководству выше о том что «надо менять подход», либо компания в которой собственно нечего делать…
                        • 0
                          Мне, как разработчику, непонятно – зачем вообще становиться тимлидом? Ведь расти в технологическом плане можно бесконечно и жизни не хватит, чтобы научиться отлично решать задачи на всех языках и платформах. Неужели тимлидам много платят?
                          • +2
                            Тимлидам — не то, чтобы много, но чутка поболе. Однако начальникам — поболе порой в разы. А мимо тимлида начальником не станешь.
                            И потом, «расти» — понятие неоднозначное. Джуниор, миддл, сеньор — всё! Ну, или техник, инженер, инженер 2 кат, инженер 1 кат, ведущий инженер — всё! А то, что ты такой замечательный специалист с богатейшим внутренним миром и отлично решаешь любые задачи, будут знать человек пять, и не факт, что твой начальник будет среди них. Задача решается коллективом, а кто ее решил — пофигу, более того, быстрый говнокодер может цениться выше. А расти по руководящей линии можно гораздо дольше, а с плавным уходом в политику — вообще почти бесконечно. При этом можно быть никаким специалистом, и, что интересно, и никаким руководителем.
                          • 0
                            Странно, почему тимлид занимался менеджментом денег?
                            • +1
                              В каждой компании свое понятие о зоне ответственности тимлида, в ряде случаев туда может включаться и денежные вопросы (например, о премировании сотрудников, найме фрилансеров и т.п.). Плюс это перевод, а в другой стране понимание роли тимлида может несколько отличаться.
                              • 0
                                Ну это к тем компаниям, где программисты занимаются пиаром продукта, правовой стороной приложений и тд. Или я не прав?:)
                                • +1
                                  Не совсем понял последний коммент, но насчет тимлидов. Смотрите, тимлид это младший менеджер и в теории вопросы денег должны решать более старшие менеджеры (project manager, product manager и т.п.), но все очень сильно зависит от структуры компании. Я знаю, западные компании где старший программист на самом деле исполняет роль мини-тимлида, а тимлид практически роль project manager. Знаю компании, где project manager'ов в принципе нет, а тимлиды подчиняются напрямую директору по разработки (в основном небольшие или продуктовые). Знаю компании, где есть две параллельные иерархии — линейная и проектная, где линейный менеджер-тимлид занимается управлением ресурсами, а project manager договаривается с ним о ресурсах на проект. Во этих и других случаях тимлид вполне может заниматься и менеджментом денег.

                                  Вывод: в каждой компании может быть свое понимание обязанностей тимлида, project managera, технического менеджера и т.д.
                                  • 0
                                    Ну, по-хорошему, каждый должен делать то, что у него получается лучше всего. Тимлид должен следить за кодом, продумывать архитектуру и развитие продукта. Принимать опять же архитектурные решения.
                                    • +1
                                      Тимлид должен следить за кодом, продумывать архитектуру и развитие продукта. Принимать опять же архитектурные решения.

                                      С чего вы взяли что это обязанности любого тим лида?
                                      1) Следить за кодом скорее обязанность старших разработчиков (тим.лид, в принципе, не обязан быть самым лучшим программистом и вообще быть программистом, тим.лид команды разработчиков иногда может быть например бизнес аналитиком или QA).
                                      2) Продумывать архитектуру и развитие продукта это скорее обязанность архитекторов, бизнес аналитиком и технического лида/технического менеджера (это далеко не всегда тоже самое что тимлид), в конце концов, технического директора (CTO: Сhief technical officer/ Chief technology officer), для тим.лид это скорее второстепенная обязанность.

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

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

                            Самое читаемое