Когда ты становишься менеджером, возможности кодить у тебя становится сильно меньше. И чем выше позиция, тем меньше времени у тебя на это остается. А со временем еще и желание погружаться непосредственно в код притупляется (моя история).
При этом для многих именно возможность “писать код” и является самым важным, а может и единственным критерием “ты можешь быть техническим менеджером”.
Я не согласен. Самое важное - это сохранять способность понимать “язык” инженеров (разрабов, тестировщиков, devops-ов) и говорить с ними на этом языке.
Как это достигать?
1. Много читаем, слушаем, смотрим
2. Задаем инженерам вопросы (про особенности реализации, про возникающие сложности, про то, что они рекомендуют почитать/посмотреть)
2* попутно убеждаемся, что 80% проблем не меняется, потому что люди не склонны меняться, да и технологии/практики не так уж сильно меняются
3. Не ведемся на ловушку “ничего не меняется” и продолжаем пропускать информацию через мозг. Потому что изменения всегда есть, просто они редко революционные, а скорее эволюционные
4. Есть еще, спорный для меня вариант, “возвращаться обратно в инженеры, а потом снова в менеджеры”, но если это делать, то делать регулярно. Практическая реализация этого маятника у меня вызывает вопросы: опыт показывает, что нужно быть готовым к сложностям вида “странно, из менеджеров уходит… нам не нужны менеджеры, нам нужны инженеры” или “у него недостаточный менеджерский опыт, не рулил командой в N человек”. В общем, вариант “со звездочкой”.
Помните, ваши основные менеджерские хард-скилы - это умение работать с людьми, приоритетами и задавать правильные вопросы.
Что еще посоветуете? Писать код по ночам/выходным не предлагать, для этого времени есть масса других, более приятных, активностей :)
Что для вас "хороший технический менеджер"? Особенно интересно мнение инженеров.
Что еще почитать по теме?
Is there a path back from CTO to engineer?
What Makes a Great Manager of Software Engineers?
#management #развитие #байки
При этом для многих именно возможность “писать код” и является самым важным, а может и единственным критерием “ты можешь быть техническим менеджером”.
Я не согласен. Самое важное - это сохранять способность понимать “язык” инженеров (разрабов, тестировщиков, devops-ов) и говорить с ними на этом языке.
Как это достигать?
1. Много читаем, слушаем, смотрим
2. Задаем инженерам вопросы (про особенности реализации, про возникающие сложности, про то, что они рекомендуют почитать/посмотреть)
2* попутно убеждаемся, что 80% проблем не меняется, потому что люди не склонны меняться, да и технологии/практики не так уж сильно меняются
3. Не ведемся на ловушку “ничего не меняется” и продолжаем пропускать информацию через мозг. Потому что изменения всегда есть, просто они редко революционные, а скорее эволюционные
4. Есть еще, спорный для меня вариант, “возвращаться обратно в инженеры, а потом снова в менеджеры”, но если это делать, то делать регулярно. Практическая реализация этого маятника у меня вызывает вопросы: опыт показывает, что нужно быть готовым к сложностям вида “странно, из менеджеров уходит… нам не нужны менеджеры, нам нужны инженеры” или “у него недостаточный менеджерский опыт, не рулил командой в N человек”. В общем, вариант “со звездочкой”.
Помните, ваши основные менеджерские хард-скилы - это умение работать с людьми, приоритетами и задавать правильные вопросы.
Что еще посоветуете? Писать код по ночам/выходным не предлагать, для этого времени есть масса других, более приятных, активностей :)
Что для вас "хороший технический менеджер"? Особенно интересно мнение инженеров.
Что еще почитать по теме?
Is there a path back from CTO to engineer?
What Makes a Great Manager of Software Engineers?
#management #развитие #байки