В двух из трех негативных кейсов, которые описаны в статье увольнение стало не желанием рукводства компании, а желанием самих специалистов. Тому несколько причин, но в общем они сводятся к тому, что для них стало очевидно, что в _текущей_ компании с _текущим_ набором обязанностей им справляться трудно. Откатываться на должность разработчика - это сильное решение, оно не всякому по силам. У нас есть несколько таких кейсов (когда тимлид уходил в разработчики), но их немного, чаще всего человеку психологически проще попробовать себя в другой компании.
В целом если человек вдруг осознает, что не хочет быть тимлидом - это не повод расставаться, у нас всегда найдется вариант подключить хороших специалистов к проектам в качестве разработчиков. Но тут должно совпасть желание у обеих сторон.
В третьем кейсе ("Тимлид — жалобная книга") - пришлось расстаться по обоюдной инициативе: спустя нескольких подходов с попытками скорректировать поведение и обсуждением, что от него ожидается на этой позиции сотрудник сам признался, что не способен эти ожидания оправдывать, на чем мы и расстались без каких-либо обид и претензий, до сих пор иногда сотрудничаем, обмениваемся новостями, он приходит на наши корпоративы и т.д. Не вижу здесь ничего страшного, считаю, что не каждое место подходит каждому человеку.
Какую-то мрачную картину вы описали :)
В общем посыле ("руководителем чаще становится тот, кому ближе коммуникации, чем быть с кодом 1 на 1") - согласен, думаю это нормально. Каждому по желанию. Плохого в этом ничего не вижу, руководителю не обязательно быть самым хард-скилловым в команде, конечно это будет круто с точки зрения его авторитета, но имхо это редкость (или скажется недостаток софт-скиллов, т.к. много времени уделено хард-скиллам, или человек должен тянуть обе эти состовляющие одновременно круто - что мне кажется редким даром).
Зачем руководителю обещать "нереальные плюшки" или зачем "кодерам дискридитировать руководителя" - не понял. Нереальные плюшки приведут к невыполнению сформированных задач, а тратить время на то, чтобы дискридитировать своего руководителя мне кажется пустой потерей времени с учетом текущих потребностей рынка.
Или я вас не так понял, тогда прошу прощения :)
Константин, спасибо и тебе что осилил и нашел время написать комментарий :)
Прекрасно понимаю о чем ты говоришь: когда тебе предлагают повышение, ты как то больше думаешь про новые возможности, а не про новые обязанности, и иногда ожидания обманываются.
На мой взгляд самая важная задача стоит у вышестоящего руководителя: донести не столько "плюшки" от нового места, но (самое главное) новые обязанности и сложности. На некоторых собеседованиях, когда я вижу что человек излишне романтизирует должность я специально уделяю некоторое время на то, чтобы "спустить его на землю". Рассказываю, что ему кучу времени нужно будет тратить на решение конфликтов, планирование, отчеты и прочее-прочее. Только когда я убежусь, что человек это осознает - мы перейдем к обсуждению условий работы.
Самим специалистам тут совет трудно дать, самый правильный (на мой взгляд) совет является самым очевидным: стоит взвешивать все плюсы и минусы, въедлево распрашивать из чего должен будет состоять твой рабочий день на новой должности, если есть возможность - общаться с коллегами на этой должности чтобы узнать как у них обстоят дела на самом деле.
Кстати, здесь кроется еще одна моя любимая ловушка: почитайте про Принцип Питера, очень интересно на мой взгляд :)
Суть параграфа в том, что тот, кто старается улучшать процессы вокруг себя - быстро растет по карьерной лестнице, а тот, кто "идет по накатанной" и только жалуется на несовершенство мира вокруг - нет.
По поводу вопроса, как до этого додуматься: почитайте про цикл Деминга - правильно настроенные или снятые метрики производства должны давать вам гипотизы по улучшению тех или иных процессов, или хотя бы подсвечивать "узкие" места.
Сами гипотизы, проблемные места и варианты их решения можно также выявлять в формате брейншторма со своей командой (они и проблем накидают, и гипотиз).
Или подчерпывать на конференциях/статьях и т.д.
Заодно кстати может быть интересно и полезно почитать про hadi-циклы :)
Я верю что это одна из крутых возможностей для любого руководителя (тимлида, например) - способность уменьшать энтропию своими решениями :)
За пример спасибо, интересно, изучу.
Спасибо вам за ссылку на видео, проглядел быстро - интересно. Сегодня досмотрю в самолете.
Рад, что пригодилось :)
Солидарен с предыдущим оратором.
Разве что предполагаю, что у аналитиков должно быть больше решений основанных на данных :)
Светлана, может есть какие-то конкретные вопросы? Давайте разберем :)
А я больше склоняюсь к мнению, что категоричность всегда идет рука об руку с недостатком опыта или максимализмом :)
Нет ничего абсолютного: нельзя утверждать, что иерахичная система - the best, также как и не стал бы я утверждать, что бирюза везде будет еще лучше.
У вас видимо были свои примеры из опыта, у меня свои.
Я например знаю одну очень крутую компанию которая выросла из стартапа с такой вот бюризой, а теперь когда столкнулись с ростом и сопутствующими проблемами как лекарство "открыли" для себя рациональный менеджмент и иерархии, хотя вот уж казалось бы :)
И то и другое (и классические иерархичные системы управления и гибкие) надо уметь готовить, так же как и в методологиях разработки ПО: если заставить менеджера/тимлида/специалиста который всю жизнь работал по T&M провеести проект по waterfall (или наоборот) - скорее всего он его завалит.
А развитие в тимлида для специалиста никак не может являться тупиковой веткой развития, т.к. эта должность априори учит брать ответственность на себя, принимать сложные решения, усмирять свою гордость в угоду общему делу - а из этих вещей формируется характер, и формируется стержень. За такими людьми потом идут другие, ведь они - лидеры.
В какой бы компании потом такой человек не работал (в бюризовой или нет) - эти навыки и опыт однозначно будут ему полезны.
И вам спасибо, что прочитали и нашли время на комментарий :)
Вместе с большой ответственностью приходят и большие возможности ;)
Читаем, изучаем, практикуем и делаем выводы :)
Разные есть подходы и определения, например в модели Такмана (которую мы как раз решили раскрыть в нашем курсе для тимлидов, чтобы больше руководителей узнали про нее и чтобы это подтолкнуло их посмотреть и другие варианты) таких этапов целых 5-ть.
Самое главное, что мне кажется важно учесть когда изучаешь все эти модели - это не начать клеить ярлыки на людей согласно только что прочитанной книге/статье/whatever, люди иногда оказываются сильно сложнее, чем может показаться после того, как вы такую модель "освоили" :)
Так в статье - про тимлидов :)
Но имхо не обязательно становится ни тем ни другим (ни тимлидом, ни техлидом), чтобы иметь возможность пилить самые интересные задачи, и вместе с этим такая возможность есть у обоих ролей - все зависит от ваших навыков тайм-менеджмента, и управления сроками и ожиданиями ;)
Ностальгия по былым временам? :)
Я чаще встречаю на собеседованиях романтические заблуждения вроде "когда я стану тимлидом - буду пилить только самые интересные задачи" :)
А по поводу коммуникаций - 100% это так, поэтому наравне с хард-скиллс нужно качать и умение слушать, слышать и говорить свою правду так, чтобы люди хотели меняться, а не набить тебе морду :)
Костя, спасибо за статью, имхо очень полезные советы не только для дизайнеров! Добавил себе в список книгу "Карта культурных различий", давно хотел почитать, но теперь точно сразу после sapiens.
Еще рекомендую всем книгу "Ясно-понятно" от Ильяхова (продолжение "пиши-сокращай")