А это правда что во многих компаниях принято нанимать новых team leader'ов чем ставить на этот пост своих, уже проверенных сотрудников, которые "доросли" до такой должности?
Здравствуйте, Paul Poloziouk, Вы писали:
PP>А это правда что во многих компаниях принято нанимать новых team leader'ов чем ставить на этот пост своих, уже проверенных сотрудников, которые "доросли" до такой должности?
Вспомнилось:
Есть профессии,
в которых отсутствие связей только на руку...
Когда компания на грани банкротства — и дошло до ввода антикризисного комитета, — увольнение старых лидов, и приглашать новых со стороны — это нормальная практика.
Здравствуйте, Сергей Глазунов, Вы писали:
PP>>А это правда что во многих компаниях принято нанимать новых team leader'ов чем ставить на этот пост своих, уже проверенных сотрудников, которые "доросли" до такой должности?
СГ>Вспомнилось: СГ>
СГ>Есть профессии,
СГ>в которых отсутствие связей только на руку...
СГ>Когда компания на грани банкротства — и дошло до ввода антикризисного комитета, — увольнение старых лидов, и приглашать новых со стороны — это нормальная практика.
На мой взгляд, у такого решения есть два исхода: наиболее вероятный — все быстро загнется (т.е. что бы не мучилось). Второй вариант, менее вероятный, все будет нормально — значит таких лидеров действительно нужно было давно уволить. В програмировании вероятность первого вариант, мне кажется, много выше чем второго.
На мой взгляд самое глупое что можно сделать это нанаять ПМ со стороны, когда есть свои люди готовые выполнить их обязаности. Это приведет к тому, что свои люди готовые стать ПМ уйдут в другое место, а новые еще будут входить в суть дела и еще не факт что со всем справятся. Здесь самое сложное определить когда люди доросли, а когда еще нет. Мне кажется что нужно делать человека (при наличии такой возможности) ПМ чуть-чуть раньше, чем он сам осознает это и начнет искать себе такую должность на стороне, т.е. планку нужно ставит всегда чуто-чуть выше чем обычно прыгает человек — чтобы бы стимул для роста.
Здравствуйте, DarkGray, Вы писали:
D>>На мой взгляд самое глупое что можно сделать это нанаять ПМ со стороны, когда есть свои люди готовые выполнить их обязаности.
DG>При повышении до ПМ одного из равных сотрудников приводит к разрыву коллектива.
Гипотетический пример: в компании есть три разработчика готовых стать ПМ'ами, но что бы никого не обидеть, нужно нанять четвертого со стороны? Мне кажется в такой ситуации обидятся все трое (может быть и четверо, так как нанятому ПМ тоже с такими обижеными спецами будет работать не здорово). Мне кажется, лучше выбрать одного из равных (тем более что абсолбютно равных не бывает, почти всегда есть критерий, по которму можно выбрать одного причем заслужено), и сделать его ПМ, чем в такой ситуации приглашать человека со стороны.
Здравствуйте, DarkGray, Вы писали:
D>>На мой взгляд самое глупое что можно сделать это нанаять ПМ со стороны, когда есть свои люди готовые выполнить их обязаности.
DG>При повышении до ПМ одного из равных сотрудников приводит к разрыву коллектива.
сотрудники никак не могут быть равными. в любой группе людей есть те кто в большей или меньшей степени подходит на роль лидера. кто умеет управлять людьми. кто не боится взять ответственность на себя и может сделать это грамотно. а для кого то достаточно того что ему просто ставят задачи которые он выполняет. выделение таких сотрудников будет воспринято вполне адекватно.
Здравствуйте, k., Вы писали:
k.>Здравствуйте, DarkGray, Вы писали:
D>>>На мой взгляд самое глупое что можно сделать это нанаять ПМ со стороны, когда есть свои люди готовые выполнить их обязаности.
DG>>При повышении до ПМ одного из равных сотрудников приводит к разрыву коллектива.
k.>сотрудники никак не могут быть равными. в любой группе людей есть те кто в большей или меньшей степени подходит на роль лидера. кто умеет управлять людьми. кто не боится взять ответственность на себя и может сделать это грамотно. а для кого то достаточно того что ему просто ставят задачи которые он выполняет. выделение таких сотрудников будет воспринято вполне адекватно.
Проблема не в тех кто может или кто лучше из "равных", а в тех, которые считают что "не хуже" или лучше остальных. А это собственно все "равные" и есть.
Здравствуйте, Nikto, Вы писали:
k.>>сотрудники никак не могут быть равными. в любой группе людей есть те кто в большей или меньшей степени подходит на роль лидера. кто умеет управлять людьми. кто не боится взять ответственность на себя и может сделать это грамотно. а для кого то достаточно того что ему просто ставят задачи которые он выполняет. выделение таких сотрудников будет воспринято вполне адекватно. N>Проблема не в тех кто может или кто лучше из "равных", а в тех, которые считают что "не хуже" или лучше остальных. А это собственно все "равные" и есть.
То есть лучше взять человека со стороны, хотя в текущей группе уже есть человек подходящий на роль лидера? а это не послужит ли толчком для роста недовольства в коллективе?
а если уж кто-то считает что он не хуже, а даже лучше остальных — пусть докажет это на деле если лидерство человека основанно только на том что его поставили над остальными "править" то о каком уважении как к профессионалу может ити речь?
Здравствуйте, k., Вы писали:
k.>То есть лучше взять человека со стороны, хотя в текущей группе уже есть человек подходящий на роль лидера? а это не послужит ли толчком для роста недовольства в коллективе?
Как правило таких людей переводят тимлидерами в другой проект. Это разумно, так как у нового руководителя взгляд будет не замылен.
DG>>При повышении до ПМ одного из равных сотрудников приводит к разрыву коллектива.
D>Гипотетический пример: в компании есть три разработчика готовых стать ПМ'ами, но что бы никого не обидеть, нужно нанять четвертого со стороны?
да, есть такой вариант
D> Мне кажется, лучше выбрать одного из равных (тем более что абсолбютно равных не бывает, почти всегда есть критерий, по которму можно выбрать одного причем заслужено), и сделать его ПМ, чем в такой ситуации приглашать человека со стороны.
в этом случае, есть следующие риски:
1. У выдвинутого человека не сложатся отношения с другой командой. Психологически тяжело трябовать или наказывать человека, с которым еще вчера пил пиво, и разбирал по косточкам начальника.
2. Если в команде было нескольких лидеров, то поднятие одного из них приведет к отношению на ножах с другими лидерами, какой критерий бы руководство не выбрало бы
имхо, если есть явный лидер, то его стоит выдвинуть, если же лидеров несколько, то тогда их лучше выдвигать в другие отделы.
D>На мой взгляд самое глупое что можно сделать это нанаять ПМ со стороны, когда есть >свои люди готовые выполнить их обязаности.
Это правильно, но подоплека тут немножко не та. Вопрос в доверии. Кто больше вызывает доверия — свой старожил или новичок? Обычно свой старожил, но не всегда.
Некоторые компании, перерастая рубеж человек в 25-30, просто потихоньку увольняют всех старожилов, и заменяют на "сотрудников по резюмешкам". И тому есть причины.
.
DG>2. Если в команде было нескольких лидеров, то поднятие одного из них приведет к >отношению на ножах с другими лидерами, какой критерий бы руководство не выбрало бы
А это хорошо. Люди в тонусе держатся, конкурируют между собой, отсюда мотивация работать лучше...
Здравствуйте, DarkGray, Вы писали:
D>>Гипотетический пример: в компании есть три разработчика готовых стать ПМ'ами, но что бы никого не обидеть, нужно нанять четвертого со стороны? DG>да, есть такой вариант
Конечно есть, вопрос в том пользоваться им или нет.
D>> Мне кажется, лучше выбрать одного из равных (тем более что абсолбютно равных не бывает, почти всегда есть критерий, по которму можно выбрать одного причем заслужено), и сделать его ПМ, чем в такой ситуации приглашать человека со стороны.
DG>в этом случае, есть следующие риски: DG>1. У выдвинутого человека не сложатся отношения с другой командой. Психологически тяжело трябовать или наказывать человека, с которым еще вчера пил пиво, и разбирал по косточкам начальника.
Во-первых, если мы говорим у профессионалах (иначе почему они претендовали стать ПМ'ами) то видимо необходимости их бить все время по рукам как детей не будет. Во-вторых, это нужно будет научиться делать в любом случае, и такое деление людей на своих и чужих к хорошему не приведет. Я вообще считаю, что нужно разделять свое поведение на работе от общения с друзьями за пивом — и все будет хорошо. Естественно полностью стереть грань нельзя, но надо хотя бы к этому стремиться. У меня были случаи когда я был не доволен человеком в профессиональном плане, но лично он мне был симпатичен. В таком случае я всегда старался отделить дружеские отношения от профессиональных — и я считаю, что этому нужно учиться.
DG>2. Если в команде было нескольких лидеров, то поднятие одного из них приведет к отношению на ножах с другими лидерами, какой критерий бы руководство не выбрало бы
Если они не умеют отделять свои личные отношения от профессиональных — то может быть это как раз то время, когда этому стоит научиться. Я считаю, что для духа комманды хорошо, когда происходит рост людей в комманде, а не наем новых для того чтобы руководить. Многое еще зависит от вышестоящего лидера, как именно произойдет это назначение и что при этому будет сказано.
DG>имхо, если есть явный лидер, то его стоит выдвинуть, если же лидеров несколько, то тогда их лучше выдвигать в другие отделы.
Не совсем согласен, во-первых для этого должно быть подходящее количество отделов, требующих руководства и с отсутствием собственных людей для выдвижения в ПМ. Во-вторых, лучше руководить тем что ты знаешь, а не переходить на новое место. Тогда опыт ПМ как разработчика может быть использован максимально полно.
Здравствуйте, Maxim S. Shatskih, Вы писали:
DG>>2. Если в команде было нескольких лидеров, то поднятие одного из них приведет к >>отношению на ножах с другими лидерами, какой критерий бы руководство не выбрало бы
MSS>А это хорошо. Люди в тонусе держатся, конкурируют между собой, отсюда мотивация работать лучше...
Это потребительское отношение к людям, которе ни к чему хорошему не приведет. Програмисты должны работать в спокойной обстановке, а не все время интриговать кто станет новым ПМ'ом.
Здравствуйте, DarkGray, Вы писали:
DG>>>При повышении до ПМ одного из равных сотрудников приводит к разрыву коллектива.
D>>Гипотетический пример: в компании есть три разработчика готовых стать ПМ'ами, но что бы никого не обидеть, нужно нанять четвертого со стороны?
DG>да, есть такой вариант
D>> Мне кажется, лучше выбрать одного из равных (тем более что абсолбютно равных не бывает, почти всегда есть критерий, по которму можно выбрать одного причем заслужено), и сделать его ПМ, чем в такой ситуации приглашать человека со стороны.
DG>в этом случае, есть следующие риски: DG>1. У выдвинутого человека не сложатся отношения с другой командой. Психологически тяжело трябовать или наказывать человека, с которым еще вчера пил пиво, и разбирал по косточкам начальника. DG>2. Если в команде было нескольких лидеров, то поднятие одного из них приведет к отношению на ножах с другими лидерами, какой критерий бы руководство не выбрало бы
То что Вы описалитипичный совковый бардак и отсутствие субординации в класической руссконародном стиле. Работа это одно, текилу пить совсем другое.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Ни одна из виденных мною софтовых компаний, где "строили" сотрудников, не ходит в неудачниках.
MSS>Да, не только они добились успеха. Но они его добились все.
У меня абсолютно противоположный опыт А из компании, в которой "строят" сотрудников, я бы просто ушел.
Здравствуйте, Maxim S. Shatskih, Вы писали:
D>>На мой взгляд самое глупое что можно сделать это нанаять ПМ со стороны, когда есть >>свои люди готовые выполнить их обязаности.
MSS>Это правильно, но подоплека тут немножко не та. Вопрос в доверии. Кто больше вызывает доверия — свой старожил или новичок? Обычно свой старожил, но не всегда.
MSS>Некоторые компании, перерастая рубеж человек в 25-30, просто потихоньку увольняют всех старожилов, и заменяют на "сотрудников по резюмешкам". И тому есть причины. MSS>.
В принципе согласен — дешевле нанять новых программистов , которые будут изо всех сил в течение испытательного срока и несколько месяцев после его прохождения работать, работать и ещё раз работать. А через некоторое время (обычно через 3-4 месяца после прохождения испытательного срока) производительность труда часто немножко падает. Это происходит потому что человек осознает что он вроде как бы прошёл достаточно серьёзный этап и поэтому ему можно перейти на нормальный режим работы. А вот в период прохождения испытательного срока человек трудится неимоверно потому что пытается доказать что он достоин тех денег и той работы, которые ему доверят после испытательного срока.
>Это происходит потому что человек осознает что он вроде как бы прошёл достаточно >серьёзный этап и поэтому ему можно перейти на нормальный режим работы.
Если есть шансы роста — то расслабления не происходит.
Кстати, повышение оклада не есть мотиватор. Именно по твоей причине.
Первое время человек благодарен, и работает изо всех сил. А потом привыкает к новому окладу, считает, что он стоит больше по сути своей, и начинает работать как раньше.
Айчеры просчитали, что повышение оклада мотивирует только первые 2-3 месяца.
Здравствуйте, Maxim S. Shatskih, Вы писали:
>>Это происходит потому что человек осознает что он вроде как бы прошёл достаточно >>серьёзный этап и поэтому ему можно перейти на нормальный режим работы.
MSS>Если есть шансы роста — то расслабления не происходит.
MSS>Кстати, повышение оклада не есть мотиватор. Именно по твоей причине.
MSS>Первое время человек благодарен, и работает изо всех сил. А потом привыкает к новому окладу, считает, что он стоит больше по сути своей, и начинает работать как раньше.
MSS>Айчеры просчитали, что повышение оклада мотивирует только первые 2-3 месяца.
То есть, получается, у программистов малого звена нет выбора и их всё равно погонят в шею и наберут новых вместо того чтобы повышать им зарплату, да? Печально....
А так хотелось хоть кусочек сыра.... хоть иногда....
Как же так получается, как же жить дальше-то, а? ???
Здравствуйте, Maxim S. Shatskih, Вы писали:
DG>>2. Если в команде было нескольких лидеров, то поднятие одного из них приведет к >>отношению на ножах с другими лидерами, какой критерий бы руководство не выбрало бы MSS>А это хорошо. Люди в тонусе держатся, конкурируют между собой, отсюда мотивация работать лучше...
эх батенька, если бы всё было так, как вы изволите(с) не помню кто...
реальная ситуация (у меня на работе): приняли нового челавека на пост IT директора (хотя своих кандидатов было как минимум 3). В принципе контора наша не софтверная, но IT играет не из последних ролей, т.к. без фIT развал конторы пройдёт за 2-7 дней. ну так вот, человек этот — "руководитель" со стажем, но, кроме как интриговать (в плохом смысле этого слова) и спекулировать информацией ничео не может... да и не хочет, хотя без понимания специфики IT депртамента нашей организации можно только дров наломать...
0.5 года спустя... имеется "дирекция" IT во главе с тем человеком, которого приняли на работу, на которую все положили $уй и собственно сам отдел, во главе которого стоит зам. нового начальника, но этот зам своего начальника при каждом случае на $ях далеко увозит. Исходя из аксиомы, что начальников просто так не уволmyz.n получается скверная картина. Какой тут может быть тонус?
Теперь встал вопрос о смете корпоративной платформы... наш новый IT начальник, особо не разбираясь в наших потребностях начал задвигать нам Oracle B-Suit, который ну не пришей к нам. В итоге его опять спустили на ..ях. Совсем высокое начальство пока в великой думе, что делать.... а у нас началос разброд и шатание, т.к. этого нового человека сейччас уже посылают в пешее эротическое путешествие открыто... с другой стороны "старая" комманда по сути узурпировала все информационные каналы и начало шантажировать руководство (ревность, как это вместо нас внешний чел появился, а мы так старались), типа если уволите, то вся работа накроется медным тазом в считанные часы.
какой при таком раскладе повышенный тонус может быть?
Re[8]: team leaders
От:
Аноним
Дата:
12.06.04 20:31
Оценка:
Здравствуйте, dnsokol, Вы писали:
D>эх батенька, если бы всё было так, как вы изволите(с) не помню кто...
[чик-чик]
Какая знакомая история...
Я уже встречал этот непроходимый идиотизм и любовь к Oracle B-Suit.
Фамилия вашего директора IT не на "Ми" начинается?
D>Теперь встал вопрос о смете корпоративной платформы... наш новый IT начальник, особо >не разбираясь в наших потребностях начал задвигать нам Oracle B-Suit, который ну не
Бороться надо эго же оружием. Интригами. Например, написать докладную высшему начальству, что Б-Сьют вам не нужен, а желание его внедрить — есть не более чем желание получить откат
Если высшее начальство — не идиоты, то такое пройдет. А если идиоты — то менять работу надо.
PP>То есть, получается, у программистов малого звена нет выбора и их всё равно >погонят в шею и наберут новых вместо того чтобы повышать им зарплату, да? Печально.... PP>А так хотелось хоть кусочек сыра.... хоть иногда.... PP>Как же так получается, как же жить дальше-то, а? ???
Здравствуйте, Alex Fedotov, Вы писали:
AF>Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>Айчеры просчитали, что повышение оклада мотивирует только первые 2-3 месяца.
Максим, и что HR предлагает на последующий срок втаком случае?
AF>Меня вообще не мотивирует (мне, правда, и не повышают).
... ибо процент идет?
кстати, а какие варианты могут быть лучше варианта от МС с их опционами?
фактически оклад есть + соцпакет + бонус : процент от общего успеха, все честно
все как Максим недавно в "азах HR" вещал
кто-то из МС уточнит о текущих схемах оплаты в МС, может быть сейчас там все по-новому?
... << Rsdn@Home 1.1.4 beta 1 >>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, DarkGray, Вы писали:
DG>1. У выдвинутого человека не сложатся отношения с другой командой. Психологически тяжело трябовать или наказывать человека, с которым еще вчера пил пиво, и разбирал по косточкам начальника. DG>2. Если в команде было нескольких лидеров, то поднятие одного из них приведет к отношению на ножах с другими лидерами, какой критерий бы руководство не выбрало бы
Собственно подтверждаю — со мною как раз подобное было. К счастью для меня дело закончилось сменой части подчиненных. Увы, но действительно есть люди которые не способны воспринимать человека с которым проработали на равных должностях как начальника.
Здравствуйте, Valerio, Вы писали:
AF>>Меня вообще не мотивирует (мне, правда, и не повышают). V>... ибо процент идет?
Нет никакого процента. Просто я работаю так, чтобы потом стыдно не было, от зарплаты это не зависит. Зарплата от этого — тоже: я точно знаю, что если начну работать по утрам (кроме дней и ночей), зарплату не повысят ни на цент.
V>кстати, а какие варианты могут быть лучше варианта от МС с их опционами?
Если опционы — это stock options, то это широко практикуется. Только, в свете последних SEC regulations, большинству крупных компаний скоро будет невыгодно этим заниматься.
Здравствуйте, dupamid, Вы писали:
D>Здравствуйте, DarkGray, Вы писали:
D>>>На мой взгляд самое глупое что можно сделать это нанаять ПМ со стороны, когда есть свои люди готовые выполнить их обязаности.
DG>>При повышении до ПМ одного из равных сотрудников приводит к разрыву коллектива.
D>Гипотетический пример: в компании есть три разработчика готовых стать ПМ'ами, но что бы никого не обидеть, нужно нанять четвертого со стороны? Мне кажется в такой ситуации обидятся все трое (может быть и четверо, так как нанятому ПМ тоже с такими обижеными спецами будет работать не здорово). Мне кажется, лучше выбрать одного из равных (тем более что абсолбютно равных не бывает, почти всегда есть критерий, по которму можно выбрать одного причем заслужено), и сделать его ПМ, чем в такой ситуации приглашать человека со стороны.
Просто так взять и назначить — экономически невыгодно — компания получает ПМ-а, которого несмотря но то, что он из "готовых стать ПМ'ами" все равно некоторое время придется обучать, помогать, более пристально контролировать и т.д. точно так-же как и нанятого со стороны. В то-же время она теряет теряет очень классного девелопера, которому тоже надо искать/готовить замену. В итоге нанять нового ПМ-а получается раза в два дешевле.
Гораздо более правильный вариант, когда рост из девелопера в ПМ-ы происходит постепенно и "естественно":
синьйор девелопер, который почти самомтоятельно разруливает в проэкте все технические вопросы и почти самостоятельно занимается распределением задач между членами комманды -> PL, который продолжает заниматься вещами типа написания кода или дизайна -> ... -> PL при ПМ-е, который руководит десятком проэктов одновременно и поэтому делегирует 90% своих обязанностей своим PL-ам -> PM
Что касается "обиженых спецов", то матричная структура здесь рулит — кто-то участвует в проэкте с самого начала или даже на этапе подготовки предложения/участия в тендере, а кто-то присоединяется, когда пора прорабатывать детали дизайна и посать код; кто-то работает в однотипных проэктах под одного и того-же заказчика, а кого-то "бросают" вытягивать навые или спасать заваливающиеся проэкты и т.д. В итоге у разных людей получается разный опыт и разная скорость роста обусловлена вполне обьективными причинами, так-сказать идет "естественный отбор".
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, dnsokol, Вы писали:
D>>эх батенька, если бы всё было так, как вы изволите(с) не помню кто... А>[чик-чик]
А>Какая знакомая история... А>Я уже встречал этот непроходимый идиотизм и любовь к Oracle B-Suit. А>Фамилия вашего директора IT не на "Ми" начинается?
Кстали любовь к конкретным решениям которые внедряют конкретные люди чаще всего объясняется конкретными откатами..
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
AF>Нет никакого процента. Просто я работаю так, чтобы потом стыдно не было, от зарплаты это не зависит. Зарплата от этого — тоже: я точно знаю, что если начну работать по утрам (кроме дней и ночей), зарплату не повысят ни на цент.
Алекс, в Вашем профессионализме сомнений быть не может. Что и подтверждается этим ответом
V>>кстати, а какие варианты могут быть лучше варианта от МС с их опционами?
AF>Если опционы — это stock options, то это широко практикуется. Только, в свете последних SEC regulations, большинству крупных компаний скоро будет невыгодно этим заниматься.
да, stock options. не просветите немного, куда ветер дуть начинает?
... << Rsdn@Home 1.1.4 beta 1 >>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, Valerio, Вы писали:
AF>>Если опционы — это stock options, то это широко практикуется. Только, в свете последних SEC regulations, большинству крупных компаний скоро будет невыгодно этим заниматься.
V>да, stock options. не просветите немного, куда ветер дуть начинает?
Компании теперь должны будут указывать stock options как расходы в income statement. Компаниям это невыгодно, так как это с одной стороны лишняя морока (особенно для крупных компаний), а c другой — уменьшает видимую величину прибыли, что делает их акции менее привлекательными.
Здравствуйте, Maxim S. Shatskih, Вы писали:
C>>Что касается "обиженых спецов", то матричная структура здесь рулит — кто-то участвует
MSS>В The Microsoft Secrets было сказано, что в этой компании некоторые девелоперы могут и поболе получать, чем средный PM.
MSS>Зарплата должна гибко назначаться. Со многими PMными задачами справится рядовая секретутка (с английским, конечно).
если лидерство человека основанно только на том что его поставили над остальными "править" то о каком уважении как к профессионалу может ити речь?
Мы уже победили, просто это еще не так заметно...
А из компании, в которой "строят" сотрудников, я бы просто ушел.
