Комментарии 7
Хм, базовая проблема обозначена вообще в первом абзаце: "тимлида назначило руководство. Чаще всего ими становились опытные архитекторы или разработчики". Но вместо того, чтобы бороться с изначально неверным подходом, зачем-то его стали прикрывать тряпочкой.
Это как лечить запущенный пульпит ударными дозами нурафена. Боль, конечно уйдет. Зубы - тоже.
Здравствуйте! Спасибо за ваш коментарий!
На самом деле, я в статье не указала, что назначались тимлиды из опытных архитекторов и разработчиков, которые работали в командах уже долгое время и проявляли лидерские качества.
Негатив в работе появился из-за большого количества текучики и менеджерских задач. При этом команды положительно относилась к назначениям тимлидов. Тимлиды сами формулировали проблемы и задачи и мы совместно принимали решение какие инструменты им помогут.
Дело не в том, что проявляли лидерские качества или нет. Не исключено, что руководство посмотрело, что человек проявляет эти лидерские качества и спросило, хочешь ли быть лидом, а человек-то и не хотел, но и отказать было неудобно. Или не спрашивали, а просто ставили перед фактом.
Плюс, тимлид - это не карьерный рост для разработчика, это новая карьера. Он фактически становится джуном и его надо обучать и менторить. И этот момент, судя по разным чатикам и постам, руководство пропускает. Считает, раз он опытный линейный сотрудник, то и с обязанностями линейного руководителя справится. А это так не работает.
Не исключено, что более разумным было бы ставить не самого опытного с лидерскими наклонностями, а пусть менее опытного, но проявляющего интерес к организации процессов. Если такой сотрудник будет работать как тимлид в тандеме с опытным сотрудником, который будет закрывать технические вопросы, то результат мог бы быть лучше. Но история не терпит сослагательных наклонений.
Вы молодец, что помогли командам выстроить процессы. Жаль, что компания обратилась за помощью, когда ситуация стала близка к критичной.
Да вообще не стоит пытаться в тимлиды вытаскивать разработчиков. Пусть идут через техлидов в архитекторы и так далее. А на менеджерские позиции лучше брать кого-то или с профильным образованием или с менеджерским опытом. А если разработчик хочет стать менеджером - пусть и начинает с позиции начинающего (с зарплатой тысяч в 50, так как и пользы с него примерно столько же). В противном случае некомпетентность так и будет тотальной на всех уровнях.
Управление людьми, управление процессами, мотивация, лидерство - это все достаточно сложные компетенции и области знаний, которым надо учиться и развивать и достаточно длительное время.
Хотя, будем честными, учат менеджменту довольно фигово.
Внутренне, хотелось бы видеть на позиции тимлида кого-то кто практически знаком с разработкой, чтобы он не угробил процесс метриками и улучшениями. И поначалу всё внутри взбунтовалось, как так не разработчик будет лидить!
Но потом осознал, что пока такой руководитель будет как джун под присмотром, он сможет понять как идет разработка наблюдая и задавая вопросы по процессам. Плюс в команде будет техлид, который сможет объяснить и предостеречь от плохих оптимизаций процессов.
В целом, продукт менеджеры вполне себе успешно лидят команды, без опыта разработки. Так что и профессиональный руководитель сможет.
А то что учат хреново, так сложно этому учить. В технических и естественнонаучных областях проще организовать практические занятия в массовом масштабе, а вот для руководителей - это сложнее.
Как вариант, чтобы студенты-руковолителя в качестве практики лидили группы студентов-технарей над каким-то длительными проектами. Возможно, организовывать при ВУЗе такие работы, чтобы задействовать студентов с разных направлений, чтобы в рабочую группу не попадали только студенты из одной учебной группы, кафедры. А были представлены несколько кафедр, факультетов.
А зачем на позиции тимлида (менеджерской) кто-то, кто знаком с разработкой? Угробить процесс сможет любой некомпетентный менеджер - и у бывшего разработчика шансов только больше. Впрочем, команде отдельный лид вообще не нужен.
Вообще, стоит разделять мендежмент людей, процессов, проектов, продуктов, ресурсов - это все очень разные направления с очень разными компетенциями и лучше бы их не объединять в одном человеке.
Но при этом все эти специалисты могут работать со многими командами одновременно. А в команде пусть останется техлид, без лишних менеджерских обязанностей и полномочий.
Ну и любой вменяемый менеджер на новом месте не будет сразу все ломать, а посмотрит на команду (команды), а потом уже попробует что-нибудь улучшать.
Я когда-то предлагал для дипломов собирать команды из разных факультетов и делать общие стартапы. Но пока даже в топовых вузах до этого не дошли, а жаль.
Как выстроить работу команды и отпустить тимлида в отпуск