Comments 57
Короче, лайфхак для вкатунов: идите сразу в тимлиды, там даже кодить не надо. Это шутка, но с долей правды
Есть же масса примеров, и я в том числе, когда тимлидами становятся не бывшие разработчики, а бывшие аналитики и тестеры. Просто они в себе не совмещают две роли, а исполняют одну - управление командой (тимлидство)
а чем отличается человек, который "просто управляет командой" от менеджера? Зачем называть его тимлидом в таком случае? В чем его лидерство заключается?
Ничем, в этом и суть ) Вопрос в подмене понятий ) Лидерство в том, чтобы из группы людей сделать команду
Лидер (значения)
Материал из Википедии — свободной энциклопедии
«læddan» — древнеанглийское слово, употреблявшееся в значениях «вести», «приводить»
Лидер (от англ. leader — ведущий, первый, идущий впереди):
Лидер — лицо в какой-либо группе, организации, команде, подразделении, пользующееся большим, признанным авторитетом, обладающее влиянием, которое проявляется как управляющие действия.
Я именно об этом и говорю - это подмена понятий. Не нужно делать разработчика менеджером, пусть будет тимлидом. А менеджером сделайте кого угодно, пусть будет менеджером. Тимлид должен быть интерфейсом команды через который осуществляется обратная связь с менеджером. Если у вас тимлид не участвует в разработке, то это просто менеджер.
И я это говорю не с неба взяв, у меня за спиной 10 лет менеджером(а сейчас бекендер), в том числе "руководитель группы отдела продаж" ну т.е буквально тимлид. Так сказать побывал с обеих сторон.
Дак менеджер это и есть тимлид а тимлид это менеджер. В англоязычной среде его даже называют engineering manager.
Хотя вопрос того что вы подразумеваете под этим термином.
Возможно то что вы подразумеваете то что в статье описано как менеджер+техлид.
Это часто встречаемая комбинация которую часто называют тимлидом.
Также в статье отличный кейс приведен когда это перестает работать - как только команды кросфункциональные.
Вы вот себе тимлида у которого в команде рфонтендер бекендер дизайнер и датасаентист как представляете? Он от того что вы называете менеджер чем будет отличаться?
Это тимбилдинг, и это не про лидерство.
Лидерство это про умение обеспечить доверие и поддержку людей для совместного достижения цели. Команду для этого строить желательно, но совершенно не обязательно.
И да, в команде разрабов не-разрабу получить нужное доверие будет очень непросто.
60% респондентов из купера, что тимлид не должен писать код
Видимо только 40% знают, что в таком случае он будет тем самым мифическим продакт менеджером, а не тимлидом.
Я бэк разработчик. Если б мой тимлид был тестировщиком (или кем угодно кроме бэк разработчика) я бы искал другой проект. Проджект менеджер пожалуйста, но тимлид это всегда старший разработчик. Если ты не можешь посоветоваться с тимлидом по коду - какого ты дьявола вообще должен слушать этого человека?)
посоветоваться с тимлидом по коду - какого ты дьявола вообще должен слушать этого человека
Может конечно в россии не так, но по коду надо посоветоваться с тех лидом, по межкомандному взаимодействию, по задачам, по тому чтоб донести какиет проблемы менеджменту, что "у меня и так 100500 задач, я понимаю что Вася болеет но у меня уже bandwidth'a нет" и прочее в этом духе - это с тим лидом.
По-моему эта путаница - это беда нашей отрасли. У команды должен быть менеджер = лидер, и это не обязательно технарь (лучше не технарь, хорошо если есть бекграунд). Это не лучший программист, это именно менеджер - другая профессия. Так же в команде должен быть старший программист / техлид, который имеет тех авторитет и к которому идут разработчики с техническими вопросами. Но лидер команды менеджер. Сейчас часто совмещают первого и второго и это большая беда.
Менеджер не лидер, он вообще по отношению к команде внешняя сущность. И, как уже тут сказали, команда его не примет как одного из своих, он не погружен в реалии кода. Менеджер это управленец, он владеет конкретным продуктом, ведет учет, управляет потоком задач на высоком уровне, следит за бюджетом и учитывает интересы продукта. Команда это исполнительный блок, группа специалистов разной квалификации и специализации, она разбирает поток задач и выполняет эти задачи наиболее эффективным способом, с учетом доступных ресурсов и компетенций. Слаженная команда может принадлежать нескольким проектам, а в случае разногласий иногда и фирму покидает в полном составе, такие случаи история уже знает. Тимлид тут это просто старший опытный разработчик, знакомый со спецификой кода, с бизнес-процессами, с реалиями корпоративных игр вышестоящих товарищей. Лид способен быть интерфейсом между командой и бизнесом, это наиболее грамотный, и в техническом плане, и в бизнес-плане, человек, который понимает о чем говорят вышестоящие товарищи, понимает их реальные потребности, и реальные ограничения текущего кода, понимает проблематику сверху и снизу. Лид способен перевести технические подробности на язык бизнеса, и бизнес-потребности на язык технарей. Его задача быть клеем, и внутри команды, и внутри бизнеса, оптимизировать процессы, пресекать тупняки, находить короткие пути решения тех или иных проблем, не учитывая никакие зоны ответственности, на чем спотыкаются обычные разработчики. Его задача быть крайним в команде, замыкать все внутренние вопросы и проблемы на себе, не допускать их утечки вовне, не допускать нарушения зон ответственности. Именно его будут нагружать разработчики всякими проблемами и непонятками, и он их разрешает за считанные минуты, тем самым избегая серьезных простоев на ровном месте, потому что без лида в таких случаях начинается игра в "горячую картошку", никто на себя ответственность не берет, и простейший технический вопрос утекает наверх, покидает зону ответственности технарей, и летает по всяким менеджерам и управленцам, которые не понимают что от них хотят и причем тут они вообще, и летать он там может неделями, что выглядит просто дико. Также задача лида - тактические, оперативные решения, внутри его сферы ответственности: многие вопросы или проблемы можно решить внутри команды, без привлечения внешних , и тем самым сократить время на всякую бюрократию, увеличить эффективность процессов - время ответа человека за пределами команды может достигать недели-двух, а пинг до лида обычно менее часа. И его задача быть ориентиром, вдохновлять молодых - как ни крути, но внутри команды самый большой авторитет именно у лида, новички к лиду обычно относятся особенно трепетно, в их глазах это чуть ли не человек-легенда, на его авторитет работает и огромный опыт, и роль, и тот факт что с ним считается бизнес и он постоянно пропадает на совещаниях с большими людьми, ну и личный фактор конечно же, рано или поздно лид окажет помощь каждому из команды, решит его проблему.
А чем то что вы называете тимлидом отличает от техлида? я пока только 1 особенность заметил - ему нужны софтскилы чтобы общаться с бизнесом. Все остальное на 90+% подходит под описание техлида. Выходит тимлид это техлид с софтскилами и немного бизнес майндсетом? :)
По поводу клея - в англоязычной среде это делают часто staff инженеры. Етсь даже ряд статей про путь Staff engineer и прямо таки "being glue" от Tanya Reilly. Стафф инженеры при этом часто следуют архетипу "техлид". Так что опять же (из моего пузыря) похоже на описание техлида.
Под конец про общую ответственность за команду - это очень похоже на работу обычного технического менеджера.
И самый главный вопрос к вашим рассуждениям - а если команда кроссфункциональная. Допустим есть 1-2 бекендера, 1 QA, 1 ML и 1 DS researcher или скажем Front+UX+Back+QA - как тимлид будет взаимодействовать с частью команды, которая не является его прямой специализацией? например если он бывший бэк? точно также как менеджер не тимлид, верно? в чем тогда разница? или ваше понятие тимлид не применимо к таким командам?
Интересно послушать ваше мнение
Хм, а ты не путаешь teamlead и techlead?
Впрочем, в нормальных процессах teamlead вообще не нужен, а вот techlead - да, старший разработчик.
То что вы называете тимлидом - в статье называется техлидом (ролью, не лычкой). У вас тимлид просто еще выполняет/совмещает роль техлида из статьи.
Ну тут нет ничего удивительного, у тестировщика и аналитика потолок роста ниже, поэтому переход в "проджект-менеджеры" практически безальтернативен, а вот разработчик может себе позволить и дальше писать код, если ему интересно.
вся суть несогласия с озвученным в статье могу описать этой картинкой:
В чем заключается отличие тимлида от просто подкованного технически менеджера если он не тянет с нами(командой) одну лямку, не ест из одной плошки и не спит под дождем в одной траншее перед боем? Чтобы держать руку на пульсе тимы и понимать как управлять их мотивацией нужно быть погруженным в их быт, а значит участвовать в коде так или иначе.
А если в твоей команде не только разработчики, а есть и аналитики, и тестеры, и дизайнеры? ты же не можешь быть погруженным в быт по всем направлениям? Суть мысли в том, что есть техлиды, которые тянут одну лямку, едят из одной плошки и спят под дождем в одной траншее перед боем, а есть тимлиды, которые объединяют всю команду целиком.
Звучит как неверная трактовка понятия TeamLead, ну по моему мнению. Team leader - лидер команды. Ну не всей же, а команды бекенда например - человек ИЗ команды, который представляет вас всех на уровне менеджента. Такая практика между прочим есть не только в ИТ, а годами существует во всех отраслях. Бригадир, Мастер цеха, Руководитель группы отдела (например продаж). Это всегда обязательно человек ИЗ группы, который складывает ЧАСТЬ полномочий чтобы нести личную ответственность за общую деятельность группы. Таким образом он держит руку на пульсе группы, в курсе ежедневных чаяний и несет личный ответ за происходящее. Группа же в таком случае ассоциирует себя с представителем и ощущает ответственность перед ним, так как подставляешь ты брата по команде а не какого-то там зазнайку с менеджерского олимпа.
Тех лид же имеет свои абсолютно не пересекающиеся зоны ответственности, но тоже в рамках команды.
Вы в примере к статье приводите 20 тимлидов, но они все из одной компании, ну т.е существуют в рамках одной системы. Чтобы опрос можно было посчитать релевантным стоило опросить 20 лидов из 20 компаний, например. Лиды из Купера как минимум подвержены давлению своей группы, раз все не пишут то и я не буду, ну просто как пример. Или вот ещё - а что если в Купере, просто предположим, огромная систематическая проблема, связанная именно с тем что лиды код не пишут? Они изнутри системы этого не видят, а вы к ним обращаетесь с уже сформированным личным мнением, т.е так или иначе подвержены "предвзятости подтверждения"(см confirmation bias). СбреМегаМаркет как раз показал ужасные результаты из-за чего и предпринял (как мне кажется абсолютно неудачный) ребрендинг, так может все из-за лидов, которые не пишут код?(я само собой утрирую)
Да просто многие конторы вкладывают разные понятия в один и тот же термин. У нас в фирме в каждой команде есть тим лид, а есть it лид. Тим лид отвечает за формирование команды, бюджетирование, планирование ресурсов, является входной точкой от потребителей системы, в коде особо не разбирается, но знает хай лвл все ключевые принятые решения. IT лид же это прокаченный разраб, который отвечает за технические решения, декомпозирует задачи для других разрабов, принимает технические решения.
На самом деле, чёткой границы между этими профессиями не существует. Например, тестировщик может писать код для автоматизации тестирования программ. Дизайнеры в ИТ зачастую работают с HTML/CSS для создания интерфейсов. Аналитик должен мыслить как программист, чтобы грамотно составить техническое задание, которое, по сути, уже наполовину является решением задачи.
Я, как Corporate ICT Officer, занимаюсь обслуживанием внутренней ИТ-инфраструктуры. Иногда пишу код на PowerShell, чтобы оптимизировать рутинные процессы.
Но почему всё внимание сосредоточено на кодировании? Если я графически автоматизировал процесс в облаке Azure или Amazon, это тоже демонстрирует инженерное мышление. Уверен, что даже дизайнеры, работая в Photoshop, используют макросы для автоматизации определённых задач.
Поэтому предлагаю заменить термин "кодирование" на "автоматизация", поскольку он лучше отражает реальность.
Можно есть из одной плошки, спать в одной палатке, ночевать в одной траншее, НО лидер не будет эту траншею копать, эту еду готовить и палатку ставить. Он будет распределять работы, анализировать данные разведки, ну а дальше сам метафору продолжишь
все верно, именно так и должно быть. Никто не говорит, что он должен быть таким же, он просто должен быть с нами, если он не с нами, то он и не лидер, а оторванный от коллектива обычный менеджер. Как пример - всякие там байки про полководцев, а-ля Македонский, Суворов, Петр 1 и иже с ними, которые само собой траншеи не копали и в штыковую не шли в авангарде, однако делили общий быт с бойцами и не чурались за одним столом с ними есть одну еду, за что были и почитаемы всеми от рядового до офицера, именно так лидерство и работает - ты должен быть выше команды, но частью команды, а не абстрактным "царь-батюшка" который с небес дает безликие приказы
Сейчас в вакансиях в основном пишут "тимлид/senjor", "играющий тренер" и прочий бред, лишь бы сэкономить на тратах на персонал. Если вдруг тимлид скажет что ему нужен еще техлид (а может и еще продакт), то там покрутят у виска и скажут что-то типа "У нас пока не заложен на это бюджет". Не знаю что там у вас в Купере, но обычных компаниях все эти позиции надо с боем выбивать. А пишет код тимлид в основном не потому что хочет не потерять "разработческую хватку", а просто потому что горят сроки или не хватает разработчиков
У нас в Купере так же - политика компании такая, что тимлидами становятся разработчики, но и команды у нас чаще всего состоят из разработчиков одного стека. И проджектов, сидящих в команде, нет, поэтому тимлиды совмещают и техлидство, и тимлидство.
Я бы сказала, что всё зависит от того, как устроена структура команд в компании, ведь играющий тренер на самом деле - по факту сокращение капасити команды почти на одного человека
Почему тимлидами в командах становятся разработчики? Чаще всего в командах никого кроме разработчиков нет.
Почему у тимлидов не хватает времени на написание кода? Команды недостаточно опытны и процессы через тимлидов выстроены.
Почему команды недостаточно опытны? Горизонтально масштабироваться проще всего через деление команд.
А как же аджайл-подходы? SoS и тимлиды как аватары команд. Они же тоже когда-то программировали и команды как раз однородны.
как только вас назначают на должность тимлида, выбирайте себе техлида в пару
Это легко говорить из околосберовской конторы. Там только свистни - тебе сразу трех техлидов найдут. А там, где прибыли не триллионные, вопрос из заголовка как раз и стоит наиболее остро. И решается не в пользу тимлида. И погромировай, и управляй, и с созвонов не вылазь. И фару на лоб, как водится.
Эх, если бы "околосберовские" конторы отличались:) у нас такие же ограничения и по финансированию, и по найму. Но осторожно смею предположить, что в таких конторах понимают, что если один человек будет "И погромировай, и управляй, и с созвонов не вылазь" - в конце концов это будет зомбик, которого придется отстрелить, если он до этого момента не отстрелится сам.
Если мы имеем не самоорганизующуюся команду профессионалов и оцениваем не по работающему продукту, то да - надо взять одного из членов команды, кинуть в бочку с другим, а того, кто выживет, отправить обратно в роли тимлида заставить его забыть всё что умеет и принудить делать работу руководителя проекта. Этот рецепт, безусловно, проще, чем нанять команду профессионалов и обеспечить их всем необходимым, найти РП, который знает что такое "руководить" и что такое "проект" в ИТ, а не в ЖЭКе. Но этот рецепт не про эффективность, а про то, как не утонуть и вообще доплыть хоть куда-то.
Продакт - про то, куда развиваться, что болит у заказчика
Проджект - про то, как раздобыть ресурсы, как поженить снабжение, разработку, тестирование, рекламщиков ... , спланировать работу так, чтобы Группа 1 дала результат одновременно с Группой 2 и т.п.
Тимлид - про то, какой технологией лечить проблему клиента, какие стандарты разработки в команде, что дать Васе, что Пете и проверить, что оба не накосячили и не внесли ненужной отсебятины
В статье же попытка обосновать необходимость еще одной сущности. За 20 лет управленческой деятельности был на всех трех ролях, не считая собственно разработчика, и оглядываясь назад, не вижу нужды в четвертой.
Тимлид - про то, какой технологией лечить проблему клиента, какие стандарты разработки в команде, что дать Васе, что Пете и проверить, что оба не накосячили и не внесли ненужной отсебятины
Это все верно только для маленькой команды каких-нибудь джунов или максимум мидлов. Когда команда более-менее большая и опытная - можно, конечно, продолжать заниматься микроменеджментом и контролировать каждую строчку, но уже в ущерб своим основным обязанностям, т.к. основные обязанности тимлида это все-таки эффективно организовывать, мотивировать и делегировать.
Тимлид это капитан команды, играет ли капитан - конечно, иначе на кого молодым равняться, он не делает много грязной работы, но голы забивает. Как Овечкин в Вашингтоне :) А если он не играет, то это уже какой-то менеджер, завхоз, сервисмен
Это опять про разницу между techlead и teamlead.
Техлид - да, тоже разработчик.
Тимлид - про процессы, людей, приоритеты, коммуникации, т.е. совсем другие компетенции.
Очень большая проблема процессов во множестве компаний - это смешивание техлида и тимлида в одном человеке. В результате ничего хорошего не получается.
Техлид
Если сфера не "тех", то как тогда "капитан команды" называется? Или ваша классификация только для разработки годится?
про процессы, людей, приоритеты, коммуникации
Это руководитель. Manager, если угодно.
Принципиальное отличие ролей "техлида" и "тимлида" нужно далеко не для всех деятельностей. Да даже в IT в некоторых командах не нужен тимлид, в некоторых - техлид, в некоторых - ни тот ни другой (но нужны специалисты вне команды - про людей, процессы и так далее).
Единой правильной картинки нет. Но без разделения ролей и активностей нарисовать подходящую картинку для конкретных людей в конкретном проекте - тоже не получится.
Это же надо было так оскорбить тимлида, опустив его до уровня проджект менеджера?))
У разработчика есть два варианта развития - тех лид и тим лид, соглашусь, что совмещать и то и то это плохо. Но он в любом случае должен оставаться разработчиком - хорошо знать проект (от теории до непосредственно кода), должен уметь сам решать задачи любого уровня - хоть ТЗ написать, хоть тестировать, хоть разрабатывать (пусть хуже профильного специалиста, но уметь должен).
Таким образом тим лид это разработчик, который обладает достаточным опытом и знаниями и плюс к тому хорошими софт скиллами и авторитетом в команде. Ни один серьезный программист не станет слушать человека, который не умеет писать код или делает это крайне плохо)
К сожалению, сейчас в айтишку тащат все ублюдские практики ведения бизнеса из других сфер и начинают появляться "тимлиды", не умеющие писать код. Таких проектов стоит избегать)
По-моему, автор лукавит и подменяет понятия.
Вопрос в заголовке статьи мог бы быть: Должен ли тимлид уметь писать код?
И (по-моему) ответ на этот вопрос должен быть утвердительным. Почему? Потому что здесь и содержится лукавство автора: когда все тимлиды умеют писать код, то можно и задуматься "а так ли это нужно?". А вот если бы они изначально не умели?
Очень хорошо об этом сказал Козьма Прутков (осовремененно):
Когда спросят тебя: что важнее луна или солнце, отвечай луна! Ведь солнце светит, когда и без того светло, а луна ночью.
И вопрос только в том, насколько ранее писавший тимлид умеет это делать и понимать в современных реалиях (ведь стеки меняются и выходят новые стандарты языков). То что раньше какие-то вещи делались легко и просто (например, через россыпь костылей с техническим долгом и спагетти-кодом), сейчас может потребовать больше времени. И, конечно же, наоборот: масса вещей делается сейчас легче и проще.
Но насколько проще? А тимлиду лучше знать! Но будет ли он это знать? А так может тимлиду писать код? Если не для продакшена, то хотя бы для понимания?
-
Прим: про "играющего тренера" можно возразить: но капитаны команд играют. Например, Игорь Владимирович Акинфеев. Да, наверное, если его поставить в нападение, то играть он будет не лучше, чем на воротах. Но он же играет.
Должен и ещё как. Иначе за 5 лет для рынка он превратится в мидла и потом вообще непонятно что делать. На мидла не берут потому что овеквалифаед с таким опытом, на синьора не берут потому что стрёмно - навыки не актуальные.
Сам из такого выкарабкиваюсь и несколько таких собесил.
Тимлид - это менеджер = другая профессия. Рост из разработчика в тимлида чаще это общая ошибка и боль отрасли.
Тимлид который не был сеньором это плохой тимлид. При этом ставить токсичного буку сеньора тимлидом нельзя, получится очень плохой тимлид.
Надо совмещать. И разработчиков понимать и уметь любой код написать и с менеджерами и смежниками на одном языке о продукте и сроках поговорить.
Код писать со скоростью сеньора и даже мидла конечно же не надо, но брать себе таски по которым нет дедлайнов и можно затянуть хоть на месяц-другой это правильно. Таски на переложить джейсон стоит брать только если хочется посмотреть что там с процессами или люди из команды начали на них жаловаться. Вдруг тесты на самом деле болят, а тестирование на самом деле ерундой занимается? Проверить на себе это лучший путь. А вот таски вида "ничего не понятно, но очень интересно" себе брать можно и нужно смело. И как код писать не забудешь и сроки никому не сорвешь.
Тимлид который не был сеньором это плохой тимлид.
Да, при необходимости сменить работу это и становится главной проблемой тимлида. Он конечно был синьором когда стал тимлидом, но новый работодатель хочет чтобы он демонстрировал синьорские навыки и сейчас, после нескольких лет менеджмента. А для этого надо было много ходить.
Так стоит и подаваться на вакансии тимлидов.
Примерный набор навыков: Написание кода на уровне мидла, знание архитектуры и технологий лучше сеньора ибо кругозор больше, умение говорить с людьми те самые софт скилы. Таких людей на рынке не то что мало, их скорее совсем нет.
Подаваться можно, но не возьмут. Зарплата тимлида высокая, цена ошибки для компании ещё выше. А архитектуры и софтскилы сложно проверять. Поэтому обязательно спросят детали технологии и если ответ не тянет на синьора, то без шансов.
По написанию кода на собеседовании сеньора от мидла вы уже не отличите. Пытаться их различить спрашивая тонкости которые знают не сеньоры, те кто с ними сталкивался глупо. Дальше идет архитектура и поговорить, тут тимлид должен быть лучше сеньора. Больше кругозор и больше опыта в разговорах.
Не вижу особых проблем. Многие фирмы понимают кого они ищут и что хотят.
В случае сферического тимлида в ваккуме, который хорош как его не поверни, то да, но в реальности почти всегда бывает по-другому и на то есть сто вариантов.
Например, сплошь и рядом случается , что тимлидскую позицию хороший изначально программист получает потому что он быстро стал экспертом в продукте и предметной области и стал слишком ценен для бизнеса, чтобы позволять ему просто программировать. И дальше он по уши погружен в проблемы конкретного проекта и предметную область, а расти дальше как программисту у него нет времени. Задача архитектуры при этом он решает, но во-первых в реальных даже дико монструозных проектах, эти проблемвы редко бывают сложными, а во вторых с компании всегда есть гораздо более сильные архитекторы, которые ему и подскажут. В третьих, в команде может быть крутой синьор который не стал тимлидом из за софтскилов и гораздо рациональнее в архитектуре положиться на его мнение, чем изобретать архитектуру не программируя и в итоге получить конфликты с этим синьором и командой в целом. При этом лид, как единственный человек, который знает что на самом деле нужно делать, вечно перегружен и является бутылочным горлом команды. Ему платят за то, чтобы команда знала что делать и перла вперед. Поэтому сесть и учиться у него тоже нет времени, в отличии от девелоперов, которым как раз за эти компетенции и платят. В итоге отказ от активного программирования оказывается фатальной ошибкой в карьере тимлида.
Другой очень распространенный вариант - тимлид с нерелевантными знаниями. Например, на момент когда он стал из синьора тимлидом веб разработка сводилась к JQuery и MVC а теперь везде SPA. Или он мог работать как крутейший синьор в команде которая пилила десктопное приложение, а через 5 лет тимлидства уже все на вебе и он понимает фреймворки уже только на уровне мидла. Или он вышел в тимлиды когда в его проекте все было в монолите и специальные люди это возили и ставили, а теперь все на клауде, с микросервисами и CI/CD. Он в целом понимает все эти новые технологии, даже сам их внедрял, но начни обсуждать детали, быстро видно, что реальный опыт с ними у него с ними мидловский.
Все так. Марина, привет )
Просто в IT, как в относительно молодой отрасли, нет устоявшейся терминологии и общепринятого разделения обязанностей. Вот в промышленных коллективах, как уже упоминали выше - бригадир, мастер участка, начальник цеха - сразу всем понятно, кто чем занимается. А в IT кальки с английского языка наполняются своими смыслами, плюс подмешиваются термины всеми любимых "эффективных сов" и приёмы от них же, что в итоге приводит к размножению руководящих контуров...
Мне кажется, что все намешали в кучу. Техлид отвечает за код, за архитектуру. Но он не отвечает за бизнес-логику. За это отвечает тимлид. И именно тимлид должен уметь оценивать задачи, знать/закладывать архитектуру, понимать когда нужно создавать новый микросервис. Да, совместно с техлидом. Но инициатива от лида должна идти.
Если лид - это не писавший код человек, то по сути это не лид, а просто руководитель проекта - менеджер. Он никак не может оценить сроки выполнения по добавлению какой-нибудь фичи и вообще понять а может ли быть это реализовано.
Это вы ещё delivery manager, project manger, product owner и прочих не добавили в обсуждение :) Нет у этих профессий чётких списков. Чтобы так случилось надо написать и утвердить в компании документ о ролях и ответственностях этих ролей. В РФ это штатное расписание кажется называется. А в холиварах это не решается и пользы не несёт. И так культура корпоративная не очень развита, а тут ещё это.
Тимлид должен писать код. Иначе он просто хрен с горы, которому можно навешать что угодно.
Несколько месяцев назад на хабре было очень много статей про продакт-менеджеров. И при ближайшем рассмотрении всегда оказывалось, что продакт-менеджер и проджект-менеджер - это одно и то же. Вот только все ПМ (аббревиатуру можете расшифровать по вкусу) вопили, что продакт - это круто, а проджект - это отстой.
Сейчас вот появилась статья, где проджект-менеджер идентифицирует себя, как тимлид.
Мне вот интересно, что это за напасть такая у проджектов? Какое-то массовое расстройство профессиональной самоидентификации? Или вам кто-то сказал что слово "проджект-менеджер" ругательное или неприличное? В чём проблема называть свою профессию общепринятым термином?
Вопрос слишком абстрактно поставлен. Нужно рассматривать более конкретную ситуацию. Например такую.
Руководитель проекта решает, что при реализации проекта непременно нужен тим-лид.
Руководитель проекта вводит позицию тим-лида в штатное расписание, и устанавливает перечень обязанностей.
В соответствии с перечнем обязанностей, тим-лид должен делать трололо, поскольку по мнению руководителя проекта, трололо способствует повышению продуктивности команды.
В обязанности тим-лида не входит понаписывание кода, в свободное от трололо время.
Но свободное время у тим-лида все-таки есть, поскольку все хорошо в меру, даже трололо.
Таким образом возникает вопрос - "Следует ли тим-лиду писать код, если у него нет этого в обязанностях, но есть на это время?". Или лучше даже не начинать, потому что он будет постоянно отвлекаться на трололо, и ничего по-нормальному не напишет?
Не думал, что в Купере так плохо устроены процессы: более половины считает, что team lead не должен писать код...
очень мило автор в разделе "подмена понятий" подменил понятия, позабыв указать, что тимлид в отличие от проектного менеджера отвечает за долговременную стратегию команды (в том числе в разрезе найма), за найм персонала, отвечающего целям команды и организации, за развитие персонала, за выполнение kpi команды, за планирование бюджета, за соблюдение трудового законодательства и техники безопасности на рабочем места в конце концов. Да и за проведение полит информации по поводу корпоративной культуры и политики высшего менеджмента. И за проведение команды через различные изменения и трансформации тоже
Должен ли тимлид писать код?