Майкрософт, часть 2. Карьерная лестница

Все, о чем я здесь пишу, является моим личным мнением, которое не является официальным мнением моего работодателя. Так, на всякий случай!

С момента начала работы в Майкрософте уже прошло 8 месяцев, а значит уже можно сравнить местную внутреннюю кухню с кухней отечественной.

Киевские софтверные «гиганты» и общая культура IT компаний очень сильно отличаются от американских. Прежде всего, это связано с культурными отличиями, средним возрастом сотрудников и размерами компаний. Средний возраст влияет на то, как ведут себя люди в офисе, как они одеваются, и о чем говорят на кухне или в курилке. Средний возраст сотрудников киевской IT компании существенно ниже, чем в американской или европейской. Этот показатель у нас тоже начинает расти, но разница все еще остается очень существенной. Прибавьте сюда наш менталитет и общительность, и получите довольно большую разницу в том, как проходит неформальное общение. В киевском офисе ржачь стоял с завидным постоянством, ничего подобного в Штатах я не видел. Хотя вру, в нью-йорской конторе такое было, прямо перед тем, как ту команду разогнали;)

Средний возраст и размер компаний очень сильно влияют на карьерный рост. В украинской компании, если тебе 25 и ты не синьер, то ты явно что-то делаешь не так. Это же приводит к определенным проблемам, когда тебе тридцать и у тебя есть амбиции расти в техническом плане. У нас (да, я все еще отношу себя к «нам») относительно легко продолжить расти в тим-лидах или ПМ-ах, но чисто техническая лестница оказывается довольно короткой. Есть позиция архитектора, но архитектор в 30 – это все же вынужденная мера отечественного аутсорса для выделения касты «продвинутых синьеров», их нельзя сравнивать с архитекторами МС-а или Гугла. Поверьте.

Уровни

Размер американских IT-компаний вынуждает их формализовать карьерную лестницу более строгим образом, что выражается в существенно большем числе «лычек» и уровней. При этом тебе дают возможность развиваться в качестве независимого исполнителя (т.н. IC – Individual Contributor), или в качестве менеджера. При этом определяющим является твой уровень (level), а не категория (исполнитель/менеджер). Уровень определяет твою приставку (Senior, Principal, Partner etc), вилку ЗП, бонусы и т.п.

Существует возможность переходить между этими категориями без потери/прибавки в оплате. Например, Brian Harry и Mark Russinovich перешли с позиций Technical Fellow (высшая техническая позиция в Майкрософт) на позиции CVP (Corporate Vice President) и CTO (Chief Technical Officer) Azure соответственно. Наверняка есть серьезные переходы и в обратную сторону, но на ум ничего не приходит.

Уровней over 9000. Все начинается с уровней 59-60, что соответствует тайтлу SDE (Software Developer Engineer), и идет вверх до 80 левела (!), что соответствует позиции Technical Fellow.

Каждому левелу соответствуют определенные ожидания. SDE обычно получают сразу после колледжа и подразумевается, что он/она будет требовать помощи со стороны коллег (т.е. будет не только помогать, но и немного вредить). SDE 2 означает автономность. Senior SDE – влияние на результаты работы команды. Principal SDE – влияние на уровне нескольких команд. Technical Fellow означает влияние на индустрию в целом.

Определение слова «влиять» обычно отдается на откуп менеджеру, что может сделать процесс карьерного роста достаточно сложным. В бытность наличия тестеров (об этом ниже), «влияние» могло проявляться в изобретении очередного тестового фреймворка или чего-то настолько же ценного.

Это может быть плохой новостью для тех, кто ожидает, что для получения принципала в МС-е достаточно плотно закрыть дверь в свой собственный кабинет (которых кстати, уже нет) и пилить код. Для карьерного роста здесь потребуются все те же soft skills, которые многие из нас так любят игнорировать.

Особенно может быть непросто в ситуации, когда команда состоит из синьеров и принципалов и есть пара SDE 2. Как в этом случае им влиять на группу более «старших» коллег, чтобы получить новую «лычку» - остается загадкой.

Формальная лычка «архитектора» здесь отсутствует, хотя позиция принципала примерно соответствует кругу обязанностей архитектора. За тем лишь исключением, что принципалы и даже более высокие технические должности подразумевают задачи кодирования. Сферических архитекторов в вакууме здесь не любят.

Троевластие

Еще год назад в МС-е было троевластие. Были разработчики (SDE – Software Developer Engineers), тестеры (SDET – Software Developer Engineer in Test) и ПМ-ы (PM – Program Managers). У каждой из этих «каст» были свои лиды или мендежеры (Development Lead/Manager, Test Lead/Manager, PM Lead/Manager). При этом команда состояла из нескольких девов, нескольких тестеров и ПМ-а, при этом общего менеджера у них не было!

Месяцев 8 назад кто-то из высшего руководства узнал, что лет уже пятнадцать модно стала всякая гибкая хрень и решил, что тестеры больше не нада! Их переименовали в разработчики, а их обязанности раскидали на команду целиком.

ПМ-ы, как это не странно звучит для нашего уха, не являлись и не являются главными над разработчиками. Это такие же IC (individual contributor) со специфичным набором обязанностей. Это такая себе смесь бизнес-аналитика, технического писатели и product owner-а, который может также отвечать за согласование требований/графиков между смежными группами разработчиками.

Руководителем же является лид/менеджер, который отвечает за распределение плюшек и отвечает за результат работы группы.

Аджайл штуки применяются разными командами по-разному, начиная от достаточно канонического скрама, заканчивая менее демократическими подходами к управлению.

Интересно, что кодят тут все, и даже ПМ-ы обладают достаточно высокими техническими скиллами. Да и менеджеры все являются технарями и активно участвуют в архитектурных дискуссиях, а иногда и берутся за более грязную работу.

Общие впечатления

Наличие тысяч амбициозных технарей делает процесс карьерного роста более сложным, чем мы привыкли. Делать какие-то выводы слишком рано, а обобщать вообще не следует, поскольку каждая команда в МС-е обладает своими особенностями.

Можно точно сказать, что в Штатах карьера программиста складывается иначе. Все несколько сложнее. Народ, в целом, более лоялен, сидит на одном месте дольше нашего разработчика, который валит в соседнюю контору при любом косом взгляде со стороны менеджера или заказчика. В основном, люди здесь более автономные, сидят себе и делают свою работу, хотя идут на контакт весьма охотно, если их о чем-то спросить/попросить.

Самое главное отличие в том, что если у нас человек с десятью годами опыта и лычкой тимлида/архитектора считает себя чуть ли не вершиной пищевой цепочки, то здесь он оказывается в средней ее части. Длина карьерной лестницы дает о себе знать.

Общение с коллегами показало одну интересную особенность: стремление к новым должностям здесь есть, но вот хождение по головам практически отсутствует. Есть квоты продвижения на верх, но подковерные игры здесь, вроде бы, не приняты.

Level Up-ы

UPDATE: по просьбе Алексея, немного подробнее о продвижении по карьерной лестнице.

В Майкрософте “переоценка” уровня происходит раз в полгода. Здесь это называется Connect-ами. Основной коннект происходит в августе, а промежуточный – в феврале.

Это то время, когда сотрудник встречается со своим менеджером и подводит итоги того, что было сделано, что было запланировано (да, вполне возможно, что именно в таком порядке), что будет сделано и что не будет сделано. Он дает оценку своим достижениям за последние полгода, получает обратную связь от менеджера и может попросить обратной связи со стороны коллег (обратная связь от коллег будет доступна лишь менеджеру).

В результате заполняется небольшая вагонеточка бумаг, на основе которой менеджер принимает решение о: повышении уровня и переводе на другую позицию. Во время годового коннекта также решается вопрос годовых бонусов, опционов и повышения ЗП.

Еще год назад, во время годового коннекта каждому менеджеру нужно было выбрать сколько-то лучших перформеров, сколько-то худших перфофремов и сколько-то средних. Согласно этой градации распределялись бонусы, а попадание в худшие перформеры несколько раз могло привести к совсем уж печальным последствиям. Сейчас такое требование убрали, но цифровая оценка твоей “успеваемости” все еще осталась.

Процесс оценки того, достоин человек перевода на следующий уровень или нет, принимает менеджер. В случае с переходом на более высокие уровни (Синьер –> Принципал и выше) в этом процессе будут принимать участие менеджеры более высокого уровня. Решение остается непосредственно за менеджером, который может сказать, чего тебе не хватает для полного счастья и куда нужно себя развивать, чтобы это счастье поскорее наступило. Опираться, при этом, он может на формально-неформальные документы с описанием того, что ожидается от сотрудника того или иного уровня.

В целом, человеческий фактор здесь присутствует по полной, но достаточно высокая средняя адекватность сотрудников и менеджеров позволяет этой системе работать.

Ссылки

• Майксрофт. Часть 1