Комментарии 38
Ради этого прекрасного мига все и затевается. До его чудесного наступления нужен примерно год.
Розовые очки. Даже выполняя все эти пункты, через год можно увидеть резко возросшую текучку кадров. Почему - а потому что человек, который всю жизнь привык управлять компьютером, людьми, скорее всего, будет управлять также. А это плохой подход.
Конечно, у программиста внутри могли быть хорошие навыки коммуникации, но в статье ничего не сказано, как выявлять таких программистов.
Лучший мой руководитель был с образованием семейный психолог. После него, понимаешь, какое же в среднем «дно» на уровне менеджмента.
Глупо выдвигать в руководство специалиста, который умеет только хорошо кодить. Имеет смысл присмотреться, а кто при этом ещё и неформальный лидер в команде. И сделать его формальным. Не все хотят или могут руководить людьми. И это нормально.
Не, ну если человек руководить в принципе не хочет, то не надо его насильно в начальники. Только хуже будет.
С другой стороны, если он хочет именно лидером, а больше толком ничего не умеет - тем более не надо. Скатится в микроменеджмент и "я начальник, ты дурак".
А если он вроде и с головой, и не против, то уже можно. Только человек должен сразу понять, что на код у него останется от силы процентов десять времени. Остальное будут митинги, переговоры и поверпоинт. И ещё придётся научиться правильно делегировать задачи и ненавязчиво контролировать процесс их выполнения, а не бросаться грудью на тикет "вот щас сам сделаю!".
И софт скиллс, да. То за повышением придут, то пожаловаться, то похвалиться, иногда с предложением "давайте всё переделать". И надо будет как-то с этим жить...
Очень опасная рекомендация. Неформальный лидер часто может строить свой авторитет на негативной базе (обычно, сам того не замечая).
Розовые очки. Даже выполняя все эти пункты, через год можно увидеть резко возросшую текучку кадров.
Я пишу из своего реального опыта. То есть, если бы я так не делал и это бы не был системно успешный кейс - я бы не писал. Текучка кадров гарантировано будет, если не заниматься работой с новоиспеченным руководителем, о чём собственно и пост.
Почему - а потому что человек, который всю жизнь привык управлять компьютером, людьми, скорее всего, будет управлять также. А это плохой подход.
Конечно, у программиста внутри могли быть хорошие навыки коммуникации, но в статье ничего не сказано, как выявлять таких программистов.
Абсолютно согласен. Но есть сферы и проекты, где для управления необходимы глубокие технические знания. Поэтому действительно нужно выбирать человеку который а) хочет б) теоретически может. А после этого с человеком работать. Как его выбирать? Вы правильно написали - должны быть коммуникационные и организаторские задатки, а также желание их развивать. Иногда стоит просто прийти ногами в команду и понаблюдать за людьми.
Лучший мой руководитель был с образованием семейный психолог. После него, понимаешь, какое же в среднем «дно» на уровне менеджмента.
Какой был размер команды и проект, если не секрет?
На самом деле все очень просто.
Начальник инженеров не равно самый крутой инженер.
Нужны совершенно другие навыки.
Спросите, что Пете необходимо чтобы всего этого добиться. Начиная от полномочий, до ресурсов. Не пропускайте этот пункт! Сам он скорее всего вам не скажет и в конце выяснится, что надо было нанять ещё двух бэков, но он не знал, что так можно.
Вот это очень важно, сами не раз натыкались на это.
Мы по такой схеме вырастили администраторов секций рекламы и SEO, правда, они еще прошли курс "Кто такой руководитель", там как раз-таки объясняли им, как изменяется их продукт, по каким статистикам будем оценивать деятельность. Помогло. Не сразу. Но помогло.
Очень важно прокачивать таких ребят именно в менеджменте и показывать ценность всех этих руководительский дел.
Очень важная статья. Сколько видел плохих руководителей, выросших из хороших специалистов. Сам таким чуть было не стал (чуть не стал - потому, что убежал от подкатившей ответственности, а не потому, что стал хорошим). Я вообще не встречал хорошей литературы на эту тему (если по менеджменту вообще существует хорошая литература), которая нормально ставила на место мозги вчерашним специалистам или тем, кто делает из них лидов.
Так и живем - на одного хорошего менеджера ещё пяток хороших инженеров со званием менеджера. А руководит в таких командах все равно вышестоящий. Или анархия/демократия, что в условиях организации не лучший вариант.
Соглашусь с тезисом «знать не хуже чем середнячок», но позволю себе скорректировать: знать «что» делают его подчинённые и «зачем» они этот делают. А вот «как» - уже знать не нужно, а может даже и вредно. По крайней мере в команде экспертов.
5-7 человек самое вредное число, ИМХО. Еще 1-2 человека и приходится изменять схему управления.
Наверное, в мире разработки это возможно. Но каким образом применить аналог shadow code review на поддержку инфраструктуры, например, я не очень представляю. Или на другую деятельность, не заключающуюся в генерации читаемого артефакта.
IaC + task tracker. Проблема в том, что команда инфраструктуры это люди, а люди не всегда стремятся обучаться чему то новому.
IaC не перевезет стойку между цодами и не разберётся с погрузкой, не смонтирует стойку в зал и не подключит кабели. И даже если брать только виртуальные действия - IaC из коробки хорошо работает только для ограниченного числа модных ныне задач. IBM Power, SAN и снепшоты на каком-то массиве HP - всё, нет никакого IaC. И это не вопрос обучения, штат разработчиков питон будет стоить компании дороже, чем штат хардкорных админов
То что Вы описали, это хорошо известный в менеджменте так называемый «Синдром менеджера игрока». Синдром заключается в том что в данном случае Петр вместо выполнения обязанностей руководителя продолжает делать то чему его учили и что он хорошо делал до этого, быть хорошим программистом. Теперь Вы предлагаете потратить целый год для того что бы помочь человеку адаптироваться к новым условиям. Для Петра это будет тяжелейший переход. До этого Петр программировал, его деятельность была основана на алгоритмах и математике где многое исчислимо. Но теперь Петр попадает в условия в которых алгоритмы будут работать во первых только с некой степенью вероятности, поскольку теорем здесь нет, есть только статистика, и во вторых они не имеют обратного действия ctrl-z не работает, в третьих, люди не компьютеры, нельзя взять и заменить один кусок кода на другой, более совершенный. То есть вы вот так вот свободным, волевым решением отправляете одного из лучших программистов в условия «серой мглы» неопределенности, с возросшей ответственностью за людей, без инструментов, знаний и навыков. «Добрый» Вы человек однако. А с учетом того что вы будете платить заработанную плату человеку в течении года который не может полноценно выполнять свои обязанности и не факт что этот Петр продолжит работу менеджером и в сложившихся условиях не поменяет место работы, это наводит на тревожную, но разумную, мысль: «Валить надо от этого безответственного придурка, такой и проект утопит, и нас в дерьме искупает». Придурком, как вы понимаете, в данном случае будет не Петр. Финансовую ответственность никто не отменял и деньги надо считать.
Есть ли альтернативный подход? Оказывается такой подход есть и он находится прямо у нас «под ногами».
Когда возникает потребность нанять человека, вполне разумным и ответственным подходом является предварительно продумать работу будущего сотрудника и фактически заранее спроектировать его работчее место.
Начинать надо с неприятного, но необходимого. Придется анализировать и выяснять требования законодательства предъявляемые как к рабочему месту так и к будущему работнику с позиций закона.
Второе, необходимо определиться с сутью будущей работы, разобраться в чем заключается работа, какова ее продолжительность, какие требования предъявляет работа к рабочему месту и какие требования к навыкам будущего сотрудника. Особенно тщательно это надо сделать, если это будущий руководитель, который будет иметь подчиненных.
Третье, после того будет сформирован список требований, можно попробовать выяснить способы тестирования конкретных навыков будущего работника, попытался их фактически измерить.
Четвертое, потребуется определиться во сколько нам это все обойдется.
Пятое, надо принять решение, берем внешних кандидатов или растим своих. Можно провести конкурс и позволить участвовать своим на равне с внешними кандидатами.
Шестое, подготовить будущее рабочее место, разработать как использовать доступные Вам способы отбора, окончательно сформировать критерии отбора, определиться каким образом будет организован и проведен онбординг. Выяснить возможность дообучения кандидата.
Седьмое, Вам нужно сформулировать предложение которое вы будете делать будущим кандидатам.
Восьмое, Вам нужно будет подготовить план проведения и организовать тестирование и собеседование с кандидатами.
И вот теперь, на девятом пункте, если все срослось успешно, Вы можете себе позволить пригласить к себе людей и сделать им соответсвующее предложение.
Десятый, одиннадцатый и последующие пункты Вы можите расписать самостоятельно, по аналогии.
Очень хороший и логичный план, не учитывающий важного факта - я говорю про инженерный менеджмент в малом и иногда среднем бизнесе. Поэтому:
Тимлидство - может требовать определенной инженерной квалификации (что полбеды) и специфичных навыков для вашего проекта (что уже серьезное препятствие).
Всё вышеперечисленное во многих случаях не подходит для такого типа бизнеса - могу раскрыть этот тезис подробнее, если он вызовет сомнение.
Вы так говорите, будто за забором тысячи квалифицированных тимлидов стоят и только ждут когда их наймут. На некоторые позиции поиск может более года занимать. Если у вас конечно внятные требования к кандидату.
Ну а по поводу доброты - вся статья как раз о последствиях принятого решения и как в этой ситуации правильно действовать чтобы не покалечить ни свой бизнес, ни человека.
не учитывающий важного факта - я говорю про инженерный менеджмент
У меня для Вас плохая новость, похоже что инженерный менеджмент это либо заблуждение, либо Ваше личное изобретение. Так часто бывает, менеджмент сложен. Нельзя просто почитать "Основы менеджмента" Хедоури и Мескона и сказать, я квалифицированный руководитель, это так не работает. Требуется большая практика что бы ощутить как взаимодействуют люди, как формируется иерархия, как формируется мотивация.
Тимлидство - может требовать определенной инженерной квалификации (что полбеды) и специфичных навыков для вашего проекта (что уже серьезное препятствие).
Вот это интересный момент. Полбеды с инженерной квалификацией смягчается тем что руководитель не программист, у него другая работа, а вот что означают специфичные навыки для проекта. Это надо понять более подробно. Есть навыки присущие самому проекту, например, знание предметной области проекта, знание ключевых элементов проекта их особенностей и взаимосвязей, знание формальной и фактической иерархии проекта. Есть навыки связанные с созданием программного продукта, например, знание и умение применять гибкие технологии управления проектом по созданию программного продукта. Или навыки руководителя связанные с выполнением работы по управлению, то есть прогнозировать и планировать, организовывать, отдавать распоряжения, координировать и контролировать. Или навыки лидерства и борьбы за фактическую власть и политическое влияние.
Судя по тому что вы описываете, как вы потратили год на то что бы обучить человека тому какая у него получается иерархия целей в новой позиции и как целесообразно распределять рабочее время что бы эти цели достигать, то у Вас самих внутри нет ясности по данной тематике. Однако, положа руку на сердце, я Вам так скажу, на теме проектирования работы подчиненных у меня «буксовали» все из моего окружения. Это прямо какая-то «Terra incognito», хотя решение лежит на поверхности, нужно сделать списки требований и навыков. Дальше пазл начнет складываться сам собой.
С тимлидами вообще никаких сложностей не должно возникать, это обычные бригадиры, толковые и надежные сотрудники, на которых любое производство держится, иерархия группы сама выдвигает на передний план подходящих для этого людей. С инженерами и разработчиками ещё проще, они более организованы и сами покажут на будущего тимлида и сообщат что с ним им будет работать проще и они ему доверяют. Все что от Вас требуется это помочь этим людям грамотно освоиться в новой позиции, шаг за шагом, без потрясений, но этим Вы разберетесь, опыт позволяет.
Всё вышеперечисленное во многих случаях не подходит для такого типа бизнеса - могу раскрыть этот тезис подробнее, если он вызовет сомнение.
Сомнение у меня вызывает не тезис, сомнение у меня вызывает насколько хорошо Вам удалось разглядеть, что в основе предложенного мною плана лежит принцип «сначала думай, потом делай». Сначала определись, пойми что ты от будущего человека хочешь, сможет ли он это делать и как долго, и на каких условиях, подготовься как следует и только потом приглашай людей. Практика показывает что это работает независимо от типов, видов, категорий бизнесов и не только.
Что касается «доброты», то, извините, это писалось не про Вас и не для Вас. Это было написано для разработчиков перед которыми встает выбор переходить на управленческую позицию или оставаться разработчиком. Выбор сложный, хотелось показать разные его стороны. Вы писали хорошо, ярко, так что не обессудьте, приходиться соответствовать.
У меня для Вас плохая новость, похоже что инженерный менеджмент это либо заблуждение, либо Ваше личное изобретение
Собственно после этого вашего тезиса как-то странно продолжать дискуссию. Я бы вас попросил убрать явно снисходительнвый тон и основательнее подходить к проработке своей позиции. А то даже немного за вас стыдно. Очень уж тон текста не соответствует ценности его содержания.
Про тон текста это вы справедливо заметили, но термин инженерный менеджмент сильно режет ухо. Я вам расскажу следующее. Менеджмент имеет в своем основании проверенную временем, приличную научную базу с всеми обязательными атрибутами научных исследований. Это и научный метод, гипотезы, эксперименты, теории объясняющие те или иные явления, теории дающие альтернативное объяснения. И когда вы употребляете инженерный менеджмент получается что это какой то отдельный менеджмент от инженеров или специальный менеджмент для инженеров. Но если чуть копнуть поглубже, то на поверку оказывается что за всем этим стоит обычный менеджмент основанный на научной базе и никакого отдельного, специального, инженерного и всякого другого не существует. Единственное место где инженерный менеджмент оправдан это википедия, там деткам так искать удобнее. Некоторые честно называют инженерный менеджмент псевдодисциплинай. В общем, не ведитесь на этот маркетинговый Bull sheet, там только денег хотят, Вам точно подсовывают контрафакт.
Но вся эта терминологическая возня не интересна. Более привлекательным может быть обсуждение следующих моментов. В IT компаниях характерно следующее. В следствии напряженного умственного труда, увлекательной деятельности и возможных переработок сотрудники испытывают сложности с определением момента завершения работы за текущий день. Какие критерии будут использовать тимлиды, что бы не доводить людей до выгорания? Удаленка только добавляет сложностей.
Сейчас идет гонка за разработчиков. Какие возможности могут иметь тимлиды для повышения лояльности программистов в их группе?
Существует ли у Вас ротация персонала, например, для улучшения взаимно отношений между разработчиками и тестировщиками, им можно предложить поменяться рабочими местами сроком на 3 - 5 дней. Эта идея похожа на маленькую провокацию. Что могут предложит тимлиды для улучшения взаимодействия команд, как измерить результат?
Появление бригадиров - тимлидов разрушает плоскую структуру организации, перемены происходят спонтанно и часто это сопровождается снижением мотивации разработчиков. Каким образом тимлиды могут помочь в преодолении этой угрозы, на какую помощь руководства тимлиды могут расчитывать?
Это всё не простые вопросы, на них нет однозначного ответа. Но даже если Вы немного поразмышляете об этом, это уже обернется сторицей.
"был хороший программист, стал плохой руководитель". Самое печальное, что руководители, которые допускают эти ошибки при повышении сотрудников, искренне считают, что виноваты пети. Однажды от такого руководителя получил такое высказывание: "у нас не детский сад, мне некогда нянчиться с сотрудниками, они должны все сами". Откуда у этих самих найдутся необходимые компетенции, если в компании нет даже маломальского корп. обучения при этом - не известно.
Однозначно, с сотрудниками надо работать. А с молодыми руководителями работать усиленно.
Спасибо за статью! Отправил своим петям, как еще одно свидетельство со стороны.
В связи с этим возникает вопрос: что делать, если ты — Петя, а твой руководитель этого не знает/не понимает?
1) разместить резюме, и получить оффер, уже на этом этапе можно сказать проблема решена, но можно продолжить;
2) прийти у руководителю и объяснить, что ты не хочешь быть Петей, и если он не потратит время и деньги на поиск лида в команде или лучше вне команды, то тебя там нечего не задержит.
3) если руководитель согласился, но сроки сдвигаются, то просто уходить.
Я бы посоветовал обстаятельно обьяснить ситуацию руководителю. Возможно дать почитать это статью. Если руководитель поставил вас в эту ситуацию не умышленно - обговорить план действий по мануалу в статье или выставить вакансию тимлида, если вы не хотите занимать эту позицию. Если же вы понимаете что руководитель вас поставил и держит в такой ситуации умышленно - бегите.
Учитывая, что «вот-вот» (по опыту) может длиться от полугода до бесконечности, похоже, что правильный вариант «бегите».
Только вот психологический портрет Пети подсказывает, что
1) Пете трудно всё это безобразие бросить (как же там релиз без него)
2) На новом месте Петя будет склонен к рецидиву.
В любом случае, спасибо за совет.
Как я понял для себя, главное это быть востребованным на рынке и не терять развитие/получение опыта.
У меня была ситуация, когда полноценном лидом Петей я не стал, который будет востребован на рынке, а время потратил, и более того потерял знания middle’а
Не за что, советы давать легко. Я сам был таким Петей, а теперь в роли начальника у которого такие Пети работают. Поэтому искренне надеюсь на максимально позитивное разрешение ситуации и для вас и для вашего руководителя. В чём бы оно не выражалось, даже в вашем уходе. :) Иногда уход специалиста - очень полезный кейс для руководителя.
Как сделать из линейного сотрудника начальника и потом с этим жить