Почему делегирование — это сложно?
Все начинающие руководители сталкиваются с проблемой переосмысления собственной роли. Раньше ты был разработчиком, сегодня стал менеджером. Но что это такое — менеджер? Руководители редко говорят новоиспеченным тимлидам какие теперь будут их обязанности, а сам "вчерашний разработчик" хватается, как утопающий, за нечто понятное ему из прошлой роли — написание кода — и продолжает оставаться разработчиком с лычкой менеджера. И это, на самом деле, проблема, которая уходит глубоко корнями в экзистенциальный вопрос: "А зачем я буду нужен, если не буду писать код?" Вопрос, который естественен для переходного периода смены роли и который может усугубить синдром самозванца, если вовремя на него не дать ответ.
Я часто вижу мысли (как на картинке к посту) о том, что харды — это обязательно только жесткие навыки программиста (ну или специалиста любой профессии). Но что такое харды в принципе? Это знание инструментов и умение с ними работать. Так почему мы считаем, что инструменты есть только у специалистов, а менеджер просто "руками водит"? Потому что про инструментарий менеджера мало кто говорит. Причем даже сами менеджеры, которые других менеджеров назначают. А знаете почему? Потому что многие менеджеры находятся в зоне "интуитивного менеджмента" и инструментов управления не знают. Поэтому и держатся они за то, что им понятно.
Однажды, я прочитал фразу в книге Леши Пименова (кстати, ее можно бесплатно выиграть, тут инструкция), которая мне прямо врезалась в голову и я в тот момент ее по настоящему прочувствовал:
Руководитель должен осознать, что мир его работы изменился и ему нужно выбрать другой фокус — развиваться как управленец, при этом деградируя как специалист, или отказаться от управленческой должности.
Деградировать, как специалист, это не значит деградировать в принципе. Это значит, что необходимо изучать и применять новые инструменты, формировать новые харды, постепенно отказываясь от своих прошлых инструментов и обязанностей. Это сложно, но это неизбежно нужно сделать, так как не возможно быть везде и всюду ответственным, всех ревьюить, все ТЗ согласовывать, весь код в одного писать. Нужно учиться отпускать ответственность, передавать ее другим членам команды. Нужно учиться делегировать.
Но делегирование — это навык. Один из ключевых жестих навыков (хардов) руководителя, которому обычно не учат. И делегировать нужно другим людям, а у людей нет документации или открытого API. Тем не менее, у делегирования есть разные подходы и свой инструментарий, о которых поговорим в следующим постах.
А как у вас с делегированием? Становились "жертвой" делегирования? А может сами совершали ошибки при передачи ответственности? Поделитесь, мне интересно 🙏🏼
P.s.: кстати, серию постов не просто так начал, в январе (надеюсь) запишем и опубликуем подкаст с моим участием, посвященный теме делегирования, должно быть интересно.)
Think about it 🧠 | @ulyanov_life
