#люди В предыдущем посте я упомянул career-driven developmen | Человек и машина

#люди

В предыдущем посте я упомянул career-driven development. Само название, безусловно, шутка, производная от *-driven development, например Test-Driven Development.

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

Всем знаком термин “терминальная позиция”? В нашем ИТ-мирке это чаще всего senior engineer. Терминальная позиция - это та должность, до которой каждый, со временем, обязательно дойдет, если будет… просто работать. В среднем, такой путь занимает от 7 от 10 лет, 22-летних вундеркиндов в расчет не берем.

Почему же она терминальная? Потому что дальше идти наверх становится гораздо сложнее. В маленьких компаниях это вызвано отсутствием должностей (дальше только тимлид), в крупных - очень серьезным входным порогом.

Раскрою ситуацию с крупными конторами. В них процесс повышения в должности бюрократизирован и процедурен. Есть некая “матрица компетенций”, отражающая ожидания от специалиста и его вклада. Некто идет на повышение, специальные люди смотрят на его вклад и принимают решение, сопоставляя вклад номинанта с вышеназванной матрицей.

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

Вот тут и начинается загвоздка. Чем выше по должности вы пытаетесь пройти, тем больше становится масштаб! Если не перейти в менеджмент, дальнейшая линия развития после Senior это Staff+ (инженер-архитектор здорового человека, не путать с чуваками, которые кроме Visio и Outlook ничем не пользуются) - и если условный L5 (senior) делает что-то крупное, но в пределах своей команды, то L6 (staff) работает в проекции нескольких команд, влияя на несколько продуктов или на целые бизнес-юниты.

Становится понятно, что, чтобы стать Staff’ом, нужно писать не очередной микросервис, а что-то уровня Nginx/ClickHouse. Об этом в следующем посте.