Комментарии 149
Добрый день, а какой путь предложите Вы?
Это во многом зависит от того, чего вы лично хотите.
Если хотите оставаться на технической стороне, то лучше переходить в смежные специальности, расширяя навыки, и в другие компании для повышения зарплаты.
Если хотите именно руководить, тогда надо идти в менеджмент, но именно идти полностью и бесповоротно, не пытаясь усидеть посередине, совмещая менеджмент с написанием кода.
Очень интересно было бы почитать про уход в айтишный менеджмент, минуя позицию тимлида.
У вас просто завышенные представления о низших уровнях менеджмента. В моей текущей компании все очень просто. Достаточно выразить желание туда идти, и если общих возражений нет, то когда откроется подходящая вакансия, то вашу кандидатуру рассмотрят и вполне возможно одобрят. Важно понимать, чем вы будете заниматься на нижнем уровне:
Вы будете управлять одной, максимум двумя скрам командами, т.е 7-20 человек.
Вы вполне возможно будете играть роль скрам мастера для них
Бюджет этих двух команд и их инфраструктуры будет на вас
Вы будете посредником и организатором между продуктом, высшим менеджментом и техническим тим лидом, решая все проблемы и конфликты, расставляя приоритеты
Вы будете тащить всю бюрократию священную с персоналом: найм, продвижение по службе, перформанс ревью и прочее.
Зарплата останется ниже синьора или такой же
На этом уровне можно надолго застрять, потому что дальше позиций становится кратно меньше, а конкуренция жёстче и менее основанной на объективных факторах
Вы будете помойной ямой для всех мелких одноразовых порученей: сделать отчёт, подготовить презентацию, собрать какие-то данные, которые нельзя извлечь из систем одним запросом
У вас что-то не так с процессами. Тимлид не делает сам руками ничего из того что не хочет. У него команда есть для этого.
И денег тимлидам обычно дают больше любого сеньора в их команде. Бывает что совсем немного больше, но не суть. Если это не так, то опять что-то не так в процессах.
Остальное верно, но акцент не туда. От половины до двух третей времени работа тимлида это говорить с людьми, писать и читать разные тексты и сидеть в чатиках. Остальное покодить что-то. Вам, да и многим другим, не нравятся эти основные занятия. Бывает и это нормально. Но многим они нравятся. Есть влияние на большие штуки, есть виденье продукта и возможность влиять на его развитие, есть деньги, есть много или даже очень много разнообразия. Опять же софтскилы прокачиваются очень быстро. Рутинные такси на переложить джейсон делать не надо.
Дальше каждый сам решает хочет он и дальше писать код или сменить деятельность на разговоры и писать немного кода в оставшееся время.
А он не роль тимлида описал, а чисто менеджерскую. Есть такое разделение в некоторых компаниях, когда вместо нормального полноценного тимлида есть нечто невнятное, упомянутое им как "технический тим лид", и нечто второе невнятное чисто менеджерское, нередко называемое "продактом". Задачи обычной роли тимлида при этом разделены на технические и управленческие и выданы разным людям. А поскольку роль на одного а людей двое, то получается некоторый недогруз, из-за которого от "технического тим лида" ждут продуктивности полноценного сениора (плюс к технической части тимлидских задач), а менеджера догружают чем попало начиная от роли скрам мастера и заканчивая рисованием графиков.
Иногда это даже работает. Например когда у единственного кандидата в тимлиды управленческие навыки отсутствуют, как и желание их прокачивать, и полноценно роль тимлида он не потянет, а больше - некому, искать полноценного тимлида слишком долго и сложно, а работу работать надо уже сейчас.
Но Вы правы в том, что обычные процессы при таком подходе действительно сломаны.
Я даже отдельным комментарием с вами соглашусь. Ваш второй комментарий ниже полностью описывает то что я думаю.
Бизнес еще не понимает как разделить обязанности и как грузить людей работой. Сфера у нас молодая, стандартов управления нет еще. Как раз мы сейчас и формируем эти правила.
А на продактов не надо ругаться. Они хорошие и нужные люди. Если их правильно готовить. Продакт идет на рынок и выясняет что ему нужно. Потом приносит обратную связь и думает что доделать или переделать. И иногда связывает команды друг с другом, продукт обычно требует взаимодействия кучи команд. Тимлид не думает об этом. Он думает как сделать фичу которую принес продакт. Тимлид и продакт обычно много часов в неделю сидят на общих встречах. Чтобы совместить желания рынка и возможности разработки.
Все те истории которые мы знаем про софт умирающий от фичей ради фичей это плохая продуктовая команда. Они недоработали и не поняли что нужно рынку. Команда разработки это просто делала в меру своих сил. Рынок может хотеть разного. Команда продукта должна это вовремя понять.
Разделение функций "организационного лида" и "технического лида" нередко бывает обоснованным и естественным. При этом роль/функция "технического лида" по-хорошему должна быть опциональной.
В основе всей конструкции лежит роль "организационного лида", совмещающая в себе в какой-то пропорции менеджмент и разработку. Далее, если "организационный лид" не чувствует в себе достаточной экспертизы в ключевых областях, или просто видит, что в команде есть более технически подкованные специалисты, он может предложить кому-то из них функцию "технического лида". Если всё срослось - супер! :)
Области ответственности у двух лидов при этом могут даже совсем не пересекаться: у "организационного лида" - организационный менеджмент, внешние связи, тимбилдинг, налаживание процессов и т.п. У "технического лида" - принятие технических решений, определение технических политик, надзор за ревью, заполнение разрыва между архитектором и командой. В идеале функция "технического лида" делегируется полностью, тогда и места для конфликтов будет меньше.
Время на кодинг у лидов выделяется просто по остаточному принципу, это нормально. У "технического лида" этого времени скорее всего получится больше, у "организационного" - меньше...
Ну и в общем да: с процессами в описанном случае что-то не так. Если кто-то сверху почему-то решил, что "норма выработки кода" у лида такая же, как у всех - надо просто идентифицировать это как проблему и эскалировать. Если наверху не реагируют, и ситуация непробиваема - система просто больна. Надо просто делать выводы лично для себя... Рядом наверняка найдутся другие системы с более разумным менеджментом и процессами.
В идеале функция "технического лида" делегируется полностью, тогда и места для конфликтов будет меньше.
На практике я такого не встречал, а Вы?
Из того, что я видел/слышал - тех.лид это обычно эксперт в отдельной области (напр. по конкретной БД или ЯП), и их в команде может быть больше одного (ну потому что они по разным областям). И хотя они немного разгружают тимлида, но полностью с него все технические аспекты снять не в состоянии (ну потому что они только считаются техническими, а по факту принятие многих технических решений обосновано не только техническими причинами, но и человеческими/управленческими, а тех.лиды о таком просто не задумываются).
Ну вот года 2-3 назад как раз сам оказался в роли такого "организационного лида". И нашёлся в команде коллега помоложе и думающий порезвее :) И с кругозором на более современном уровне. А я в ту пору как раз прочитал где-то про такое разделение функций.
Ну вот всё и сложилось :) С удовольствием делегировал более молодому коллеге техническую часть, за собой оставил организационную. Всё получилось естественно и бесконфликтно. Может быть не во всех деталях так, как описал выше. Выше - это некоторая экстраполяция на все те функции, которые можно было бы захотеть делить, а на практике функций может и меньше оказаться...
Я говорил выше именно про менеджера низшего звена, так как кто-то выше спросил, как можно стать менеджером не проходя тим лида.
Тим лид у нас это чисто дополнительный шильдик к грейду и как говорилось в статье, он не имеет формальных полномочий. С зарплатой напрямую это вообще никак не связано, просто может быть учтено как плюс при присвоение следующего грейда.
Грубо говоря, тим лид решает как что-то делать, какой стек, архитектура, интеграции с другими компонентами и т.д., на своем уровне конечно.
Я не могу сказать правильно это или нет, просто описываю, как есть. Я не думаю что есть какой-то стандарт, каждая компания по своему решает.
Формальные полномочия должны быть. Иначе опять что-то не так в процессах.
Тимлид должен нанимать, увольнять, повышать и выдавать премии своей команде. С одобрения вышестоящего руководства, коррупция все дела. Но в целом сам. Явно сам, чтобы вся команда знала кто им премию выдаст или не выдаст.
Хорошая практика. Утрировано. Пред НГ выдать тимлиду бюджет на N миллионов рублей и сказать раздать команде. Себе брать нельзя. Тимлид должен хорошо решить эту задачу. Поровну нельзя, надо кому-то дать в разы больше а кому-то в разы меньше. Критерии хорошести как обычно мутные. Команда должна быть довольна. Мнение того кто не по лучил премию очень важно.
Вы описали техлида или архитектора. Без менеджерских обязанностей и полномочий. Обычно под тимдидом подразумевают не это.
Тем не менее, у нас это так. То что я описал у нас называется manager. У них отдельная структура и намного более низкие требования к технической части. Некоторые менеджеры никогда не были разработчиками и не имеют соответствующего образования, в пришли из продукт / проджект менеджмента или вообще из менеджмент в другой области.
Я в другой структуре. У нас как раз разработка отделена от продуктового менеджемента.
Продукт решает свои задачи. Как денег заработать, как долю рынка захватить и все такое. И вот за код и команду разработки отвечают тимлиды. Продукт и слова не скажет если тимлид кого-то захочет уволить и не лезет и раздачу премий.
Точнее лезет, но на уровне вот тимлид хочет дать миллион премией разрабочику, а продукт недоволен качеством фичи которую этот разработчик за год сделал. И у тимлида должны быть очень хорошие аргументы почему этот разработчик на самом деле молодец. Или наоборот. Есть классная хорошо сделанная фича, а премии разработчику нет. Тимлид должен объяснить почему ее нет.
У нас тим лид НЕ влияет на продукт точно также, как и любой синьор. Последнее слово все равно за product manager и менеджер. Тим лид отвечает за внедрение.
Это плохо. Тимлид должен вилять на все технические штуки. Продукт это не только свистелки с перделками. Это иногда большие сложные штуки. Тут тимлид включается и рассказывает как они влияют на все что уже есть в продукте. Это не право вето, но влияние сильное. Опять говорить с людьми надо.
Ну последнее слово ж все равно за продактом. Тимлид просто доносит до продакта технические трудности, из-за которых хотелку продакта реализовать не получится или получится но с проблемами в будущем.
Продукт это не только свистелки с перделками. Это иногда большие сложные штуки
Если решение о больших сложных штуках принимает тимлид, на выходе обычно мощная, красивая, реально классная и вылезанная с технической стороны штука. Одна беда - нафиг никому не нужная...
Поэтому в нормальном формате продакт говорит, что нужно сделать, а тимлид рассказывает ему варианты как можно. А как нельзя, даже Вася из соседнего отдела говорит что можно.
Тимлид не делает сам руками ничего из того что не хочет
Это только из технического. А вот по административной части он - наименьшая единица, у него в этом смысле нет подчинённых.
Странно, но мне чаще встречаются лиды, которые в основном подкручивают kpi, чтобы получать БМ и это не зависит от конторы. Есть и банки и вендоры.
Вот и думайте после этого, стоит ли идти в менеджмент или лучше быть вечным синьором
У синьора кроме тимлида есть как минимум рост в архитектора
Ага, когда умрёт предыдущий арх, как-то так, возможно есть другие способы, кроме как высидеть эту позицию, но они все равно по срокам сильно больше, чем среднее время работы в одной компании) А должность погонщика (лида в том числе) - это предательство самого себя, туда разве что новоиспечённые сеньеры с 3 годами опыта лезут. Лучше уютно вечно кодить, чем отвечать за всех и вся в команде за плюс-минус те же бабки. Условно говоря 10+ лет учишься выполнять свои рабочие обязанности левой пяткой, хоть тебя в три ночи разбуди с 800 промилле в крови, чтоб потом этот чудесный комфортный скилл променять за слежением 24/7 за всеми фичами в команде и за работой всего состава команды и на забитый встречами и микротасками календарь.
Плюс уровень вовлечённости должен быть снова как у зелёного юнца, а это прямой путь к выгоранию. Потому как вовлечённость будет уже нагнетаться искусственно, только для того чтоб не было факапов, а не потому что тебе искренне интересна каждая фича. А так разработал, тестирование прошёл - и хоть трава не расти - деньги честно заработаны)
так сеньоров и назначают тим лидами же, видел в вакансии у сеньора требование: опыт управления командой разработки
Ну очень интересно было прочитать про ваш не особо удачный пример того как может выглядеть ситуация тимлида.Но вы точно уверены что это можно экстраполировать на всех?
Я знаю нескольких человек, которые говорили тоже самое. Парочка даже решили пойти обратно в простые синьоры, потому что нагрузка выше, в плюсов для себя лично практически нет.
Я работаю тим. лидом давно. Много проектов, несколько контор. Всё так и есть, как описано в статье. Подпишусь под каждым словом. Чтобы остаться на нужном техническом уровне неизбежно придётся перерабатывать, много. То, что модно зовут 'играющим тренером'. Меня почему-то эта формулировка раздражает неимоверно. Нет такого, ты или тренер или игрок :) А так ты реально шестирукий Шива, обязанностей огромное количество, реальных инструментов влияния даже на состав команды не всегда много. Поймала себя на том, что ситуаций, когда ты сел в 10 часов на минуточку и очнулся часов в 5, забыв про завтрак и обед много. Почему стоит работать на этой позиции? Наверное у каждого свой ответ. У меня случались проекты, когда всё нужно было сделать с нуля и тогда это очень интересно. Тим. лид - это стержень, без которого всё рассыплется. Ну или получится лебедь, рак и щука. А так, вот не было ничего, а вот уже что-то закрутилось, живое, и это стоит того :)
Просто немного перефразирую абзац из статьи:
Чем дольше разработчик работает, тем сильнее он привязывается к специфичной архитектуре своего текущего проекта. Он начинает выполнять задачи, нужные только внутри компании, и нигде больше на рынке. В результате разработчик теряет свою ценность даже в плане технических навыков, становясь менее гибким.
Это так, но на группенфюрера то же воздействие во много раз сильнее.
Разработчик свою ценность на рынке при этом не теряет, т.к. опытные разработчики на рынке в дефиците, и нанимают их чаще всего по принципу "есть 3+ года опыта, может рассказать, что такое хэшмапа и решить easy с литкода", то есть критерии общие для любых компаний с любой архитектурой.
А вот тимлидов предпочитают выращивать внутри компании, а не нанимать с рынка, как раз по причине их ориентированности на процессы в конкретной компании.
Не знаю, где Вы нашли такие компании, которые спрашивают пару вопросов и сразу берут. По моему опыту, от полутора до трёх часов обычно длится интервью: и про устройство памяти, и про многопоточность, и про авторизацию и аутентификацию, и про солид спросят. Всякие контр-вариации делегатов частенько всплывают.
А где вы такие компании берёте? Ни разу за двадцать с лишним лет с таким не сталкивался :)
На hh. Некоторые компании даже не скрывают, что спрашивают много деталей: например, Озон или Билайн заранее указывают, что будут гонять по GC и прочим тонкостям. Наверное, такова специфика продуктов. Обидно то, что уже раз пять была ситуация, когда интервьюер честно сам не мог вспомнить, когда применял спрашиваемую тему в работе. Это больше бич средних компаний, копирующих вопросы для интервью из интернетов.
Я такое один раз встретил. Когда хотел в Microsoft пойти. Причём они честно сказали что это чисто фильтр для отсевв потому что очень много желающих.
Как бывший сотрудник Microsoft могу с уверенностью сказать, что процесс интервью там один из самых приятных, которые я встречал в своей карьере. Это касалось и входного интервью, и последующих, на внутренние позиции.
Бывает немного затянуто, но по сути это куча вопросов на софт скиллы + один вопрос про хэшмап и одна простейшая задачка с литкода.
Может в России это как-то иначе. У нас они меня гоняли хорошо.
То есть не то чтобы у меня остались негативные воспоминания. Даже несмотря на то, что меня в итоге не взяли. Но я у них пропотел:)
Я собеседовался только с коллегами из Чехии, Испании, США и Германии, но не из России.
Я про это же и говорю: я сам завалил все собеседования, кроме тех первых входных, чтобы попасть в компанию, но сам процесс всегда был очень комфортным. Один раз мой интервьюер даже позвонил мне и полтора часа объяснял, где я был неправ и что мне надо делать, чтобы развиваться в своей роли.
Архитектуры на уровне диаграмм похожи до боли друг на друга, причем даже в маленькие проекты часто уже закладывается то, что привык видеть в крупных проектах. Роль Лида успешно переводить с языка пользовательских историй в вендор-специфичное описание таска, понятное разработчикам. Да, каждый разраб в той или иной степени может такой перевод делать со временем при более детальном знакомстве с проектом, но при каком то непонимании все вопросы к Лиду. Поэтому разработчик может сменить работу и уже на другом проекте получать инструкции от местного лида. А у лида весь прикол в детальном знании архитектуры. Поэтому чаще всего придется увольняться как лид, снова идти сеньером, и там уже за год-два вырасти в лида, при условии, что там не будет шустрого и бойкого чела, который решил 20 лет на одном месте отработать лидом и не выгорать )
Архитектуры на уровне диаграмм похожи до боли друг на друга
Смешно. Если не разработчику показать примеры кода разных проектов на одном ЯП (особенно если это Go) - он тоже скажет, что код практически одинаковый. Внешне - похожи, конечно. Только вот как и в коде, одно малозаметное изменение может превратить удобную, работающую архитектуру - в говно, которое создаёт больше проблем, чем решает. Но на уровне диаграммы это изменение - просто ещё одна стрелочка, их там и так целая куча, одной больше, одной меньше - какая разница, да. ;-)
А у лида весь прикол в детальном знании архитектуры.
Нет, конечно. "Прикол" лида в софт-скиллах и управленческих навыках плюс к хардам и техническим. А специфику конкретного приложения лид после перехода на другой существующий проект изучит примерно с той же скоростью, что и любой сениор.
Поэтому чаще всего придется увольняться как лид, снова идти сеньером, и там уже за год-два вырасти в лида
И это тоже чушь. По такой логике и архитекты, и тех.диры должны на новой работе начинать как сениоры.
1) архитектуру невозможно изменить малозаметным изменением. Аналогия с разными яп нерелевантна
2) если у вас когда нибудь была лычка Лида, то могли заметить, что в отличии от руководителей направления, у вас графа "количество подчинённых: 0". Фап на софт скиллы в отрасли мне не понятен, как будто рынок переполнен инфантильными аутистами, которые игнорят всех и вся в слаке или тимс, и не могут ни ответить на вопрос ни сформулировать. Не встречал таких ещё, в отношении которых можно было бы сказать дерьмовые софт скиллы.
3) проблема в том, что хоть скорость и одинакова, но это все равно год+ вкатиться. Поэтому лидов дешевле растить из своих сеньеров, чем нанимать.
4) снова аналогия и снова некорректная. Техдиру и архитектору не надо изучать кодовую базу в десятке репозиториев у новой команды, чтоб оценить возможность либо невозможность того или иного принятого решения. С сеньера в техдира в готовую компанию это очень смешно )) в стартап разве что, если нет сына инвестора с дипломом Оксфорда на горизонте.
Глупость. На типовом стэке какие могут быть специфичные задачи? Формошлёпство и двигание кнопок во всех конторах одинаковые.
Всё так. Еще, если вы когда-либо задумывались о роли CTO в стартапе - своём или чужом - или планируете занять эту позицию, то роль "тимлида-шестирукого-шивы" станет хорошей репетицией. С той разницей, что в случае CTO у вас будет контроль над всеми рычагами управления. Но как развитие для сеньора внутри большой организации, тимлид - тупиковый путь.
А откуда по вашему в большом бизнесе берутся руководители отделов и СТО? Кажется это как раз выросшие тимлиды.
Плох тот тимлид, который не мечтает стать СТО
СТО это высоко. А вот руководителями отделов из 50-100 человек тимлиды становятся массово. Это понятный и доступный карьерный путь.
В абсолютном большинстве компаний вся инженерная команда меньше 50-100 человек. Если открыть, к примеру, список стартапов, получивших финансирование Y.Combinator пару лет назад, то там и инжереную команду из 10 человек найти -- ещё постараться надо. Хотя всё это -- технологические продукты, сравнительно успешные. И во всех этих командах есть CTO
Сдаётся мне что в районе 30 лет оч многие думают, что впереди некие не открытые острова, не занятые позиции, много нового... А нужно пойти в сеньоры, а нужно пойти в Лиды, а вот, нужно пойти в тех-лиды, а ещё архитектор, может туда пойти правильнее... Прикольно )) типа есть правильный путь, а есть не правильный...
Подпишусь. Все эти пути правильные.
Один тупик есть. Вечный мидл. У этого тупика есть свои плюсы. Понятная работа, лет через 10-15 она не будет забирать много сил. Достаточно денег для неплохой жизни. Много свободного времени, мало ответственности. Но для карьеры тупик. Знаю людей счастливых на мидловых должностях. Им хорошо, у них интересы и жизнь. Денег просто хватает. Новое место работы находится по щелчку пальцев. До пенсии работа никуда не денется.
Подпишусь. Все эти пути правильные.
До пенсии работа никуда не денется.
Ха Ха - за последние 20 лет ландшафт кардинально поменялся. Правильные пути теперь не правильные и до пенсии работать прграммистом из сегодняшних только пара процентов доберется. В РФ это будет пожестче чем в центральных мирах - факт. Радуйтесь сегодняшнему счастью мальчуганы. Сложность 98% бизнес программирования будет нивелирована до офисного клерка-программиста, а оставшеие 2% поглотят монополисты. Так то я добрый - это реальность жестокая.
И где минусы?
Я считаю это риторический вопрос о том, кем лучше. Все люди разные и ситуации разные: Одно дело или ты тимлид арбитражной команды и это тобой собранная команда или ты тимлид в найме, где тебе ставят в определённые не совсем комфортные условия, мягко говоря)). Вобщем каждому своё, мне и как одинокому фрилансеру вполне норм, если бывает переизбыток заказов, то раздаю знакомым за % и не парюсь)
Любая работа/роль - походит не для всех. Многие не смогут потянуть работу сениора, многие не потянут работу тимлида или архитекта или тех.дира - и это абсолютно нормально. Если это не твоё - не надо себя мучить. Надо найти то, что подходит лично тебе (а для этого полезно пробовать разное), и стараться большую часть времени заниматься именно этим. А ещё не надо думать, что все такие же, как ты - это не так, все очень разные! И если автору не подошла роль тимлида и в ней для него обнаружились только одни минусы - не надо думать, что так для всех.
Поэтому я не буду говорить за всех, я скажу лично за себя: исходя из моего личного опыта всё описанное в статье полная чушь! Нет, я понимаю, что где-то бывает и так, но в описанном в статье виноват по большей части сам автор. Давайте разберём по пунктам:
Тимлид — это крайний чувак без рычагов влияния
У тимлида полно рычагов влияния! Он представляет всю свою команду перед тимлидами других отделов, перед архитектом, тех.диром, а в некоторых компаниях и перед внешним заказчиком. Для них всех его мнение - это мнение всей его команды. Именно с ним они все согласуют что команда может, а что нет. Это даёт возможность управлять тем, какие задачи и в какие сроки будет решать его команда. Аналогично и с другой стороны: для команды основной начальник - это тимлид, они делают то и так, как он скажет. А это даёт возможность управлять тем, как будет разрабатываться проект: ставить процессы (включая как технические - типа как команда пишет тесты, как делается ревью, как управлять тех.долгом, какие инструменты использовать, etc., так и не технические - напр. как поставлен процесс обучения, контроль выгорания, etc.). Ну и плюс если тимлид очень хочет кого-то уволить - обычно никто из его собственных руководителей ему мешать не станет. Если тимлид аргументированно расскажет тех.диру что кому-то в его команде нужно повысить з/п или что нужно кого-то нанять - если у компании в принципе есть на это средства то обычно к нему прислушаются (ну потому что он единственный обычно реально владеет такой информацией).
При этом Вы абсолютно правы в том, что команду обычно тимлид получает собранную не им, что финальные решения принимает не он, что финансы и найм ему напрямую неподконтрольны! И, знаете что? Это вот всё - совершенно обычная ситуация для любого менеджера. А тимлид (в отличие от тех.лида) - это таки менеджер, пусть и только половину своего рабочего времени. Идеальных условий, в которых у менеджера есть все необходимые ресурсы для решения (правильная команда, достаточно денег, возможность принимать любые решения) поставленной бизнесом задачи - практически не встречается в реальной жизни. И работа хорошего управленца (менеджера) как раз в том и заключается, чтобы в этих условиях справляться с поставленной задачей. Не устраивает команда - обучи её сам (или найди того, кто это сделает за тебя и для тебя) или сумей убедить руководство сменить команду или сумей убедить руководство что для текущей команды нужно ставить другие задачи (с которыми она в состоянии справиться). Но нередко достаточно просто иначе декомпозировать и перераспределить задачи между членами команды - а это полностью во власти тимлида, - чтобы существующая команда "потянула" поставленные задачи. Недостаточно денег - найди способы использовать альтернативные мотивации для команды, научись обменивать не очень нужные тебе ресурсы своей команды на что-то более нужное.
Ненормированные обязанности
С одной стороны описанное Вами правда, но с другой - это смешно читать. Ну примерно как если бы программист жаловался на то, что ему не только функции нужно писать, но ещё и глобальные константы объявлять, причём код нужно нередко писать не в одном файле а в куче разных, причём используя не один язык программирования а ещё и всякие странных DSL вроде protobuf, Makefile, SQL, etc., причём писать не только код но ещё и юнит-тесты, и, о ужас, не только писать код но и ревьювить код коллег, да ещё и культурно оформлять свои замечания на ревью…
Реальная обязанность у тимлида ровно одна, причём это верно для абсолютного большинства компаний: он должен сделать так, чтобы его команда успешно закрывала требуемые задачи в требуемые сроки (ну, хотя бы чтобы они не срывали эти сроки совсем уж неприлично сильно). Всё остальное, что Вы там перечислили - это просто средства достижения этой задачи. И никто не заставляет тимлида заниматься большинством этих задач - он сам принимает решение что и как делать, а чего из этого не делать. А ещё, как менеджер, надо уметь не только делать самому, но и делегировать.
В общем, вся эта суматоха и перегруженность связаны с неумением делать работу тимлида. Это норма для всех новичков, просто со временем кто-то научится, а кто-то поймёт, что эта роль не для него.
«Радость» быть играющим тренером
Потеря хард-скиллов
У вас оставалось слишком мало времени на написание кода потому, что всё время уходило на суматоху в попытке изобразить из себя менеджера. Если научиться справляться с ролью менеджера, то на код остаётся более чем достаточно времени - не столько, сколько у сеньора, но потеря квалификации точно не грозит. А за счёт того, что тимлид сам выбирает какие задачи он будет делать, то наоборот, возможностей для повышения квалификации (в рабочее время) у него заметно больше, чем у обычного разработчика.
Куда приводят мечты
Нет, переход из тимлидов в сениоры ничего не говорит о тупике в карьере. Просто до перехода в тимлиды разработчики шли по техническим ступенькам карьеры (джун-мидл-сениор), и не всегда осознают, что переход в тимлиды это шаг в сторону совершенно другой, управленческой ступеньки карьеры (следующей ступенькой в которой обычно является тех.дир, и вот он уже код не пишет вообще). Поэтому пробуют, выясняют что лично им это не подходит, и возвращаются обратно на техническую линию - там вполне можно развиваться дальше в ведущего разработчика, тех.лида, архитекта.
А что по деньгам?
Честно говоря, деньги слабо зависят от квалификации. Зарплата в значительно большей степени определяется умением себя "продать", нежели техническими навыками. Но вообще тимлиды обычно получают максимальную зарплату сениора или чуть выше - не настолько, чтобы это было прям принципиально, но всё-таки выше. Но я согласен, что чисто ради денег идти в тимлиды - глупость, оно не окупится если нет желания помимо технических навыков активно тренировать и использовать управленческие навыки.
Вендорлок на работодателя
Выше в комментариях уже написали: ровно то же самое происходит и с разработчиками, которые много лет сидят на одном проекте. Это никак не связано конкретно с ролью тимлида.
Мифическое влияние на результат
Я выше уже описал реальные возможности влияния тимлида на всё, что происходит в его команде. Тут нет никакого мифа. Мифическое влияние было конкретно в Вашем случае, и связано это не с ролью тимлида, а с тем, что Вы её ниасилили.
А теперь немного о себе, для конкретики. Я последние лет 20 нередко работаю совмещая роли архитекта, тимлида и ведущего разработчика. Мне так комфортнее всего. Роли архитекта и тимлида дают необходимые мне возможности влиять на проект и команду, чтобы в результате команда могла эффективно работать над осмысленными задачами правильным образом. А ещё я люблю писать код и не хочу от этого отказываться, поэтому попробовав себя несколько раз в роли тех.дира я отказался от идеи двигаться в эту сторону (хотя у меня это довольно хорошо получалось и мне это легко давалось), максимум на что я готов - на роль заместителя тех.дира по той части задач, которыми мне комфортно заниматься. Совмещая всю эту кучку ролей я вполне справляюсь с тем, чтобы писать код не менее 40% рабочего времени, так что с моими хард скиллами всё отлично. Да, чтобы со всем этим справляться мне пришлось сильно прокачать как технические навыки, так и управленческие - но ничего невозможного в этом нет.
Резюмируя - роль тимлида совершенно точно не для всех технарей-сениоров, но она прекрасна и даёт кучу возможностей тем, кто готов помимо технических навыков прокачивать и управленческие.
ставить процессы (включая как технические - типа как команда пишет тесты, как делается ревью, как управлять тех.долгом, какие инструменты использовать, etc., так и не технические - напр. как поставлен процесс обучения, контроль выгорания, etc.)
Так процессы могут быть навязаны сверху. Предположим, проект очень большой, и на нём работают много команд. У каждой есть свой тимлид. Скорее всего архитекторами и HR-менеджерами будут спущены инструкции по всем процессам, иначе команды не смогут работать согласованно и быть взаимозаменяемыми. В этой ситуации тимлид почти ничего решать не будет.
Некоторые процессы - безусловно. Но не все. Потому что проекты и команды разные, и им лучше подходят разные процессы. Сверху могут навязать вещи вроде использования монорепо, гайдлайнов по безопасности и т.п., но во-первых всё ещё останется немало других аспектов, и во-вторых никто же не запрещает тимлиду пытаться согласовывать изменения в этих, общих для всей компании, процессах - как для всей компании так и в виде исключений для его команды.
Простой подход "захотел - решил - реализовал" в управлении не особо часто работает. Потому что в одной трети ситуаций "решить" нет прав (такие вопросы решает более высокий начальник) а в другой трети ситуаций на "реализовал" нет ресурсов (получение которых требует временами совершенно неочевидных телодвижений). Поэтому нужно уметь разговаривать с людьми, включая не только подчинённых, но и собственных коллег из других отделов и начальство, и убеждать их сделать то, что тебе нужно. Но если этого не уметь делать, то менеджер по сути не управленец, он ничем не управляет, ничего сам не решает и ни на что не влияет, он просто "передаст", транслирующий вниз указания сверху. Более того, даже трансляция указаний "вниз" - это не такая простая задача, как кажется. Нередко нужно уметь прикрывать команду "собой" от бреда, нередко спускаемого сверху - когда с одной стороны ты отвечаешь за выполнение этого бреда, а с другой грузить им команду нельзя, и нужно сделать вид что всё выполнено делая при этом совершенно другое. Потому что если тупо транслировать всё это на команду - она и разбежаться может.
Совмещать можно хоть с оператором кофемашины, важно то какая у тебя лычка в официальном списке персонала. Если там написано сеньер разраб - значит ты он и есть, а все остальные регалии (архитект или лид) можно разве что у себя в резюме дофантазировать, а можно в комментах на хабре приписать. Де Юре все равно сеньер-помидор. Если я вчера был на созвоне с девопсами, я конечно могу в резюме написать чушь вроде senior tomato AAA+ (git ops engineer in law), но обычно просто добавляю скромно "знаком с git ops" 😁 Все разрабы так или иначе, начиная с мидла корябают арх документы в каком конфлюенс, кто-то даже на регулярной основе, но это не делает нас архитекторами. По сути у тебя доступ только к перепланировке апартаментов есть, в то время весьма расплывчатое понимание, работаешь ты в Бурдж-халифа или Москва Сити) С уровня разработчика нету ознакомления с архитектурным видением и планами поэтапного перехода к следующим эволюциям архитектуры. Все это прилетает сверху уже достаточно пережеванным в виде конкретных задач.
Лично мне работа тимлида не особо нравится, но бабки он получает хорошие. Примерно, мидл тимлид получает как сеньор программиста.
Кажется, восприятие позиции тимлида просто чересчур романтизировано. Описанные проблемы имеют место быть, но я воспринимаю их как конъюнктурные вводные условия задачи. Если конъюнктура не устраивает, значит не поняли свою позицию и задачу.
Ну можно, например, поручать команде делать скучные и рутинные операции, а себе оставлять интересные, творческие, требующие некоторого челленджа. Решать по 4 часа в день сложные и интересные задачи с полной отдачей вполне достаточно, чтобы не только не растрачивать навыки, но и развиваться. Это даже более эффективно, чем по 8 часов в день писать рутинную нудятину. А остальные 4 в день посвятить болтовне, переписке и рисованию отчетов.
Проблема, что на позиции тимлида может не быть этих 4 часов в день на решение задач. Зачастую происходит так, что у тебя остаётся всего 2-3 часа на кодинг, да и те между несколькими созвонами, от которых устаешь уже самих по себе. Да и оставишь подчинённым только скучный багтрекинг, они быстро выгорят и пойдут искать компанию получше.
Я работаю лидом. Уже довольно давно. Я ещё в 25 лет стал "мамкиным тимлидом". Судя по уровню моей тогдашней квалификации, скорее даже бабкиным, а не мамкиным)). Потом, когда поменял работу перестал быть лидом и долгое время даже не вспоминал. Сейчас снова работаю. На звонки, видеосовещания, переписку трачу примерно 2-3 часа в день. Выделяю на это дело ежедневное окно, желательно так, чтобы оно было неразрывно, т.е. чтобы эти вещи шли подряд, а потом меня уже не отвлекали и я мог спокойно работать не дёргаясь. Как правило получается - не каждый день, но примерно 4 дня в неделю из 5 удаётся уместить все созвоны, совещания и переписки в одно сплошное окно. Это, к слову, тоже менеджерский навык, умение убедить коллег, в том числе и своё руководство, что о том, что давайте общаться в строго отведенное время и без излишнего затягивания. Потом пару часов перерыв, чтобы отдохнуть, переключиться, и настроиться и, собственно 4 часа продуктивного программирования без рассеивания внимания.
оставишь подчинённым только скучный багтрекинг, они быстро выгорят и пойдут искать компанию получше
Какие нежные. А лид что не человек? Ему необходимо выгорать ради других? Это уже какая то позиция жертвы.
Команде при этом достаются менее интересные задачи. Да, так. Зато я беру на себя процессы, которыми они не хотят заниматься. Ну и потом это хоть и небольшое, но преимущество начальника - распределять задачи, кто что будет делать.
То, что далеко не везде удаётся тратить на созвоны и написание отчетов пару часов в день, это правда. Зависит от организации, да и от самой задачи над которой работаешь. Бывает, что процессы в организации посроены так, что вообще весь день приходится совещаться. К сожалению такое встречается довольно часто. Но не везде.
Вот тоже примерно похожая ситуация. Даже получается меньше звонков-переписки и другой "менеджерской" работы. Но плюс менторство.
В итоге где-то 60% пишу код, 20% менеджер, 20% ментор. В целом нормально и мне нравится.
П.С. Но должен сказать что мне с командой очень повезло. И когда мне предложили стать лидом я уже знал с кем буду работать. Иначе я бы на такое точно не подписался.
Мы последний год в компании активно занимались тем, чтобы большей части «Какие нежные. А лид что не человек?» вернуть обратно лычку разработчика, у которого в job description эти задачки решать и написано.
Честно — сработало очень приятно. «Интересные задачи» делаются сильно быстрее когда у человека на них все ментальные ресурсы, а не «остаток после встреч», команды намного меньше плачут о посредственных процессах, и что никто им с карьерным ростом не помогает. Продакты не страдают от людей с которыми хрен договоришься или с которыми «вы не вместе проблему решаете, ты просто им манипулируешь чтобы разработка сделала как попросишь»
Потому что лид, блин, человек, просто в идеале немного отличающийся по системе ценностей от разработчика и сводится она например к «мне важно какой в итоге результат и чтобы всем все нравилось», а не «смотри какую приколюху я написал / спроектировал» или «я теперь особенный разработчик у кормушки с раздачей тасок, буду самое вкусное выбирать»
(Людей отдали оставшимся лидам, но тут вероятно у нас был прекос что у многих лидов было 4-6 подчиненных и две такие команды одному взять не перегруз)
поручать команде делать скучные и рутинные операции, а себе оставлять интересные, творческие
тимлид с нулевой эмпатией это топчик, соболезную команде)
Тимлидерство - вариант для тех, кто захотел метнутья в менеджеры или не вывозит на сеньора, или банально решил, что так поднимется по зарплате. Если хороший "техник" пойдет в тимлидеры, это станет для него в будущем тупиком и разочарованием. Кому-то нравится вытирать сопли другим, мирить, договариваться, ставить в угол, получать "мокрыми тряпками" за свою команду и прочие менеджерские моменты, таким тимлидерство зайдет. Таков мой суровый опыт 😄
С автором полностью согласен.
Год назад я писал статью похожую.
https://habr.com/ru/articles/756286/
Почитав комментарии я понял что часть людей уходит туда потому что либо по выслуге лет никто лучше них проект не знает - это фактически техлид. Либо те, кто хотят заниматься архитектурой и проработкой задач - что по сути либо архитектор, либо тот же техлид. Поскольку мало кто может предложить разделение ролей на 2х людей, получаем что пипл менеджмент скорее неприятный довесок к техническому менеджменту. Я год уже работаю на позиции сеньора (после 4х лет менеджмента) и единственнач причина почему хочется уйти в Лиды - меньше технического менеджмента сверху. В целом иногда везёт, и ты будучи сеньором можешь тащить проекты без микроконтроля. Но сильно зависит от Лида.
Когда соискатель говорит "я хочу быть тимлидом", это нужно понимать как "я хочу зарабатывать, как тот, кого называют тимлидом". Однако, если работодатель говорит "мы ищем тимлида" вы должны это читать как "мы ищем человека, на которого можно возложить ответственность за достижение поставленных бизнесом целей и спрашивать с него, если что-то пойдет не по плану".
Согласен с автором. Был Тим лидом, заметил как теряю в Хард скилах, устал трепаться на митингах ради митингов. Был архитектом, там я вообще программировать разучился. Нудноватая работа надо сказать, писанина в Ворде и рисование. Сдауншифтился в сениоры и чувствую себя отлично. Пишу код, могу систему задизайнить, если надо, да с оунерами порешать если непонятки. По-моему так и надо карьеру строить
Архитекты нынче разделились на несколько разных ролей/тайтлов. Application/Software архитект достаточно близок к коду, немало его пишет сам, много ревьювит, а в плане документов чаще всего пишет ТЗ на разные модули/микросервисы. Вам такое вполне может зайти. А вот Solutions архитект и прочие Enterprise архитекты - там да, никакого кода, одни только документы.
Меня сильно разочаровывает факт, что люди сейчас в 90%+ случаев работают ради денег и собственных интересов (это в целом, не про статью).
Если бы вы работали ради идеи, у вас не было бы таких вопросов, потому что должность руководителя это возможность сделать продукт лучше, помочь пользователям, оказать влияние на слабые места чтобы в конечном итоге улучшить продукт и принести больше пользы обществу.
10 лет работал лидом на больших продуктах
Напишу коротко – пользователи превыше всего, и мы как специалисты применяем свои навыки чтобы помочь людям.
Одни умеют хорошо ремонтировать автомобили, а мы – создавать программные продукты, которыми ежедневно пользуются много людей. И поэтому не имеют значения ни хард-скиллы, ни подходы, всё это, включая саму должность руководителя, лишь инструменты в достижении цели. Поэтому руководитель – это просто опытный и ответственный товарищ, который в силу своего опыта умеет правильно направить развитие продукта, помочь пользователям и достигнуть целей для бизнеса.
Поэтому написанное в статье – я лично не понимаю этого.
Если вы хороший специалист, у вас есть опыт, вам интересно помочь обществу (если продукт большой) – преград просто нет, а карьера и всё остальное, это вторичное, оно само придет.
Меня сильно разочаровывает факт, что люди сейчас в 90%+ случаев работают ради денег и собственных интересов (это в целом, не про статью).
Как то много пафоса в ваших словах. «Принести больше пользы обществу»
Мы живем в капиталистическом мире. И у каждой коммерческой организации в уставном договоре написано «основная цель деятельности - извлечение прибыли». Здесь все про деньги. Коли людям хочется кодить для души да для мира во всем мире - они пишут опенсорс.
Где противоречие? Если кто-то платит, значит им это нужно. Значит то, за что они платят, им помогает. Если исключит несколько сомнительной моральности индустрий вроде азартных игр, то наращивание доходов своего предприятия происходит как раз через увеличение пользы обществу
Ага. Расскажите эту сказку людям, чей труд вы автоматизировали оставив их без работы. Вот уж сделали хорошо обществу :) Я могу понять когда речь идет например о методах диагностики рака и ранних смертях. Но не об автоматизации процессов ибо это все про деньги
Буквально все что вас окружает сделано промышленным способом благодаря автоматизации. И вся автоматизация во все времена кого-то оставляла без работы.
Отменяем промышленную революция и возвращаемся в средние века?
Да, в чистом виде капитализм. Достижение благ одними членами общества за счет других. Я не против этого. Такова жизнь. Но выдавать это за всеобщее добро - и есть пафос. Одни люди страдают, другие преобретают. Прогрессивно - да, двигаемся вперед да. Всеобщее благо - нет
А кому хуже жить стало? Возьмем с начала автоматизации. Когда все это началось. Век 17 примерно. И сейчас.
Жили бы как тогда. 90 процентов населения работает по 12-18 часов только чтобы поесть. В случае неурожая голод и вероятно смерть.
Бухгалтерии жить хуже стало. Если раньше нужен был целый отдел, то сейчас 2-3 человека. Да вообще речь не об этом. Вы мысль мою поняли? Нельзя считать по определению всеобщим благом ситуацию в которой страдает хоть кто-то.
Ну чисто по семантике
А выше никто и не писал про "всеобщее благо". Выше писали про "пользу обществу".
А польза обществу в целом вполне себе может быть даже если какие-то отдельные части общества при этом страдают. Более того вы вообще вряд ли найдёте хоть какое-то улучшение для общества от которого вообще никто в принципе не пострадал.
С такими рассуждениями не долго дойти до немецкой программы Т4.
Они там немощьных немцев уничтожали во благо общества. В целях экономии.
В теории можно дойти и до этого.
А можно дойти до того, до чего дошло современное немецкое общество. То есть переобучение за счёт общества для тех кто потерял работу. И создание рабочих мест за счёт общества. И оплата социальной помощи для тех кто всё равно не нашёл работу.
А с вашим подходом прямой путь в неолуддизм. От которого и обществу в целом будет хуже и большинству людей в этом обществе.
Бухгалтерии жить хуже стало. Если раньше нужен был целый отдел, то сейчас 2-3 человека.
Какие минусы? Куча народа может теперь заняться более полезной для общества деятельностью. Сводить отчеты для налоговой это не самая полезная деятельность.
Нельзя считать по определению всеобщим благом ситуацию в которой страдает хоть кто-то.
То есть все еще отменяем промышленную революцию и возвращаемся в средние века? Тогда исчезли просто целые сектора экономики.
Если кто-то автоматизирует процессы, то это обычно делается не просто так, а чтобы снизить расходы.
Соответственно из-за этого производство становится дешевле, а товары доступнее.
То есть конечно какие-то отдельные люди из-за этого теряют работу, но общество в целом от этого выигрывает.
Я приведу примеры почему не только про деньги
Быстрее производство = больше возможностей пользователям, увеличение эффективности в решении задач. Поэтому это в том числе и про пользователей.
Есть речь про B2B автоматизацию (бухгалтерия, например), то это довольно редкий сценарий, и довольно спорный. Я, например, встречал и ручную бухгалтерию, и с автоматизированную, как сотрудник, и я вам скажу, что когда всё делается щелчком пальцев, удаленно, мгновенно, от справок, и до зарплаты, и не бывает ошибок, то для основной массы потребителей (сотрудники) это польза, за исключением пары бухгалтеров которые просто найдут другую работу где автоматизации пока нет.
И да, выше тоже примеры валидные, и про стоимость, и так далее.
P.S. Ошибся веткой, похоже, это было к сообщению @2ANikulin
чей труд вы автоматизировали оставив их без работы
Люди остались не "без работы", а со свободным временем. И могут распорядиться им по своему усмотрению, в т.ч. монетизировать путём устройства на другую работу.
Общее благо не обязательно означает благо для конкретного человека в конкретный краткосрочный период. Однако оно подразумевает, что и для него в том числе будет благо на средне- и долгосрочной перспективе. Если вас уволили с ткацкой фабрики, заменив станком, то вы пару месяцев походите без работы, а потом устроитесь куда возьмут и через год сможете купить своим детям одежду дешевле и разнообразнее
Ага, уволили с ткацкой фабрики и вы ушли в свободные художники. Начали творить, рисовать и кормить свою семью. Главное не обидится на весь мир за то что вас не взяли в немецкую школу искусств:)
Уволили с ткацкой фабрики - и вы пошли в токаря на станкостроительный завод, например. Или в машинисты, потому что кто-то ещё додумался приспособить паровую машину от станка вместо лошади. Прямо или косвенно, в том числе через очень неявные связи, открылось по одному рабочему месту на каждое закрытое, а бонусом ещё и товары становятся дешевле и лучше, качество жизни растёт. (Лично для вас в ближайшие полгода-год всё весьма неприятно - но это не убыток, а инвестиция)
"вы не уволены, а из разработчиков повышены до клиентов компании" (с)
В том и беда, что сейчас если человек хочет работать и стараться ради других людей, то это пафос, а не нормальное течение вещей.
Меня сильно разочаровывает факт, что проекты сейчас в 90%+ случаев - лютый мусор
Меня сильно разочаровывает факт, что люди сейчас в 90%+ случаев работают ради денег и собственных интересов
Простите, а ради чего предлагается работать в найме? Ради интересов Кабан Кабаныча?
Интересно, почему тогда люди вообще работают тимлидами, что их мотивирует 🤔
Возможность влиять на происходящее и желание сделать работу команды более "комфортной" (чтобы они меньше делали бесполезных задач странными способами, чтобы меньше выгорали, чтобы больше развивались и в целом были больше довольны текущей работой).
В целом согласен, но лидер это не только про это. Даже это вот желание сделать работу команды более комфортной - это же не получится, если команда работает не эффективно. То есть лидер - это и про ответственность. И за команду, и за проект.
Возможно Вы прочитали слово "комфортной" и упустили всё, что написано после него. Описанный мной "комфорт" - это не про "работать меньше", а как раз про "работать продуктивнее". Так что с ответственностью при таком подходе всё будет хорошо, команда с таким тимлидом будет эффективнее решать задачи бизнеса.
Ну, чисто формально, даже "меньше делать бесполезных задач" строго говоря не означает "делать больше полезных" :) В общем, я совершенно согласен с такой постановкой, это было просто небольшое уточнение другими словами - что ответственность за продуктивность остается, и именно достигнутая продуктивность позволяет тимлиду скажем ходить к руководству и просить прибавки команде зарплаты. И в общем-то это все - именно то что меня лично мотивирует в этой работе.
У меня коллега был отличным разработчиком и хорошим человеком - всегда поможет и подскажет, а тимлидом стал не просто плохим, а хуже некуда - оказалось, что навыков разработчика для хорошего тимлидства недостаточно, а нужно еще уметь в психологию, грамотно управлять людьми, а главное - самим собой. Кто бы мог подумать...
И что хуже всего - он проблемы совершенно не видел и не понимал. Все бывшие коллеги, а теперь его подчиненные у него резко стали лентяями и неквалифицированными бездарями. Токсичность зашкаливала.
Слава Богу, что все закончилось хорошо - после того, как у него ушло полкоманды, его самого уволили с этой позиции.
Сейчас работает в другой компании, обычным разработчиком, и снова стал тем самым хорошим человеком, каким и был до тимлидства)
Тимлид — это крайний чувак без рычагов влияния
Никто не даст Тимлиду, как другому руководителю никаких рычагов влияния и полномочий.
Их надо определять и брать самому, понимая, чем занимается команда, куда должна развиваться, в каких процессах и границах ответственности она работает, при каких ограничениях, и какие проблемы имеет.
Брать знанием основных и вспомогательных процессов, участием в комитетах, грамотной аргументацией.
Нужно быть готовым работать в условиях неопределенности и получать от этого удовольствие, даже если в определенный момент ваши усилия обнулят инициативы, трансформации или кризисы вашей организации.
В разогнанной развивающейся организации это всегда или некоторая непрерывная экспансия или защита своих границ.
Если думать в этих категориях и решать сопутствующие задачи не интересно, наверное не стоит рассматривать для себя эту должность.
Очень распространена ситуация, когда Тимлиды - это хорошие исполнители, которые хоть и справляются со своими задачами, но ввиду отсутствия желания думать и развиваться в категориях управления, крайне недовольны своим положением, постоянно находятся в тревоге и стрессе и выгорании.
На самом деле все минусы работы тимлидом, описанные вами в статье, это прямое следствие нарушения принципов делегирования по отношению к тимлиду:
Команду часто собирает не тимлид, а организация и предоставляет её ему.
Финальные решения часто принимаются не тимлидом, а архитектурным комитетом или продуктовым менеджером.
Часто рычаги влияния на команду (финансы, найм, приоритеты бэклога) напрямую тимлиду не подконтрольны.
Если тимлиду официально не дают полномочия, необходимые для выполнения его прямых обязанностей, то тимлид оказывается в роли козла отпущения. И, к сожалению, в последнее время я с такой ситуацией сталкиваюсь всё чаще и чаще.
Лично я в последние годы начал просто отказываться от офферов, если на этапе собеседований не мог договориться об устраивающем меня балансе полномочий и обязанностей. Но, даже чёткие договорённости на этапе собеседований не всегда срабатывают. К сожалению, далеко не всегда работодатель считает нужным соблюдать достигнутые договорённости. В таком случае приходится просто увольняться.
Тоже обратил на это внимание - в статье описывается роль не тимлида, а какого-то "козла отпущения" - ты ничего не имеешь, но с тебя все требуют. Я сейчас подобную роль занимаю - людей сам набираю, сроки сам ставлю. Нравится это тем что в итоге возможностей стало больше - ты можешь сделать не только одну фичу, как девелопер, а полноценный продукт (силами других девелоперов, конечно :-) ). Ну или просто распараллелить себя - я знаю как делать, ставлю чёткие задачи, и дальше трекаю. И так может несколько больших фичей разрабатываться. Один я может одну фичу и быстрее бы сделал, но так сразу несколько фичей делается.
Зависит от компании, но в больших компаниях часто тимлид - это вот такой получатель по жопе. Уволить кого-то или повлиять на премию - очень сложно. С одной стороны компания хочет перестраховаться от злоупотреблений. А с другой получается что нормальным сотрудникам приходится прикладывать х2 усилий чтобы чего-то добиться.
У меня был вопиющий пример, когда мне наняли сотрудника без моего участия в тех. собеседовании. Спустя 1.5 месяца стало понятно что он не тянет совсем. Обратную связь я начал выдавать уже спустя 3 недели. В итоге я принял решение его уволить, и несмотря на то что он был на испытательном, это вызвало просто массу негодования у моего руководителя и hrbp. Что нужно было дать ему ещё шанс и уволить его в конце 3 месяца(зачем?). В целом ребята согласились с моими доводами(человек к тому же ещё был токсичным и наговорил гадостей мне при увольнении), но сказали что все равно можно было ещё подождать. С тех пор я как-то охладел к такому вот "менеджменту".
Искусство управления - оно такое… есть разные рычаги влияния. Начинать, конечно, нужно с обычных уточняющих вопросов: для чего нужно ждать до конца 3-его месяца? Вполне возможно, что у них какие-то свои KPI (а бывает что и коррупция). Если они про это честно скажут, то тогда у Вас появляется возможность дёшево (просто потерпеть новенького немного, при этом даже особо общаться с ним не нужно) оказать им услугу, и в будущем получить ответную услугу - что обычно весьма ценно. Если они нормально разговаривать не хотят - то это проблема сама по себе, которую может иметь смысл эскалировать выше. И новенький тут - уже не проблема сама по себе, а удачный кейс, позволивший оперативно выявить более серьёзные проблемы и начать их решать. Если возможности культурно эскалировать нет, то всегда можно сделать это не очень культурно - например сняв с новенького все текущие задачи, сказав ему открыто что он будет уволен в конце 3-го месяца а до этого пусть делает что хочет, и на всех созвонах (не со своей командой, конечно) не забывать упоминать, что твоя команда "недоукомлектована", потому что новенький работу делать не в состоянии и бездельничает в ожидании увольнения… рано или поздно это безобразие дойдёт до более высокого начальства, и произойдёт та самая "не очень культурная" эскалация.
Понятно, что во многих спорных ситуациях можно вырулить даже без официальных полномочий за счёт умения вести переговоры и манипулировать людьми. Но тут вопрос в другом. А стоит ли тогда вообще выруливать? По факту получается, что на всю эту подковёрную грызню приходится тратить на порядок больше времени и сил, чем оно того стоит. А время это и силы находятся за счёт того, что приходится откладывать сильно на потом по настоящему важные и нужные дела. Мне кажется, что в такой ситуации стоит задуматься о том, что ты скорее всего играешь не в те игры, не с теми людьми, и не по тем правилам, по которым в принципе стоит играть.
А стоит ли тогда вообще выруливать?
Стоит. Потому что мы живём не в идеальном мире, и выруливать потребуется практически на любой работе и в любой компании. Исключения (a.k.a. "заповедники") встречаются, но слишком редки, чтобы на них всерьёз рассчитывать. Хороший начальник создаст такой "заповедник" для своих подчинённых, но сам он всё-равно будет вынужден "жить в дикой природе".
По факту получается, что на всю эту подковёрную грызню приходится тратить на порядок больше времени и сил, чем оно того стоит.
Ну, тут как везде - по мере получения опыта количество времени и сил, которые уходят на эти глупости обычно сильно уменьшается. Я сейчас такие кейсы придумываю и реализую просто "на ходу", и времени это занимает не очень много.
А время это и силы находятся за счёт того, что приходится откладывать сильно на потом по настоящему важные и нужные дела.
Это некорректный (точнее, наивный, уж простите меня за прямоту) взгляд на вещи. Поскольку без "этих глупостей" как правило нормально работать невозможно, то кто-то ими должен заниматься. И это не менее "по настоящему" важное и нужное дело - потому что без него другие дела делать не получится.
Мне кажется, что в такой ситуации стоит задуматься о том, что ты скорее всего играешь не в те игры, не с теми людьми, и не по тем правилам, по которым в принципе стоит играть.
А вот это - очень здраво! Да, невозможно совсем не заниматься политикой (будем прямо называть эти грязные игры своим именем :-)) и быть при этом эффективным управленцем. Но вот процент времени и сил, который уходит на эти игры - должен быть в каких-то приемлемых рамках. И вот это уже зависит от конкретной системы (обычно - компании), в которой вы оказались. И да, в тех, где большая (или даже просто значительная) часть времени уходит на политические игры, лучше вообще не работать. Но и сразу сбегать из тех, где это потребовалось в минимальном объёме - бессмысленно, оно будет нужно везде, где вы работаете не один, а в коллективе, потому что это всё просто следствие человеческой природы.
Но и сразу сбегать из тех, где это потребовалось в минимальном объёме - бессмысленно, оно будет нужно везде, где вы работаете не один, а в коллективе, потому что это всё просто следствие человеческой природы.
Не могу не согласиться с вашими доводами. Мы, конечно, живём не в идеальном мире. И, определённую гибкость нужно проявлять.
Но, на мой взгляд, некоторые красные линии нельзя позволять пересекать. Есть маркеры, когда нужно начинать действовать жёстко и решительно.
Первый маркер - это нарушение четких и недвусмысленных договоренностей, достигнутых на этапе собеседований. Если рабочие взаимоотношения начались с прямого обмана, то ни чем хорошим они не закончатся.
Второй маркер - это хамство, агрессия и токсичная атмосфера, что тоже нередко встречается. Во первых хамство, особенно публичное, в отношении руководящего работника (да и вообще в отношении любого человека) резко снижает социальный статус жертвы в коллективе, и лишает его возможности выруливать в сложных ситуациях. Во вторых это крайне негативно сказывается на психологическом здоровье, что в будущем может очень неприятно аукнуться.
Так-то да, но есть нюансы.
Нередко "чёткими и недвусмысленными договорённостями" они кажутся только одной из сторон, а вторая поняла то же самое несколько иначе - и тогда это довольно типичное для всех людей недопонимание. И перед тем, как принимать решение что тут явный обман нужно сначала спокойно этот момент прояснить, а уже потом переходить к резким телодвижениям вроде увольнения. И ещё. Нередко встречается ситуация из анекдота "ну значит не получилось" - попытка обмануть/прогнуть, но если оказать сопротивление то с тобой будут работать честно. На мой взгляд, в таких ситуациях всегда стоит для начала оказать это сопротивление, выправить ситуацию, а потом уже решать, оставаться там работать или уходить. Если это выглядит как первая и последняя попытка такого поведения, т.е. по сути это входной фильтр, который разделяет новых сотрудников на тех, кого можно нагибать, и кого нельзя - то это может быть приемлемо. В конце концов те коллеги, кого тут успешно нагнули, тоже получат ценный опыт, и, в идеале, возможно таки научатся отстаивать собственные границы (тем более, что я обычно не стесняюсь им про такое рассказывать, чтобы они понимали где и как их прогнули, и что это было совершенно не обязательно).
Что до хамства, то тут тоже не всё так однозначно. Конечно, если такая атмосфера во всей компании, то работать там не стоит. Но если это один-два неадеквата, то, на мой взгляд, лучше эту проблему решать, а не сбегать от неё. И я категорически не согласен, что хамство в чей-то адрес снижает социальный статус цели! Социальный статус снижает не хамство, а последующая реакция того, кому нахамили. А эта реакция - целиком в ваших собственных руках. Если не стоить из себя жертву, то обычно ситуацию несложно повернуть в противоположную сторону, чтобы глупо и бессильно выглядел хам, а не вы.
Знаете, когда я был помоложе, я про эти ситуации думал так же, как вы. Но с возрастом понял, что аргумантация, которую вы приводите, работает только в краткосрочной и среднесрочной перспективе. А вот если расширить горизонты, то работать она перестаёт.
Ну да, бывает, что кто то внезапно "не так понял" чёткие устные а потом и письменные договорённости. Ну поговорили. Ну прояснили ситуацию. Всё решилось мирно.
Ну кто то попытался сходу продавить. Ну, проявил твёрдость. Не прогнулся.
Ну нахамил тебе начальник. А ты пропустил мимо ушей, а потом ударной работой доказал всем, что он был не прав.
Всё это и вправду работает. Но потом, когда в ретроспективе начинаешь анализировать этот период своей карьеры, то внезапно понимаешь, что не стоило даже и начинать. И что годы потрачены впустую. А ты то при этом не молодеешь. И времени у тебя больше не становится.
Поэтому с возрастом я изменил своё мнение по этим ситуациям. Есть условия, на которых я работаю. А есть условия, на которых я принципиально не работаю. И ни на какие компромиссы я в этих вопросах не иду.
Есть условия, на которых я работаю. А есть условия, на которых я принципиально не работаю. И ни на какие компромиссы я в этих вопросах не иду.
Всё верно, у меня ровно то же самое. Просто, вероятно, у нас с Вами отличается список этих самых условий: что критично, а в чём можно проявить гибкость.
Я довольно снисходительно отношусь к человеческим недостаткам (вроде вышеупомянутого желания прогнуть или нахамить). Зато в отношении некоторых технических вопросов у меня совершенно принципиальная позиция, например быстро-грязно говнокод ни я ни моя команда не пишем (и вытекающие из этого частные требования наличия доки, тестов, CI/CD, etc.), даже если это именно то, что нужно в данный момент бизнесу - просто потому, что мне это не интересно и я не хочу тратить время своей жизни на такую работу.
Вопросов было задано на тот момент предостаточно, а вот ответов получено крайне мало. Единственная причина(ну это мое мнение) почему возникла данная ситуация это микроменеджмент со стороны вышестоящих людей(точнее одного). В больших компаниях это поставлено на поток. Там центр принятия решений находится на уровне direction/unit lead т.е. тот кто управляет лидами. А лид в их понимании это такой метасеньор, который больше технарь чем управленец. При этом я знаю, что есть компании где нет таких проблем и лидам вполне себе доверяют принимать такие решения(если они обоснованы), но кажется это капля в море.
В микроменеджмент на таких высоких позициях мне верится слабо. Обычно микроменеджментом грешат линейные менеджеры низшего звена (тимлиды и упомянутые в других комментах продакты), и то не очень долго. Потому что это во-первых очень тяжело и во-вторых толком не работает. Поэтому чем ты выше в управленческой иерархии тем выше вероятность, что ты этот урок уже усвоил, иначе бы ты просто туда не поднялся. (Бывают, конечно, исключения - напр. когда на должность ставят не за соответствующую квалификацию, а потому что родственник/свой человек, и хотя он толком не справляется его всё-равно не уволят.)
А вот когда кто-то наверху продвигает свои личные не афишируемые интересы - это нередко внешне выглядит как странный микроменеджмент.
микроменеджмент на таких высоких позициях мне верится слабо.
Без обид, но рассуждать о том, чему свидетелем вы не были - слишком самоуверенно. Я этот вывод сделал не только на основании лишь этой ситуации.
Поэтому чем ты выше в управленческой иерархии тем выше вероятность, что ты этот урок уже усвоил
Сильно зависит. Если ты рос планомерно - да. Если ты был лидом, а потом так получилось спустя полгода стал сто компании 30 инженеров - то не факт.
Больше 10 лет отработал на позиции лид, cto, перешёл на позицию разработчика. В деньгах потерял не много, но worklife balance улучшился несоизмеримо в лучшую сторону. Руководящие должности для молодых и амбициозных, а когда в жизни заработал на все что нужно, хочется спокойствия. Подпишусь под каждым словам в статье.
P.S. после перехода прошли панические атаки)
Я тоже несколько раз возвращался на позицию просто разработчика. Но долго на такой позиции работать не мог. И дело даже не в хард скилах. С хард скилами у меня всё более чем в порядке. Проблема чисто психологическая. Я привык быть лидером. Привык принимать все решения самостоятельно. И в роли просто разработчика мне становилось тесно. И, сам того не осознавая, я начинал вести себя как лидер. Что неизбежно приводило к конфликту с официальными лидами.
Если тимлид один принимает решение за команду, том там либо джуны, либо им пора менять работу и бежать от такого тимлида
Ну, во первых, решния бывают разные. Основной тип решений, которые мне приходится принимать- это то, какие направления каким разработчикам делегировать. А какие оставить за собой. Если я принял решение о делегировании направления, то я в детали не лезу, а контролирую результаты.
Ну и по крупным архитектурным и стратегическим направлениям. Я внимательно выслушаю все замнтересованные стороны, но окончательное решение приму самостоятельно. Потому что это - моя работа.
Знаю только одного хорошего тимлида. Остальные могли чудить: играли в игры на работе, придумывали штрафы, но не давали премий, ложились спать когда команда начинала работать.
Какой-нибудь совет сеньеров намного лучше отдельного тимлида, который делает вид что все контролирует, а на самом деле всех замедляет и демотивирует.
Согласен со статьей. Пробовал, ушел обратно в разработку через 2,5 года. На мой взгляд вся эта история с тимлидством/младшим уровнем engineering manager бесполезная трата времени, где на тебе будут ездить до последнего без какой либо для тебя выгоды. Может пригодится разве что , если есть желание идти строить свой стартап. К тому же многие компании предлагают отдельный трек для роста инжинеров ( senior -> staff -> architect/principal), что как по мне намного более лучшая инвестиция времени и сил
Тимлид — это крайний чувак без рычагов влияния
Абсолютно согласен. Это и есть основная проблема.
Я тимлид, и приходилось сталкиваться практически со всеми обозначенными проблемами. Часть из них до сих пор со мной(
Уйду ли я с позиции - однозначно нет. Тех, кто ушел - понимаю полностью.
Далее субъективщина.
Надо ли становиться тимлидом? Трижды подумайте. Из 20 подопечных потенциал вижу только у двоих.
Надо ли попробовать себя в роли тимлида? Обязательно. Ради трех вещей:
посмотреть на разработку с невиданной ранее стороны;
Научиться лучше понимать мотивы окружающих (проджекты/продакты/архитекторы/бизнес и кто бы там еще на команду и ее работу не влиял);
Понять, сколько всего сваливается на вашего лида и по возможности помогать ему
Выражу возможно непопулярное мнение но мне кажется что сейчас, для больших компаний и команд, роль тимлида - это уже рудимент. Намного адекватнее мне показался подход когда есть команда адекватного размера и менеджером с одной стороны и техлидом с другой. Каждый занимается своим делом и делает это эффективно. Очень малореально это - сидеть на всех стульях во всем успевать разбираться, со всеми общаться успевать, при этом не овертаймить и не выгорать.
По хорошему, у любого менеджера должно быть в подчинении не больше 7-ми человек. Иначе он просто за всеми не уследит, вне зависимости от того, чем они занимаются. Более того, если у тимлида в непосредственном подчинении оказывается больше 7 разработчиков, то шансы на то, что он сам вообще сможет писать код стремятся к нулю (ну, предполагая что свои управленческие обязанности тимлида он выполняет честно и в полном объёме). Так что упомянутая проблема "больших" команд не специфична именно для роли тимлида, но да, для тимлидов она проявляется намного острее, чем для других менеджеров - и потому, что тимлид нередко это не очень опытный управленец, и потому, что от него ожидается что помимо управления командой он ещё и код писать должен.
Тем не менее, когда менеджером команды оказывается нетехнический человек, который сам код никогда профессионально не писал, то возникает очень серьёзная проблема: он не понимает разработчиков, их нужды и проблемы. Он не понимает что такое тех.долг, как он сказывается на морали команды и скорости разработки. Он не понимает во что проекту/компании обойдётся идея энтузиаста-техлида "всё быстренько переписать". Он не понимает как хорошая или плохая архитектура влияет на проект и команду. Он не очень понимает про выгорание. И ещё много чего не понимает. И пока он не поймёт всё это качество его управленческих решений будет значительно ниже среднего уровня, и его подчинённые будут от этого сильно страдать и увольняться.
И нет, техлид ему всё это не объяснит, потому что техлид не думает о людях, а здесь нужно именно с точки людей объяснять. А если техлид смог всё это донести до менеджера - ну значит вам повезло, и это на самом деле не техлид, а теневой тимлид, на котором всё и держится.
Согласен. По моему опыту - эта схема прекрасно работает.
А распишите обязанности тех. лида в этом случае, а то не до конца понятно, чем он будет отличаться от тим лила в отсутствии тим лида? :)
Когда над разработкой стоит человек в жизни не писавший код в продакшен все быстро начинает разваливаться. Он понятия не имеет как оценивать задачи, как нанимать, кого увольнять, что надо сделать в кодовой базе или инфре чтобы разработка улучшилась. Он даже не может оценить разработчиков и выдать им премии. Задача добавить вот тут кнопочку может занимать от дня до квартала. И человек не из разработки в жизни не отличит одну от другой.
Ваш техлид становится тем самым тимлидом без каких-либо прав. Людьми надо заниматься, а делать кроме него это некому. Если ваш техлид поумнее, то он пойдет выбивать себе права по управлению командой и станет обычным тимлидом.
Менеджер должен стоять не НАД разработкой а РЯДОМ с разработкой. По сути он выполняет функцию коммуникационного моста с бизнесом. И никаких технических решений он не принимает. Тогда эта схема прекрасно работает. Сам так запустил 2 проекта в роли техлида.
А над разработкой тогда кто стоит?
Техлид
А за что конкретно у вас отвечает техлид? Во всех фирмах где я работал и при этом были техлиды, они отвечали исключительно за какие-то технические вопросы, по хорошему вообще не связанные с проектной работой.
То есть там выбор стека, архитектура, создание внутренних библиотек для общего пользования и так далее и тому подобное.
А чем он тогда отличается от классического тимлида? Все проблемы с людьми на нем. Больше не на ком. Права тоже у него, больше их выдать тоже некому. Все разговоры о проектах, сроках, приоритетах и подобном с менеджментом тоже некому больше.
В такой схеме техлид этот тот же тимлид, но с которого сняли бОльшую часть сугубо менеджерского головняка. И он может целиком и полностью сосредоточиться на команде и на разработке.
Другой вопрос, что такая схема работает только с по-настоящему профессиональным менеджером. А это сейчас вымирающий вид. Начальников много, а менеджера днём с огнём не сыщешь. Собственно из-за этого феномена и появилась такая странная помесь инженера с менеджером, как тимлид.
Появилась? Она давно уже существует. Тот же старший или там ведущий инженер был задолго до того как ИТ появился как таковой.
И был точно такой же странной фигурой на которую могли свалить что угодно.
Ну, просто в IT эта роль появилась лет 20 назад. Потом начала плавно мутировать в роль начальника, под напором бравых парней, пришедших в IT за баблом, и не желающих возиться с кодом. Но необходимость в управлении и лидировании разработкой никто не отменял. Поэтому появились техлиды. По сути современный техлид - это тимлид 20 летней давности. Но и техлиды сейчас потихоньку мутируют в сторону начальников. Но реально управлять разработкой всё равно надо. Поэтому эту роль сейчас всё чаще и чаще берут на себя ведущие разработчики, не имея на это никаких официальных полномочий. И управляющие по сути партизанскими методами. Таких разработчиков начали называть играющими тренерами.
Ну и за весь этот зоопарк современный бизнес платит тройную цену, получая на выходе продукт, весьма и весьма сомнительного качества.
Ну, просто появилась эта роль лет 20 назад.
Может быть название. Как я уже писал выше до этого были всякие "старшие/ведущие инженеры" и иже с ними.
Это даже если забыть что в других странах они точно были уже раньше. Те же Teamleiter в Германии были как минимум в 80-90-х . А наверное и раньше.
П.С. Даже в армии(или армиях) давно уже примерно поняли каким количеством людей и на каком уровне может управлять кто-то в одиночку. Отсюда и различные офицерские и унтерофицерские звания. Ничего принципиально нового в ИТ в этом плане не придумали.
В 90х обычно была роль руководителя отдела и ведущего инженера. Но тогда IT не была такой популярной отраслью, и шли туда в основном энтузиасты. Даже шутка такая была - "программистам девки не дают" :) Поэтому руководители отделов обычно были весьма и весьма подковенные в технических вопросах люди. Часто сами кодили. А потом в IT рекой полилось бабло, и начался цирк вперемешку с зоопарком :) И сейчас уже не поймёшь, кто над кем стоит, и кто за что отвечает :)
Ну так речь о том и идёт что конкретно "роль" тимлид в ИТ в том или ином виде существовала с самого начала. И до появления ИТ уже существовала.
И тогда были очень много всяких "разновидностей". И на людей на этой позиции сваливали очень разные обязанности. И сейчас ситуация не особо изменилась. И в двух разных фирмах под словом "тимлид" будут понимать два разных набора обязанностей.
Читал статью и казалось, что это я её писал. Каждый абзац верный, все так и есть (((
Это как ефрейтором быть: платят больше на полтинник, а *пут на четвертной.
Вишенка на торте, это ЗП - которая чуть выше чем у сениора, и зачем это с такой ЗП лично мне непонятно. Управлять это очень много возни с особенностями каждого человека в подчиненной команде, ежедневный геморрой так сказать. Сколько я не видел тимлидов, в основном это или безотказные - которым начальство просто поручило быть, потому что больше некому или потому что надежный сотрудник или те кто хочет потешить свое ЧСВ через то что ему кто-то будет подчиняться.
Как результат способных тимлидов не так уж и много. А все потому что в первую очередь ЗП не соответствует тому как её оценивают квалифицированные для этой должности кандидаты. Руководство выделяющее бюджет, не понимает как все устроено и поскольку из двух групп выше поток кандидатов достаточный - возникает ощущение что ЗП соответствует рынку.
Та же беда в менеджменте, а поскольку там ЗП обычно ниже чем у разработчиков - ситуация ещё хуже. Во всяком случае так было до рукотворного кризиса 2022 года.
На своем опыте заметил интересный момент: есть еще так называемые "псевдо лиды". Это люди, которым повесили ярлык тимлида, но по факту они продолжают выполнять ту же работу, что и раньше (ну почти), + взяв на себя больше ответственности. При этом зарплата повышается совсем символически, либо остается без изменений. Полномочий, чтобы реально управлять командой или принимать стратегические решения, им тоже не дают. Получается, ты вроде бы "лид", но на деле — просто разраб с дополнительной нагрузкой и громким титулом на которого удобно сваливать просроченные сроки :)
ИМХО, я сделал вывод, что такое происходит, когда компания хочет закрыть дыры в управлении, но не готова вкладываться в рост или пересматривать свои процессы. По итогу это вызывает выгорание, ощущение несправедливости и желание уйти, что, собственно, я и сделал.
Часть аргументов очень сомнительная. А оставшаяся - крайние случаи. Да, так бывает, но так в любой профессии - бывают крайние неприятный случаи и они разные. В среднем же профессия/специальность о другом
а тимлидам сложнее, ведь позиций для них на рынке мало, а для обычных ролей требуются хард-скиллы, которые вы утратили.
по моему опыту - намного сложнее найти тимлида, чем сеньора, на открытом рынке. Думаю можно поднять статистику где-нибудь по скорости закрытия позиций
Самое забавное, что тимлидство редко приносит значительное увеличение зарплаты по сравнению с обычной позицией сеньора.
вопрос что значит "значительнее", но обычно вилки выше там, где выше ответственность. И с лидами так же. Но становиться лидом - не единственный способ расти в зарплате
Чем дольше тимлид работает, тем сильнее он привязывается к специфическим процессам своего текущего работодателя. Он начинает выполнять задачи, нужные только внутри компании, и нигде больше на рынке.
это намного более выражено у инженеров, тк какая-то специфичная технология одной компании - частая штука.
А у лида что такое может быть, мне даже сходу сложно придумать.
Потеря хард-скиллов
это задумано по-умолчанию, ты переходишь в ветку другую - получаешь новые скилы, теряешь старые. В совокупности широкий опыт как по мне, выгоднее, чем узкоспециализированный
ну и тд
Блин, чел, ну наконец-то появился кто-то, кто назвал вещи своими именами и заявил сильное мнение «тебе это не нужно». Ты мега-крут! Спасибо тебе!
Подписываюсь под каждой строчкой твоей статьи (я ровно тот тимлид, о котором идет речь в статье)
Не нужно становиться тимлидом