Pull to refresh
0
PayOnline
Система электронных платежей

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

Reading time 8 min
Views 60K
Original author: Pascal de Vink
imageОдин технический специалист нашей компании PayOnline, которая занимается автоматизацией приема платежей, предложил перевести статью автора Pascal de Vink, который проработал тим-лидом уже 2 года. Когда Pascal только занял эту должность, оказалось, что ко многим вещам он был просто не готов. Эта статья поможет избежать многих ошибок на пути от разработчика к лидеру команды. Ниже идет непосредственно перевод.

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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

Планировать


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

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


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

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


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

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


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

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


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

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

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


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

Мы рассказали о подводных камнях, к которым оказался не готов Pascal, и, надеемся, что вы извлечете урок из этих ошибок, подготовитесь и не наступите на те же грабли. Если вам нужно организовать прием платежей на сайте, обращайтесь. Подписывайтесь на наш корпоративный блог, впереди еще много интересного.
Tags:
Hubs:
+68
Comments 27
Comments Comments 27

Articles

Information

Website
www.payonline.ru
Registered
Founded
Employees
51–100 employees
Location
Россия