Само определение ситуации неправильное. Никто не будет в коммерческой неназываемой организации которая нанимает по 10-15 и больше человек в месяц "пытаться сделать менеджера" из нормального программиста если он четко открыто скажет что он этого не хочет. Советы которые написаны сверху - они для тех "нормальных" программистов которые хотели (либо были не уверены что НЕ хотят) быть менеджерами и соотв были повышены до этой роли - с их гласного или молчаливого несогласия. Эти советы им - как попытаться реально трансформироваться в менеджера если уж решили что да, хотят. Можно конечно использовать эти советы как основу для решения, но думаю что есть более интересные материалы на тему "кем быть". На тему карьерного продвижения - всего в хай-тек компании с моей точки зрения таких продвижений с моей точки зрения всего две, если оставаться в рамках engineering, а не переходить в сейлс/маркетинг/поддержку/трейнинг и т.п. 1. Individual contributor (тут в формальной иерархии high-tech максимальная должность для software инженера - если он конечно не настаивает на "программировать всю жизнь") - это либо Chief Architect, либо CTO (который может иметь маленькую группу, но реально просто идеолог, а не менеджер). Хорошая возможность если любишь вещи сделанные своими руками больше чем что-либо еще и/или получаешь удовольствие от самого процесса создания чего-то конкретного (соотв. в обоих случаях как правило имеешь очень большое ego ;) потому что думаешь что лучше тебя - никто. И действительно никто в твоей компании - потому что зачем второго такого брать если на задачи хватает одного?). Оптимальная роль для стартапа (где нужны "герои") или наоборот - для какого-нибудь весьма устоявшегося процесса где надо поддерживать статус-кво. 2. Manager. Тут собственно ограничений вверх нет. CEO - это много более 'менеджер' чем 'individual contributor', к примеру. Хорошая возможность если хочешь решать проблемы и удовольствие получаешь от результата, а вот в самом процессе готов про удовольствие забыть (поскольку менеджемент в более-менее не-рабской компании где люди свободно приходят и уходят - это всегда сплошные утрясания, договоры и компромиссы, ничем принципиально не отличающиеся от любой другой организацинной работы вовлекающей много людей - типа организации скажем вечеринки на 10 человек). Во вменяемой компании менеджер еще получает возможность (а хороший менеджер - передает её вниз) менять процессы так чтобы уменьшить будущие проблемы. У contributor такой возможности никогда нет, потому что он говорит все лишь от своего лица, и его мнение не много значит - его берут делать конкретную работу, а не улучшать процессы в компании. Как любая формальная классификация, две категории наверху конечно же упрощены. Хороший менеджер будет всегда участвовать в работе группы индивидуально, потому что гораздо полезнее и нагляднее _показать_ что именно ты хочешь, а после этого объяснить как именно ты это сделал. Просто хороший менеджер определит границу между delegate, teach и do it yourself. И соотв построит баланс между временем которое нужно потратить на обучение тима с прицелом на то чтобы они могли делать больше сами в будущем vs. сделать-хорошо-самому-сейчас-и-заткнуть-дыру.
P.S. Советы кстати очень хорошие. Многие из них я в том или ином виде пытался тебе дать, в частности 5, 6, 8 и 10, плюс 3 в части Walking (в противоположность «sitting writing e-mails»).
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2005-09-22 08:46 pm (UTC)Советы которые написаны сверху - они для тех "нормальных" программистов которые хотели (либо были не уверены что НЕ хотят) быть менеджерами и соотв были повышены до этой роли - с их гласного или молчаливого несогласия. Эти советы им - как попытаться реально трансформироваться в менеджера если уж решили что да, хотят. Можно конечно использовать эти советы как основу для решения, но думаю что есть более интересные материалы на тему "кем быть".
На тему карьерного продвижения - всего в хай-тек компании с моей точки зрения таких продвижений с моей точки зрения всего две, если оставаться в рамках engineering, а не переходить в сейлс/маркетинг/поддержку/трейнинг и т.п.
1. Individual contributor (тут в формальной иерархии high-tech максимальная должность для software инженера - если он конечно не настаивает на "программировать всю жизнь") - это либо Chief Architect, либо CTO (который может иметь маленькую группу, но реально просто идеолог, а не менеджер). Хорошая возможность если любишь вещи сделанные своими руками больше чем что-либо еще и/или получаешь удовольствие от самого процесса создания чего-то конкретного (соотв. в обоих случаях как правило имеешь очень большое ego ;) потому что думаешь что лучше тебя - никто. И действительно никто в твоей компании - потому что зачем второго такого брать если на задачи хватает одного?). Оптимальная роль для стартапа (где нужны "герои") или наоборот - для какого-нибудь весьма устоявшегося процесса где надо поддерживать статус-кво.
2. Manager. Тут собственно ограничений вверх нет. CEO - это много более 'менеджер' чем 'individual contributor', к примеру. Хорошая возможность если хочешь решать проблемы и удовольствие получаешь от результата, а вот в самом процессе готов про удовольствие забыть (поскольку менеджемент в более-менее не-рабской компании где люди свободно приходят и уходят - это всегда сплошные утрясания, договоры и компромиссы, ничем принципиально не отличающиеся от любой другой организацинной работы вовлекающей много людей - типа организации скажем вечеринки на 10 человек). Во вменяемой компании менеджер еще получает возможность (а хороший менеджер - передает её вниз) менять процессы так чтобы уменьшить будущие проблемы. У contributor такой возможности никогда нет, потому что он говорит все лишь от своего лица, и его мнение не много значит - его берут делать конкретную работу, а не улучшать процессы в компании.
Как любая формальная классификация, две категории наверху конечно же упрощены. Хороший менеджер будет всегда участвовать в работе группы индивидуально, потому что гораздо полезнее и нагляднее _показать_ что именно ты хочешь, а после этого объяснить как именно ты это сделал. Просто хороший менеджер определит границу между delegate, teach и do it yourself. И соотв построит баланс между временем которое нужно потратить на обучение тима с прицелом на то чтобы они могли делать больше сами в будущем vs. сделать-хорошо-самому-сейчас-и-заткнуть-дыру.
P.S. Советы кстати очень хорошие. Многие из них я в том или ином виде пытался тебе дать, в частности 5, 6, 8 и 10, плюс 3 в части Walking (в противоположность «sitting writing e-mails»).