Извечный вопрос: должен ли тимлид обладать самой крутой технической экспертизой в команде? Споры будут идти ещё много тысячелетий, но где, как не в крупной компании, лучше в этом разобраться?
Сегодня поговорим о техническом лидерстве, где оно может лежать в команде разработки, обязательно ли это тимлид или всё-таки не обязательно. А поможет нам в этом Анастасия Абрашитова, руководитель службы инструментов репозитория в Yandex Infrastructure.
Начнём мы с самого главного — объясним, что это за шерстяной волчара. Это известный и не очень свежий мем про то, как воспринимается лидерство на разных слоях иерархии в команде. Лидер думает, что он совершенно потрясающий, с мощными лапищами, а где-то в конце думают, что можно было бы и поровнее бежать.
Это метафора хорошо ложится именно на тимлида с технической ролью. Другое дело, что у этого конкретного тимлида не очень хорошо получается, по крайней мере, так думают некоторые члены его команды.
Про свой опыт
Как руководитель службы инструментов репозитория в Яндексе я отвечаю за наш монорепозиторий Аркадия и за то, чтобы в нём всем было всё, что нужно разработчикам для счастья.
Кроме того, люблю выступать и организовывать ивенты. Организую DevTools Party, субботники по инфраструктуре, Yet another level и Podlodka Soft Skills Crew. Веду канал «Записки из горящего дома» об управлении и софт-скилах (его название хорошо отражает мои рабочие будни). Провожу менторинг на GetMentor.dev.
Всё это я рассказываю для того, чтобы вы поняли, что у меня довольно много общения с самыми разными тимлидами. Шесть команд в подчинении, есть куча смежников, есть люди, которые подходят ко мне на конференциях, приходят на менторинг или просто задают какие-то вопросы в канале.
В какой-то момент у меня сложилось впечатление, что в русской IT-индустрии не очень хорошо развито понимание, каким вообще может быть тимлид без технической роли. Мне задают довольно много подозрительных вопросов. Приведу некоторые примеры; конечно, я их перефразировала, но, честное слово, все вопросы в основе реальные.
Вопросы волчар
Вопросы, которые мне задавали больше одного раза:
Как менять работу, если в новой команде я буду уже не таким шерстяным? Ведь я уже буду не самый экспертный эксперт, мне какое-то время понадобится на то, чтобы погрузиться, — что делать в этот период?
Я же не могу быть вожаком кросс-функциональной стаи? Я из фронтенда!
А за что они меня будут уважать, если я не самый шерстяной?
Ко мне на собеседование пришёл волчара, который технически шерстянее меня. Что делать?!
Что делать — заплакать от счастья, обнять этого человека, скорее нанять его в штат и учиться жить по-другому. Но людям это не очевидно, поэтому давайте разбираться, как вообще можно жить с технической ролью.
Давайте разбираться
Сразу определимся, кто такой тимлид, потому что в каждой компании это значит что-то своё. Здесь под тимлидом мы будем подразумевать человека, который является линейным руководителем команды разработки. То есть, у кого отпуск подписываете, тот у вас и тимлид. Если у вас в компании это как-то по-другому называется, просто мысленно переводите дальше слово тимлид на слово, которое употребляется у вас.
Где лежит роль технического лидера
С точки зрения формальной логики, вариантов не так много. Роль техлида может лежать на тимлиде — это система, которую все мы знаем, к которой привыкли, она понятна и проста.
Если эта роль не лежит на тимлиде, она лежит на ком-то ещё — появляется человек, которого обычно зовут техлидом. И вот они вдвоём в тандеме осуществляют управление командой в разных её аспектах.
Если эта роль не лежит на тимлиде или на ком-то другом, то где она лежит? Нигде!
Правильно? Неправильно!
Если у вас роль технического лидерства не лежит нигде, скорее всего, у вас один из двух вариантов:
Либо у вас команда стремительно деградирует, и людям просто плевать, что будет завтра, они все уже где-то в хедхантере головой.
В этот момент им техническое (да и вообще никакое) лидерство не нужно, потому что им уже неважно, что в этой команде будет завтра.
Либо, что более вероятно, у вас на самом деле нет команды.
У вас есть набор людей, каждый из которых делает что-то своё, и работа соседа не очень сильно на этого человека влияет. Поэтому ему не очень важно, что и как сделает сосед, что и как у соседа будет завтра, ему не очень важно, чтобы все были как-то согласованы. Ему важно, чтобы его личная полянка была такой, какой ему нужно.
Такой вариант действительно иногда нужен, но мы про него сегодня разговаривать не будем, потому что мы говорим про роль технического лидера в команде.
Поэтому если роль не лежит на тимлиде и не лежит на каком-то другом человеке в лице техлида, то она лежит на нескольких людях — это коллегиальная роль.
Коллегия — это сообщество людей внутри вашей команды. Это может быть вся ваша команда или совет трёх сеньоров, тимлид может сюда входить или нет. Это общественный орган, который по каким-то заранее понятным правилам и своим процедурам выбирает технические решения, осуществляет распределённую роль технического лидерства.
Формальная логика говорит о том, что больше никаких вариантов нет. Обычно в этот момент все начинают выбирать, какой вариант самый лучший. И мне очень важно, что после этого рассказа вы вышли с одной очень просто мыслью — это не вопрос веры/истины.
Нет единого правильного ответа на вопрос о том, где должна лежать роль технического лидера в команде, потому что это на самом деле три разных инструмента, которые должны быть в ящике с инструментами у абсолютно любого тимлида. В зависимости от ресурсов команды, вашего времени и компетенций, а также целей, которых нужно достичь, вы должны выбрать один из этих инструментов — тот, который будет удобнее, эффективнее и который вам больше подойдет.
Я годами жила в каждой из этих систем: была тимлидом с технической ролью, была тимлидом без технической роли, у меня была коллегия. Я даже была техлидом в тандеме двух людей. И все эти варианты нормально работали. Так что могу с уверенностью говорить, что здесь нет лучшей системы, а только три инструмента, из которых нужно выбирать по ситуации.
Поэтому сегодня мы не будем смотреть изолированно на каждый вариант как кусок пирога. Мы попробуем посмотреть на эти варианты горизонтальными слоями в разных аспектах: что будет происходить в разных ситуациях, в которые попадает команда. Начнём с группы ситуаций, которые я озаглавила устойчивость.
Устойчивость
Первая ситуация, в которой можно пошатнуть свою устойчивость — это уход техлида.
В ситуации, когда у вас техлида нет, вам это не грозит (как в песне «Если у вас нету друга»).
А вот если у вас техлид есть, то его уход, конечно, будет чреват для вас переменами. Конечно, это не так больно, как уход тимлида, но вам всё равно придётся эту роль как-то замещать: либо искать преемника снаружи, либо кто-то был подготовлен внутри, если повезло, либо вам придётся переходить в одну из двух других систем. Возможно, вам придётся экстренно взять эту функцию на себя, а вы не всегда к этому готовы, у вас весь календарь занят. В общем, это обязательно будет какая-то боль и обязательно что-то поменяется.
В случае с коллегией понятно, что техлида нет. И если уходит один из членов коллегии, то на самом деле будет одно из двух: либо коллегиальный орган выдержит и продолжит гладко нести свои функции, потому что людей там достаточно, либо он развалится, потому что их осталось слишком мало или потому что он слишком разбалансируется по своему уровню: кто-то заметно сильнее, чем остальные. В этой ситуации у вас просто выделится техлид из этой коллегии. То есть никакой боли и ничего страшного здесь не произойдёт.
Посмотрим на другую ситуацию — уход тимлида.
В ситуации, когда на тимлида завязано вообще всё, и это тот самый шпиндель, на котором всё крутится, его уход — это просто катастрофа, которая команду оставляет в руинах. Понятно, что можно к этому как-то подготовиться, пытаться искать себе замену, и если новый поезд уже стоит на запасном пути, будет не так больно. Но в общем случае на человека было замкнуто всё, и этот человек ушел.
С одной стороны, возможно, такая роль даёт job security, такого сотрудника не захотят увольнять, если вообще всё на нём замкнуто, и при этом он нормально работает. С другой стороны, если вы из тех тимлидов, которые хотят развиваться по управленческой ветке, расти вверх и заниматься чем-то другим: либо стать руководителем более высокого уровня, либо просто переходить в другие команды со временем, — вы не сможете это сделать, если с вашим уходом всё развалится. При прочих равных люди наверху, которые на вас смотрят, подумают: «Так, этого мы не будем повышать, потому что без него в команде всё развалится». Поэтому если вдруг у вас есть амбиции и при этом вы тимлид, на которого всё замкнуто, пожалуйста, перестаньте так делать, для вас это очень невыгодно.
Если тимлид уходит из команды, где есть техлид, конечно, боль и перемены тоже будут, но в значительно меньшей степени. Почему? Кому-то придется подхватывать роль тимлида, на время или на постоянку, но подхватывать надо гораздо меньше: не нужно забирать на себя технологии, ревью, погружения в кодовую базу. Начальник вышестоящего уровня, которому придётся затыкать собой эту дыру, действительно заткнёт её, чаще всего довольно бесшовно.
Ситуация с коллегией такая же, как если у вас есть техлид. На тимлиде не лежат техлидские полномочия, поэтому тимлида немножко проще заменить. Кстати, найти ему замену тоже проще, потому что преемнику не придётся во все стороны бежать.
Следующая ситуация, которая может пошатнуть стабильность, — это приход сильного технического специалиста. Помните вопрос от волчары — что делать?
Если вы тимлид и строили свой авторитет на том, что вы самый шерстяной, всех сильней технически, то вам в этой ситуации будет суперсложно. Придётся часть своего уважения и авторитета переложить на другого человека. В этот момент вам важно остаться лидером команды. В первую очередь, это сложно ментально для самого лидера. Ему в этот момент кажется, что он теряет лидерство, что его больше так не любят и не уважают, что теперь какое-то двоевластие. В общем, это действительно болезненная ситуация — перестройка в систему с техлидом, если до этого техлида не было.
Если техлид был, тоже будет непросто, потому что был у вас один техлид, а стало два. Скорее всего, вам из них придётся организовывать какой-то коллегиальный орган, потому что вы же не можете как в «Игре престолов» снять булавочку «Десница короля» и повесить на другого человека. Вашему текущему техлиду от этого будет больно. Тут боль немножко поменьше, и есть смена формата. Тем не менее, команду в этот момент будет по-всякому штормить. Но роль тимлида в этой схеме никак не изменится, он останется островком стабильности, поэтому будет значительно легче.
Коллегия здесь — это самый безболезненный вариант. Конечно, может быть очень странная ситуация, когда пришедший технический специалист на голову выше не только тимлида, но и вообще всей команды. Возможно, этого человека получится взять в коллегию. Более того, даже если он сильнее ребят в этой коллегии, это будет плюс, потому что люди в коллегиальном органе при принятии совместных решений очень стремятся быть одинаково компетентными. Приход сильного технического специалиста в команду в этой ситуации усилит вашу коллегию. Все остальные ребята в ней будут пытаться подтянуться на уровень этого компетентного человека, чтобы с ним спорить на равных.
Ещё одна ситуация — приход нового тимлида. Помните, тимлид у нас ушёл на позапрошлом пункте, а теперь пришёл новый.
Кстати, у меня есть доклад о том, как чуть менее больно приходить тимлидом в команду (см. QR-код).
Итак, пришёл тимлид, и в первом варианте ему надо сразу бежать во все стороны: подхватить людей, проект, возможно, какие-то продуктовые истории, ещё и технологии. Сидит целая команда и говорит: «Ревьюшку нам посмотришь?» В этот момент тимлиду, конечно, ещё сложнее.
Если есть техлид, всё проще. Я здесь поставила зелёную галочку и слова «Надо сработаться». Всё будет с зелёной галочкой, если сработаться получиться.
Вообще в истории тандема двух людей (тимлида и техлида) очень многое зависит от личностей этих людей, от их способности вместе работать. В частности, очень многое зависит от личности техлида. Если у вас техлид конфликтный и не примет нового тимлида, например, он сам хотел стать тимлидом, то здесь будет какая-то боль и конфликт. Но в общем случае двум людям просто нужно сработаться и продолжить нести свои две разные роли на себе.
С коллегией в принципе проще всего, потому что этот орган как был установлен и работал, так и продолжит работать с приходом нового тимлида. Конечно, тимлиду со временем придётся научиться с этой коллегией работать, устанавливать системы, взаимодействовать с таким коллективом. Но это тимлида очень хорошо прокачает в организационном плане. Это самый простой вариант в случае прихода нового тимлида.
Теперь рассмотрим ситуацию конфликта в управляющем слое (в лидерах).
Если вы один, то опять же у вас «нету друга», вам ничего не грозит.
Если есть конфликт между тимлидом и техлидом — прямо серьёзный конфликт, то это катастрофа. В глазах людей есть два лидера: тимлид (про людей и проекты), техлид (про технологии и как код писать), — и вдруг Иван Иванович с Иваном Никифоровичем поссорились. Команда попадает в ситуацию, когда надо выбирать, кого они любят больше — маму или папу? У кого-то чуть больше лояльности будет в одну сторону, у кого-то в другую.
В худшем варианте этот конфликт двух лидеров породит раскол в команде, и у вас уже начнётся гражданская война тех, кто поддерживает одного, против тех, кто поддерживает другого. Это очень токсичная ситуация. Именно поэтому очень многое зависит от правильного выбора личностей тимлида и техлида. Конфликт между ними будет очень и очень болезненный, скорее всего, это будет война на поражение, то есть один из них в конце концов уйдёт. Если они прямо серьёзно поссорились, то уже не помирятся. Каждый из них будет видеть потерю своего авторитета и лидерства в том, что он сдался, проиграл, грубо говоря.
С коллегией конфликт вам, скорее всего, не грозит. Вернее, если вы нашли себя в конфликте с целой коллегией людей или даже со всей командой, и они вам говорят, что надо делать одним образом, а вы топите за другой, то нужно очень внимательно посмотреть в зеркало. Скорее всего, проблема где-то там, а не в конфликте с ребятами. Поэтому здесь обычно конфликтов не бывает.
Посмотрим на немного другие характеристики, которые я гордо озаглавила эффективностью, насколько она в управлении может быть.
Эффективность
Начнём мы со скорости принятия решений — это знакомое нам слово latency.
Итак, latency маленькое, если решение принимает ровно один человек. Всё, что нужно, — это в своей голове подумать и принять решение. Это быстрее всего делается, когда это делает один.
Когда у вас целая коллегия людей, которым надо встретиться, обсудить, всем погрузиться в контекст и до чего-то общего договориться, конечно, это происходит медленно. Скорость принятия решения в коллегиальной системе низкая, к этому нужно сразу быть готовыми.
С другой стороны, есть масштабируемость, то есть throughput.
И вот когда у вас один тимлид, которому надо принять все технические решения, а ещё все нетехнические решения, разрешить все проблемы своих людей, придумать всякие проектные планы, продуктовые важные мысли, то этот человек — очень узкое бутылочное горлышко. Естественно, здесь у очень многих тимлидов начинают копиться технические решения, которые надо принять, а времени нет.
Если есть техлид, это тоже бутылочное горлышко, потому что всё должно пройти через этого одного человека. Но оно значительно шире, потому что это человек, который ровно про техническое лидерство и думает. Он хотя бы 100% времени этим занят, не отвлекается на другие лидерские роли. Поэтому здесь всё более спокойно.
В случае, когда у вас коллегия, всё масштабируется хорошо. Например, если у вас совет трёх сеньоров, вы можете каждого из них отправить прорабатывать самостоятельную техническую фичу. Например, надо прогрузиться, что-то продумать, набросать дизайн, поставить эксперимент, всё это дело защитить, и три сеньора каждый занялись своей фичей — всё параллелится и масштабируется по числу людей.
Но есть сложность установления такой системы — допустим, вы пришли, а в команде вообще ничего нет, чистый лист, надо что-то делать.
Сложность установления системы, в которой тимлид несёт на себе всё, сама по себе довольно низкая, потому что это распространённая схема. Мы все её 133 раза встречали, ещё 133 раза встретим. Всё понятно, надо просто брать и делать.
В ситуации с техлидом, как я уже говорила, самое важное — это личность техлида. Просто этого человека надо найти, объяснить ему, какие функции он на себе будет нести, и дальше жить с ним дружно. В принципе, это не очень сложно, если у вас есть подходящая кандидатура. Если нет, возможно, эта схема вообще не для вас.
Самых сложных вложений требует история с коллегиальной системой, потому что вам нужно выбрать, по какому принципу люди в эту коллегию попадают, как эта коллегия работает и какие там правила. Вообще, как сделать так, чтобы эти люди между собой не конфликтовали, никто не чувствовал себя неуслышанным, обиженным, как это дружно и грамотно построить в плане процессов. Тут нужна какая-то организационная сила.
Вообще говоря, если у вас один лидер, и это тимлид, то органически эта система сама по себе никак не способствует вовлечению и развитию команды. Я не говорю, что у вас этого нет, если вы тимлид с технической ролью. Но вам для этого приходится прилагать дополнительные усилия. Вы организуете какие-то мероприятия, которые вовлекают ваших ребят в то, что происходит, отдельно им рассказываете, что в продукте делается, зачем и почему, пытаетесь повысить мотивацию, подыскать какие-то возможности для развития, уговорить их развиваться (или, наоборот, считаете, что не нужно уговаривать людей — если они приходят, тогда и будем развивать). Но общем, это отдельный комплекс мероприятий по вовлечению и развитию, органического в этой схеме ничего нет.
Точно так же органически ничего такого не заложено и в тандеме тимлида с техлидом: они замкнуты каждый в своей роли, и тоже нужны усилия, чтобы появилось вовлечение и развитие. Более того, в этой схеме придётся делать эти усилия с двух сторон — и тимлиду, и техлиду. Тимлид, скорее, будет больше про вовлечённость, техлид про развитие, но они очень сильно будут пересекаться и просить друг у друга помощи.
Самая хорошая вовлечённость и гармоничное развитие в ситуации с коллегией, потому что у вас есть люди, которые очень хотят выровняться. Они хотят быть уважаемыми, чтобы их слушали, их мнение принимали во внимание, поэтому они стремятся выйти на один уровень и быть не хуже, чем сосед. Более того, люди, которые не вошли в коллегию, будут стремиться в эту коллегию попасть. Для этого тоже нужно сделать какие-то шаги по собственному развитию, и они их будут делать, потому что быть в коллегии почетно.
С другой стороны, есть сегрегация команды.
Если у вас один тимлид, единственное, что вам грозит, это дистанцирование команды от лидера. Тимлид может этого хотеть, может этого не хотеть, но может так получиться, что возникнет дистанция между тимлидом и командой. Иногда это проблема, если тимлид этого не хотел, если он желает быть частью команды, чтобы все думали, что он бро или сист. А команда немножечко отходит в сторонку, в бар ходит без него. Тут возможно дистанцирование лидера. Иногда это проблема, но в основном — моральная проблема для самого лидера.
Если у вас есть тимлид и техлид, тут проблема чуть-чуть похуже. Во-первых, в глазах членов этой команды есть ОНИ — это уже два человека, такая прослойка, каста лидеров. Сразу возникает — есть МЫ, а есть ОНИ, и всё немного сложнее.
Хуже, если один из этих людей для команды бро, а второй не бро. Например, команда ощущает свою общность с техлидом, понимает, что это тот лидер, который рядом. А есть тимлид, он часто на отшибе, мы его не очень часто видим, не очень хорошо понимаем, он чем-то своим занимается — он нам не бро. В этой ситуации начинает перетекать авторитет и человеческие симпатии в техлида. Это не очень хорошая ситуация, особенно если техлид её почему-то подогревает со своей стороны.
Но самая большая сегрегация может возникнуть в коллегии. Если у вас туда включена не вся команда, то вы всех поделили на две касты: те, что принимают решение, и те, что не принимают. Естественно, те, которые не принимают, чувствуют себя ущемлёнными (с большой вероятностью). Самое простое, что можно сделать, — это ввести понятные социальные лифты. Люди, которые в коллегию не входят, должны понимать, что им нужно сделать, чтобы в эту коллегию попасть. Может быть, достаточно формально аттестоваться на сеньора, если у вас в компании такое есть, и сразу попадаешь туда. Может быть, нужно защитить дизайн для трёх больших фич перед этой коллегией, и тогда ты будешь один из них. Главное, чтобы все понимали, что надо сделать, чтобы стать одним из этих ребят. Тогда будет полегче, иначе не вошедшие в коллегию будут чувствовать себя второсортными, им от этого будет некомфортно, начнутся конфликты.
Последнее, о чём здесь хочется поговорить — это ответственность за принимаемые решения.
В ситуации, когда все решения принимает один человек, с ответственностью всё просто и понятно — она вся на этом человеке. Уровень личной ответственности тимлида огромный, высокая ответственность — это фактически наш job description.
Если у вас есть техлид, то всё сложнее, потому что, конечно, ответственность на техлиде есть, вы туда делегировали часть полномочий. Но, как вы знаете, делегирование с вас ответственность не сняло. Техлид будет отвечать за те решения, которые он (или она) напринимали, а вы будете отвечать за то, что этого человека в техлида выбрали и, может быть, недостаточно контролировали. В общем, ответственность здесь в любом случае лежит на двух людях, и это может вызывать непонимание: кто именно отвечает за те или иные провалы, которые случились.
Самый низкий уровень ответственности в коллегиальной системе, потому что это коллективная ответственность, а коллективная ответственность — это всегда коллективная безответственность. «Что же ты такой дизайн предложил, из-за которого все завалилось?» — «А что же вы его ОКнули? Мы же все вместе» — «Нет, ты больше виноват!» — «Нет, ты». В общем, здесь нет ответственности, поэтому ответственный, как всегда, тимлид, хотя он вроде бы это полностью вынес в коллегию. Но именно тимлиду отвечать, потому что здесь никакой личной ответственности у людей нет.
Это всё из горизонтальных слоев. Дальше подведём итоги, и посмотрим на каждый вариант вертикально, как на кусочек пирога.
Подведём итоги
Техническое лидерство на тимлиде
Самая простая и распространённая схема, её проще всего установить и поддерживать.
Высокий уровень контроля и авторитета. Все рычажки, переключатели и руль находятся в руках одного человека — тимлида.
Высокая скорость принятия решений, потому что всё проходит через одного человека.
Высокая зависимость команды от тимлида при этом. Уход тимлида — это катастрофа (даже в отпуск или на больничный).
Узкое бутылочное горлышко, потому что тимлид несёт на себе много обязанностей, и при этом все технические решения проходят всё равно через него (или через неё).
Сложность с наймом технически более сильных специалистов, потому что тимлиду придётся перестраиваться. В этот момент морально очень непросто, скорее всего, большинство тимлидов просто предпочтёт суперсильного технического специалиста не нанимать. Это будет потеря для команды.
Низкая вовлечённость команды в этой схеме, потому что органически здесь ничего нет.
Есть выделенный техлид
Это самое компромиссное решение. У него немного ярких плюсов, но и очень ярких минусов тоже мало:
Возможность низкого вовлечения тимлида, то есть тимлид может заниматься чем-то ещё. Это может быть даже один тимлид на несколько команд, потому что значительную и трудоёмкую часть технологии несёт на себе другой человек.
Возможность смены тимлида проще. Даже если вы сами хотите куда-то уходить или идти на повышение, вам такая схема очень выгодна, потому что оттуда проще уйти и найти преемника.
Всё ещё высокая скорость принятия решений, потому всё идёт через одну голову (голову техлида).
Серьёзный минус — риск тяжелых конфликтов. Если тимлид и техлид вступят в сильный конфликт, это будет катастрофа.
Коллегиальное техническое лидерство
Здесь, наоборот, начну с минусов:
Сложность выстраивания системы, потому что она требует хорошей организации тимлида, особенно если тимлид раньше это никогда не делал, этот инструмент у него в ящичке ещё не лежит, его придётся освоить, выучить, может быть, через какие-то ошибки положить.
Низкая скорость принятия решений, потому что людям нужно совещаться.
Низкая личная ответственность, потому что одного лично ответственного нет.
С другой стороны:
Это самая стабильная схема. В эти команды можно камнями кидать, с ними вообще ничего не случится.
Хорошо масштабируется. Когда вам нужно принимать много всяких сложных решений, много прорабатывать, то есть много техлидской работы, она масштабируется по числу людей, вовлечённых в коллегию.
Есть органическое вовлечение и развитие людей в то, что у вас происходит.
Ещё раз хочу сказать, что это не вопрос веры. Вам не стоит “выбирать самую хорошую систему”, потому что все три системы хороши, и нужно смотреть, что у вас есть и что вам нужно. Ни в коем случае не выбирайте себе какую-то одну систему навсегда, это очень пагубно.
В качестве сцены после титров хочу сказать пару слов об авторитете.
Помните, в начале был вопрос: а за что меня тогда будут уважать, если я не самый шерстяной волчара?
Так вот, если вы, например, очень хорошо играете на фортепиано, то вас уважают как очень хорошего пианиста. Если вы очень хорошо бегаете марафоны, то вас уважают как очень хорошего бегуна. Уважение не бывает само по себе, оно не в вакууме, а всегда применительно к какой-то роли или области знаний. Если вы очень хороший технический специалист, вы лучше всех программируете, то вас уважают как разработчика — не как руководителя, а как разработчика. А вам нужен не этот авторитет, а авторитет именно руководителя — вы же руководитель, вы хотите, чтобы люди за вами шли. Соответственно, вам нужно быть хорошим руководителем, чтобы вас как руководителя уважали.
Авторитет тимлида в умении руководить
Не буду здесь подробно рассказывать, что для этого нужно, потому что это не по теме доклада. Очевидно, нужно выстраивать отношения с людьми, которые есть у вас в команде, поэтому:
Уважайте ваших подчинённых.
Находите и решайте проблемы, которые мешают им работать.
Помогайте им в стремлении расти и развиваться.
Старайтесь всегда исходить из позиций взаимной выгоды.
Атрибуцируйте их достижения им самим.
Нужно нормально руководить самой командой, поэтому:
Будьте прозрачны: зачем мы делаем то, что делаем, почему именно это и почему именно мы — людям нужен смысл.
Стремитесь к порядку: для хорошей работы нужны понятные правила, процессы, распорядки, приоритеты.
Не будьте авторитарны.
Наконец, нужно быть личностью, за которой всё-таки хочется до какой-то степени идти, поэтому:
Будьте честны.
Будьте открыты к фидбеку.
Аргументируйте свои решения и отвечайте на вопросы.
Будьте человеком — не бойтесь признавать свои ошибки и озвучивать сомнения.
Не бойтесь советоваться с командой и отдельными подчиненными.
Не бойтесь делегировать.
Если, например, вы постоянно нечестны со своими людьми, и они об этом знают, вряд ли они захотят, чтобы вы были их лидером, правда?
Доклад Анастасии Абрашитовой "Самый шерстяной волчара: тимлид с технической ролью и без" на конференции TeamLeadConf 2023 в Москве.
