Comments 24
Как оно должно выглядеть
Всегда подозревал что управление тесно связано с темными силами.
Особенно для людей слабо заточенных под управленческий процесс.
Ведь управление это такой же навык как IT. Так какой смысл брать хорошего айтишника и ставить его на управление?
Почему не взять управленца, и не привить ему навыки айти?
Почему не взять джуниора, у которого уже есть базовые айти навыки, и не взрастить из него управленца?
А пока ответа на эти вопросы бизнес не дает, и делает страшные вещи по типу "извлечь самого лучшего копателя на поле, из самой глубокой ямки, дать ему золотую лопату и заставить контролировать чтобы другие копали лучше", ваша статья будет очень помогать всем "копателям с золотой лопатой" не сойти с ума. Спасибо.
Почему не взять управленца, и не привить ему навыки айти?
Потому что привить среднему управленцу айтишные навыки на мой взгляд и по моему опыту всё-таки сложнее чем привить среднему айтишнику навыки управленческие.
Почему не взять джуниора, у которого уже есть базовые айти навыки, и не взрастить из него управленца?
Например потому что пока вы такого джуна растите, то вы имеете ни рыбу, ни мясо. То есть зарплату ему платить надо, а использовать его особо не получается.
Я несколько раз наблюдал, что толковые люди на должность типа тимлида получаются скорее из хороших QA, чем из собственно разработчиков. И это вполне логично: разработчику карьера роста скорее в сторону усиления экспертности (глубже и/или шире), а не на управление людьми, а QA изначально комплексная область.
Многие компании так и делают, E5 в Facebook и Google как раз когда можно начинать идти в управленца. Не джун - но понимает как вещи работают вокруг
Наташа, спасибо Вам за текст.
Почти 5 лет назад я окончил "президентскую программу подготовки управленческих кадров", это что-то вроде курсов для тех, у кого УЖЕ есть управленческий опыт.
Главный вывод, который я сделал тогда - это "я не хочу руководить", после чего съехал обратно в разработку.
Бытует мнение, что в разработке хороший руководитель может занять место любого "выбывшего бойца" и показать, как надо. У меня сейчас обратная ситуация: я не хочу коллективной разработки, боюсь допускать кого-то в проект и "пилю" сам.
Привет! Спасибо за классный материал. Сам побывал пару лет руководителем и остались двойственные ощущения. 🥲
Ты пишешь, что убирать неруководительские задачи надо делегированием, автоматизацией и прочим. Основное все же делегирование, да? А что если нет желающих получить новые обязанности? Среднему разработчику вполне тепло и комфортно с текущим кругом обязанностей, а если что, найти другой проект проще простого. Вдохновлять к великим свершениям? На практике такого никогда не видел, хотя часто слышал про такой вариант.
Не очень понятно из статьи, как поддерживать экспертизу, если через какое-то время все твои знания не актуальны, пропадёт сразу авторитет и принятие решений будет занимать х10 времени.
У меня был такой руководитель, человек немного в возрасте и видно, когда-то «шарил». Но почти на каждой встрече предлагал абсурдные идеи, на которых очень настаивал, и приходилось тратить время и силы на объяснение очевидных вещей.
А для тех, кто все-таки не хочет расставаться с «лопаткой», есть замечательная позиция «техлид». Это тебе дают самую большую золотую лопату, ты выгребаешь самые сложные большие ямы и решаешь, как и чем вы будете копать новый участок.
В статье ж пишет, что экспертизу должны растить подчинённые. Твоя ж задача теперь это искать таланты и помогать им расти.
Техлид, в моем понимании, это как раз эксперт без команды, но с решающим словом с т. з. реализации.
Да я понял мысль, но вот ситуация, ты - тимлид, который забыл, как включать компьютер. Вот у вас новая задача и два твоих сеньора спорят, как стоит её решать. Как принимать решение, если ты стал тумбочкой?
Сам в такой ситуации не был (не так уж долго был на руководящей позиции), но в рулетке кейсов на podlodka team lead crew это обсуждали и сошлись, что норм в таких случаях искать помощи из-вне, как на уровне компании, так и позвать внешнего консультанта.
Кажется, было бы намного проще поддерживать уровень экспертизы, и самому принимать решения.
Думаю, все зависит от числа подчиненных.
Если ты тимлид команды из 3-4 человек и пилите один продукт, тут вообще не вижу причин и самому код писать (важно только не брать критовые части себе).
А вот когда человек уже 10-15, то, кажется, в большинстве случаев у тебя не будет достаточного погружения во все контексты, чтобы эффективно принимать технические решения.
Да, тут согласен.
Я имею ввиду больше про просто, например, читать книги, статьи, релизы новых инструментов, чтобы быть в контексте, что происходит в индустрии.
А не просто сидеть и руководить.
Я бы сказал что если у тебя 10 или уж тем более 15 подчиненённых, то это уже и не совсем тимлид. Многовато это для команды. И тут уже на мой взгляд 100% нужен не айтишник, а управленец.
Все равно невозможно быть экспертом во всем рано или поздно придется столкнуться с технологиями с которыми никогда и не встречались, как раз задача лида в моем понимание понять чьи аргументы звучат убедительнее или предложить как организовать проверку.
Основная задача руководителя — убирать все препятствия на пути достижения цели. Система может работать очень эффективно, если устранить всё, что мешает ей это делать: убрать все точки сопротивления, шероховатости и нестыковки.
На мой взгляд, главная задача руководителя - выстраивать процессы.
Если процессы выстроены адекватно, то и проблем постепенно становится меньше. Если же процессы выстроены криво (классический вариант - компания жадничает нанять мануал-тестировщика, и программисты сами решают, что их задача "закрыта") - то последствия разгребать можно бесконечно. Также проблемы буду накапливаться как снежный ком, если команду разработчиков ставят в позу постоянной нехватки времени.
Ну и еще. Надеюсь доживу до тех времен, когда психологическое образование для руководителей станет такой же хорошей базой (т.е. это будут спрашивать), как и профильное образование для разработчика.
Классный материал! Подтверждающий мысль, что человек с головой в принципе справиться и с управляющей позицией.
Единственное, мало сказано про ключевое отличие руководителя - при переходе от управления кодом к управлению людьми - самое драматичное, что человек - не управляем по своей сути. Код написал, не понравилось - переписал, ошибка - исправил. Код стерпит. И сделает ровно так, как ты ему сказал. Человек нет. У него есть свободная воля, а еще он может обижаться, а еще мы (как человеки) часто боимся, что он обидится - начинаются игры и т.д.
И мастерство руководителя включает в себя - важную компетенцию управлять неуправляемыми. Через включенность, синергии, поддержку, единство целей и т.д.
часто боимся, что он обидится - начинаются игры — очень верно подмечено. Я тоже сначала боялась, что люди обидятся и начинала игры, это всегда приводило к плохому. А потом с помощью других людей обнаружила существование навыка «новая коммуникация».
С помощью этого навыка можно увидеть в себе этот страх, открыто поговорить с человеком и всё прояснить. Жизнь упрощает невероятно.
У нас в ТГ есть группа, где мы как раз прокачиваем этот навык t.me/sozdateli_now
Включенность, синергия, поддержка и единство целей — это то, что можно развивать осознанно.
15 лет был руководителем в ИТ (начинал с 10 подчиненных, закончил на 300). Вернулся в разработку. Рад)
брать на себя ответственность,
На мой взгляд - это ключевой момент в вашей статье, а про него ни слова не сказано.
Совершенно непонятно, в каком видет несет ответственность руководитель и чем это отличается от исполнителя.
Еще момент: когда руководитель "руководит снаружи", как показано на вашей схеме, за что он несет ответственность? За неверную инструкцию? Это классический формализм, в Италии по такому принципу да же забастовки устраивают, когда делают свою работу исключительно в рамках инструкций.
для руководителя обязательны. Это управление временем,
В вашем списке я бы на первое место поставил способность принимать решения и нести за них ответственность. При такой формулировке многое меняется, в том числе и вопрос проф навыков, ведь тогда становится очевидно, что начинающий специалист, просто физически не может быстро оценить возможные последствия принятия решения, а для этого как раз нужен именно опыт: не просто так в хирургии до самостоятельного ведения операции с момента завершения вуза и ординатуры проходит еще порядка 5 лет.
Хорошая структура. Спасибо за статью. А что посоветуете читать?
Руководство разработкой: beginner's survival guide