И так, вот команда растёт, растёт и дорастает хотя бы до 15+ человек. В этот момент вы неожиданно понимаете, что у вас 3 бекенд-разработчика или даже 5. Здесь возникает неудержимое желание сделать одного из них Самым-Главным-Бекенд-Разработчиком-Проекта. Это желание понятно, и даже логично:
Человек уже погружен в предметную область проекта.
Доказал способность реализовывать задачи.
У него высокий уровень лояльности к проекту и возможно к вам лично.
Кто-то должен заниматься процессами на бекенде. Ну там gitflow внедрить или merge-request’ы. А может даже какой-нибудь CodeStyle выбрать и ему следовать. Ну и в конце концов кто-то должен ответить однозначно на вечный вопрос: Laravel, Yii или всё-таки перейдем на Python?
Эту роль на самом деле часто выполняет технический директор. Но вопрос в количестве – при росте количества проектов и программистов, техдир уже не сможет нести ответственность за конкретные технологические решения в каждом проекте.
На всякий случай небольшой дисклеймер: история с бэкендерами рассматривается сугубо, как пример повышения линейного работника до руководителя и не является рекомендацией к способу организации команд. В целом я считаю, что всё что написано ниже можно отнести к любому случаю повышение до руководителя, вне зависимости от профессии и сферы.
И так, по причинам выше вы решили не звать “варяга”, а сделать программиста Петю руководителем. И он даже согласен и уже строит планы по внедрению SOLID всем, и чтобы никто не ушел обиженным.
Но вас на этом замечательном пути к прекрасной архитектуре с нулём legacy ждёт ряд препятствий. И это, даже не считая недостижимости нуля legacy на живом проекте :)
На самом деле большинство препятствий обусловлены одним простым фактом — когда Петя становится руководителем - у него меняется конечный продукт. О конечном продукте рассказал здесь — тема, конечно, не такая интересная, но методологически очень важная.
Если проще — вчера Петя отвечал за то, чтобы качественно выдать свои задачи в срок, а сегодня он отвечает за то, чтобы это делал весь отдел. И давайте вместе угадаем какой самый простой способ этого добиться в глазах вчерашнего, возможно весьма достойного, разработчика? Конечно, сделать все задачи самому! Ну или в крайнем случае — сделать самому всё самое сложное.
Самое плохое, что Петя не осознаёт смены конечного продукта. Для него ситуация выглядит просто — эти товарищи работают хуже, а я - человек ответственный, всё сделаю. О, ещё и зарплату повысили, да сверхурочные платят — фантастика просто. Я тут теперь не просто самый умный, а самый умный за деньги. Петя, конечно, ноет, но по большому счёту Петя чувствует себя комфортно. Более того, если Петя пробудет в этой ситуации пару месяцев — вытащить его уже не получиться, он будет отбиваться руками и ногами. С другой стороны, Пете хорошо, а кому плохо? Начнём перечислять :)
1. Бизнесу
Дисклеймер: Напоминаю, я пишу про малый и средний бизнес, находящийся в реальных рыночных условиях. Когда такой бизнес растет, это всегда связано с большим количеством проблем и задач. Поэтому вещи, который кажутся очевидными в структурно изложенном тексте, в реальной жизни, могут быть совершенно непонятны. Они ловко прячутся за бесконечной борьбой с кассовыми разрывами и срывами сроков.
Я знаю несколько ситуаций, когда заставить много работать такого Петю, дав ему должность — было хитрым планом начальства. Ничего не скажу о мозге таких товарищей — просто о мертвом либо хорошо, либо никак. Но это хороший управленческий пример “выстрела себе в ногу”, потому что:
а) Петя становится незаменимым — любая болезнь, отпуск, что угодно, что мешает Пете работать менее 10 часов в день приводит к срывам сроков.
б) Петя теряет требовательность к своей работе — ошибки будут объяснены 10 часовым рабочим графиком (что, кстати, справедливо).
в) Петя становится не предсказуемым, по факту вы не знаете — будут ли задачи сделаны и если сделаны — то, когда?
Итого — мы очень быстро получаем незаменимого и непредсказуемого халтурщика, вместо ценного специалиста. И это я ещё не говорю о полной невозможности к масштабированию. Внимание, господа руководители! Это происходит не потому, что Петя плохой! Любой человек поставленный в ситуацию, когда он вынужден работать по 10 часов в день станет таким. Так что, если вы это сделали не специально, а просто не осознавали, как смена конечного продукта влияет на специалиста — срочно исправляйте. А если сделали специально, потому что вам так сиюминутно выгодно — горите в аду.
2. Коллегам
Беря на себя все самые сложные и интересные задачи — Петя забирает у коллег ценный опыт. В результате люди, которые оказались под его началом имеют только две возможности:
Имитировать бурную деятельность за деньги, когда реальную нагрузку на себе несёт Петя.
Менять работу.
Напоминаю, что мы с вами не в линейной RPG, где этот выбор вам дадут в качестве ветки диалога. Это жизнь. Люди, которые находятся в этой ситуации не осознают её. Петя крутой? Крутой. Начальник? Начальник. Логично что он делает больше меня? Логично. Вопрос только в том, что так на рынке появляются “сеньоры” с 10 летним стажем, не способные связать двух строчек кода во вменяемый результат. И абсолютно не осознают, что есть какая-то проблема. На прошлой работе нормально всё было. У нас один товарищ так и не понял, зачем в высоко нагруженном проекте 2 базы данных. Ну ничего, рынок IT сейчас дикий, даже такие работу находят :) Но хотите ли вы быть таким?
3. Лично Пете
Работать по 10 часов в день может казаться классно примерно лет до 27.
А потом ты:
Полностью выгорел.
Вместо приобретения полезных навыков решал собственные косяки (и иногда своих лоботрясов).
Скорее всего имеешь нормальные такие проблемы со здоровьем.
Можешь работать только в конкретных, созданных специально для тебя условиях.
В общем по факту - позитивный эффект от такой ситуации только краткосрочный. В итоге, проигрывают все. Хотя я знаю конторы, где такая ситуация тянется десятилетиями. Но там это просто медленное загнивание и жизнь на проедание когда-то заработанных связей, сделок, продуктов и т.д.
Как сделать правильно?
Приготовьтесь — если вы делаете хорошего линейного специалиста руководителем — придётся много с ним работать и проходить определенные стадии. Пройдемся по ним.
Стадия объяснения
На этой стадии Пётр ещё толком не понимает, что с ним произошло. И вам необходимо объяснить ему как минимум четыре вещи.
Ожидания от него изменились. Теперь вы ждёте того, чтобы все остальные товарищи на проекте будут работать также хорошо, как и он. И что самое важное — готовы к падению ЕГО персональной эффективности. Потому что Пете теперь от 30 до 70 процентов времени надо будет уделять руководству. И это нормально. Под “готовы к падению его личной эффективности” - я имею в виду, что вы пересмотрите сроки выполняемых Петей задач, с учётом новых реалий. А вы как хотели? Только так :)
Не только программирование является работой. При том говорить это придется не один раз. Петра очень и очень долго будут преследовать флэшбеки по этому поводу. Вы вполне можете застать его очень грустным после вполне удачного релиза. На вопрос, чё он такой грустный Пётр ответит: “А чё я сегодня делал то? Ну там с тем поговорил, ну с этим. Ну постоял над душой пока ветку в прод толкали. Но я же не работал.” И не важно, что Пётр случайно выстроил всю коммуникацию между аналитиками, тестерами и бекендерами. Если он сам не кодил — значил не работал.
Уровень конкретности задач стал ниже, и Петя — именно тот человек, кто должен их сделать более конкретными для своих ребят.
Петя отвечает не только за то, как работают его ребята, но и за то, как он взаимодействует с другими. К примеру, как передаются задачи фронтендерам, или как должна приходить аналитика.
Стадия договоренности
Окей, Пётр понимает, что он теперь руководитель и занимается своей командой. Теперь вам очень важно договорится с ним о том, чего вы конкретно хотите от Пети. А то может выясниться, что переход на Python будет затеян в самый неподходящий момент. Для того чтобы договорится вам надо сделать несколько “простых” действий:
Расскажите о проблемах, которые вы хотите, чтобы Пётр решил. Чем конкретнее вы сможете их сформулировать, тем лучше. Ну там чтобы релизы не задерживались, или нулевой даунтайм на продакшене, или чтоб багов было поменьше. Даже если у вас есть технические компетенции, старайтесь говорить именно о проблемах, а не предлагать сразу решение. Но и диалог в угадайку не превращайте :)
Поставьте сроки. Только, пожалуйста, не волюнтаристским образом, а исходя из бизнес-задач.
Спросите, что Пете необходимо чтобы всего этого добиться. Начиная от полномочий, до ресурсов. Не пропускайте этот пункт! Сам он скорее всего вам не скажет и в конце выяснится, что надо было нанять ещё двух бэков, но он не знал, что так можно.
Подкорректируйте свои желания исходя из Петиных возможностей и тех ресурсов которые вы можете ему предоставить.
Поздравляю, вы договорились!
Стадия выполнения
На этой стадии главное помнить — ничего и никогда не идет ровно так, как задумывалось. Особенно когда у Пети нет опыта. Поэтому сделайте самое главное: помогите Петру с собственным рабочим графиком. Он как “играющий тренер” всё время будет выглядеть примерно так:
Надо объяснить, что чем больше Петр уделяет внимание подготовке задач и организации работ — тем меньше его будут неконтролируемо дергать. То есть, если:
Подробности технических решений оговариваются во время постановки задач.
Налажена нормальная схема поставки кода (нормальной считается любая, хоть git pull на продакшене прямо из репозитория /*черт, даже писать больно*/, которая объяснена людям и отработана с ними).
Договорено как должны приходить задачи бэкендерам и в каком виде они должны уходить (ну там описание API, и прочее).
Технические и архитектурные решения регулярно обсуждаются с командой и подробно разбираются.
Налажен перекрестный CodeReview.
И всё что угодно, что вам ещё нужно сделать для простого программерского счастья.
При таком подходе работу руководителя можно свести к 30 процентам своего времени. А вот если Пётр как руководитель сделает следующие:
Любой push в любую ветку строго через Merge Request, который принимает лично Пётр. (Петя ответственно относится к качеству, поэтому строго всё контролирует!)
По любому вопросу надо подходить к Пете. Если бэку что-то непонятно в аналитике — сначала к Пете. И наоборот. Если аналитику нужно что-то объяснить - он объясняет Петру и никому другому. (Петя понимает важность коммуникаций, поэтому не доверят их подчиненным)
Все самые сложные вещи делает только Петя. (Потому что Петя лучше всех знает систему. Неудивительно — смотрите пункты выше)
При таких раскладах работа руководителя будет занимать 70% рабочего дня. И еще 70% работа программиста сверху :)
Также сильно рекомендую на этой стадии регулярно встречаться с Петей и корректировать цели или ресурсы.
Стадия ретро
Ну собственно про эту стадию даже писать как-то неловко — уж сильно она очевидная. Но и не написать нельзя! Напоминаю, на Стадии договоренности вы должны были обсудить четкие цели и сроки. Вот по результату — обязательно надо встречаться и по сути проводить классическую ретроспективу. Что получилось, что не получилось и почему. Ещё неплохо бы, если Петя реально сильно повысил производительность (не разово, а принципиально) по результатам такой ретро поднимать ему зарплату. Тогда вы с Петей будете жить долго и счастливо.
Собственно цикл повторять до …
Наступление прекрасного момента
Когда Пётр станет полноценным руководителем, и вы поймете, что уже не сами ставите ему цели, а рассеяно киваете на предложения, потому что уверены, что он лучше вас разбирается во вверенном ему участке работ.
Ради этого прекрасного мига все и затевается. До его чудесного наступления нужен примерно год. Поэтому крепитесь и:
Объясните человеку, что вы от него хотите и в какой срок.
Дайте человеку необходимые ресурсы и полномочия.
Сбейте свои желания с возможностями :)
Регулярно общайтесь и корректируйте цели и ресурсы.
Вместе анализируйте результаты деятельности.
Повышайте заработную плату, по достижению видимого результата.
И тогда у вас появится надежный понимающий человек, которому вы можете доверять. Это бесценно :)
Всем добра!
Комментарии (38)
Ivan_cod
04.10.2021 12:09+8На самом деле все очень просто.
Начальник инженеров не равно самый крутой инженер.
Нужны совершенно другие навыки.
mpudalov Автор
04.10.2021 12:12+4Абсолютно согласен, но есть и обратная сторона - инжереный менеджмент требует инженерной квалификации. Так и получаются тимлиды :)
botyaslonim
04.10.2021 15:36+1Сколько было статей на эту тему, и всё равно в очень многих компаниях ставят наверх хороших инженеров с очень посредственными коммуникативными навыками
mpudalov Автор
04.10.2021 16:25+3А иногда просто выхода нет. К сожалению. Главное не забивать на это и развить слабые стороны человка. Говорю как бывший бекендер :)
mpudalov Автор
04.10.2021 16:55+25-7 человек самое вредное число, ИМХО. Еще 1-2 человека и приходится изменять схему управления.
FlashHaos
04.10.2021 17:14Наверное, в мире разработки это возможно. Но каким образом применить аналог shadow code review на поддержку инфраструктуры, например, я не очень представляю. Или на другую деятельность, не заключающуюся в генерации читаемого артефакта.
AlexGluck
04.10.2021 20:43IaC + task tracker. Проблема в том, что команда инфраструктуры это люди, а люди не всегда стремятся обучаться чему то новому.
FlashHaos
04.10.2021 21:20IaC не перевезет стойку между цодами и не разберётся с погрузкой, не смонтирует стойку в зал и не подключит кабели. И даже если брать только виртуальные действия - IaC из коробки хорошо работает только для ограниченного числа модных ныне задач. IBM Power, SAN и снепшоты на каком-то массиве HP - всё, нет никакого IaC. И это не вопрос обучения, штат разработчиков питон будет стоить компании дороже, чем штат хардкорных админов
AlexGluck
04.10.2021 22:12+1Но все эти задачи можно ставить в таск трекеры и отслеживать статус их выполнения. Никто не запрещает размещать фото выполнения работы в комментариях в таск трекерах (почти у всех есть смартфоны которые делают достаточные фотографии для оценки).
Alente1
04.10.2021 13:44+1Спросите, что Пете необходимо чтобы всего этого добиться. Начиная от полномочий, до ресурсов. Не пропускайте этот пункт! Сам он скорее всего вам не скажет и в конце выяснится, что надо было нанять ещё двух бэков, но он не знал, что так можно.
Вот это очень важно, сами не раз натыкались на это.
Мы по такой схеме вырастили администраторов секций рекламы и SEO, правда, они еще прошли курс "Кто такой руководитель", там как раз-таки объясняли им, как изменяется их продукт, по каким статистикам будем оценивать деятельность. Помогло. Не сразу. Но помогло.
Очень важно прокачивать таких ребят именно в менеджменте и показывать ценность всех этих руководительский дел.
mpudalov Автор
04.10.2021 14:02Так и происходит. Ценность "руководительства" - одна из самых сложных вещей, которые необходимо доносить.
FlashHaos
04.10.2021 14:34+5Очень важная статья. Сколько видел плохих руководителей, выросших из хороших специалистов. Сам таким чуть было не стал (чуть не стал - потому, что убежал от подкатившей ответственности, а не потому, что стал хорошим). Я вообще не встречал хорошей литературы на эту тему (если по менеджменту вообще существует хорошая литература), которая нормально ставила на место мозги вчерашним специалистам или тем, кто делает из них лидов.
Так и живем - на одного хорошего менеджера ещё пяток хороших инженеров со званием менеджера. А руководит в таких командах все равно вышестоящий. Или анархия/демократия, что в условиях организации не лучший вариант.
aklimano
05.10.2021 00:57+1Как насчёт книги "Как пасти котов"? Мне кажется для начального понимания и введения в тему довольно занятная (если вас не смущают необычные аналогии конечно).
Jon7
05.10.2021 09:24+1То что Вы описали, это хорошо известный в менеджменте так называемый «Синдром менеджера игрока». Синдром заключается в том что в данном случае Петр вместо выполнения обязанностей руководителя продолжает делать то чему его учили и что он хорошо делал до этого, быть хорошим программистом. Теперь Вы предлагаете потратить целый год для того что бы помочь человеку адаптироваться к новым условиям. Для Петра это будет тяжелейший переход. До этого Петр программировал, его деятельность была основана на алгоритмах и математике где многое исчислимо. Но теперь Петр попадает в условия в которых алгоритмы будут работать во первых только с некой степенью вероятности, поскольку теорем здесь нет, есть только статистика, и во вторых они не имеют обратного действия ctrl-z не работает, в третьих, люди не компьютеры, нельзя взять и заменить один кусок кода на другой, более совершенный. То есть вы вот так вот свободным, волевым решением отправляете одного из лучших программистов в условия «серой мглы» неопределенности, с возросшей ответственностью за людей, без инструментов, знаний и навыков. «Добрый» Вы человек однако. А с учетом того что вы будете платить заработанную плату человеку в течении года который не может полноценно выполнять свои обязанности и не факт что этот Петр продолжит работу менеджером и в сложившихся условиях не поменяет место работы, это наводит на тревожную, но разумную, мысль: «Валить надо от этого безответственного придурка, такой и проект утопит, и нас в дерьме искупает». Придурком, как вы понимаете, в данном случае будет не Петр. Финансовую ответственность никто не отменял и деньги надо считать.
Есть ли альтернативный подход? Оказывается такой подход есть и он находится прямо у нас «под ногами».
Когда возникает потребность нанять человека, вполне разумным и ответственным подходом является предварительно продумать работу будущего сотрудника и фактически заранее спроектировать его работчее место.
Начинать надо с неприятного, но необходимого. Придется анализировать и выяснять требования законодательства предъявляемые как к рабочему месту так и к будущему работнику с позиций закона.
Второе, необходимо определиться с сутью будущей работы, разобраться в чем заключается работа, какова ее продолжительность, какие требования предъявляет работа к рабочему месту и какие требования к навыкам будущего сотрудника. Особенно тщательно это надо сделать, если это будущий руководитель, который будет иметь подчиненных.
Третье, после того будет сформирован список требований, можно попробовать выяснить способы тестирования конкретных навыков будущего работника, попытался их фактически измерить.
Четвертое, потребуется определиться во сколько нам это все обойдется.
Пятое, надо принять решение, берем внешних кандидатов или растим своих. Можно провести конкурс и позволить участвовать своим на равне с внешними кандидатами.
Шестое, подготовить будущее рабочее место, разработать как использовать доступные Вам способы отбора, окончательно сформировать критерии отбора, определиться каким образом будет организован и проведен онбординг. Выяснить возможность дообучения кандидата.
Седьмое, Вам нужно сформулировать предложение которое вы будете делать будущим кандидатам.
Восьмое, Вам нужно будет подготовить план проведения и организовать тестирование и собеседование с кандидатами.
И вот теперь, на девятом пункте, если все срослось успешно, Вы можете себе позволить пригласить к себе людей и сделать им соответсвующее предложение.
Десятый, одиннадцатый и последующие пункты Вы можите расписать самостоятельно, по аналогии.
mpudalov Автор
05.10.2021 19:38Очень хороший и логичный план, не учитывающий важного факта - я говорю про инженерный менеджмент в малом и иногда среднем бизнесе. Поэтому:
Тимлидство - может требовать определенной инженерной квалификации (что полбеды) и специфичных навыков для вашего проекта (что уже серьезное препятствие).
Всё вышеперечисленное во многих случаях не подходит для такого типа бизнеса - могу раскрыть этот тезис подробнее, если он вызовет сомнение.
Вы так говорите, будто за забором тысячи квалифицированных тимлидов стоят и только ждут когда их наймут. На некоторые позиции поиск может более года занимать. Если у вас конечно внятные требования к кандидату.
Ну а по поводу доброты - вся статья как раз о последствиях принятого решения и как в этой ситуации правильно действовать чтобы не покалечить ни свой бизнес, ни человека.
Jon7
06.10.2021 02:08-2не учитывающий важного факта - я говорю про инженерный менеджмент
У меня для Вас плохая новость, похоже что инженерный менеджмент это либо заблуждение, либо Ваше личное изобретение. Так часто бывает, менеджмент сложен. Нельзя просто почитать "Основы менеджмента" Хедоури и Мескона и сказать, я квалифицированный руководитель, это так не работает. Требуется большая практика что бы ощутить как взаимодействуют люди, как формируется иерархия, как формируется мотивация.
Тимлидство - может требовать определенной инженерной квалификации (что полбеды) и специфичных навыков для вашего проекта (что уже серьезное препятствие).
Вот это интересный момент. Полбеды с инженерной квалификацией смягчается тем что руководитель не программист, у него другая работа, а вот что означают специфичные навыки для проекта. Это надо понять более подробно. Есть навыки присущие самому проекту, например, знание предметной области проекта, знание ключевых элементов проекта их особенностей и взаимосвязей, знание формальной и фактической иерархии проекта. Есть навыки связанные с созданием программного продукта, например, знание и умение применять гибкие технологии управления проектом по созданию программного продукта. Или навыки руководителя связанные с выполнением работы по управлению, то есть прогнозировать и планировать, организовывать, отдавать распоряжения, координировать и контролировать. Или навыки лидерства и борьбы за фактическую власть и политическое влияние.
Судя по тому что вы описываете, как вы потратили год на то что бы обучить человека тому какая у него получается иерархия целей в новой позиции и как целесообразно распределять рабочее время что бы эти цели достигать, то у Вас самих внутри нет ясности по данной тематике. Однако, положа руку на сердце, я Вам так скажу, на теме проектирования работы подчиненных у меня «буксовали» все из моего окружения. Это прямо какая-то «Terra incognito», хотя решение лежит на поверхности, нужно сделать списки требований и навыков. Дальше пазл начнет складываться сам собой.
С тимлидами вообще никаких сложностей не должно возникать, это обычные бригадиры, толковые и надежные сотрудники, на которых любое производство держится, иерархия группы сама выдвигает на передний план подходящих для этого людей. С инженерами и разработчиками ещё проще, они более организованы и сами покажут на будущего тимлида и сообщат что с ним им будет работать проще и они ему доверяют. Все что от Вас требуется это помочь этим людям грамотно освоиться в новой позиции, шаг за шагом, без потрясений, но этим Вы разберетесь, опыт позволяет.
Всё вышеперечисленное во многих случаях не подходит для такого типа бизнеса - могу раскрыть этот тезис подробнее, если он вызовет сомнение.
Сомнение у меня вызывает не тезис, сомнение у меня вызывает насколько хорошо Вам удалось разглядеть, что в основе предложенного мною плана лежит принцип «сначала думай, потом делай». Сначала определись, пойми что ты от будущего человека хочешь, сможет ли он это делать и как долго, и на каких условиях, подготовься как следует и только потом приглашай людей. Практика показывает что это работает независимо от типов, видов, категорий бизнесов и не только.
Что касается «доброты», то, извините, это писалось не про Вас и не для Вас. Это было написано для разработчиков перед которыми встает выбор переходить на управленческую позицию или оставаться разработчиком. Выбор сложный, хотелось показать разные его стороны. Вы писали хорошо, ярко, так что не обессудьте, приходиться соответствовать.mpudalov Автор
06.10.2021 05:47+2У меня для Вас плохая новость, похоже что инженерный менеджмент это либо заблуждение, либо Ваше личное изобретение
Собственно после этого вашего тезиса как-то странно продолжать дискуссию. Я бы вас попросил убрать явно снисходительнвый тон и основательнее подходить к проработке своей позиции. А то даже немного за вас стыдно. Очень уж тон текста не соответствует ценности его содержания.
Jon7
06.10.2021 16:22Про тон текста это вы справедливо заметили, но термин инженерный менеджмент сильно режет ухо. Я вам расскажу следующее. Менеджмент имеет в своем основании проверенную временем, приличную научную базу с всеми обязательными атрибутами научных исследований. Это и научный метод, гипотезы, эксперименты, теории объясняющие те или иные явления, теории дающие альтернативное объяснения. И когда вы употребляете инженерный менеджмент получается что это какой то отдельный менеджмент от инженеров или специальный менеджмент для инженеров. Но если чуть копнуть поглубже, то на поверку оказывается что за всем этим стоит обычный менеджмент основанный на научной базе и никакого отдельного, специального, инженерного и всякого другого не существует. Единственное место где инженерный менеджмент оправдан это википедия, там деткам так искать удобнее. Некоторые честно называют инженерный менеджмент псевдодисциплинай. В общем, не ведитесь на этот маркетинговый Bull sheet, там только денег хотят, Вам точно подсовывают контрафакт.
Но вся эта терминологическая возня не интересна. Более привлекательным может быть обсуждение следующих моментов. В IT компаниях характерно следующее. В следствии напряженного умственного труда, увлекательной деятельности и возможных переработок сотрудники испытывают сложности с определением момента завершения работы за текущий день. Какие критерии будут использовать тимлиды, что бы не доводить людей до выгорания? Удаленка только добавляет сложностей.
Сейчас идет гонка за разработчиков. Какие возможности могут иметь тимлиды для повышения лояльности программистов в их группе?
Существует ли у Вас ротация персонала, например, для улучшения взаимно отношений между разработчиками и тестировщиками, им можно предложить поменяться рабочими местами сроком на 3 - 5 дней. Эта идея похожа на маленькую провокацию. Что могут предложит тимлиды для улучшения взаимодействия команд, как измерить результат?
Появление бригадиров - тимлидов разрушает плоскую структуру организации, перемены происходят спонтанно и часто это сопровождается снижением мотивации разработчиков. Каким образом тимлиды могут помочь в преодолении этой угрозы, на какую помощь руководства тимлиды могут расчитывать?
Это всё не простые вопросы, на них нет однозначного ответа. Но даже если Вы немного поразмышляете об этом, это уже обернется сторицей.
ole325
07.10.2021 11:38да все же понятно, в компании где кроме пети черт ногу сломит, т.к. не документации, ни планов, ни чего нет, то тим-лид с улицы посмотрит и скажет, что надо документацию писать пол-года и процесс выстраивать, а не ваши релизы выпускать, а оно владельцу надо? если и так все выходит регулярно
RadioAgent
05.10.2021 09:26+2"был хороший программист, стал плохой руководитель". Самое печальное, что руководители, которые допускают эти ошибки при повышении сотрудников, искренне считают, что виноваты пети. Однажды от такого руководителя получил такое высказывание: "у нас не детский сад, мне некогда нянчиться с сотрудниками, они должны все сами". Откуда у этих самих найдутся необходимые компетенции, если в компании нет даже маломальского корп. обучения при этом - не известно.
Однозначно, с сотрудниками надо работать. А с молодыми руководителями работать усиленно.
Спасибо за статью! Отправил своим петям, как еще одно свидетельство со стороны.ole325
07.10.2021 10:59Все верно, у нас и Пети и руководители еще хуже чем Пети. Концепция про петю хорошо работает пока это подросший стартап, и немного нужно управлять.
san-smith
07.10.2021 09:06Спасибо за прекрасную статью — читал и узнавал себя в Пете:)
В связи с этим возникает вопрос: что делать, если ты — Петя, а твой руководитель этого не знает/не понимает?ole325
07.10.2021 10:49+11) разместить резюме, и получить оффер, уже на этом этапе можно сказать проблема решена, но можно продолжить;
2) прийти у руководителю и объяснить, что ты не хочешь быть Петей, и если он не потратит время и деньги на поиск лида в команде или лучше вне команды, то тебя там нечего не задержит.
3) если руководитель согласился, но сроки сдвигаются, то просто уходить.
mpudalov Автор
08.10.2021 18:18+1Я бы посоветовал обстаятельно обьяснить ситуацию руководителю. Возможно дать почитать это статью. Если руководитель поставил вас в эту ситуацию не умышленно - обговорить план действий по мануалу в статье или выставить вакансию тимлида, если вы не хотите занимать эту позицию. Если же вы понимаете что руководитель вас поставил и держит в такой ситуации умышленно - бегите.
san-smith
08.10.2021 19:08В моём случае скорее история «Потерпи ещё немного, тимлид вот-вот появится».
Учитывая, что «вот-вот» (по опыту) может длиться от полугода до бесконечности, похоже, что правильный вариант «бегите».
Только вот психологический портрет Пети подсказывает, что
1) Пете трудно всё это безобразие бросить (как же там релиз без него)
2) На новом месте Петя будет склонен к рецидиву.
В любом случае, спасибо за совет.ole325
08.10.2021 19:27+1Как я понял для себя, главное это быть востребованным на рынке и не терять развитие/получение опыта.
У меня была ситуация, когда полноценном лидом Петей я не стал, который будет востребован на рынке, а время потратил, и более того потерял знания middle’а
mpudalov Автор
09.10.2021 08:52Это вообще отдельная боль. Когда-то я был полноценным Full-stack (ещё во времена JQuery), а потом обменял эту квалификацию на управленческие навыки. Хотя в бэкенде я ещё силён :) И в целом доволен, но иногда накатывает тоска и руки тянуться освоить TypeScript, благо штука простая.
ole325
09.10.2021 11:33Теперь организую процесс, что бы шестеренки сами крутились, а свободное время беру какую либо задачу самому решать, ну или в паре с кем то, но в qa задачи конечно попроще.
mpudalov Автор
09.10.2021 08:47Не за что, советы давать легко. Я сам был таким Петей, а теперь в роли начальника у которого такие Пети работают. Поэтому искренне надеюсь на максимально позитивное разрешение ситуации и для вас и для вашего руководителя. В чём бы оно не выражалось, даже в вашем уходе. :) Иногда уход специалиста - очень полезный кейс для руководителя.
HellWalk
Розовые очки. Даже выполняя все эти пункты, через год можно увидеть резко возросшую текучку кадров. Почему - а потому что человек, который всю жизнь привык управлять компьютером, людьми, скорее всего, будет управлять также. А это плохой подход.
Конечно, у программиста внутри могли быть хорошие навыки коммуникации, но в статье ничего не сказано, как выявлять таких программистов.
Лучший мой руководитель был с образованием семейный психолог. После него, понимаешь, какое же в среднем «дно» на уровне менеджмента.
mrVasilisk
Глупо выдвигать в руководство специалиста, который умеет только хорошо кодить. Имеет смысл присмотреться, а кто при этом ещё и неформальный лидер в команде. И сделать его формальным. Не все хотят или могут руководить людьми. И это нормально.
Racheengel
Не, ну если человек руководить в принципе не хочет, то не надо его насильно в начальники. Только хуже будет.
С другой стороны, если он хочет именно лидером, а больше толком ничего не умеет - тем более не надо. Скатится в микроменеджмент и "я начальник, ты дурак".
А если он вроде и с головой, и не против, то уже можно. Только человек должен сразу понять, что на код у него останется от силы процентов десять времени. Остальное будут митинги, переговоры и поверпоинт. И ещё придётся научиться правильно делегировать задачи и ненавязчиво контролировать процесс их выполнения, а не бросаться грудью на тикет "вот щас сам сделаю!".
И софт скиллс, да. То за повышением придут, то пожаловаться, то похвалиться, иногда с предложением "давайте всё переделать". И надо будет как-то с этим жить...
kaichou
Очень опасная рекомендация. Неформальный лидер часто может строить свой авторитет на негативной базе (обычно, сам того не замечая).
mpudalov Автор
Я пишу из своего реального опыта. То есть, если бы я так не делал и это бы не был системно успешный кейс - я бы не писал. Текучка кадров гарантировано будет, если не заниматься работой с новоиспеченным руководителем, о чём собственно и пост.
Абсолютно согласен. Но есть сферы и проекты, где для управления необходимы глубокие технические знания. Поэтому действительно нужно выбирать человеку который а) хочет б) теоретически может. А после этого с человеком работать. Как его выбирать? Вы правильно написали - должны быть коммуникационные и организаторские задатки, а также желание их развивать. Иногда стоит просто прийти ногами в команду и понаблюдать за людьми.
Какой был размер команды и проект, если не секрет?