Комментарии 23
Тоже был "играющим тренером", даже писал об этом. И если для меня это было полезным опытом, то для некоторых моих коллег это стало серьёзным ударом: выгорание, уход с работы, крест на управленческой карьере.
Мой вариант: “Играющий тренер в ИТ: семь раз отмерь...”
Абсолютно согласен, это не универсальный вариант для всех. Есть как плюсы, так и минусы, среди которых как раз риски выгореть, уйти из профессии и т.п.
Заходить в это направление нужно осознанно и, крайне желательно, с внешней поддержкой опытного коллеги-руководителя. Со стороны, чаще всего, лучше видно когда что-то идет не так, а опытный коллега может дать дельный совет или вовремя остановить.
Просто на них навесили обязанностей сверх всякой меры. Чтобы один человек делал работу 2х очень опытных сотрудников - сильного сеньёра и начальника отдела. Вот они и выгорают от истощения.
Реально можно качественно писать код не более 5 часов в день, а то и меньше. Все остальное это либо чудовищное падение качества, либо работа на износ так, чтобы потом 2 недели вообще не работать, а восстанавливаться.
Если же человек и пишет код, и занимается менеджментом, то он может писать код часа 2-3 в день, и ещё пару часов участвовать в совещаниях, писать отчёты, официальные письма и т.д.
Подозреваю, что ваши знакомые работали в режиме - часов 6-7 пишу код и ещё 3-4 на менеджмент, а может и ещё жестче. Наверное старались выслужиться и доказать начальству, что они соответствуют занимаемой должности. Вот и переутомилась от постоянного напряжения. Короче работодатель поиспользовал их на 200% и выкинул, после того, как они сломались.
Ничего особенного на них не навешивали, где-то не доглядели (процессы еще не были отлажены), где-то человек сам понял, что управление не его (и это отчасти даже плюс - вовремя понять, что это "не твое"). В общем причины были разные.
Если вам проще считать, что компания всегда хочет вас "поиспользовать" (без какой-либо компенсации) - ваше право. Такое часто встречается, но бывают и исключения.
Поделюсь своим опытом, у меня опыт из QA, DevOps, разработки. Есть вещи, которые я знаю хуже чем мои подчиненные, но мой общий бекграунд и разностороннее понимание одной и той же проблемы дает ощутимые преимущества при решении сложный кейсов. Я это не ради похвалы себя пишу, а чтобы показать, что это работает. Конкретно в играющем тренерстве: если вы не были разработчиком, то вам будет сложнее ими управлять, т.к. вы не знаете специфики. Научиться этому можно, но потребуется время.
Великие достижения в области авиации, космонавтики делались под руководством играющих тренеров Королева, Туполева, Микулина и других. Параллельно с ними конечно были в этих коллективах безвестные завхозы и табельщицы. Сейчас эти завхозы и табельщицы взяли верх. А что до выгорания. Ну тяжело общаться с завхозами и табельщицами не будучи завзозом и табельщицей.
В целом согласен, но акцент бы усилил на размере команды: для команды из 3 человек писать самому можно и нужно (менеджерская составляющая будет еще незначительной), а в команде больше 7 человек лучше сосредоточиться только на лидских активностях.
И от фазы продукта зависит: после выхода в прод менеджерская нагрузка возрастает.
По поводу размера команды - я об этом писал в последней части
Роль играющего тренера – это хороший старт для руководителя небольшой команды (1-3 подчиненных). С ростом опыта возможно увеличение команды до 7 подчиненных, но минусы постепенно начнут превалировать над плюсами. Если в команде больше 7 человек, на мой взгляд, лучше придерживаться более классических форм управления с разделением ролей руководителя и исполнителя. Опять же, всё зависит от конкретной ситуации и вашего опыта, желания и компетенций.
По фазе продукта - имхо, зависит от ситуации и распределения ролей. Но как дополнительный фактор тоже допускаю.
Сотрудник занимающий несколько ролей ГАРАНТИРОВАННО хуже справляется с ними. Т.е. его эффективность в данных ролях ниже, а значит каждая роль обходится дороже. В какому случае эта магия может быть выгодна? Случай только один, сотрудник как вол за счет своих внутренних комплексов, а следовательно ценой дикого стресса, БЕСПЛАТНО эти роли пытается тянуть и вытягивает на приемлемый уровень. Или роль настолько редуцированная, что в реальности не следует говорить об "играющем тренер", например не является же руководителем сотрудник который админит и ведет табель.
Если же говорить об нормальной организации играющего тренера, то ему на часть ролей нужен "зам"( да, как у "больших" начальников ), который эту роль и будет выполнять. И это будет всегда дороже чем, отдельный сотрудник на каждую роль.
Так что, если у вас есть ценный сотрудник, которого вы хотели бы видеть руководителем, а он не готов отдать технически компетенции, то или он не может быть руководителем( да, не все умеют и могут делегировать ) или будьте готовы сильно увеличить затраты, выше того уровня за который вы наймете менеджера на эту позицию. Остальное это экономия на штате ценой выгорания сотрудника, самая некрасивая форма эксплуатации, компания отряхнётся и дальше пойдет, а сотруднику их этого состояния долго выплывать.
Я явно обозначил, что работа играющим тренером это компромисс
Итогом работы в качестве играющего тренера будут компромиссы и допущения. Периодически будет требоваться корректировка в моменте. Рассматривайте роль играющего тренера как временную – для набора управленческого опыта или срочного решения возникшей ситуации
Как долго человек будет работать в таком формате (и ради чего) решается ситуационно, это зависит от ряда факторов. Причем решение принимает как компания, так и человек.
Я знаю кейсы, когда такой формат помогал растить руководителей, но знаю истории, когда он же их окончательно выжигал и люди уходили из профессии. Здесь нельзя четко сказать "это плохо или хорошо", в разных ситуациях ответ будет разным.
В последнем абзаце вы фактически спрашиваете стоит ли растить лидов или брать их всегда снаружи. Тут каждая компания сама решает хочет ли она вкладывать деньги в человека. У обоих вариантов (растить или брать снаружи) есть свои плюсы и минусы.
Отдельно добавлю, что
компания отряхнётся и дальше пойдет
сильно зависит от компании (ее политик, правил и норм) и совсем не зависит от принятых форм управления, а также вашей конкретной позиции в компании
В последнем абзаце вы фактически спрашиваете стоит ли растить лидов или брать их всегда снаружи. Тут каждая компания сама решает хочет ли она вкладывать деньги в человека. У обоих вариантов (растить или брать снаружи) есть свои плюсы и минусы.
Нет, я утверждаю, что процесс выращивания кадров, хотя в данном случае мне кажется данный термин не совсем верным, поскольку это смена компетенции, а нее рост, не бесплатный. Кто-то за этот процесс в любом случае заплатит. Или компания, которая понимает, что вчерашний разработчик не может быть эффективным руководителем и кто-то должен делать его вчерашнюю работу, или сотрудник который по наивности решил, что оно само рассосется. В худшем случае платят и компания, и сотрудник.
По этому сотруднику нужно сто раз оценить свои силы и возможности перед тем как в такой квест ввязаться и ОЧЕНЬ хорошо понимать, как он из этого квеста будет выходить. Знать выход в данном случае, это не порядок важнее всего остального. Очень часто сотрудник думает нужно только поднапрячься и не отдает себе отчет в том, что это поднапрячься, само не закончится НИКОГДА, а будет только расти. Проблема в том, что сотрудник понимающий эту фичу с поднапрячься особо не нуждается в таких статьях, это уже или готовый менеджер или человек понимающий почему не хочет им быть. В остальных случаях сотрудник ввязывается в проект "начальник" и только потом понимает, что оно само не рассосётся и оказывается, что его компетенции и веса не достаточно, чтобы защитить себя от подобной практики руководства. Классно если ему с руководство повезло и оно относительно мягко его через этот этап проведет, избегать совсем этого этапа не очень хорошо, это очень полезный опыт для руководителя, должен произойти слом, чтобы человек прочувствовал, что такое делегирование, но я практически не встречал такого "менторства" в реальном мире. Основные риски здесь в выгорании сотрудника или в его глухой защите от этого самого выгорания, и в том и в другом случае, человек начинает тормозить все процессы, работает с крайне низкой эффективностью, демотивирует всех кто с ним взаимодействует, топит любую новацию, консервирует свою зону ответственности.
Соглашусь, за этот опыт придется заплатить (возможно даже обеим сторонам). Выбор должен быть осознанным как со стороны компании, так и сотрудника. И, повторюсь, крайне желательно иметь опытного ментора/наставника, чтобы он помог без потерь пройти этот этап роста в руководители.
Рост в лидов через играющее тренерство практикуется в ЦИАН достаточно давно, накоплен большой опыт, набиты шишки. Сейчас процесс уже отлажен, за каждым тренером закреплен ментор, который следит за ростом и проблемами + предлагает решения. Если нужно больше деталей - скажите.
Каждый раз, когда на работе говорили про "играющего тренера" это означало, что ты должен нахаляву сочитать обе роли на фуллтайм. Типа одновременно тимлид и сеньор-помидор. А потом ты садишься на проект и у тебя либо команда разваливается, либо приходят вопросы, а чего ты так мало накодил за неделю. Проходили.
Правда это была галера, которая притворялась, что она не галера.
Такой вариант вполне возможен. Но это не означает, что играющее тренерство не работает в 100% случаев.
Вопрос в том какая цель этого всего с точки зрения бизнеса.
Мне кажется, что это чисто экономия.
Какие плюсы для работника я так особо и не понял.
Одна из целей бизнеса - развитие сотрудников внутри компании, вместо найма извне.
Плюсы я описывал в блоке плюсы/минусы - детально смотрите там. Немного дополню/обобщу именно будущего играющего тренера (еще никогда не был лидом). Но это тоже зависит от зрелости процессов:
вам дают возможность роста в управление/менеджмент, не требуют экспертных знаний в управлении;
хорошая возможность понять нравится/не нравится менеджмент. Может это вообще не ваше и в мечтах было по-другому
рост постепенный с менторством от опытных коллег;
развивается многозадачность и улучшается взаимодействие с командой
Спасибо за статью и за советы, в частности.
Совмещаю работу владельца продукта и аналитика. Для меня основная трудность - это постоянные переключения и смена контекста. Зато как ВП ты очень хорошо погружен в продукт, знаешь его нюансы и можешь говорить с разработчиками на одном языке.
Рад, что статья оказалось полезной :)
Переключения контекстов это прямо часть жизни играющего тренера. С одной стороны - развивает многозадачность, с другой - получаешь расфокус со всеми вытекающими.
К слову, это хороший показатель, что, возможно, менеджмента уже слишком много и "пора выбирать". Если вы один 15 человек напрямую менеджите (без подчиненных лидов), то кмк это прям достижение, либо команда хорошая. Столько в прямом подчинении имхо сильно тяжеловато.
Ну, слово "достижение", как по мне, слишком сильное в этом контексте. Балансировать свои задачи удается, хотя сложности довольно ощутимы. А команда, безусловно, хорошая. Мастера своего дела, с которыми приятно работать.
Вот несколько простых методов, которыми пользуюсь сам. Было приятно увидеть некоторые из них в статье :)
Составляйте планы. Это очень помогает держать фокус на главном.
Доверяйте. Эффективно делегировать без доверия не получится.
Будьте открытым и доступным для команды. Рассказывайте о своих планах и будьте готовы потратить столько времени на объяснения задач, сколько потребуется вашим коллегам. Команда, хорошо понимающая потребности клиента, справится с задачами лучше. А вы потом потратите меньше времени на корректировку результатов.
Поощряйте инициативу. Порой разработчики, погруженные в бизнес-ценность продукта, предлагают отличные идеи.
Помогайте. Вы не только руководитель, но и участник команды. Правда, нужно четко разделять помощь и решение задачи за коллегу.
Берегите время. Если что-то не нужно делать (или, вероятно, не потребуется), не тратьте на это ни свое время, ни время своих коллег.
Используйте календарь для обсуждений. Если нужно пообщаться дольше 15 минут, лучше поставить встречу. Так не придется работать урывками над своими текущими задачами. Простой тайм-менеджмент.
Записывайте задачи и договоренности. В голове все удерживать очень сложно. Да и не нужно.
Совмещаю разработчика и ВП. При этом и раньше был хорошо погружен, и знал нюансы — потому что когда ты ведущий разработчик в небольшой команде, иначе может и бывает, но редко. Жду не дождусь, когда вернется штатный ВП, чтобы свалить с себя нафиг эти обязанности. Понимаешь, что нужно, понимаешь, что выбора особо нет — но очень некомфортно.
Работал в таком режиме, опыт положительный, но - это стартап, и отдел был небольшой, и не было всего что есть у "настоящего" начальника - служебных записок, отчетов, согласований, разработки/защиты бюджета и прочего подобного.
Не все из перечисленного есть у любого руководителя. Например, бюджеты могут быть у вашего начальника на вашу команду, но вы ими напрямую не управляете (скорее рекомендуете ему что-то включить). Служебные записки писал пару раз в жизни и в ИТ особо не встречал.
В тему "настоящего" начальника предложил бы меньше на эту тему рефлексировать. Если вы управляете людьми, процессами - то вы вероятно уже начальник. На сколько хороший - другой вопрос, но сами регалии в духе
служебных записок, отчетов, согласований, разработки/защиты бюджета и прочего подобного.
тут имхо малозначимы. Они могут быть как у хорошего, так и у плохого руководителя. Развивайтесь, достигайте новых целей и поувереннее в себе :)
Спасибо за совет )
В тему "настоящего" начальника предложил бы меньше на эту тему рефлексировать
Рефлексия моя не о том, что начальничество это фу, не фу, мне нравится, но не бюрократическая рутина, а организация успешной деятельности, а это не везде доступно, где-то нужно отвечать за, и быть точкой коммуникации с вышестоящим руководством, не более.
В общем - как повезет с работодателем
Играющий тренер в ИТ: запретить нельзя допустить