7 заблуждений начинающего тимлида

Привет! Я Игорь Степанов, Senior Team Lead в Plarium. Сейчас я руковожу командой тим- и техлидов и отвечаю за техническое состояние клиентской части проекта Raid: Shadow Legends. Когда три года назад я стал тимлидом команды разработки, у меня было размытое представление о том, какие сложности могут поджидать на новой позиции.

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

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

Заблуждение № 1: тимлид обязан быть технически сильнее всех участников команды

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

Как только я вступил в должность, меня настиг страх по поводу опыта. Среди моих подчиненных и других коллег было много специалистов (а точнее — большинство) с бóльшим опытом, чем у меня. В департаменте был тимлид, тринадцать разработчиков и два архитектора. Я не представлял, с чего начинать строить авторитет и взаимодействие с командой.

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

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

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

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

Заблуждение № 2: соперничество идет команде на пользу

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

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

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

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

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

Если в команде руководитель относится ко всем одинаково справедливо, сотрудникам проще перестать сравнивать себя с другими. Формируйте единую цель и, давая возможность каждому сконцентрироваться на собственном вкладе, стройте общее дело. При таком подходе сотрудники будут охотнее делиться новыми знаниями с другими. Экспертность команды будет расти вместе с развитием отдельного участника, а не замыкаться на одном человеке.

Заблуждение № 3: тимлид может тратить столько же времени на программирование, как и прежде

В роли тимлида у вас больше не будет возможности выделять на программирование столько же времени, сколько на позиции девелопера. Новые обязанности могут «не пустить» вас программировать день, два, а иногда и целую неделю.

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

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

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

Но не всё так страшно, как кажется. Руководящая позиция позволяет реализовать больше идей, чем можно осуществить в одиночку. По сути, вы получаете возможность производить больше кода, который соответствует вашим стандартам качества.

Заблуждение № 4: переработки эффективны

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

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

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

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

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

Заблуждение № 5: никто не сделает так же качественно, как я сам

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

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

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

Можно долго рассказывать, как и что должно работать, но лучше запоминаются собственные «шишки». Если вы позволите сотруднику сделать ошибку, а потом вместе с ним ее исправите, шансы, что он больше ее не допустит, будут в разы выше, чем когда вы будете говорить, что и как делать. Главное — не бросать человека в центр океана, ожидая, что он сам научится плавать. Учитывайте возможности и желания сотрудника, контролируя выполнение задачи в соответствии с его уровнем. Начните с бассейна :)

Идеальный вариант — разбавление задач умеренной сложности, выполняя которые человек чувствует себя комфортно, с задачами-вызовами, позволяющими сотруднику обучиться чему-то новому. Разумеется, такая возможность есть не всегда, но именно подобный темп помогает планомерно расти и развиваться.

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

Заблуждение № 6: «костыли» — это всегда плохо

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

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

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

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

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

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

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

Заблуждение № 7: хороший тимлид должен сам со всем справляться

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

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

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

Стоили ли мои усилия полученного результата? Я думаю, они были полезны проекту. Но я мог бы получить 90 % выгоды, затратив раза в два меньше нервов и жизненных сил, если бы учел все вышеописанные заблуждения, особенно № 4 и № 5 :)

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

Обязательно делитесь переживаниями и трудностями со своим руководителем, другими тимлидами, HR BP вашей команды. Сильный сотрудник не тот, у кого нет проблем, а тот, кто умеет их выявлять, находит в себе силы признать, решить и сделать выводы на будущее.

Вывод

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

Конечно, сколько теории не читай, пока не испробуешь на себе — полностью не разберешься. Но всё же некоторых заблуждений удастся избежать.

Вооружайтесь моими советами и пишите свои мысли по этому поводу в комментариях. Буду рад пообщаться.

Всем хорошего тимлидства!

👍НравитсяПонравилось40
В избранноеВ избранном17
LinkedIn

Лучшие комментарии пропустить

Я ближе к теХлид на проекте и могу добавить ошибок:

1) Если у вас как у true программиста было убеждение «надо работу работать а не языками болтать» то его лучше пересмотреть или даже отменить, потому что теперь часто важно лишний раз поговорить (о тасках — для прояснения, о котиках — для тимбилдинга, о перформансе — для ревью, о «как дела» — для понимания что происходит, о много чем — для knowledge sharing-а ...)

2) Заранее думать обо всех процессах с позиции «как это маштабируется?». К примеру, если у вас не задокументированы какие-то процессы или части проекта, и вы как-то командой обьясняли проект и процессы, когда нанимали по одному новых людей. К сожалению когда новых людей станет одновременно 3 (а еще хуже 3 но со смещением выхода каждого на проект в 2 недели), нужен или чеклист или хорошая документация, или еще что-то что позволит им идти по налаженной схеме и самостоятельно получать/читать/смотреть информацию а не ждать все от кого-то

3) ну и вообще думать обо всем long-term-овом о чем в моменте забывают (но здесь сложно найти баланс что является преждевременной оптимизацией, а что long-term-thinking-ом)

4) Раз в неделю думать «что сейчас делаю только я, могу ли я это передать другим» — если есть какие-то вещи которые постоянно делаете только вы (неважно: может только вы разбираетесь в каком-то месте кода, или только вы обычно грумите бэклог перед спринтом) — это узкое место с которым нужно что-то делать (расшаривать знания) чтобы вас не искали, не дергали из отпуска, и вообще было легче

5) думать о любой проблеме как о возможности («если кто-то невнимательно делает код-ревью или принимает pr-ы не глядя, это возможность обсудить и донести важность ревью», итп)

...если что-то вспомню, еще допишу

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

То, что «тимлид — это не сеньёрный уровень, а просто роль»- это заблуждение или факт?

Факт, это роль как и DM/PM а не левел разработчика после синьора, даже мидл может быть тимлидом, и я такое много раз видел.
Но на многих галерах тимлиды очень обижаются когда им такое говоришь, так как они думают что по хард скилам они круче любого синьора, хоть и проводят почти все время на митингах, и почти не пишут код.

Когда-то я считал, что ПМ должен быть технически силён.
Сейчас планка требований в отрасли растёт, как мне кажется, и спрос немалый как с сеньёра не-тимлида, так и с тимлида-несеньёра.

Лучше всего быть наверо uml-архитектором, гением отфонарных эстимейтов.

Сейчас PM и PdM могут вообще гуманитариями быть(и при этом толково выполнять свои обязанности)
А технически сильные это Technical DM и Technical PgM, которые должны быть бывшими разработчиками.

Сейчас планка требований в отрасли растёт

Это несмешная шутка

Заблуждение номер нуль: все (∀) люди равны, вменяемы, адекватны, разумны, сообразительны, добропорядочны и единственная проблема — в цене.

Найцікавіше, що «7 помилок починаючого тімліда» і «7 помилок досвідченого тімліда» — це будуть не дві статті, а одна і та ж стаття.

победитель — тот, кто поднялся на один раз больше, чем упал

ніколи не розумів цієї цитати. раз упав — раз піднявся, два впав — два піднявся, три — три.
Можливо мова йде що побєдітель —
круто піднявся ? Тоді для чого падав ?

Думаю, малось на увазі, шо не всі знаходять в собі сили «піднятися» після «падіння».

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

Джейсон, ты ли это?)

статья правильная. в укороченом варианте:
п. 1 — если тим лид умнее всей команды то такая команда никуда не годится
п. 2 — соперничество в команде по знаниям — хорошо т.к. есть стремление к повышению скилов и общему росту сотрудников но в проекте соперничесттво разрушит проект и тимлид должен это соперничество нивелировать
п. 3 — тимлид уже не столько разработчик сколько технический менеджер проекта и часто на него ложатся обязаности работы с чел. фактором. первая и основная задача это правильный выбор технологий, архитектуры и правильное распределение задач и нагрузок
п. 4 — переработки — это глобальные просчеты /ошибки тимлида или руководства на которые тимлид повелся.
п. 5 — бред сумасшедшего (про заблуждение!) ибо всегда есть кто-то кто в узкой области будет знать ситуацию лучше и в этом не ничего страшного и зазорного.
п. 6 — костыли это действительно плохо но бывают ситуации и жизнь их диктует , когда к сожалению без них никак. Особенно если речь идет о проекте который делается для конкретного заказчика, а не речь о неком стартапе где можно максимально (или должно) предусмотреть все по максимуму
п. 7 — перекликается с п.1 если тимлид сам со всем справляется то зачем тогда все остальные?

вывод: "

победитель — тот, кто поднялся на один раз больше, чем упал

"
мегаправильный!

Здравствуйте, Дмитрий, спасибо за положительный отзыв и интересные выводы!Дополню комментариями несколько из них:
— По четвертому пункту: был у меня период, когда я много овертаймил, и не по тому, что не вкладывался в сроки или меня кто-то просил, а просто потому что мне было интересно. На проекте было предостаточно сложных задач, на которых я мог развиваться, а вокруг были люди, которые готовы были мне помочь начать и поревьюить итог.

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

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

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

Здравствуйте, Игорь!
я понимаю почему Вы пришли к таким выводам и в общем они правильные, немного может пояснения ... ну я бы добавил ...
по п.4 — да такой эффект бывает когда «захоплюєшся» но его надо очень быстро откинуть т.к. уграете свое здоровье и не только. Важно понимать, что работа есть работа. Это не критика, а просто делюсь опытом , в свое время был таким же но хорошо, что вовремя по рукам дали :)
да... инт. задачи и т.п. это здорово но или в своем стартапе тогда некие овертаймы допустимы или же при рабочем режиме очень полезно раз в неделю , например в четверг делать пол дня или часа два просто общалку — т.е. не столько регламентное обсуждение проекта сколько поговорить на технические темы по душам но без пива :) Овертаймы — это всегда не есть хорошо.
по п.5 — это задача тимлида подтягивать. т.е. да иногда это выглядит как детский сад когда делаете нечто вместе. Ведь «завтра» будет сл. проект и там Ваш подчиненный/сотрудник должен делать сам. Есть много приемов как сие сделать и научить людей, т.е. подтянуть. в принципе если речь идет о первом проекте и Вы еще не «чуствуете» людей и правильно не можете распределить нагрузку/задачи то в принципе понятно но после первого проекта да и во время работы с первым проектом надо вносить корректировки. Есть достаточно рабочее правило т.е. (НАПРИМЕР!) дается задача на 5 рабочих дней , при постановке задачи четко инт. у человека все ли ему понятно и справится ли. при получении «да» на все вопросы отдаете задачу и не трогаете его ровно трое суток, а вот в конце третьих суток (рабочих дней — сорри) проверяете и контролируете. Дополнительно делаете некие чекпоинты чтобы можно было проверить что и как. по результату делается уже итого. Да, если на задачу выделяется семь рабочих дней то даете пять чтобы если что то можно было подтянуть ситуацию — т.е. иметь запас.
Знаете есть такое правило/тест что ли когда начальника без предупреждения отправляют в отпуск и смотрят как работает коллектив без него. так вот есть три варианта:
— работает лучше == начальника на курсы повышения квалификации т.к. нач. «давит» людей
— работает хуже == выгнать такого начальника т.к. он ключевое звено которое может сломать работу , условно говоря он ушел в отпуск, заболел, уволился и работа пошла в/на/под
— работает так же == начальнику премия потому, что правильно поставлены задачи , люди компетентны и знают что делать.
конечно все очень утрировано но в принципе обобщенно так :)

Да, насчёт промежуточного контроля, действительно действенный способ. Мне нравятся подходы, описанные в рамках ситуационного менеджмента, когда в зависимости от уровня специалиста вы расставляете в разном объеме точки контроля в начале, в процессе и в конце работы над задачами. Таким образом новичкам нужно уделять внимание на каждом этапе. А по мере развития сотрудника можно постепенно ослаблять контроль в следующем порядке:
— в процессе;
— в начале;
— в конце.

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

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

Таким образом финальная, поддерживающая, стадия работы с сотрудником будет заключаться в регулярных 1:1, в рамках которых можно обсуждать результаты за определённый период.

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

Единственное что, для чистоты эксперимента, нужно, чтобы руководитель в рамках своего отпуска не занимался работой, что может быть сложно проверить, особенно теперь, в условиях удаленной работы :)

я катал на рыбалку а там пофиг на работу :)

— Объясни, почему у вас и оружие огненное, и корабли железные, и одежда, а у нас только копья и перья?
— Э-э, скажи, на островах в племени кто-нибудь может быть умнее и сильнее вождя?
— Нет, что ты!!!
— А у нас можно.

Це в якому племені ви зараз вождь?

п. 1 — если тим лид умнее всей команды то такая команда никуда не годится

Ще одна помилка. Розумний тімлід буде навчати команду і допомагати їй зростати в професійному плані.

з точки зору економіки — навіщо команда якщо є одна персона яка може все? фонд зп можна легко економити і один буде тягнути. Нормальний тімлід і так навчає команду і навчається у команди але при цьому якщо він розумніше команди то або йому немає що там робити або команді

Кто хочет более полную версию, рекомендую www.amazon.com/...​ting-Growth/dp/1491973897

А мне понравилась статья. Спасибо что поделились, полезно!

Здравствуйте, Алексей, спасибо за отзыв! Рад, что моя статья была вам полезна :)

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

Эффективная ночная птиччка :)

а хто має писати статті на такі теми, як не людина з досвідом і розумінням?

Я ближе к теХлид на проекте и могу добавить ошибок:

1) Если у вас как у true программиста было убеждение «надо работу работать а не языками болтать» то его лучше пересмотреть или даже отменить, потому что теперь часто важно лишний раз поговорить (о тасках — для прояснения, о котиках — для тимбилдинга, о перформансе — для ревью, о «как дела» — для понимания что происходит, о много чем — для knowledge sharing-а ...)

2) Заранее думать обо всех процессах с позиции «как это маштабируется?». К примеру, если у вас не задокументированы какие-то процессы или части проекта, и вы как-то командой обьясняли проект и процессы, когда нанимали по одному новых людей. К сожалению когда новых людей станет одновременно 3 (а еще хуже 3 но со смещением выхода каждого на проект в 2 недели), нужен или чеклист или хорошая документация, или еще что-то что позволит им идти по налаженной схеме и самостоятельно получать/читать/смотреть информацию а не ждать все от кого-то

3) ну и вообще думать обо всем long-term-овом о чем в моменте забывают (но здесь сложно найти баланс что является преждевременной оптимизацией, а что long-term-thinking-ом)

4) Раз в неделю думать «что сейчас делаю только я, могу ли я это передать другим» — если есть какие-то вещи которые постоянно делаете только вы (неважно: может только вы разбираетесь в каком-то месте кода, или только вы обычно грумите бэклог перед спринтом) — это узкое место с которым нужно что-то делать (расшаривать знания) чтобы вас не искали, не дергали из отпуска, и вообще было легче

5) думать о любой проблеме как о возможности («если кто-то невнимательно делает код-ревью или принимает pr-ы не глядя, это возможность обсудить и донести важность ревью», итп)

...если что-то вспомню, еще допишу

Здравствуйте, Елена, спасибо за дополнение! Очень полезные советы :)

Это вы щас на каком языке разговаривали?

За пункт 5) окрема подяка.

Почему я должен править эти мелочи до двенадцати ночи, если Олегу было лень задержаться на 5 минут и внести правки в свою же работу?

Интересно: а если Олегу реально было лень не то что задержаться, а просто доработать до конца своего рабочего дня — убежал на пиво «я завтра доделаю», и это не 1й раз — ваши действия?

Очевидно, с текущим рынком — заложить +20% в естимейт в следующий раз на пивасик Олега и не сильно настаивать на его следующем райзе перед вышестоящим начальством))) Вообще затупы в программировании обычное дело, так что всегда можно что-то придумать что сказать клиенту в этом случае и не править самому до 12 ночи.

Конечно, это ж не Олег будет клиетну объяснять, почему демо откладывается на день и почему эстимейты вдруг выросли на 20%.

Очевидно, с текущим рынком

При чем тут рынок?

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

При чем тут рынок?

При том что очередь кандидатов не стоит и надо беречь каждого. Заменить Олега некем. Найм другого Олега не исключает те-же риски и будет стоить дорого, даже если ты крупный американский продукт.

Конечно это все в общем абстрактном случае. Например, в случае если это кикстартерный стартап — тогда попа. У этих отчаянных парней — вообще никаких буферов в плане денег и времени.

Качайте софт-скиллы.

Вот интересно, это только в постсовке под софт-скилами подразумевают навешивание лапши окружающим или во всем мире так заведено?

И это было бы правдой, так как без фичи Олега качества продукта явно ниже.

А это не для всех фичей так)

Заменить Олега некем

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

взял бы мидла Петра и джуна Колю

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

За те же деньги общая производительность может даже вырости.

Во-первых деньги не те же! Новый сотрудник — это сразу +500 к зарплате (иначе зачем ему менять работу?). Во-вторых производительность джунов отрицательная (больше времени тратиться на их обучение) — это банальная истина. В третьих производительность — она не линейная. Синьор напишет за день — а мидл может неделями ковырять и пытаться найти решение. Просто потому что раньше с таким не работал, опыта нет.
Давно известная истина: что бы хорошо работали мидлы — должен быть хоть один синьор, который сможет им подсказать!

Вот интересно, это только в постсовке под софт-скилами подразумевают навешивание лапши окружающим или во всем мире так заведено?

Не знаю, как во всем мире, но в Голландии — ДА (но вслух об этом, конечно, никто не говорит).

вариантов много но напрашивается два варианта сразу:
— а нужен ли такой Олег вообще
— может лучше пусть он подумает хорошо и на сл. день доработает но более нормально

а если не первый раз то (ИМХО) как-то работа организована «дивно» и с этим явно что-то надо делать и с Олегом в том числе.

на сл. день доработает но более нормально

хм, кстати очень даже да! вечером можно сделать еще хуже чем было

В пятницу вечером — особенно)))

— а нужен ли такой Олег вообще

да не нужен конечно, уволь его и посмотри с какой скоростью другая фирма возьмет его на работу))) (Спойлер: Менее 1 недели — я проверял) Вам шашечки или ехать?

и что, что возьмет? мне ехать а не шашечки посему я предпочту специалиста который будет нормальным человеком и нормально работать а не валить и подставлять всю группу (20+ лет руководящих должностей и куча сотрудников которых сам брал на работу так что тоже знаю о чем говорю). Хотя людей увольнять не люблю но если какой-то сотрудник «валит» коллектив то ариведерчи. сделать из человека спеца можно, а вот из непонятно чего сделать человека тут нужна эволюция, Дарвин, папа/мама/ремень и т.д.

Я знаю, я с кучей людей типа вас общался, так что не надо мне тут опытом кидаться. За последние лет 20+ реалии поменялись. И теперь Олегу надо крайне накосячить, чтобы мое начальство и начальство моего начальства, а также клиент согласились с тем, что его надо гнать.
И при том, не мое начальство еще не дало мне по шее за рекруторский ценник в минимум 1.5 зарплаты Олега))) Вот так и едем на том, что есть) Максимум — можно через ейчаров поесть мозг Олегу на тему дисциплины, успех будет крайне переменный)

и что, что возьмет?

Конечно. Косяк Олега в сравнении с тем, что иногда некоторые творят — как-раз очень легко разрулить. Это даже не косяк, а так — косячок)))

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

И теперь Олегу надо крайне накосячить, чтобы мое начальство и начальство моего начальства, а также клиент согласились с тем, что его надо гнать.

У нас с галеры увольняют только если начальнику по голове дал. Все остальные косяки — в худшем случае перекинут на другой проект. Даже если человек вообще ничего полезного не делает — его все равно будут держать «для массовки» — потому что клиент платит за головы.

У нас с галеры увольняют только если начальнику по голове дал.

север помнит

я предпочту специалиста который будет нормальным человеком и нормально работать а не валить и подставлять всю группу

Такие люди сейчас нарасхват — о том и речь! Вы попробуйте такого для начала просто на интервью к себе заманить. Если придет — то узнаете насколько выше рынка он попросит. А может в итоге ему не понравится то, что вы делаете и он через пару месяцев уйдет.
Что бы гарантированно переманить к себе хорошего специалиста и удержать — ему нужно платить хорошо выше рынка. Уверенны что это окупится?

искал таких и коллектив держался долго , ротация была очень редко. что я делал не так?

т.е. Ваше предложение ехать с колесом квадратным и которое поперек течению?

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

Да пофиг на другую фирму! Ты сначала попробуй найди замену этому разгильдяю который будет работать хотя бы так же. Во-первых любой новый сходу захочет на 500 баксов больше — просто за переход. Во-вторых если он действительно толковый и ответственный — то у него УЖЕ есть работа где его ценят. Что бы его переманить рекрутерам придется пообещать ему что-то необычное, а не просто +500. Даже если его заинтересуют — скорее всего он не будет бросать проект на середине (ответственный ведь!) а поработает еще месяц-другой пока ему там не найдут замену. В среднем вакансии синьора закрывают от 3х до 6 месяцев!
Так что сходу уволишь одного разгильдяя за то, что не доделал работу — вся команда будет за него пол-года овертаймить!

то что с персоналом проблема — согласен на все 1000%
но тут есть и подвох — пожалеешь одного разгильдяя так остальные станут тут же такие же и зададут вопрос: «а чего мы должны... если Олег...»

Мне не подходит быть начальником! Потому что хороший начальник — как дирижер: он играет ЧУЖИМИ руками. И поскольку подчиненные — это люди, то все они разные. Если девелопер хорошо знает 1-2 языка и умеет с их помощью решать задачи в проекте — то начальник это как девелопер, которому дали 10 репозиториев на разных языках и все их нужно поддерживать!
Быть начальником требует СОВСЕМ других навыков и опыта: не важно какой опытный ты был девелопер и сколько всего знал — здесь ты работаешь с людьми и только опыт общения, а лучше управления людьми имеет значение. Естественно у девелопера, который большую часть жизни провел за монитором такого опыта меньше, чем у какого-нибудь таксиста.
Что бы быть ХОРОШИМ начальником нужно знать каждого человека в команде, понимать его сильные стороны, принимать его недостатки (взрослого человека не перевоспитать), искать чем его мотивировать, видеть потенциальные конфликты, правильно распределять задачи, стараться «тянуть» подчиненных в нужном направлении что бы они росли ...
Но и это только половина работы: ведь у начальника то же есть начальник. И с этой стороны то же надо уметь работать: уметь настоять где надо, уметь подлизнуть когда надо, уметь прикрыть свой зад, уметь «копать» под начальника, уметь интриговать с начальниками своего уровня, уметь отбиться от лишних обязанностей, которые на тебя сгрузит босс. «Беззубому» начальнику высшее руководство всучит самых проблемных и бесполезных подчиненных и потом на него-же спишет все неудачи что бы выбросить «мусорную команду» вместе с руководителем.
Я всегда считал что из девелоперов получаются плохие руководители! Даже какой-нибудь школьный учитель и то сможет «пасти» великовозрастных детей-задротов лучше, чем вчерашний тостер или программист. Каждый специалист должен заниматься своим делом: одни работать с компьютерами — другие с людьми!

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

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

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

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

Дальше всё зависит от Олега :)

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

Тут есть варианты:
1. Олег не задержался на 5 минут, чтобы доделать таск, а с завтра он в отпуске — за такое надо наказывать.
2. Олег не задержался на 5 минут, а у вас завтра релиз или демо. А что, QA непроверяют релиз перед выкладкой? Если проверяет, то в чем проблема? Ну прийдет Олег утром, за 5 минут доделает таск, запустит билд, потом тесты и к приходу QA все будет ровно так, как если бы он это сделал еще вечером. Конечно Олег поступил не лучшим образом (взять себе на заметку, что теперь Олег последний в очереди за бонусами и повышениями), но и ругать его особо не за что. И тем более не стоит сидеть и за него что-то доделывать до 12 ночи.
3. Если это обычный день, а Олег ушел забрать ребенка из садика. То тут вообще нет проблемы.
Короче тема Олега не раскрыта.

Олег не задержался на 5 минут, чтобы доделать таск, а с завтра он в отпуске — за такое надо наказывать

кого саме? манагера, Олєга, тіму?

5 мінунт на додєлать?
це хіба що попісать можна встигнути, чи про яку таску?

Вроде же позиция Team Lead устарела уже, и его заменили Tech Lead и Engineering Manager.

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

А зачем тим-лид? Скажем, сейчас софтовые проекты делаются, в основном, эджайл — это значит скрам-тимы. В каждом скрам-типе на 5-10 чел, есть «продакт оyнер».

А зачем тим-лид?

Если это аутсорс, то PO далеко в США с разницей в 10 часов, и надо что бы кто-то в на месте гребцов гонял.

Если это аутсорс, то PO далеко в США с разницей в 10 часов, и надо что бы кто-то в на месте гребцов гонял.

Для этого, вроде, есть галерный ПМ.

Хотя, если это скрам-тим на стороне галеры — то хрен его знает. Можно и ПО из местных назначить, но у них обычно со знанием бизнес/предметной-области голяк.

П.С. Впрочем, насколько я понял — у Пларииума вообще продукт свой (игрушка). Т.е. даже не аутсорсинг.

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

Для этого, вроде, есть галерный ПМ.

PM может быть 1 на 100 человек, и быть вообще не в курсе как его гребцов зовут.

Техлид то ладно. Это обычно эксперт в кодировании (+ в предметной области, если есть бэкграунд + прокачается на проекте). Т.е. этакий «кодящий тренер».

Но тимлид — это совсем иное.

Ты не понял, это еще хуже, галеры обманывают техлидов делая их тимлидами)

Именно! Галеры экономят, считая что один ПМ и 100 человек заменеджить сможет. Потому что клиенты не хотят платить за погонщиков — только за девелоперов. Естественно такой перегруженный ПМ сразу ищет на кого бы из подчиненных перекинуть свою работу.
Я последние годы работаю именно тех-лидом: это значит 6-8 часов пишу код сам + 2-4 часа управления задачами и помощи 5-10 девелоперам из своей команды.
При этом мне постоянно стараются навязать работу ПМ и даже HR: например что бы я проводил с каждым 1-1 митинги каждую неделю, что бы собирал статистику и трекал всякие KPI, что бы проводил мотивационные «партсобрания» и следил за моральным духом...
Я в этих случаях прямо говорю: вы продали меня клиенту как девелопера и он платит что бы я 8 часов в день решал задачи. Если я буду менеджить людей — я не успею писать код. Лучше вместо следующего повышения моей зарплаты на 500 баксов — наймите на эти деньги девочку — HR и пускай она мотивирует девелоперов, следит как они работают, делает отчеты и т.д. Мне это — не интересно!

это значит 6-8 часов пишу код сам + 2-4 часа

...получается, 8-12 часов/день?)

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

Так и есть. Помимо запланированной соей работы (кодинга, распределения тасок, митингов) тех-лид еще и помогает другим членам команды. Один день помощ может не требоваться — а в другой приходится несколько часов вместе дебажить что бы разрулить какой-то затык. Плюс обязательное участие в код-ревью. Иногда все ок, а иногда приходится долго объяснять девелоперу почему его решение будет работать криво или не оптимально.
Собственно смысл роли тех-лида это поддерживать своим опытом менее опытную команду. Если бы в команде все были синьоры с 5+ годами опыта — то им бы и тех-лид был не нужен.
К сожалению в аутсорсе нет такой работы как помогать другим. Клиент платит за задачи и потраченное на них время, за «парное программирование» не заплатит. Поэтому тех лид билит 8 часов работы клиенту как девелопер + остальное компания покрывает за счет разницы рейтов. Т.е. условно говоря клиент платит Х за каждого члена команды, тех-лид получает 0.7*Х, а остальные члены команды 0.4*Х или вообще 0.2*Х если это джуны, которых продали как синьоров.

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

Как-то ты странно себе работу архитекта представляешь! В реальности все с точностью наоборот: меньше половины времени архитект работает сам, придумывает архитектуру или делает РОС. А потом он должен эту архитектуру «продать» клиентам (раньше для этого еще и в командировку полететь), а потом еще донести до всех команд и постоянно следить и пояснять. Так что общения и «торговли лицом» выше крыши!

Идеальная позиция для интроверта.

Ни в коем случае! Иначе я бы давно стал таким архитектом «из мечты», который только сидит у себя в кабинете, придумывает архитектуру, а с остальными общается только UML диаграммами.

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

Тут неплохо разобрано:
dou.ua/...​tware-architect-position
Про «рабочего архитекта», которому не приходится много общаться — не слышал. Даже тех-лиду приходится 1-2 часа в день тратить на общение (митинги и помощь членам команды).

Смотря какой архитект. В аутсорс-компании часто архитект много помогает с присейлом (ревьювят и помогают заэстимейтить потенциальные проекты, поговорить с клиентами) и с ревью текущих проектов компании (промониторить все ли ОК, итп)

тоді йди не просто в архітєкти, а солюшен архітєкти

Если в команде все синйоры 5+, может получиться сонное царство — каждый хорошо знает как за дорого ничего не желать. И не трогайте меня в теч дня, не мешайте концентрироваться на выше упомянутой задаче.

ти вибрав путь к вигоранію

А дєвочка вивчила англійську досконало, знає Jira, Agile, Srum, Kanban, основи HTML s CSS і каже: за 500 не хочу горбатитися, робіть самі.

Техлид то ладно. Это обычно эксперт в кодировании (+ в предметной области, если есть бэкграунд + прокачается на проекте). Т.е. этакий «кодящий тренер».

Это не «эксперт в кодировани». Тех лид налаживает тех процессы (код конвеншны, частенько CI/CD, если нет девопса и т.д.), ведет тех митинги в команде, ведет тех долг, отвечает за состояние всего кода в целом, а часто еще и за деплой/поставку софта, часто распределяет таски/стори по девелоперам, определяет или согласовывает с архитектором и/или девелоперами микро- и/или даже макро- архитектуру, и т.д. Ему не обязательно быть тех гуру (тем более, в узконаправленных технологиях), но ему надо хорошо разбираться в широком спектре технологий, принципов, паттернов, методик и всего, что касается разработки ПО, и иметь солидный опыт разработки ПО, что бы успешно выполнять свои обязанности.

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

Это и имеется в виду, под «экспертизой в кодировании».

Для этого, вроде, есть галерный ПМ.

Прокси продакт оунер часто называют, и он проксирует все вопросы к ПО от местных гребцов и потом созванивается с нормальным ПО и передает взад гребцам уточнения :-)

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

Против пользы от техлидов — не спорю. А тимлид зачем?

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

Тимлид тимлидов — это что-то новенькое

Архитекторов начальник и тимлИдов командир! :-)

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

Все просто: в нормальных компаниях есть ПМ и есть менеджеры 2 уровня (над ПМ). Здесь это назвали тимлидами и тимлидами-тимлидов. Зачем? Очевидно что бы сэкономить на зарплатах — ведь менеджерам уже нужно платить больше, чем девелоерам. А так девелопер (и возможно даже не синьор) за ту же зарплату + возможность покомандовать будет выполнять работу ПМа или даже начальника отдела.

а и такое уже есть?
хотя в одной конторе в которой работал был персонаж, визитку спецом сохранил : «директор дирекции директоров зам директора...»
важный мальчик был, щеки надувал круче хомяка...

Заблуждения 3, 4 и 7 — это одно и тоже, сказанное другими словами. А хотя нет, теми же словами. Я так понимаю автор в самом начале очень сильно впахивал и ему это больше всего запомнилось.
А самое главное он к сожалению упустил. В статье много про технические детали, но ничего не сказано про психологический аспект этой роли.
Тим лид это в первую очередь — ответственность. За всё спросят с тебя. Что происходит в команде, кто выгорел, кого нового взяли, почему завалили спринт и тд.
Важно быть готовым к такому уровню ответственности, не бояться принимать решения и делать ошибки, быть опорой всей команде, ты всегда знаешь больше других — тебя зовут на закрытые митинги, ты должен знать орг структуру компании и руководство.
Ты можешь уделять время программированию, по фану, но команде от тебя нужно другое, код они и сами писать могут, и да, порой лучше чем ты)

Хорошо и по делу. Мне понравилось. Видно, что не готовили на пятницу. Ни политики, ни релокейтов. Даже не сравнили производительность Node.js с другими платформами

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

Бывает и строго обратная ситуация: тимлид никакой не лид, а просто оверпрайснутый хряк, пристроенный в проект. Этакий эффективный филин.

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

любую хорошую идею можно легко загробить душными совещаниями и цветными отчетами (ц)

и украсить расчленёнкой бюрократа

А можно они вообще кодить не будут? А пойдут в сейлзы. Вазелин в подарок.

Это не зависть, а констатация. Ну что хорошему кодеру делать в тимлидах? Где и не покодить...

аналогия плохая, тренер (ПМ) во время матча кричит игрокам на поле куда бежать и что делать. В ИТ тим лид для того и нужен, чтоб брать на себя эти вопросы микро-менеджмента, кому и куда бежать.

тренер (ПМ) во время матча кричит игрокам на поле куда бежать и что делать.

Это доказывает что аналогия правильная. Тренер кричит куда бежать — но сам не бежит! Если бы он пытался бегать и кричать — то выдохся бы очень быстро.

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

Тогда тимлид — это то же менеджер, начальник, но не девелопер. И если он не девелопит хотя бы 4 часа в день — то неизбежно теряет квалификацию, не в курсе всех изменений в коде и уже не может принимать правильные технические решения. Получается что синьоры из его команды знают лучше тимлида — тут ему остается или смириться с тем, что решать лучше им или продавливать свое мнение силой («я начальник — ты дурак»).
Работа быть начальником — это работа ЧУЖИМИ руками! Умение использовать людей как инструменты для решения задач. Начальник, который делает работу сам — плохой начальник и плохой работник. Такое возможно только от жадности: начальнику не хотят дать в команду достаточно подчиненных и говорят «работай сам» или работника не хотят повышать до начальника, и дают немного «покомандовать» вместо промошина.

Так играют же инвалиды, дети и слабоумные :-)

порожденный жадностью галер, как и фулстек

Отутка я нє соглашусь. Фулстеки породжені не галєрами, вони були задовго до того і довгий час асоціювалися більше з невеликими продуктовими командами.

Фулстеки появились, когда придумали веб-апы (SAP). До этого, например, дотнет девелопер писал веб-сайт полностью и это не считалось фулстеком. А мог еще и GUI интерфейс на дотнет писать если надо — и это то же не было отдельным «стеком».
Как только оказалось что нужно делать отдельный UI на других технологиях или вообще мобильное приложение — то, вместо нанимать отдельную команду для этого, решили что те же дотнет девелоперы теперь должны стать «фулстеками».
Заметьте: я никогда не видел фулстека, который бы сначала был фронтенд девелопером — а потом выучил бы дотнет что бы стать фулстеком! При этом «фулстеков» которые пришли с «бэкенда» (хотя тогда он еще не назывался так) — большинство.
Когда проект полностью делают такие фулстек — синьоры — это обман. Потому что у такого фулстек-девелопера например от 3х лет опыта в бэкенде и 1 год опыта во фронтенде. Ну и какое фронтенд приложение может написать команда где у всех 1 год опыта?! А настоящего фронтенд — синьора взять на проект философия не позволяет: у нас ведь в команде все фулстеки!

фуллстек == «тыжпрограммист» (это тренд из 90-х 2000-ых)

Raid: Shadow Legends.

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

можна додати 8 —
«якщо є проблеми то до мене прийдуть з ними», особливо це стосується актуально коли деву вже зрозуміло, що в терміни не вкладаться, а тімліду стане відомо наступного тижня

Спасибо за дополнение, Анатолий. Абсолютно согласен с вами, настроенные каналы обратной связи между тимлидом и командой невозможно переоценить!

— як відрізнити від 16-річного синьйора?
— тімліду вже 17

Заблуждение № 5: никто не сделает так же качественно, как я сам

В цілому, інколи, буває і заправду. Однак, як на мене, по цій якості і буде видно наскільки людина успішна на цьому поприщі. У хорошого ліда будуть донесені до команди необхідні стандарти і вимоги, згідно яких не буде страшно комусь делегувати відповідні завдання. Бути лідом без делегації практично не можливо, а це саме вже:

Заблуждение № 7: хороший тимлид должен сам со всем справляться

Спасибо за комментарий, Мирослав. Я согласен с тем, что при грамотной организации командной работы, что несомненно является критерием качества работы тимлида, делегировать будет проще. Заблуждение № 5 как раз и было о понимании важности такого инструмента как делегирование.

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

Какой прекрасный комментарий. Вот прям вся суть работы такого «тимлида»

Подписаться на комментарии