Недавно наткнулся на пост, который поразил меня до глубины души:
тимлид - это САМЫЙ ДОРОГОЙ ресурс команды. И когда тимлид садится писать код, вместо того, чтобы решать свои прямые задачи, он обесценивает свой трудочас. Для всяких технических вещей в команде есть техлиды, а задача тимлида как раз в том, чтобы у техлидов было все необходимое, чтобы эти вещи реализовать.
В последнее время я все чаще и чаще сталкиваюсь с мнением о том, что тимлид не должен писать код. И, если лет эдак 15 назад это была просто шутка, то сейчас это мнение становится чуть ли не мейнстримом в индустрии. Поэтому я хочу чётко сформулировать свой взгляд на этот вопрос.
Я работаю в индустрии с 1999 года. Почти 25 лет уже. И все эти годы я пишу код, на каких бы позициях я ни находился. И не считаю это чем-то зазорным. Более того, по моим наблюдениям, лидер, который не пишет код, очень быстро теряет технологический контекст, и начинает принимать некачественные технические решения. По сути он теряет техническую квалификацию. А с учётом скорости развития индустрии, процесс утраты квалификации оказывается весьма и весьма стремительным.
Пора начать называть вещи своими именами. Если вы не пишете код, то утрачиваете техническую квалификацию. А если вы не обладаете технической квалификацией, то по-факту вы не являетесь тимлидом. Постараюсь свой тезис обосновать.
Вы можете сказать, что вы дескать "управляете людьми". Но, суть процесса управления людьми заключается в делегировании полномочий. А без соответствующей квалификации вы не можете делегировать технические задачи потому что:
Вы не можете нанять инженера, так как вы не в состоянии оценить его квалификацию.
Вы не можете поставить задачу инженеру, так как вы не можете её сформулировать.
Вы не можете оценить качество выполнения поставленной задачи, потому что вы не понимаете её суть.
Вы не можете оценить адекватность сроков выполнения задачи, так как не можете оценить её трудоёмкость.
Вы не можете выступать в роли арбитра в спорах между инженерами, так как не понимаете суть этих споров, и не обладаете авторитетом среди технарей.
Вы не можете обучать нанятых вами инженеров, так как вам нечем с ними поделиться.
Вы не можете выявлять технических лидеров в команде, чтобы делегировать им полномочия развития тех или иных направлений.
Вы не можете обеспечить "отказоустойчивость" вашей команды, так как не можете оценить реальный вклад в работу инженеров. Вы не понимаете, кого нужно удерживать, а с кем можно спокойно попрощаться. Вы не можете адекватно оценить риски ухода того или иного инженера. И, как следствие, вы не можете вовремя минимизировать эти риски.
Отсюда вывод - людьми вы НЕ управляете. Поэтому лидером команды (т.е. тимлидом) вы НЕ являетесь.
Может вы хотите сказать, что вы управляете процессом разработки? И это тоже неправда. Без технической квалификации вы:
Не можете осуществить декомпозицию крупных технических задач.
Не можете адекватно расставить приоритеты задачам.
Не можете спрогнозировать сроки выполнения задач.
Не можете оценить степень риска выполняемых задач. Как следствие, вы не можете спрогнозировать потенциальные кризисы процесса разработки, и подготовиться к ним.
Вы даже не можете принять решение о наиболее подходящей методологии разработки для вашего проекта.
Может вы хотите сказать, что вы принимаете стратегические технические решения? Это тоже не так. Потому что без технической квалификации вы:
Не можете спроектировать архитектуру самостоятельно.
Не можете оценить качество спроектированной архитектуры.
Не можете подобрать адекватный технологический стек для реализации спроектированной архитектуры.
Не можете оценить архитектурные и технологические риски.
Не можете спрогнозировать долгосрочную архитектурную и технологическую эволюцию проекта.
И, как следствие, вы не можете сформулировать требования к квалификации нанимаемых инженеров.
Так что же вы можете? Хорошо, если вы знаете бизнес, для которого разрабатываете техническое решение. Но тогда вы тоже не тимлид - вы бизнес аналитик. Ну или владелец продукта.
А если вы и бизнеса не знаете... То всё, что вы можете - это готовить итоговые отчёты о проделанной работе. Ну может слайдики рисовать. И то с натяжкой. Презентовать проект вы тоже не можете. Так как не понимаете суть проекта и не можете ответить на любые вопросы, требующие мало мальских технических знаний.
Но тогда кто же вы? Да вы по сути просто секретарша. Но тогда у меня возникает риторический вопрос. Почему секретарша является самым дорогим ресурсом в команде?
Комментарии (169)
Emulyator
24.03.2024 15:29+6По моему опыту одинокого эникейщика тимлид не нужен. ) Но если подумать, то как быстро опытный программист потеряет связь с командой, если она не скачет со стека на стек, а пользуется известными, хорошо отработанными технологиями? Думаю не быстро. Другой вопрос: а почему бы тимлиду не пописать проект с командой, ведь не все же время заниматься стратегическим планированием, или чем они там занимаются? )
Vitimbo
24.03.2024 15:29+8Когда-то работал как фулстек и на достаточно хорошем уровне мог сверстать страничку в этих ваших реактах или ангулярах. Спустя 2 года чистого бэка уже не могу. То есть саму суть работы веб приложения я понимаю, а вот как ИМЕННО надо этот редакс использовать уже хз. Так что навык можно потерять достаточно быстро.
Но, думаю, что если приспичит, то за пару недель освою обратно.
Kenya-West
24.03.2024 15:29+5вот как ИМЕННО надо этот редакс использовать уже хз
Моё мнение после нескольких готовых проектов, в которых есть этот конкретно Redux - он нафиг не нужен.
Не поймите меня неправильно, я сам в своём сложном проекте в итоге накостылил работающее подобие стора, со всякими этими эффектами и экшенами. Но оно получилось в разы проще и быстрее для понимания, чем, к примеру, следующий философии Redux'а ангуляровский NgRx.
Сам паттерн единого стора имеет право на жизнь (хотя в последнее время от него стараются чуточку отходить), но он, блин, должен быть проще и требовать минимум кода. А не как в недевственном NgRx, где на хранение одного поля ты пишешь редьюсеры, экшены, слайсы, эффекты на ≈200 строк. Это смешно. Я, когда это увидел, офигел и обратно не выфигел. Притом несовпадения типов выдают эксепшены на 3000 строк, это невозможно отдебажить даже с Copilot - тупо контекста не хватает.
Резюмируя, скажу - ничего вы не потеряли, а наоборот, избежали совершенно лишней головной боли. Для простых случаев напишите что-то типа service locator и затем закостыльте под "типа стор". Как поймёте, что созрели - мигрируете на любую библиотеку, которая реализует Redux, но максимально просто и понятно.
Rampages
24.03.2024 15:29+2На фронтенде такое ощущение все пытаются вписаться в какие-то тренды, пытаются использовать библиотеки из какого-нибудь треда "за последние 2 недели вышли 2 новых библиотеки! мастхэв для каждого! убийца angular/react/vue/etc! успей освоить сегодня!" :)
На полгода выпадаешь из индустрии и потом вкурить почему надо использовать это... начинаешь читать документацию и вроде что-то полезное, много чего пофиксили, добавили новых фич, но как-то сильно переусложнили ради случаев, вероятность возникновения которых стремится к 0%...
kasiopei
24.03.2024 15:29Получается что какой фреймворк не используй он устареет через пару лет и превратится в легаси :-) Напоминает запланированное устаревание.
zerodayexp
24.03.2024 15:29Это, кстати, похоже на стереотип, который сформировался на этапе становления фронтовых фреймворков.
Не знаю как в стартапах, там свои приколы, но в больших кампаниях никто не бегает от одного фреймворка к другому. Сейчас используется реакт/ангуляр по мере необходимости, вью много не вижу (что, кстати, подтверждает тезис, что никто по фреймворкам не прыгает, т.к. вью последний появился).
Прыжки по либам/фреймворкам осуществляется только если это действительно дает профит и если кост прыжка не сильно большой
Vitimbo
24.03.2024 15:29Согласен, только у нас, помимо чисто redux, все ещё было обильно обмазано сагами. В результате, чтобы работать со стором, приходилось писать какой-то невероятный объем кода, хотя, я всего лишь делаю store.SomeValue = value.
Аж вьетнамские флешбеки полезли.
AllexIn
24.03.2024 15:29+15Team Lead не должен писать код. Потому что он вообще не кодер. Это Team Lead, он всей командой руководит, в том числе маркетологами, дизайнерами, моделлерами(и кто там у вас еще в вашей сфере специфический есть).
Если мы говорим о Lead Developer/Programmer(должность которого существенно ниже Team Lead'a), то он писать код должен, хотя это и не его основная работа.
Опять же, возникает вопрос, почему Tech Lead у вас по рангу ниже Lead Developer'a.
В моей практике, как правило, Lead Developer руководит разрабами в конкретной команде. В то время как Tech Lead стоит над проектом, и реализует свою квалификацию на уровне всех проектов компании. То есть это авторитет, которые разруливает вопросы применяемых технологических решений и утверждает подходы для каждого проекта. У вас по описанию это просто рядовые разрабы, какие-то.... Что в вашей компании отличает техлида от рядового сеньора работающего над проектом?
dyadyaSerezha
24.03.2024 15:29+3Конкретнее. Сколько людей в подчинении у тимлида у вас?
AllexIn
24.03.2024 15:29+1Конкретно у нас около 50.
vkni
24.03.2024 15:29+8У нас, и, кажется, это традиционно, ГруппенФюрер - это самый мелкий начальник над группой "линейных" программистов от 1 до 8 человек (оба крайних варианта временные).
Zenitchik
24.03.2024 15:29+2Респект, за знание младших командных должностей НАТО (Бундесвера в частности) )))
Я - ради страйкбола изучил (разные клубы реконструируют разные войска).
isden
24.03.2024 15:29+5Это старый мем на самом деле :)
Zenitchik
24.03.2024 15:29Полагаю, этот мэм примерно ровесник блока НАТО. Группенфюрер, он же тимлидер, - капральская (гефрайтерская) должность в армиях НАТО.
isden
24.03.2024 15:29+4Группенфюрер
Оно еще с 20-х годов (прошлого века) в одной известной организации использовалось.
Zenitchik
24.03.2024 15:29+1Причём, даже в двух. И значило в них совсем разное. Скажем, в Вермахте, группенфюрер - это была ДОЛЖНОСТЬ, примерно, как сейчас в Бундесвере. А в СС - группенфюрер - это одно из генеральских ЗВАНИЙ.
Сложно сказать на счёт 20-х годов. Должность группенфюрера наверняка была в Вермахте с самого начала. И, наверняка, существовала и до Вермахта. А вот в была ли в 20-х годах в СС собственная линейка званий, или она появилась уже вместе с войсками СС - я не уверен?
isden
24.03.2024 15:29На википедии на эту тему вроде +- похоже на то что читал ранее, но за достоверность не уверен.
muxa_ru
24.03.2024 15:29+8Если слово "группенфюррер" вызывает у Вас ассоциацию с НАТО, а не с Броневым, то я поинтересуюсь, Вы не засланный ли к нам?
Zenitchik
24.03.2024 15:29+3Надеюсь, это была шутка. С каких пор военная грамотность стала признаком "засланного"?
UPD: Буду признателен, если Вы подскажете, где, кроме НАТО группенфюрер является синонимом (немецкоязычным) тимлидера (англоязычного). Персонаж Броневого, насколько я помню, тимлидером не был.
muxa_ru
24.03.2024 15:29+3Конечно это шутка.
Только вот это слово не из военной грамотности, а из кинокультуры , например, из Штирлица.
Поэтому "...фюрер" нас веселит, а то как оно звучит на других языках - нет.
Поэтому и возникает вопрос о том, сколько Вам лет и в какой стране Вы провели детство, что не считывате такие отсылки.
Zenitchik
24.03.2024 15:29+3Кинокультуру, я разумеется, знаю.
Но видите-ли в чём дело... Группенфюрер СС - это по-нашему генерал. Т.е. никак не "это самый мелкий начальник над группой "линейных" ", о котором писал @vkni.
Зато "самый мелкий начальник над группой "линейных" " называется в войсках НАТО по-английски "Team Leader" (ничего не напоминает?), а по-немецки - группенфюрер.
Строится вполне закономерная ассоциативная цепочка: "тимлид" -> "тимлидер" - "группенфюрер".
Её можно продолжить и до Броневого. Но в обход тимлидера к Броневому не придёшь, если только за уши не притягивать.
Потому я и подумал, что @vkniтоже что-то понимает в пехоте вероятного противника...
muxa_ru
24.03.2024 15:29UPD: Буду признателен, если Вы подскажете, где, кроме НАТО группенфюрер является синонимом (немецкоязычным) тимлидера (англоязычного). Персонаж Броневого, насколько я помню, тимлидером не был.
Так всё же, где Вы провели детство и сколько Вам лет?
Потому что нейтив должен отличать аллюзии и каламбуры от логических построений.
Zenitchik
24.03.2024 15:29Мне 39. Я всю жизнь прожил в Москве.
Дело в том, что никакой каламбур, если только не притянутый за уши (что убивает его ценность), не превратит тимлида в генерала.
muxa_ru
24.03.2024 15:29+3А каламбур и не должен никого ни во что превращать.
Каламбур это шутка построенная на внешней схожести формы, а не содержимого. Более того, разница содержимого может быть не багом, а фичей - обеспечивая твист.
В данном случае твист состоит в том, что названия должностей становятся стилизованными про киношные.
Например, вот случайная картинка из интернета на эту тему.
Само собой, делать такие каламбуры на, например, испанском смысла нет - нет ассоциаций.
Zenitchik
24.03.2024 15:29Каламбур это шутка построенная на внешней схожести формы
Верно, а когда схожести нет, и автор просто ляпнул - то это не каламбур, и совсем не смешно.
Например, вот случайная картинка из интернета на эту тему.
В этой картинке есть логика. И нет группенфюрера.
vkni
24.03.2024 15:29Надеюсь, это была шутка.
Как у вас могли возникнуть сомнения в этом? Team lead - это командир взвода примерно, то есть Zugführer.
Zenitchik
24.03.2024 15:29Team Leader - это командир Fireteam. Это подразделение из 2-4 человек, входящее у них в состав отделения (section).
Командир взвода (squad) назвается squad leader.
А вот на счёт Gruppenführer я ошибся. Это оказался командир отделения Gruppe(de) == Section(en).
А Team(en) == Trupp(de) - соответственно.
vkni
24.03.2024 15:29Вы правы, отделения.
Zenitchik
24.03.2024 15:29Файертим - это не отделение, а более мелкое подразделение. В нашей армии такого нет.
Zenitchik
24.03.2024 15:29Расчёт в разных войсках имеет разное соответствие. У меня, например, расчёт был аналогом взвода.
Я не знаю, как у пехоты и миномётчиков, но, насколько я слышал, все структуры меньше отделения у нас не отражены в штате, а существуют только в виде порядка взаимодействия бойцов. Например - гранатомётчик с помощником гранатомётчика. У НАТО подобная пара, скорее всего, была бы записана как фаертим (по аналогии с фаертимом ПЗРК "Стингер" - из двух человек).
Кстати, у них пехотный фаертим делится на пары, которые не отражены в штате.
JBird
24.03.2024 15:29+1группенфюрер является синонимом (немецкоязычным) тимлидера (англоязычного).
У немцев же есть вполне однозначное Teamleiter, и безо всяких отсылок ко временам художника )
Zenitchik
24.03.2024 15:29А в немецком языке это не является отсылкой. Просто слово, составленное из двух общеупотребительных корней.
denis-isaev
24.03.2024 15:29+7Есть ощущение, что вы тимлидом называете совсем иную роль в компании, чем ваши собеседники.
У вас эта команда в 50 человек что ли больше не делится на меньшие команды со своими лидами? Вот так по 50 человек и ходите на проектные встречи?
Вообще для штата в 50 человек уже всякие SAFe и LeSS придумали, чтобы выравнивать командЫ между собой, потому что одна плоская единая команда в 50 человек - это как-то... необычно.
ssmaslov
24.03.2024 15:29SAFe это у нас для 700 человек. Для,50 норм 1 тимлид, я,например таким являюсь. Но у нас (конкретно в мой команде) дейли нет ибо бессмысленно. 2 раза в неделю общая встреча с жестким таймингом 30 минут. Естественно, не 50 человек над задачей работает, под конкретные задачи динамически формируются. В них нет выделенных должностей, просто обьединение на одну задачу. А так (почти) все со всеми работают. И да, дел у меня хватает и без кодирования, хотя и умею (не на всех стеках которые есть в команде). Я даже задачи не распределяю, это координатор делает, он же примерную трудоемкость оценивает, за мной только нетиповые случаи. Если бы я и код писал я очень быстро стал одновременно говнокодером и говноменеджером одновременно.
petejones83
24.03.2024 15:29+3Кто такой "координатор"?
Тимлид должен проводить 1:1 с членами команды, если каждому давать по часу раз в пару недель + еще час на подготовку, то у вас все рабочее время уйдет исключительно на это.
Ну, или вы просто не проводите 1:1.
dyadyaSerezha
24.03.2024 15:29+1050?? Тогда у нас точно разница в терминах. У тимлида обычно 3-9 человек. Если больше, то это Х, это начальник второго уровня и под ним тимлиды.
P.S. Гугл находит такой размер группы у тимлида: 3-7 или 5-7.
ssmaslov
24.03.2024 15:29Зачем группе 5 человек выделеный лид?! Это какой то неправильный подход
Kragius
24.03.2024 15:29+5Знаете, я ничего не имею против вас и вашего подхода. Но может быть если у всех вокруг так, а у вас - иначе, может быть это у вас подход не такой?
Ну то есть ваш подход явно работает, никто не спорит. Но во всех местах, которые я знаю - тимлид это главный программист для команды в 3-7 человек. Он пишет код, занимается планированием задач, думает над архитектурой и работает связующим звеном между менеджментом и программистами. И судя по комментам, в основном тимлид именно такой, а не такой как у вас. Так что может у вас термины перепутались?
dyadyaSerezha
24.03.2024 15:29Это самый стандартный подход во всем мире. И предполагается, что он тоже пишет код (10-30%)
ViktorAbba
24.03.2024 15:29Все зависит от размера кампании, если в компании 20 человек, то на 5 человек тимлид - это нормально.
FireFly111
24.03.2024 15:29+5Это не вопрос подхода, это вопрос терминологии.
Исторически в самоорганизованной команде появляется её лидер, который не только пишет код, но и что-то организует и коммуницирует, его называли тимлидом раньше. Сейчас кого только так не называют, в том числе и линейных менеджеров.
saboteur_kiev
24.03.2024 15:29+5Team Lead не должен писать код.
Давайте сделаем так. Тимлид не обязан писать код, а не не должен.
Он руководит не всей командой, а своим набором девелоперов. Тимлид маркетологов рулит маркетологами, тимлид дизайнеров - дизайнерами.
Если у вас фича-команда, то он будет обязан разбираться во всем, поэтому зачастую фича команды существуют в виде "девелопер-дба-qa", а не все эти маркетологи и так далее.
Tech Lead не стоит над проектом. Это просто ключевой технический человек в конкретной команде девелоперов или маркетологов или QA. Над проектом стоит архитектор.Lead Developer это вообще не позиция, ну по крайней мере не самая популярная
ssmaslov
24.03.2024 15:29+3Это вы что то свое придумали. Уж кто не стоит над проектом так это архитектор. Информация 100%, поверьте мне как выпускнику эпам архитект скул и руководителю службы архитекторов в компании с ИТ штатом в примерно 1000 человек (уже нет, но был такой этап карьеры в прошлом).
saboteur_kiev
24.03.2024 15:29Поверьте человеку, который работал в компании со штатом в десятки тысяч сотрудников, где архитекторы это кроме позиции еще и отдельные права во внутренних системах. Именно архитекторы следят за стеком технологий, лицензиями, и вообще итил.
kazimir17
24.03.2024 15:29+40А поделитесь секретом, как вам удается писать код когда в день 4 созвона на 3 часа с зазором в 30 минут + вопросы в чате которые нужно порешать + поправить какой-то конфиг + исследовать проблемы на стенде + еще всякая мелочевка. У меня не получается вот никак.
ermadmi78 Автор
24.03.2024 15:29+10Вот именно по этому я и начал задумываться об уходе на пенсию ;)
vkni
24.03.2024 15:29Кмк, сама по-себе, жёсткая структура не очень хорошо отражает краткосрочные софтовые проекты. Вот у нас в текущей группе ТЛ и 3 рядовых сеньора; при этом проекты ведут сеньоры. Соответственно, если кто-то выполняет часть чужого проекта, он должен переподчиниться временно, что ли? Очевидно, что ведущий проект обладает большей компетенцией по проекту, чем временный помошник. Но через месяц будем подтягивать другой проект, там будет другой ведущий.
ssmaslov
24.03.2024 15:29Именно так у меня организовано. Я лид у группы в примерно 50 человек среди которых и формируются команды, причем в разных задачах главным в рамках задачи становится тот кто в конкретной задаче, вчерашний главный в другой задаче может стать подчиненным, в том числе синьор у джуна, и никаких проблем
AirLight
24.03.2024 15:29+5Вот кто главный в описываемых Вами командах, те и тимлиды, а если под вами несколько таких команд, то вы не тимлид, скорее тимлид тимлидов, но более правильное название Engineering Manager.
vkni
24.03.2024 15:29Обычно нижняя структура фиксируется, при этом менеджер нижнего уровня называется Team Lead по традиции. Некоторое время назад это был «играющий тренер», «первый среди равных», но сейчас это всё больше и больше вырождается в менеджера среднего звена. При этом проекты падают на сеньоров, которые и организуют что-то гибкое, как вы описываете.
Gradiens
24.03.2024 15:29+2как вам удается писать код когда в день 4 созвона на 3 часа
Ну вы сами обозначили то, что съедает основное время.
А все ли эти созвоны являются обязательными для вашего проекта? Точно нельзя их пропустить?
А можно сделать покороче то, что пропустить нельзя? Концентрироваться только на важном. Не отступать от агенды. Все, что вылезло, не обсуждать сразу же, а запарковать и (возможно) поручить другим людям.
Ок, допустим все важно и короче сделать нельзя. Тогда делегируйте.
Это тех встреча? Делегируйте синьору или системному аналитику или архитектору. Потом за 5-10 минут он вам расскажет все о чем договорились на часовой встрече.
Это бизнес встреча? Делегируйте бизнес аналитику.
Вам некому делегировать? Растите спецов в команде.
Если вы и БА и СА и архитектор и менеджер и еще конфиги правите - ну, не удивительно, что времени не хватает.
Делегирование - наше все!
kazimir17
24.03.2024 15:29Хороший план, если я все делегирую то работы останется на пару часов в неделю, кто б мне еще за это полную зарплату платил, эх. PS. Написание кода я делегировал в первую очередь)
Gradiens
24.03.2024 15:29+5Если вы успешно все делегируете без потери контроля и производительности - то вам не просто зп будут платить. Вас повысят, чтобы вы масштабировали опыт и принесли больше пользы.
Пока на вас завязаны все процессы - никто вас не повысит. Ведь вы не вырастили никого, кто вместо вас сможет по 3 часа в день совещаться и все разруливать.
LeVoN_CCCP
24.03.2024 15:29Вы знаете, этому сильно помогает таймзона. Я понимаю, что для многих это не вариант, просто как факт. У меня пересечение с основным контингентом в компании примерно 3-3.5 часа в день, и впихнуть 4 созвона на 3 часа (это кстати любовь исключительно отдельных людей такое кол-во времени) это уже не моя проблема. Плюс все чаты и почта это примерно 2-2.5 часа в день (не просто прочитать-ответить, а ещё проанализировать и понять).
Да, мне становится проблема, когда мне надо минут 15-20 от человека, чтоб найти у себя свободные эти минут в периоде 3-3.5 часа и одновременно у человека который мне нужен.
Кстати подобное заметил не только я, у кого подобное пересечение.
Редактировано: Дополнительно что вспомнил, некоторые люди в своём календаре забивают по 2-4 часа в день на "само-митинг" и делают в эти часы что они хотят сделать. В принципе тоже самое что и разница в таймзоне.
botyaslonim
24.03.2024 15:29Очень просто. Садишься и пишешь, когда есть свободные 15 минут. Один из навыков тим-лида - уметь постоянно переключаться между задачами
bungu
24.03.2024 15:29+23Я тимлид и не пишу код как минимум 3 года. Я нанял достаточно хороших разработчиков в команду чтобы они это делали.
Если вы не пишете код, то утрачиваете техническую квалификацию. А если вы не обладаете технической квалификацией, то по-факту вы не являетесь тимлидом
Так я хочу дальше в CTO расти. Нахрена мне этот код нужен. Руководство хочет результаты - они их получают, а кто там писал код им уже нкиакой разницы нет.
Если вы не пишете код, то утрачиваете техническую квалификацию.
Да и хрен с ним. Я хочу решать высокоуровневые задачи, например, найти разработчика на рынке труда. Если захочу код написать то лучше pet-проект сделаю. Простите, но всю жизнь писать код я не планировал.
Count_s
24.03.2024 15:29+2CTO который забыл как писать код - так себе CTO в софтверных компаниях. Как минимум не надо забывать навыки чтения)
ris58h
24.03.2024 15:29+2Зачем CTO читать код, если у него не синдром Илона Маска? Чтобы что?
santa324
24.03.2024 15:29+1Что бы понимать где херню делают а где хорошо работают. Иначе не понятно зачем в его должности буква Т. И не вижу ничего плохого равняться Илона.
Индустриия ещё не придумала объективных метрик качества, которые бы позволяли оценить код без его чтения.
ris58h
24.03.2024 15:29Вы можете привести пример того, как это по-вашему должно происходить на практике? CTO выбирает случайный комит из десятков (а то и сотен или тысяч) за день и смотрит насколько хорошо код оформлен?
santa324
24.03.2024 15:29+1Когда у какой-то команды что-то долго не получается, хотя ему кажется что там все должно легко быть, он залезает в код и пытается понять смог бы он сам это сделать, если нет то почему и т.п. А лучше даже заранее иногда посматривать, что-бы упредить такое развитие ситуации.
А дальше делает выводы о компетенциях тех кто эту часть системы проектировал и разрабатывал. Если архитектура г. - значит техлид той команды слаб. Если архитектура норм, но реализация компонентов паршивая - значит команда не может набрать нормальных разрабов (или управлять ими). А может у них все хорошо - но какая-то смежная команда насоздавала проблем в связанных частях системы и из-за этого все плохо.
unreal_undead2
24.03.2024 15:29CTO выбирает случайный комит
Нет, CTO скорее решает, какие языки использует и поддерживает организация (и, скажем, в какие комитеты по стандартизации стоит войти), а для этого читать код (необязательно написанный в самой организации) всё таки стоит.
bungu
24.03.2024 15:29+1Вы и автор что-то слишком драматизируете. Я 10 лет не писал на PHP, но вполне себе бегло могу просмотреть код. Так что потеря навыка после нескольких лет разработки мне кажется это вообще из области нереального
ssmaslov
24.03.2024 15:29+1Я не совсем такой (но действую так же). Мне тупо нравится писать код, я это делаю. В нерабочее время. В рабочее делаю как и Вы
Yuriy_75
24.03.2024 15:29+2>>Руководство хочет результаты - они их получают, а кто там писал код им уже нкиакой разницы нет.
По сути, вы занимаетесь "продажей" руководству результатов труда разработчиков.
bungu
24.03.2024 15:29По сути, вы занимаетесь "продажей" руководству результатов труда разработчиков.
Вероятно так и есть. Конечно руководство еще беспокоят такие моменты как атмосфера в коллективе, профессиональный рост сотрудников и прочие плюшки, которые есть в IT-компаниях
iago
24.03.2024 15:29+2тут вопрос терминологии. Вы себя называете тим лидом, хотя по сути являетесь менеджером среднего звена, пришедшему из программирования. И, т.к. воспоминания об основной профессии в вас еще слишком свежи, вы хотите называть себя тимлидом и "первым среди равных", хотя равным уже, скорее всего, не являетесь, и чем дальше - тем больше будете отдаляться от разработчиков, терять с ними общий язык, и уходить в мир бордов, карточек и отчетов.
Ни в коем случае не осуждаю этот выбор, все профессии нужны, и если вы успешно справляетесь со своими задачами, руководство вас ценит и т.п. вы приносите пользу бизнесу - значит так и нужно, но я бы все же назвал вашу позицию не тим лидом, а <выберите удобную приставку> менеджером
panzerfaust
24.03.2024 15:29+20Если сохраняет возможность писать качественно - пусть пишет. А если это уже входит в конфликт с менеджерскими обязанностями, то лучше не надо. Я как-то за карьеру уже наелся этих приколов: типа тимлид там наговнякал какую-то идею в коде, а ты иди доводи до ума. Сделано наспех - сделано на смех. Возьми лучше и задачу в трекере грамотно распиши, чем говнокодерством заниматься.
ermadmi78 Автор
24.03.2024 15:29+5Тут уже тимлиду в какой то момент необходимо принять решение о том, куда ему дальше развиваться. Либо идти по пути классического карьерного роста в сторону менеджмента среднего звена и дальше в топ менеджеры. Тогда надо переставать писать код, переходить на позицию менеджера проекта, и на своё место ставить толкового паренька из команды. Либо начать расти "вширь", и углублять техническую квалификацию. Тогда нужно выбить на проект этого самого пресловутого менеджера проекта, и всю менеджерсую баламуть спихнуть на него.
panzerfaust
24.03.2024 15:29+1Тогда нужно выбить на проект этого самого пресловутого менеджера проекта, и всю менеджерсую баламуть спихнуть на него.
Так музыку-то не тимлид заказывает. Мелкие и средние компании просто не тянут сразу 2 ставки эксперта и менеджера проекта. Отсюда и все эти "играющие тренеры".
bungu
24.03.2024 15:29Отсюда и все эти "играющие тренеры".
Последнее время часто вижу этот термин в вакансиях. Обычная экономия. Так же сейчас ищут разработчика и девопса в одном лице и тп
ermadmi78 Автор
24.03.2024 15:29+6Мелкие и средние компании просто не тянут сразу 2 ставки эксперта и менеджера проекта. Отсюда и все эти "играющие тренеры".
В реальности дело обстоит ровно наоборот. "Играющий тренер" - это очень справедливое и выгодное предложение.
Вот как вы думаете, что происходит с проектом (если он не разваливается конечно), когда тимлид уходит в секретарши, и перестает выполнять все те функции, которые я описал в статье?
А происходит следующее. Один или несколько инициативных разработчиков берут эти функции на себя. И по факту получается, что такой инициативный разработчик продолжает на 100% тянуть лямку разработчика а вдобавок неофициально тянет лямку тимлида. А, так так официальных полномочий у него нет, ноша тимлида оказывается раза эдак в 2 тяжелее обычной. Т.е. получается, что он за ту же самую зарплату работает за троих. А потом секретарша просыпается, вспоминает, что она таки тимлид, и начинает бить этого самого инициативного разработчика по рукам.
Разработчик весь этот балаган какое то время терпит, а потом просто увольняется и идет уже на официальную позицию играющего тренера. И там он уже может вздохнуть с облегчением. Выкладываться на 100% как разработчик не надо, можно тратить 50% времени на разработку. Полномочия тимлида официальны, партизанить не надо, в подполье прятаться не надо, соответственно функции тимлида начинают выполняться легко и играючи. Плюс чисто психологически проще - никто тебя не пресует и не бьет по рукам. Вот и получается, что за зарплату 1.5x такой разработчик начинает работать в 3 раза меньше да еще и в комфортной психологической обстановке.
sci_nov
24.03.2024 15:29+18Должен ли Линус Торвальдс писать код, да еще и низкоуровневый?
Должен ли заведующий кафедрой преподавать?
Должен ли Илон Маск подавать молоток рабочему, если он его попросит ненароком?
Думаю, зависит от сочетания желания и нагрузки.
А так, если опыт был приобретен, то Team Lead должен скорее читать код, чем писать. Читать документацию, следить за развитием технологий. Составлять документацию по проектам. Писать код - отдельная работа, требующая много времени. Пилить свои задумки в фоне, ставить микро эксперименты - почему нет, что-нибудь да и пойдет в продукт, не сейчас, так через год-два.
Итого: если Team Lead не пишет продуктовый код, ничего страшного.
Gradiens
24.03.2024 15:29+3Должен ли Линус Торвальдс писать код, да еще и низкоуровневый?
Да, если хочет остаться Линусом Торвальдсом
Должен ли заведующий кафедрой преподавать?
Хотя бы иногда, если не хочет остаться чисто администратором.
Должен ли Илон Маск подавать молоток рабочему, если он его попросит ненароком
По-настоящему - ни в коем разе, если хочет остаться Илоном Маском! Для PR - можно.
iago
24.03.2024 15:29+1да кому нужны будут эти "задумки в фоне", от человека, который не занимается разработкой, тем более через год-два. Пошли в менеджмент - идите до конца.
Торвальдс ценен именно как программист и визионер низкого уровня, если бы в 90-х годах он стал менеджером линукса, то в 2005 не родился бы Git.
dyadyaSerezha
24.03.2024 15:29+6Если вы не пишете код, то утрачиваете техническую квалификацию. А если вы не обладаете технической квалификацией, то по-факту вы не являетесь ...
Эта логика должна работать вплоть до СТО или как? Где граница?
ermadmi78 Автор
24.03.2024 15:29+4Очень хороший вопрос. У меня, к сожалению, нет на него ответа. На мой взгляд CTO - это вообще растрельная позиция. С одной стороны нужно обладать широкими (но, часто не глубокими) техническими знаниями. C другой стороны, поддерживать себя в форме, продолжая писать код, на такой позиции скорее всего нереально.
Я поэтому всегда осознанно отказывался от позиций такого уровня. Потому что просто не знаю, как на них выживать. Если найдутся люди, которые поделятся своим опытом выживания в роли CTO, то будет просто замечательно.
denis-isaev
24.03.2024 15:29+5CTO - обычный манагер, который знает непонятные другим манагерам технические термины, может на хабре их встретил, а может они родом из 80-х - времени, когда он еще был разработчиком и писал код :)
// шутка юмора
Gradiens
24.03.2024 15:29+2Граница там, где вы перестаете работать с непосредственными исполнителями.
Начальник должен хорошо понимать работу исполнителя. Быть в контексте. Уметь (может лучше, а может хуже - вопрос дискуссионный) делать эту самую работу.
Когда вы MoM, то есть в нашем случае менеджер лидов, вам нужно понимать работу лида. Код для этого не нужен
dyadyaSerezha
24.03.2024 15:29+1То есть, стратегически планировать и всё такое, по сути не зная технологий, а лишь читая полупопулярные обзоры и хвастливые презентации?
Zenitchik
24.03.2024 15:29+29Судя по комментариям, тимлидом в разных компаниях называют СИЛЬНО разную сущность.
AllexIn
24.03.2024 15:29+1Да в целом с грейдами и позициями все очень плохо. Нет устоявшейся терминологии и требований для соответствия.
Есть компании где на полном серьезе рассуждают, что 3 года и уже сеньор, есть где если у тебя за плечами нет 10 лет и минимум КН - ты едва можешь претендовать на мидла.
Xantorohara
24.03.2024 15:29+11Написание кода - это удивительный и чарующий процесс.
Особенно когда всё уже делается на автомате, независимо от языка. Руки пишут всё сами, а глазам остаётся только делать код-ревью. Предполагаю, что у автора это так и получается.
Для тимлида написание кода может быть вообще одним из немногих доступных видов отдыха после бесконечных созвонов-митингов-плэнингов.
Miller5275
24.03.2024 15:29+2Надеюсь, не придется столкнуться с ситуацией как в нашем сельском хозяйстве: в 90 и 0 хлынули военные (ведь они управляют подразделениями, значит и предприятием смогут!) ну как бы так себе идея. Потом ближе к 10 началось полицейско-милицеское нашествие, основная тема- контроль (всего на свете). Сейчас пришли банкиры и прокуроры, даже актеры и журналисты и все это не рядовые позиции, это менеджмент, это замы и генеральные. Я к тому , что руководитель должен быть в теме, он может и не писать код, но знать отрасль и как устроены языки (чем например Питон от С# отличается или от 1С) он должен. Это мое мнение.
gleb_l
24.03.2024 15:29+7Я недавно сформулировал для себя правило эффективного найма независимо от роли - фактически из мира схемотехники. Есть пассивные и активные элементы. Активные обеспечивают выполнение бизнес-задач, а пассивные выполняют согласующие, демпфирующие и стабилизирующий функции. Так вот, применение активных элементов в схеме должно быть оправдано - человек в соответствующем месте должен принимать решения или действия, модуль денежного эквивалента которых многократно превышает стоимость его рабочего времени для компании за тот же период. То есть, если ты - транзистор, то твой h21 должен быть >> 1.
iago
24.03.2024 15:29+2вот как технарь может разложить все по полочкам из мира, где если сделать неправильно - просто не будет работать (в отличие от менеджмента). А если технического бэкграунда нет, они этого даже не понимают
makcumka2000
24.03.2024 15:29+1Как выше уже было сказано - роль тимлида сильно зависит от компании. Где то это просто техлид, где то занимается people менеджментом, где то отвечает за зарплаты, где то является solution архитектором, у кого-то в подчинени 5 человек, у кого-то 35. И вот от набора этих самых является и зависит должен ли тимлид писать код или нет.
У нас в компании считается что тимлид не должен писать код при этом если он его пишет - это не возбраняется, но лишь при условии что остальные «обязательные» активности не страдают.
Сам я с мнением автора насчет потери квалификации не согласен, вполне можно регулярно читать код своей команды и оставаться «в тренде», выполняя функции технического менеджера.
kinall
24.03.2024 15:29+1Как-то интересно у вас получается, чёрно-бело: как только человек перестал писать код, он сразу же "выпадает из темы", теряет квалификацию, забывает весь свой бэкграунд, разучивается понимать трудоёмкость...
Но это же, простите, глупость. Вот я тимлид. Я писал когда-то на фреймворке версии 7.3, потом стал тимлидом, после этого моя команда перешла на тот же фреймворк, но версии 8.1. Если я сейчас полезу писать код, то я однозначно наговнокодю, потому что я буду писать в привычном стиле (для версии 7.3). Поэтому я код не пишу. Вопрос: почему в этой ситуации должны пострадать все те навыки, что вы перечислили - в любом из ваших списков?
ermadmi78 Автор
24.03.2024 15:29+1Ну, я намеренно написал статью в несколько провокационном стиле. У вас есть полное право не соглашаться с моим мнением. Но, я надеюсь, что благодаря моей статье вы задумаетесь, и сами себе зададите вопрос - "А правильной ли дорогой я иду? Это точно то, чего я хочу от этой жизни?" На этот вопрос тоже нет правильного или неправильного ответа. Просто возможно вам этот вопрос поможет понять, что вы свернули куда-то не туда. И вовремя исправить ошибку. Или наоборот - окончательно убедиться в том, что выбранный вами путь лично вам хорошо подходит.
uuger
24.03.2024 15:29+2писал когда-то на фреймворке версии 7.3, потом стал тимлидом, после этого моя команда перешла на тот же фреймворк, но версии 8.1.
Гораздо хуже, если бы это был "фреймворк" версии 7.7 и переход на 8.3
iago
24.03.2024 15:29+1тонко, не все поймут, только кому за 30-35, но мне лично вы настроение здорово подняли!
Gradiens
24.03.2024 15:29Вы же сами пишете, что после перехода команды на новый фреймворк наговнокодите. Значит, квалификация устаревает. И забывается. Да, не за день. И не за год. Бэкграунд просто так не пропьешь.
Но в любом случае, с течением лет, технические навыки пострадают. Взамен разовьются другие навыки. И это - нормально
kinall
24.03.2024 15:29Значит, квалификация устаревает. И забывается.
Квалификация как разработчика - да, конечно. Как тимлида - нет, по крайней мере, судя по спискам из статьи.
Gradiens
24.03.2024 15:29+1Парадокс жизни заключается в том, что 80% вакансий хотят тимлида с прокачанными хардами. И не просто прокачанными, а еще и современными. Чтобы и "тим", и "тех" в одном флаконе.
Хотят на такую позицию, на которой эти самые харды растеряешь, погрязнув в бизнесе - административке - пипл менеджменте.
nskidanov
24.03.2024 15:29+4эта ситуация возникает, когда в компании нет возможности расти, не становясь менеджером. когда заколочена установка, что надо быть начальником, чтобы прибавлять в зарплате. так хорошие программисты, которым нравится писать код, становятся плохими менеджерами, потому что обнаружили что от секса заводятся дети и ипотека. тогда TeamLead будет фокусироваться на постановке задач, контроле и улучшении процессов, а TechLead будет совершенствоваться в технических высотах. Хорошей практикой, которую стоит перенять у зрелых компаний, является практика высоких корпоративных грейдов для крутых спецов - вплоть до ранга вице-президентов с соответствующей зарплатой
muxa_ru
24.03.2024 15:29А можно начать текст с определения термина тимлид?
А то может это как с "котлета", которую в России понимают по одному, а во Франции - по другому?
serverbay
24.03.2024 15:29Нет хуже обиженного программиста, чем программист, которому 46 лет... очень жаль, что вам попался такой тимлид, который не научил уважать себя, свою сферу деятельности и своего тимлида. Если ваш текущий тимлид вас не устаивает, то найдите другую работу.
aGGre55or
24.03.2024 15:29Не просто должен, а обязан. Это синонимично старой песне про микроменеджмент: понабирают по объявлениям велеричивых читателей книг про успешный успех в плохом переводе с ангельского и они начинают рассказывать бизнесу, что руководитель не должен ничего делать сам т.к. это убивает его эффективность. Пока у компании есть деньги, чтобы руководители водили руками - это длится, но затем оказывается, что для "убийства эффективности" надо чтобы было что убивать. А "убивать" уже нечего. Никто вообще не понимает что и как работает. И даже: работает ли хоть что-то - тоже)))
Yuriy_75
24.03.2024 15:29>>Почему секретарша является самым дорогим ресурсом в команде?
Очевидно, потому что эта секретарша общается с вышестоящим начальством.
netch80
24.03.2024 15:29+1С точки зрения типов профессионального роста, программисту расти до начальника обычно смысла нет - он растёт квалификационно, в лестнице не поднимаясь выше того же техлида (хотя сколько человек подчиняются его решениям, не определено - могут быть и миллионы).
Зато для QA карьера до тимлида и выше - самое оно: сохраняя принципиальную техническую компетентность, он её только улучшает от такого роста. (Разумеется, если это грамотный разносторонний QA, а не просто тестер.)
Для принятия принципиальных решений вроде какую архитектуру выбрать - у него есть возможность заслушать разных экспертов. Так работает уже давно за пределами IT, где не важно, например, что начальник подразделения может не знать сам какие-нибудь параметры твёрдости конкретной марки стали.
kasiopei
24.03.2024 15:29+4Понабрались англицизмов и запутались в них. Тимлид это просто начальник. Когда управление меняли на менеджмент всем ясно и четко объясняли что начальником может быть дурачок. Самое главное чтобы он не импровизировал и действовал по выданному скрипту. Многие приняли правила игры, а многим здравый смысл не дает покоя.
По логике компетентность в области падает с ростом должности. Директор может быть нулем в технике. Мне не повезло увидеть человека умного в технике и управлении одновременно. Возможно такие есть, но те что видел лажают из-за профдеформации. Во всяких НИИ начальство выбиралось из инженеров. При госплане они делали что требовалось. Когда сказали "крутитесь сами" оказалось что найти заказ и организовать продажи не способны. Все держится только на связях в оборонке. Влезть в гражданский рынок не способны. Например было все чтобы создать свои мобильники. Потом пришли аффективные менеджеры и лучше не стало. Какая там должна быть золотая середина не знаю. Может быть есть целые науки про это, но в моем пузыре признаков их существования не наблюдаю.зы. Судя по комментам у многих карго культ :-)
gandjustas
24.03.2024 15:29+1Классическая путаница.
Тимлид должен уметь писать код, но совершенно необязательно должен писать код для проекта, командой которого он руководит. По моему опыту наличие 7+ программистов уровня middle в команде приведет к тому, что тимлид вообще перестанет код писать.
Тимлид обязательно должен читать код, чтобы понимать что делают его подчинённые.
Тимлид, очевидно, должен поддерживать квалификацию, чтобы его умение писать, читать и понимать код не устарело. Поэтому очень даже неплохо если тимлид таки пишет иногда код своего проекта, иначе ему придется еще как-то в нерабочее время поддерживать квалификацию.
Единственный вариант тимлиду не писать код, если он за время устаревания навыков разовьет менеджерские скилы настолько, что перескочит на следующий уровень - тимлид-тимлидов или как он там называется.
0serg
24.03.2024 15:29Чисто теоретически за качеством кода может следить техлид. Для понимания того что один человек в команде быстро решает выделенные ему таски а у другого это все очень сильно затягивается, как и оценивать уложится ли исходя из этого команда в дедлайн или нет технические подробности тимлиду знать не обязательно. Но на практике конечно способность читать код и разбираться в том как таски формируются тимлиду помогает очень сильно.
gandjustas
24.03.2024 15:29Не понимаю в чем функция тимлида, если есть еще и техлид. А если есть еще ПМ, ПО, начальник отдела и еще куча менеджеров, то тем более.
Я наверное слишком стар, но все еще живу по модели команды, описанной Бруксом - "бригада хирургов". В ней есть главный хирург (тимлид), который отвечает за успех операции в целом, несколько специалистов в своих областях и медсестры, которые подают инструменты и накладывают повязки.
При этом бригада не выбирает сама кого лечить и от чего лечить. Хотя главный хирург (тимлид) может быть также лечащим врачом (архитектором решения), а может и не быть.
0serg
24.03.2024 15:29Если брать PAEI модель менеджмента Азидеса, то менеджмент сводится к четырем вещам
Producer - способность добиваться результата. Руководитель понимает куда команда должна идти, какой результат должен получиться и добивается его
Administrator - организация процесса разработки. Сколько времени займет процесс разработки? Сколько человек понадобится? Сколько мы в прошлый раз сделали? Каких правил мы придерживаемся?
Entrepreneur - генерация идей. Что нужно бизнесу? Что хотят потребители?
Integrator - организация людей в команду. Как разрулить конфликт между парой девелоперов? Кто нуждается просто в похвале а кому надо дать денег? Если Вася пришел с вопросом X то кто может на этот вопрос ответить?
Любой менеджер должен в какой-то мере уметь все четыре вещи, но он в принципе не может быть сильным во всех четырех. Поэтому надо иметь несколько типов менеджеров, каждый из которых отвечает лишь за часть из вышеописанных направлений. Вместе они будут работать наиболее эффективно. И тут довольно естественным решением является вытащить P и E на уровень компании в целом. А тимлид соответственно - это тот кто возьмет на себя функции A и I.
То есть
менеджер говорит что нам для компании надо бы сделать продукт X
техлид говорит что для этого возьмем технологию Y и сделаем последовательность шагов 1,2,3...
тимлид вместе с техлидом превращает эти шаги в таски для разработчиков и исходя из прошлого опыта оценивает время потребное на каждую таску и число нужных людей / время на общую разработку
-
дальше тимлид пинает разработчиков чтобы они соблюдали установленные правила, ведет документацию по проекту, следит за тем чтобы статус тасок отражал реальное состояние дел, оценивает то укладывается команда в срок или нет, поднимает тревогу если возникают проблемы, объясняет к кому обратиться за помощью, выставляет оценки работе индивидуальных разработчиков и т.д.
В общем административная деятельность и поддержка.
gandjustas
24.03.2024 15:29Натягиваете сову на глобус. Тимлид это не "менеджер", "менеджер" это примерно на два уровня выше. Тимлид решает очень частную задачу - как сделать так, чтобы все члены команды "гребли" в одну сторону с максимальной эффективностью.
0serg
24.03.2024 15:29Ну так я не вижу тут противоречия. Тимлиду и его команде спускают список задач сверху, он просто следит за тем чтобы они выполнялись и обеспечивает поддержку сотрудникам. Техлид же и прочие менеджеры относится к тем кто эти задачи ставит, корректирует и принимает решение выполнены они или нет.
ssmaslov
24.03.2024 15:29Это Ваша терминология про уровни или откуда то? У нас в компании около 15 тыс штатных сотрудников. Я тимлид, у меня уровень ГД -2. То есть, между мной и генеральным директором есть только один промежуточный слой. Есть и по другому, но примерно такую же иерархию я видел в нескольких крупных компаниях. Тимлид для 5-10 человек для меня выглядит как нонсенс.
gandjustas
24.03.2024 15:29А сколько людей у вас в подчинении?
В понимании текущего рынка труда тимлид в ит - это руководитель небольшой команды, без функций управления бюджетом и стратегией.
DikSoft
24.03.2024 15:29+1Ситуация с терминологией сильно напоминает ту, что сложилась у инфраструктурщиков.
Раньше системный администратор был синонимом гуру глубин систем, нынче - синоним эникейщика.
Ну и выше тоже пошла фигня полная с названиями, системный инженер, руководитель группы, архитектор... И это в эксплуатации, а если ещё и разработку взять, то там вообще ад полный. Куча смежных ролей , определение которых позволило массе дилетантов влиться в процесс, под вывеской всяческих xxx-Ops-ов.
Miroslavskiy
24.03.2024 15:29+4Я считаю, что тимлид просто обязан быть технарем, иначе он не сможет ни корректно задачи поставить, ни оценить трудозатраты, ни подобрать кадры, ни обучить подчиненных. По моему опыту, идеальный тимлид, это тот, которые некоторые тех задачи делает сам, но не для того, чтобы сделать что-то за подчиненных, а чтобы быть в курсе актуальных изменений, не терять квалификацию.
Если говорить про технического директора, генерального директора, то конечно они должны заниматься только руководящей деятельностью. Но самые лучшие на моей практике директора это те, кто сам начинал с азов, сам ручками все делал. Тогда он не ставит бессмысленные задачи, типа сделать за 2 часа то, на что нужна неделя.
dymov_alex
24.03.2024 15:29+3Давайте начнем с того, что в разных компаниях разные требования к позиции тимлида:
кто-то считает, что это руководитель группы разработчиков
кто-то считает, что это руководитель группы сотрудников, среди которых есть аналитики, разработчики, QA и тд.
кто-то называет тимлидом главного разработчика
кто-то называет тимлидом руководителя IT
кто-то считает, что тимлид еще и в бизнес должен уметь
И, в зависимости от того, кто где работает, смотрит на позицию через призму своих процессов.
В моём идеальном мире тимлид - это руководитель группы разработчиков, он пишет код и управляет своей командой, в том числе декомпозируя задачи, проверяя код перед релизом и тд. И повышает скилы своей группы.
Он не занимается планированием дальше, чем на 1-2 спринта, он не нанимает разработчиков, хотя участвует в собеседовании, не умеет в бизнес и даже, практически, не ходит на совещания.
В его группе несколько профильных разработчиков, не больше 10. Он не выбирает задачи на команду, а получает их сверху
RichardMerlock
24.03.2024 15:29+4Карабас-Барабас никогда не стремился играть на сцене, но директором театра был крепким.
Gradiens
24.03.2024 15:29+2Так он не был тимлидом. Он был РП, который методом кнута собрал аджайл-команду. Без тимлидов.
Но даже в сказках оно так долго не работает. Если я правильно все помню,
тимлидБуратино увел команду и основал свой театр с блек джеком и Мальвиной.
vvzvlad
24.03.2024 15:29Но даже в сказках оно так долго не работает. Если я правильно все помню,
тимлидБуратино увел команду и основал свой театр с блек джеком и Мальвиной.Не было бы у них “наследства” в виде своего театра — хрен бы он куда кого увел и что-нибудь основал
Gradiens
24.03.2024 15:29Хронологически, сначала он все-таки сколотил свою
кукольную бандукоманду. Которая прошла шторминг-норминг по Такману. Проник во внутренний круг влияния по Берну. И не грубой силой (попрбуй на Артемона повыделываться), а личными качествами.Наследство - оно уже потом образовалось.
vvzvlad
24.03.2024 15:29И что бы он сделал с командой без театра и оборудования?
Gradiens
24.03.2024 15:29Хз. Может, выступал бы на ярмарке под звуки шарманки. Не принципиально.
Главное то, что команду-то он собрал.
muxa_ru
24.03.2024 15:291) Он команду не собрал, а увёл готовую
2) Не факт что эта команда согласилась бы выступать по ярмаркам, а не уйти в другой театр.
RichardMerlock
24.03.2024 15:29Папу Карло он знал очень хорошо. И, видимо, на заре карьеры был совсем другим, имел ключ и вёл интересные разговоры с Тортиллой 300 лет назад. Но со временем испортился, а с этого момента и начинается повествование.
fndrey357
24.03.2024 15:29В команде должны быть человек или люди, которые держат нервную систему других людей. Бытовые вопросы, не заставлять делать, то что не умеет или хуже получается, банальный контроль настроения и т.д.
Большинство из них перекидывают на королеву сплетен и интриг - секретаршу. Она и вовремя подскажет не наезжать на Васю, поддержит Машу, при этом не особо вмешиваясь в техпроцесс.
Собственно говоря и снимая с тимлида мелкие обязанности по поддержанию нервной системы сотрудников.
Бывают, конечно крайние случаи, когда не так, но в принципе моделька распространённая.
karon
24.03.2024 15:29То, что вы хотите видеть как тимлида, скорее сеньер которому поставили задачу создавать и двигать таски в JIra. Это не Тимлид
MAXH0
24.03.2024 15:29Почему секретарша является самым дорогим ресурсом в команде?
Иначе начнется разврат!
Batalmv
24.03.2024 15:29Полностью соглашусь с
Если вы не пишете код, то утрачиваете техническую квалификацию. А если вы не обладаете технической квалификацией, то по-факту вы не являетесь тимлидом.
В реальности тут нечего обосновывать, так как это очевидно :)
А вот некоторые моменты ниже спорны:
Вы не можете нанять инженера, так как вы не в состоянии оценить его квалификацию.
Легко, поверьте. Дело в том, что проверить знания намного легче, чем их иметь. Но тут скорее надо иметь общие знания, а не детальные
Вы не можете поставить задачу инженеру, так как вы не можете её сформулировать
Вот это еще легче. БА ставит бизнес таску на ура, а технически задачу может поставить архитектор. А QA проверит выполнение с их помощью
Ну и т.д. Просто знание на общем уровне + понимание процессов + понимание что надо творит чудеса. Задача тимлида как раз в том, чтобы ревьють, коучить, организовывать на своем уровне.
Как бы так сказать. Задача тимлида в первую очередь делать свою работу и отвечать за результат команды. А попытка распыления - это хорошо, если это реально делать больше некому. Но не стоит думать, что смежные задачи может делать только тимлид
iago
24.03.2024 15:29+3чем меньше вы понимаете в предметной области (а с годами непрограммирования этот скилл будет только расти), тем сложнее вам будет делать вами же перечисленные задачи. Коучить там и все что вы написали. Кого вы там будете коучить, чему, если ваша работа - это созвоны и карточки. Можете коучить тому, как карточка уходит из Planned в In progress.
По моему субъективному опыту, нет хуже начальников, чем "я 10-15 лет назад тоже кодил, я программист, там все просто, а еще Дельфи знаю, где кстати делся Silverlight"
Batalmv
24.03.2024 15:29+3чем меньше вы понимаете в предметной области (а с годами непрограммирования этот скилл будет только расти), тем сложнее вам будет делать вами же перечисленные задачи.
Я ж вроде написал, что полностью за то, что тим лид должен писать код, причем на самом верху :)
если ваша работа - это созвоны и карточки
Опять же, ваша работа - "результат команды". Это очень важно понимать. Если тимлид тонет в созвонах и карточках - он просто не очень хороший тим лид, вот и все. Либо на него повесили очень много не его работы, а он взял и несет.
Тимлид обязательно должен кодить, но вот найти баланс - это и есть часть работы. Возможно стоит брать разные задачи, чтобы не терять навык в мелочах, а также сложные задачи, чтобы смотреть вперед. Карточки вообще двигаюют исполнители, причем тут тимлид. Колы - часто это отличное время поработать :)
iago
24.03.2024 15:29с этим Вашим комментарием я соглашусь на 100%, возможно не уловил посыл изначального. Тормознул с ответом в комментарии, плюсанул в карму
botyaslonim
24.03.2024 15:29+1Всё верно написано. Но справедливости ради: где вы в России видели тим-лида, который вообще не пишет и не понимает код? Как по мне, у нас проблема ровно обратная: у нас самому пашущему программисту обычно вручают должность тим-лида, без чёткого понимания последним, какие функции предполагает эта работа. Либо с пониманием, но без ресурсов в виде времени/власти/денег
unreal_undead2
24.03.2024 15:29вручают должность тим-лида
Вопрос как именно "вручают" - что при этом меняется в трудовой (как там вообще по русски пишется "тим лид"?) и формальном списке должностных обязанностей? Просто всегда работал в компаниях с явно выделенными менеджерами (начиная от команд человек на 7-10) и что такое "тим-лид" не очень представляю.
Zenitchik
Т.е. они предлагают переименовать тимлида в техлида, а тимлидом называть разновидность манагера? Зачем?
nameless323
Так вроде давно уже так (по крайней мере в Сев Америке).
Team lead - буквально руководитель команды - кому какие таски, организация процессов в тиме, переводить с чистого менеджерского на язык команды и наоборот, контроль над выполнением/оценкой, и т.д. Фактически менеджерская позиция где понимание теха пригодится, но вот не прям особо критично.
Tech lead - буквально лид теха - человек в тиме который ответственный за то в какую сторону будет развиваться тех, формулирование тасков, помощь с разруливанием тех вопросов и т.д. Фактически высшая техническая должность в команде.
IvanPetrof
Руководитель - букв.
разВодитель руками?Имхо, не всегда смысл понятия отвечает своей дословной расшифровке
nameless323
Что то мне подсказывает что это буквально "водитель за руку", но если например взять дирижеров, то они реально водят руками и управляют оркестром (хотя оно от фр. diriger).
IvanPetrof
Я про это и говорю. Когда-то это был "водитель за руку". Сейчас в буквальном смысле за руку не водят (вот прям в буквальном), а термин остался.
Хотя, возможно, в современном мире руководитель это на самом деле "водитель руками". Т.е. "дирижёр". Его работа указывать (не всегда руками) правильное направление))
Ivan22
и не только в США, во всех западных современных компаниях, за тех.решения отвечает техлид (за архитектурные кстати архитектор) а за менеджерские - менеджер. Решения - нанять, уволить, сроки, бюджеты, приоритеты, мотивация - все менеджерские.
p.s. менеджеры тоже есть разные. За приоритеты и бюджеты и прочее относящееся к создаваемому продукту - отвечает продукт менеджер. За найм-увольнение - совсем другие. За организацию тим-билдингов - вообще третьи.
aryk38
давайте всегда говорить "за всех".
iago
сколько компаний, столько и процессов, иногда абсолютно отличающихся друг от друга. Вы говорите про огромные организации, где для каждой микрозадачи есть специально обученный человек, эйчары делятся на эйчаров и рекрутеров, а среди офис менеджеров есть своя иерархия. Но айти не равно энтерпрайз
Imaginarium
Если это всё действительно просто переименование -- то вполне очевидно для чего оно: чтобы поднять статус менеджера. Им всё труднее быть значимыми, особенно в технически сложных проектах, вот и переименовывают. Насильственное сращивание с командой, так сказать, а заодно и серьезное подспорье в избегании претензий со стороны технически более компетентных товарищей: одно дело не понимать, что от тебя требует менеджер (велика вероятность, что он сам не знает, чего хочет), другое -- не понимать тимлида (вроде как уже проблема оппонента, что он недостаточно умён).
0serg
В западном IT практикуется разделение работ на две карьерные ветки - "manager" и "individual contributor" aka IC. При этом тим лид считается младшей менеджерской позицией, которая как правило находится на том же уровне что и senior developer, но в ветке "manager" а не "IC". Уровнем выше может стоять "project manager" или просто "manager" в ветке менеджмента и "tech lead" или "expert" / "principal" в ветке IC (да, tech lead считается при этом более сложной и высокооплачиваемой работой чем team lead) и т.д. При этом в теории тимлид может вообще не разбираться в программировании, его задача - администрирование команды.
В России такого четкого разделения на две ветки часто нет и из-за этого team lead считается такой переходной позицией от разработки к менеджменту совмешающей в себе менеджмент и хорошие технические знания.
unreal_undead2
Скорее это first line manager, а понятия тимлида просто нет.
0serg
Одно другому не противоречит. First line manager - это собирательное название для менеджерских позиций начального уровня. Тимлид в понимании "человек который менеджит 5-6 линейных сотрудников" явно к ним относится.
unreal_undead2
Если (как это положено в нормальной компании) он явно находится на менеджерской линейке, прошёл соответствующие тренинги и т.д. - то это просто FLM. Понятие тимлид возникает скорее там, где нет чёткого разделения на девелопмент и менеджмент на нижнем уровне.