Хабр Курсы для бэкендеров
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 83
Зачем было увольняться? Через полгода можно было банально отказаться от позиции, ведь так?
Можно было, конечно, только в статье я и не пишу что уволилась из-за лида. Предложение просто показало, что в компании кроме этой ветки расти некуда, ну на тот момент, по крайней мере, я видела ситуацию именно так.
А куда тогда расти? Ну, серьезно. Если тебе надо было больше денег - приходишь и говоришь, что у тебя:
Лояльность.
Опыт работы в этой компании.
Понимание тех. Особенностей проектов.
И так далее.
И просишь больше денег, мотивируя это вышеперечисленным. Больше денег != Повышение. Когда люди это поймут?
Руководитель сказал — конечно, без проблем, вопрос только в том, что сеньорская позиция сейчас есть в другой команде, стек там не его, грейд придётся подтверждать заново, и вилка начинается ниже текущей.
Видимо руководителю давно пофигу и на эту команду, и конкретно на этого сотрудника. Странно, что тимлид так и не сделал из этого выводов.
вернуться в разработку в течение года без потери грейда и без формулировки «не справился». Живьём я такого не видела ни разу
Я такое видел, и не раз. Более того, возвращались с новым опытом, и это шло на пользу.
Ни один пункт не чинит главное — отсутствие быстрой обратной связи
Вот тут не согласен, у тимлида самая быстрая обратная связь. Иногда там даже отрицательная дельта времени, ведь дедлайн задачи, которую принесли сегодня, был вчера)
Собственно, всё. Тимлидство — это
повышениесмена профессии с обнулением стажа, отсутствием обратной связи, ответственностью без полномочий и скверной асимметрией риска. Сеньоры, которые отказываются, поступают рационально. Всем спасибо.
Я не буду разбирать, где именно вы не вычитали ИИ-слоп из своей статьи, давайте разберем ваш вывод.
Если вы считаете, что становитесь джуном переходя в тимлиды, то вы просто еще не готовы (как и произошло с тем кого вы описали).
Неспособность организовать обратную связь (снизу) и подтвердить свои полномочия (сверху) только подтверждает, что синьор был не готов для следующей ступеньки.
При этом синьор может быть очень сильным в техническом плане.
По моим наблюдениям, чем сильнее синьор технически, тем меньше он хочет идти на лида, потому что ему в кайф писать код.
Это как разные ветки прокачки, если до упора прокачал техническую часть, то управленческая ветка недокачана и это фатально на новой позиции.
Мимо дважды прошел всю лестницу до CTO, понял, что хочу продолжать писать код и заниматься R&D в тех сферах, которые мне интересны, после чего ушел из найма.
Т. е. можно считать, что я также в итоге понял, что не готов.
Не «не готов», а «не обучен». Руководство это не ступень вверх от сеньёрства, а ступень вбок, потому что она требует совсем других навыков. Вы можете прокачаться от джуна до сеньёра, просто занимаясь разработкой. А переход в руководство требует соответствующего навыка или таланта, особенно если из вас как единственного разработчика не строят отдел, а сажают руководить готовой командой. Ступень вверх для серьёра это не тимлидство, а техлидство.
Не «не готов», а «не обучен».
Это в ЕС, в РФ именно что не готов, тк часто ставят либо самого "говорливого" либо самого технически грамотного из команды. Это называется "рост" в компании и именно это описано в статье.
Нормальный подход, который вы описываете, в последние лет 5 пришел только в топ компании.
А техлида как отдельной позиции зачастую и нет, как и архитекта.
у вас много умных зерен... Но у всех монеток есть как минимум еще одна сторона.
В статье тоже один из взглядов описан, в конкретных условиях.
Человек управляя командой должен уже как минимум понимать роадмеп - тогда у него не будет этой беды с обратной связью с лагом в пол года - это к статье вопрос.
Но техническая ветка скиллов реально ортогональна к управленческой. И некоторым просто не дано - вернее они смогут, умный чел разберется, а хорошие технари они зануды, они душнилы(в хорошем смысле как правило) но они умные. Но найдут ли они в этом кайф? Будет ли у них .. гармония между всеми задачами и их жизненным укладом, условно говоря.
Но помимо этого для свежих тимлидов нужен ментор или в компании должно быть дружное лидское комьюнити с мягкой незаметной наставнической системой - для интровертов которым надо становиться экстравертами. Если руководство это не понимает - скорее всего там куча людей не владеют нужными компетенциями.
Хотя если посмотреть что у нас в найме... Тут всё прям логично
В Союзе выпускался журнал "Эко". Запомнил оттуда: "когда организация назначает способного инженера руководителем, она теряет способного инженера и приобретает посредственного руководителя"
Это такая теория есть, В любой иерархической структуре - все некомпетентны. Принцип Питера называется
Кажется, уж кому бы молчать об эффективных управленческих практиках, так это Союзу. Прям вот зарыться в ботву картофельную по самую макушку. И молчать. Это я не к критике Союза как такового, а к тому, что все, что оттуда было слышно надо сходу заносить в рубрику "вредные советы"
Практики управления в СССР были вполне современны миру модерна того времени, и иерархические структуры не сильно в корне отличались от тех же структур в США и других странах, с поправкой на идеологию. К сожалению, определенная степень ригидности и отсутствия конкуренции в последние годы Союза не позволила адаптироваться к меняющимся условиям.
К сожалению, определенная степень ригидности
Приближающаяся к стадии "дуб окаменелый, Н штук" под закат СССР
в последние годы Союза
В последние лет 15? :)
С 50 примерно началось. Управление проектами как область знания в СССР было очень даже на хорошем уровне, может даже лучше аналогов в мире. Я читал ещё советские книги по этому делу, и был весьма удивлён. Ну и подумать только - масса крупнейших проектов, где со сроками справлялись иногда и с опережением. Без этого просто не получилось бы человека в космос запустить вовсе, а ведь вышло то ещё и быстрее.
А эта степень ригидности полностью политическая, она и утянула за собой всю страну. Номенклатура уничтожила всё
Ругатели СССР часто не понимают, почему там писали столько заявлений вместо того, чтобы просто позвонить по мобильнику.
Я читал ещё советские книги по этому делу, и был весьма удивлён
Я тоже их читал. Как отвлеченная теоретическая наука (если автоматом фильтровать бесконечные реверансы -измам) - годно. А на практике?
масса крупнейших проектов, где со сроками справлялись иногда и с опережением
Знаете шутку в среде продактов? Перед тем как сесть проектировать, попробуй ответить на вопрос "А зачем вообще мы это будем делать?". Вот СССР здесь выделялся
Я читал ещё советские книги по этому делу, и был весьма удивлён.
А можете что-то интересного из прочитанного посоветовать?
С 1953го ровно. В первую неделю после смерти Сталина Хрущёв продавил несколько постановлений, с которых всё и понеслось.
Я тут уже писал, у меня в памяти осел эпизод из детской книжки "Сын полка". Там наводчика-виртуоза, который еще в Первую Мировую повоевал, неоднократно хотели повысить в звании и назначить командиром орудия. Он всякий раз отказывался и командование не настаивало, понимая, что отличного наводчика потеряют, а заурядных командиров орудий много.
Ага и получаем потом менеджеров-рандомов, которые ничего не понимают. Всем приятно работать с сильными коллегами и руководителями с техническим бэкграундом. Ваша цитата провоцирует нанимать именно менеджеров-рандомов. В итоге получаем руководителя оторванного от реальности, который сам отдаляется от проекта и команды т.к. ничего в этом не понимает.
Я лично наблюдал на работах такие истории, когда "руководитель" начинает прям орать "Я хочу такую фичу" и на любые аргументы и причины против он просто повторяет как ребёнок "Я хочу, я хочу" т.к. ему по сути нечего сказать что-то по теме.
Команды не уважает таких "руководителей", а они это прекрасно понимают и сами отдаляются от команды. Уходят в свой кабинет и общаются только с такими же руководителями-рандомами. Получается такая типичная игра в глухой телефон. Вместо того чтобы подвигаться и найти решение задачи, посмотреть на ситуацию сверху, поговорить с другими командами и предложить что-то самому.
Это от общей стратегии организации сильно зависит. У меня большую часть лет что я работал начальниками были менеджеры без знаний программирования, в том числе и немало женщин, даже сеньоров часто в команде не было. И все было вполне успешно, без вырвиглазных фич и сорванных работ. Все потомучто сразу ориентировались на легкие и средние проекты. Пришёл чел с запросом на сайт мегасервис для сотен тысяч человек, которому не будет аналогов пусть и с миллионами в карманах ответ "Дядя тебе ни к нам". Пришёл заказчик с запросом "Сделайте мне обычный сайт как у других" наша реакция "ООо рады видеть вас мил человек"))
И всё бы ничего, но пришла нейросеть и сказала, что такие вещи она будет делать в тыщу раз дешевше и в мильён раз быстрей...
На текущий момент я бы не сказал. Сочетание "вайбкодер(всмысле что в ручную этим раньше человек не занимался годы) + нейросети" на дистанции, чем больше задач тем выше вероятность что потребуется переделывать за ним. Я не буду спорить о моделях, которые использовались в этом не разбираюсь. Может там были какие то кривые и дешевые. Но фактический результат посредственный что я видел. Плюс надо учитывать что над обычным сайтом в отличии от сложного ПО где работает много человек, обычно трудятся 1-2 специалиста и как бы если и их убрать, то вообще никого не останется, что ли сам менеджер или заказчик будет проект пилить?? Даже если им не в лом, скорей всего плохо получится. Если там не прям элементарное.
она теряет способного инженера и приобретает посредственного руководителя
Правда ваша.
Но откуда иначе брать лидов? Назначать не технарей, а "менеджеров-менеджеров" - не взлетит. Нужен тех. бэкграунд.
Поэтому перевод инженера в лида - единственный рабочий метод. Кто-то возвращается назад. Кто-то приживается и прокачивается.
Да, можно еще взять "варяга" с рынка, а не жертвовать своим инженером. Но этот "варяг" тоже ведь когда-то перешел в лиды именно с инженерной позиции.
Поэтому некометентные люди сразу идут в посредственные руководители.
Спасибо за дисклеймер о выборке в одного человека.
Да, проблема описана правильная.
Тут есть только один рецепт - разработчик должен изучать процессы так же, как и другие скилы разработчика. Плюс в том, что они не меняются годами. разобравшись один раз, на следующие лет 5...10 можно не напрягаться. Построив команду под себя. можно тратить на управление в неделю порядка часа... двух, а прочее время заниматься разработкой. Но это если работодатель позволит такой финт ушами. В противном случае - реально получается "потухание" как разработчика.
100%, именно так я стал программистом. был тимлидом команды разработчиков контента для обучающих серверов универа США. когда все процессы налажены - стало скучно, и начал изучать макросы, а потом и программы писать (и из-за этот пришлось увольнять под команды, ибо половину работы делали мои программы). Потом тоже несколько раз предлагали быть Тим лидом прогеров - всегда отказывался, не смотря на то что был положительный опыт (ибо знал как там все у прогеров с их продактовнерами). А сейчас с ИИ процессы меняются чаще чем погода...
А можете мне пояснить (ну просто у меня такого не было), какие вообще функции должен выполнять тимлид по замыслу какого-то более "великого" архитектора HR и бизнес процессов?
Продакт менеджер говорит что нужно делать, сеньор - как правильно это сделать, а тимлид - "зачем вообще всю эту работу делать"? Он - главный мотиватор, или политрук, или бюрократ 1ого уровня?
Отсутствие его рациональной роли хорошо показано в разделе "Ответственность есть, рубильника нет", но я только со стороны смотрю, наверное что-то не понимаю..
В Вашей цепочке тимлид вообще лишний получается. На вопрос "зачем нужно" должен ответить продакт, вместе с ответом на вопрос "что нужно".
А если вопрос формируется как "зачем мы тут собрались", то это к основателю компании.
В статье описана проблема кривой оргструктуры в конкретной организации:
не обязательно в организации вводить все мыслимые должности
можно уже после мидла делать развилку путей роста
можно не сразу переводить человека на новую должность и позицию, а сначала назначать его ИО
Продакт менеджер говорит что нужно делать, сеньор - как правильно это сделать
Неверно. Как правильно сделать как раз говорит лид. Перед этим собрав консилиум синьоров и оформив его результат чеканной формулировкой "Мы тут подумали и я решил". Просто потому, что синьоры сами по себе (если пустить процесс на самотек) подозрительно похожи на казаков. В том плане что "где 2 казака, там 2 атамана"
Перед этим собрав консилиум синьоров и оформив его результат чеканной формулировкой “Мы тут подумали и я решил”.
Подобный шарашка-стайл довольно быстро заканчивается уходом этих самых сеньоров на фирмы с более адекватными сотрудниками.
Нет. Тут вопрос в том, что обсуждали и как, а также в том, что же это за синьоры.
Самое главное отличие синьора от миддла в том, что первый понимает, что одну и ту же задачу можно решить громадным числом способов, причем с использованием схожего объема ресурсов (т.е. деньги на лицензии, время и так далее). Мидл же зачастую проталкивает единственное и самое правильное решение.
В случае грамотного обсуждения (когда известно, какую задачу решаем, когда присутствует уважение и пр.), зачастую решение принимается и без тимлида (который, в итоге, просто его формально озвучит и будет отстаивать). В малом числе случаев необходимо сделать выбор в стиле “правостороннее vs левостороннее движение” (по сути, можно выбирать любое, тут главное - это определиться).
Собственно, если добавить к синьорам требование в обсуждение (просто минимальный уровень, чтобы была конструктивная беседа), а к тимлиду умение в корректную модерацию, то и получим то, что сказал товарищ выше.
Прораб это. Скрам-мастер про макс со специальной дырочкой, чтобы в нее прилетало от вышестоящих ))
Если вы разработчик, и стали тимлидом или собираетесь стать им, рекомендую посмотреть это видео:
Видео
У меня только один вопрос: смотреть в монитор тимлида в половине двенадцатого ночи -- это норм? :о)
Но «у меня сработало» опровергает «в среднем не работает» примерно так же, как долетевший самолёт опровергает карту пробоин.
Почему вы рассматриваете свой частный случай как "в среднем", а чужое "у меня сработало" как исключение? Может, это ваш самолёт не долетел до родной базы?
Автор, а я с Вами согласна. Из моих наблюдений прекрасные сеньоры должны оставаться прекрасными сеньорами, а не идти тимлидить
Как ни странно, я сейчас мечтаю о тихом гринде и прямо сейчас ищу работу, чтобы устроиться джуном-мидлом в такую же команду как моя второй работой. работаю тех лидом, кол-во коммитов в профиле можно глянуть, больше 5к за год. лидерство дает больше ресурсов, можно построить больше но тоже упирается в потолок. а средняя позиция хорошо масштабируется, я думаю смог бы штук 5 таких позиций тащить, по деньгам это больше чем ставка лида
"Теперь то же самое существо делают тимлидом" - да уж, качество этой статьи просто ниже плинтуса
Сейчас все идет к тому, что все эти звания и категории ничего особенного не значат. Главное - просто работать, как в коммунизме)
Прикольно читать о том, что в IT примерно такие же проблемы и примерно также устроено управление как во всех остальных отраслях промышленности)))
И очень интересно, что авторы и комментаторы отмечают наличие "отрицательного отбора" на руководящие должности)
Если б автор статьи пробежалась по западным теориям менеджмента последних лет 50 то увидела бы, что "отсутствие рубильника" у руководителя это прям вот классика и осознанное решение при построениии систем и у этого есть объяснение. Не вполне логичное но есть))) и повторюсь это вполне осознанное решение и оно "лечится" НЕ локальными "припарками" потому как "припарки" "убивают" смысл такой построения системы где рук до определенного уровня чисто "громоотвод" и ничего не решает)
За наблюдение зачет. За вывод - уж извините...
Для вывода нужно глубже погружаться в тему теории управления
Сказали "А", говорите "Б", так какое объяснение? Пусть и нелогичное...
А это результат "смешения" нескольких теорий труда и их механизмов:
во-первых "деквалификации труда" предложенной Браверманом и его последователями (которые понимали экспроприацию знаний о труде и реальных бизнес-процессов как элемент контроля над трудом и низовым менеджментом),
во-вторых: подхода предложенного Фридманом (в котором управление выполняет функцию "переключателя" между 2я технологиями контроля - ответственной автономией работников и технологиями прямого контроля и функцию осуществления этого прямого контроля)
в-третьих: постмодернистских теорий труда которые постулировали роль менеджмента не как максимализатора прибыли, а как субъекта, доказывающего свою нужность (Вилмот) задачей которого больше становится управление дискусом, ожиданиями и т.д.
Суть в том, что собственники и топ-менеджмент пытаются "совместить" старое-доброе понимание руководителя именно как технического руководителя и смесь постмодернистского дерьма с осколками западных теорий управления, в основе которых лежит задача управления по сокрытию прибавочной стоимости труда и информация о реальных бизнес-процессах и их цепочках. Что и порождает весь этот управленческий бред, который с первого взгляда кажется бессмыслицей.
Поэтому я и говорю, что это все очень логично. Правда нихрена не эффективно)))
...но это уже другая история
Так... попробуем перевести на человеческий.
1. Нельзя допускать автономии сотрудника и полных знаний обо всем - иначе сотрудник станет работать на себя, а не на дядю. Логично, я такое наблюдал много раз. Хитрый менеджер всех клиентов замыкал на себе, делал шаг в сторону и организовывал свою контору.
2. "Менеджеру нужно доказывать свою ценность..." Ну кстати... один знакомый занимался стройкой и ремонтом, находил заказчиков, договаривался, у него была бригада с бригадиром которая всё делала (сам он гвоздь вбить не может). И один рабочий как-то сказал ему "%NAME%, ты посредник". Дальше бригаде было объявлено, что этот рабочий больше с ними не работает, чтобы все поняли разницу между посредником и директором.
Это такая теория есть, В любой иерархической структуре - все некомпетентны. Принцип Питера называется
У вас ровно одна проблема. Тимлиду не дали власти. Бежать надо с таких мест.
Тимлид с властью делить премии, нанимать и увольнять это совсем другое. И естественно тимлид должен вместе с менеджерами определять сроки и скоуп задач.
Невозможно читать нейрослоп
Почему же невозможно? Я вот читал и кайфовал: и слог классный, и каждая запятая на месте. А живой человек иной раз так напишет, что ловишь кринж в каждом абзаце.
потому что результат усредненный, не уникальный, предсказуемый. подробнее в статье https://habr.com/ru/articles/1063010/
Сам стал из синьора тимлидом 3 месяца назад. Думаю, что эта роль куда содержательнее, чем описано в статье. Хотя с непривычки работать с людьми сложно, да)
Охо-хо. В науке такое тоже бывает. А одном известном ВУЗе, умер завкаф. и непонятно кого было назначать, в результате назначили человека которого все уважали - как большого ученого, но он никогда не занимался менеджерской работой. Результат любопытный, всё работает как и работало, поскольку все сотрудники квалифицированные и умные, то какое-то управление им особо и не нужно, а умственных способностей и просто жизненного опыта Большого Ученого вполне хватает чтобы компенсировать нехватку менеджерского опыта.
Ну да поэтому я не ведусь на все эти современные "карьера", "рост", "развитие". Слышу их и сразу спина чешется. Это всё стрессы и риски. Лучше мидлом быть делать средние-привычные задачи и радоваться жизни.
Принцип Питера говорит, что человек поднимается до уровня своей некомпетентности. Здесь немного иначе и грустнее: человек поднимается до уровня, где его компетентность просто не применяется.
Так это именно Принцип Питера как он есть. Он ровно про то, что в процессе роста вы начинаете обрастать обязанностями не по той экспертизе, которая обеспечила ваш рост. И вы либо становитесь некомпетентны, либо нарабатываете новую компетентность, получате новое повышение, а затем GOTO 1.
Ну нет. Думается принцип Питера всё же о том, что человек не может выполнять более сложные задачи. Но рост ограничен местом. Вот возьмём математика, если он растёт он должен (условно) от умения считать 2х2 дойти до доказательств проблем тысячелетия. И этот путь есть. А если где-то на этапе сложного урмафиза (на полпути к проблемам тысячелетия), ему сказать, так, теперь ты занимаешься управлением кафедрой математики, вот график пожарной проверки, вот новые формы отчетности, вот требования министерства, вот студенты с хвостами - давай - работай, то это другие компетенции, которые к росту сотрудника как математика не имеют отношения.
Скоро все станут если не тимлидами, то погонщиками верблюдов - ИИ-сеньоров. Есть ещё места, где приходится работать руками, но их всё меньше и меньше.
Вопрос перехода в менеджмент индивидуален. Мой опыт: трудности адаптации быстро сменились прогрессом благодаря мотивации и широте взглядов.
Руководитель не привязан к технологическому стеку, тогда как для программиста смена стека - серьёзный вызов. В управлении на первый план выходит системное мышление.
Итог - за 5 лет должность руководителя департамента (несколько отделов) и конкурентоспособная зарплата.
Да и спасибо за цифры. Сравнил свои 30-50 коммитов в день на должности руководителя.
Если смотреть по промышленности, да и не только по промышленности то часто рабочие, инженеры, шахтеры, врачи растут вверх до руководящих должностей. Таких руководителей считают ценными, потому что они понимают что и как там внизу. Но стать хорошим руководителем и стать хорошим инженером/врачом/e.t.c. это совершенно разные пути и у кого получается одно может не получится другое. Возможно наши традиции вырастить лида из сильного программиста как раз и уважения к состоявшимся руководителям поднимавшимся с самых низов.
Что касается конкретных позиций лида в конкретных кампаниях - все зависит от внутреннего устройства кампании и от того, кого именно они называют тимлидом. Потому что работу лида можно поделить условно на 3 части:
Управление командой. Разделение задач на людей, введение новичков и пришедших на другую часть проекта в курс дела, помощь с их задачами если надо, принятие решении о расширении или сокращении команды. (расширение/сокращение далеко не всегда значит прием на работу или увольнения, во многих кампаниях люди мигрируют между проектами).
Управление технической частью проекта. Проработка архитектуры, опробование новых технических подходов и библиотек и принятие решения о внедрении/не внедрении. Подготовка планов создания и развития проекта с технической стороны, оценка сроков.
Согласование планов с продактами/коммерсами/заказчиком и прочими ЛПРами. Рисование диаграмм кто чем занят, информирование заказчика о том, как развивается проект. По сути менеджерская работа, которую иногда берут на себя PMы, но без лида они не знают, что писать/рисовать.
Мне доводилось быть лидом и там все 3 части присутствовали в разных пропорциях в зависимости от проекта. На кодинг оставалось 10…80% времени в зависимости от проекта. Самые интересные были проекты с новыми для меня технологиями, которые делались маленькой командой. Тогда я понял что быть лидом - не совсем мое призвание.
Ну и надо сказать, что на проектах, где я лидом не был, у лида работа состоит из пунктов 1-3 и кодинга в разных пропорциях в зависимости от кампании проекта, и даже от фазы выполнения проекта.
А у меня к вам вопрос будет)
Вот вы специалист в IT сфере и накидали 3 задачи "Лида" в принципе это похоже на задачи на задачи глав-спеца - руководителя группы в проектном институте. За тем исключением что некоторые задачи "по классике" "уходят" нач. отдела, а некоторые - не описаны (в частности проверка документов, разработанных членами группы).
Вообще "в норме" части 1 и 3 достаточно сильно можно автоматизировать и упростить (в проектировании это PDM/PLM системы) - задача пришла》лид ставит подзадачи со сроками и промежуточными "вехами"-напоминалками》по "напоминалке" проверил》как пришла работа - проверил》если все норм отжал выполнение 》 по факту выполнения скорректировался график, и изменился отчет по работам. Кто чем занят в принципе раз ты ставишь подзадачи - сам знаешь, а для следующего "этажа" иерархии - это все отчетно-автоматизируемая тема которая решается средствамии PLM/PDM системы. Т.е. эт та работа от которой можно и нужно уходить и передавать ее машине.
Как принципе все - я убежден и видел, что наиболее ценна именно тех.экспертиза, тех.упрпвление и проверка качества работы команды и в принципе к-то именно "софтскильное управление" тут минимум и его необходимость именно в таком постодернистском ключе, требующем к-то софтскильных навыков в принципе не нужно.
Я сам на это ориентировал подчиненных лидов и так строил автоматизацию работы подразделений.
В IT такая же логика или нет?)
билет в один конец продают на встрече один на один минут за пятнадцать
Звучит слишком драматично.
Знаю несколько лидов, которым "не зашло". Ничего, вернулись.
Один из них вообще перешел на линейную должность после 15(!) лет тимлидства. Ах, да, еще и стек сменил.
Я сам трижды входил в эту реку. Показал себя -> получил повышение -> поработал год-два лидом -> поменял работу и потерял должность. И так 3 раза. Последний раз умудрился поменять работу без потери должности. Планирую и дальше быть "играющим тренером".
Другой вопрос: чтобы продолжать играть, нужны время и силы, которые не всегда есть.
Недочитал статью, так как посередине меня смутило следующее (пункт "Ответственность есть, рубильника нет"). Из личного опыта я считаю, что эта проблема - конкретно организации И сотрудника. В данном случае человек просто заткнул собой место, но никак не стал тимлидом или техлидом. Он не вырос сам, так как не может сказать, "Нет", не готов спорить с руководством и отстаивать текущую позицию, не готов выходить на контакт с продуктом и обсуждать, что нужно оставить, что убрать и т.д. В данном случае я бы сказал, что и сам человек был не готов нести ответственность, и организация не понимает, что ей нужно от этого человека. Нужно было идти и спорить. Понятно, что у нас многие боятся увольнения и, зачастую, это самый мотивирующий рычаг воздействия для молчаливого согласия. Надо попробовать поговорить сначала с тем, кто назначил, обсудить пул своих задач, возможностей и смысла нахождения на этой позиции. А так, учитывая нынешнее его положение, думаю, что он вполне способен писать код, а не заниматься всей этой политической мутней
PS. Под личным опытом я понимаю наблюдение в должности разработчика и сотрудника организаций в целом.
Из описания похоже, что тимлид выполнял ещё и функцию project manager.
Прекрасный язык и стиль повествования! Получил удовольствие.
По сути статьи, абсолютно согласен. Сам попробовал себя в 3 канторах тимлидом/техлидом. Выгорел, не работал год, потом вернулся сеньором/ведущим. В резюме написал прямо: "руководящие должности не предлагать". Хотя, кто в наше время внимательно читает резюме? Всё равно иногда предлагают.
Спасибо, поучительно (хотя я и далёк от командной работы). Очень жду (как наверное и многие читатели) возвращения недавней Вашей статьи про выгорание!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему сеньоры не хотят становиться тимлидами (и правильно делают)