Комментарии 20
Другими словами, в условиях кадрового голода ваша команда, во-первых, не должна размениваться на мелочи — только фокусироваться на самых ценных задачах; во-вторых, вы должны быть уверены, что ваше производство эффективно.
Я бы тут несколько иначе сформулировал: Вам придется выбирать приоритеты.
Если раньше вы могли сделать все, что вам поручают. То теперь команда не может сделать абсолютно все, что от нее хотят. И отказываться от чего-то — важная часть вашей работы.
"Помните, что каждый из ваших старших коллег-руководителей был на вашем месте и преодолевал практически те же самые проблемы"
То что для одного проблема - для другого проблемой часто не является, ситуации очень разные. И вообще - "Самый большой миф науки об управлении - то что она существует" (Кто-то из великих).Сталкиваясь с производственными или организационными проблемами, слушайте как можно больше мнений, выбирайте лучшее решение.
Переформулируем. Сталкиваясь с проблемами - пытайтесь их решить.Не забывайте, что без команды вы никто, поэтому оберегайте свою команду от переработок, бесполезной работы и лишних нервов. Но не переусердствуйте, ваше стремление беречь команду не должно мешать её развитию.
Как всегда. Если нужно стараться - старайтесь, а если не нужно - то не старайтесь. Не принимайте плохих решений, принимайте хорошие.Не торопитесь бежать по карьерной лестнице, получите от каждой ступени максимум практического опыта. Ведь постепенный и вдумчивый карьерный рост всегда качественнее роста стремительного, сопровождаемого «болезнями роста».
Если хочется карьерного роста, то существуют окна возможностей, следующего окна может не быть, и вообще - мир изменится. Кто-то, кто хочет карьеры, откажется от предложения повышения, потому что вспомнит, что "вдумчивый карьерный рост" лучше?К последнему выводу претензий нет.
Не так-то просто сформулировать выводы, чтоб они не выглядели очевидностями. ;)
За это время я прошёл путь от руководителя группы разработки до руководителя целого направления
Думается, будет полезно добавить сколько это в людях. Между компаниями названия структур редко совпадают, сходу непонятно сколько это шагов по карьерной лестнице и сколько сейчас в подчинении сотрудников.
в Озоне "направление" содержит "отделы", внутри которых "группы", в которых уже работают разработчики. Само "направление" может быть частью "департамента" или сразу "дирекции". Четких требований по хедкаунту нет.
так сколько было людей в подчинении и сколько стало в вашем конкретном случае?))) Это, к слову, куда как более наглядная история, чем майки и сторипоинты. Я руководил командами на 40 и на 8 человек. Разница очень большая как раз в уровне вопросов, решаемых на уровне команды, а не руководителя. Трайбы там на 100 человек - так же другой шаг. Руководить всем ИТ - следующая ступенька и так далее. Каждая ступенька - определенный набор навыков для развития, и от вашего числа "тогда" и "сейчас" как раз станет понятно, а на каком уровне вы находитесь, для которого релевантны ваши советы. К примеру, для любого следующего уровня за 20 человек я бы посоветовал найти в первую очередь полного заместителя на случай атомной войны из коллег и растить его как замену, постепенно делегируя зоны ответственности. Это гарантирует отпуска и свободную голову. Для уровня 100+ в первую очередь я бы советовал вообще отказаться от деталей и лезть только в верхние метрики команд и сервисов, но зато делать это регулярно, чтобы иметь руку на пульсе и видеть взаимосвязи. Что там дальше - еще не знаю)
тогда - один, сейчас чуть больше 50-ти, завтра (посчитал открытые вакансии на рост) - почти 70. прошел ли я строгий ценз? :D
Роман, есть ли у вас one to one с главами отделов или техлидами команд? как собираете инфу о блокерах в работе?
50-70 человек - это очень солидно, однако не возможно же общаться со всеми.
Ну тут все достаточно просто. У меня есть "директы" (те, кто структурно подчиняются непосредственно мне) - это несколько руководителей отделов (т.н. tgm-ы) и групп (тимлиды). С ними у меня 1-1 еженедельные. НО. Если кто-то из них будет тянуть несколько дней, чтобы сообщить мне о блокере, то это его серьезная ошибка. Кстати, не припомню, чтобы такие ошибки у нас допускались. Блокер, который не решается на уровне моего директа, а решаетя на моем или выше - это серьезная проблема, о которой нужно узнавать незамедлительно. На всякий случай, под блокером я тут понимаю нечто, остановившее выполнение какой-то важной производственной задачи :)
Кроме моих "директов" есть руководители, подчиняющиеся моим директам - у меня это всегда тимлиды. С ними у меня тоже есть регулярные 1-1, но проводим мы их раз в месяц. На этих встречах я обычно не ожидаю услышать о неизвестных мне производственных пробемах (ведь у меня есть директы), но иногда такое случается, что добавляет ценности этим митингам. Но в целом это встречи больше про "держать руку на пульсе", чем про "производство".
Иногда мне необходимо проводить разовые 1-1 с рядовыми сотрудниками. Причины бывают разные, редко напрямую связанные с производством. Например, это может быть сбор фидбека из первых рук по какому-то процессу или взаимодействию. Кстати, сразу после отпуска (следую своим же советам по профилактике выгорания, поэтому отвечаю с такой задержкой) планирую провести такие 1-1 с четырьмя-пятью сотрудниками. Размажу встречи на пару недель - совершенно ненапряжная работа :)
Кто-то со мной не согласится, но по моим ощущениям 10 "директов" - это тот порог, после которого уже стоит задуматься о реструктуризации, потому что, действительно, "общаться со всеми" становится тяжело.
Ни слова про планирование.
Роман, подскажите пожалуйста, что изучить, чтоб быть ближе к команде разработчиков и понимать все нюансы?
Я руководитель в ИТ, но вырос из инфраструктуры, а не разработки.
Дело в том, что сейчас огромный процент руководящих вакансий в ИТ предполагают именно знание и понимание разработки и руководство разработчиками.(я страдаю)
Если вы чувствуете недостаток хард-скилов по какой-то теме, то отвечу банально - нужно прокачивать эту самую тему. У меня в направлении есть живые примеры руководителей, которые прошли или проходят через эту же проблему - один из них, например, пошел получать второе высшее заочное образование в области математики и машинного обучения и теперь без проблем "разговаривает на одном языке" с командой ML-щиков (команд у него несколько), другой пошел на продвинутые курсы бэкенд разработки (сам он тимлид-фронтовик) только для того чтобы в будущем суметь управлять универсальными командами. А если вспомнить наш департамент (структурная едница, частью которой является мое направление), то я знаю и гуманитариев и даже бывших продактов, которые теперь успешно руководят направлениями и отделами разработки. Вы не первый с такой проблемой :)
Все это, конечно, про долгий путь, а вы страдаете здесь и сейчас, поэтому в моменте могу посоветовать опереться на команду. Если команда вам досталась в основном адекватная, то они наверняка поймут, что вам нужно немного времени, чтобы их догнать - играйте с ними в открытую, не пытайтесь строить из себя большего специалиста, чем вы сейчас есть на самом деле. Попробуйте выделить хотя бы одного синьера, который условно станет вашей "правой рукой", т.е. и подскажет и поможет принять правильное решение. Ну и не бояться задавать "глупые вопросы" в подходящие моменты - это тоже ваше обязательное лекарство.
Надеюсь, хоть немного помог.
Задокументируй, милок, все свои знания, чтобы нам было проще тебя использовать и выкинуть, когда ты станешь неугодным.
Вы правы. Стремление человека делиться своим опытом и знаниями в условиях конкурентной борьбы бывает сложно объяснить чем-то кроме его ЧСВ. Однако вы не учитываете тот факт, что написание подобных статей может быть своеобразным "перелистыванием страницы" или "закреплением пройденного материала", когда автор находится уже на следующих уровнях развития и решает уже совершенно другие задачи и проблемы, а значит имеет перспективу. "Выкидывать" же тех, кто развивается (если мы про эффективное производство, а не самодурство) - непозволительная роскошь, тем более в условиях конкурентной борьбы. Более того, когда вы уже на "следующем уровне", то вы непременно захотите, чтобы те, кто находится на уровнях предыдущих, разделяли с вами ваши ценности (если вы понимаете о чем я), ведь только тогда вы сможете в свой работе на них уверенно опереться, а для этого нужно в том числе писать вот такие статьи.
Типичные проблемы молодого руководителя