javaswag
tg4.7 тыс. подписчиков
Открыть пост ↗
https://www.youtube.com/watch?v=s3_NBOme8kE
Из выпуска: что senior-инженеру стоит знать о staff позиции
1. Staff — это не «очень сильный senior», а работа вне команды
Senior остаётся внутри команды: у него свой engineering manager, свои сервисы и дежурства. Staff подчиняется senior engineering manager, то есть менеджеру менеджеров. Обычные EM для него коллеги на одном уровне. У staff нет «своего» scope, которым он занят с утра до вечера. Его работа — то, что выходит за границы команд:. При этом по навыкам сильный senior и staff почти не отличаются. Отличаются масштаб и роль, а не глубина знаний. Поэтому staff может и не знать, какие колонки лежат в таблицах. Ему достаточно понимать семантику доставки сообщений, отказы и риски.
2. Промо дают и за сложность в согласовании, а не обязательно за техническую сложность
Тимур так описывает проект, за который получил повышение: в нём было больше soft skills, чем техники. Проблему увидел principal. Тимур предложил другую архитектуру: забирать данные заранее, в момент создания заказа, а не в момент выплаты. Затем он защитил её перед principal, архитекторами и senior director, добился, чтобы людей перераспределили на другой проект, и согласовал решение с командами под другими VP. Ещё он неделю готовился к самой защите и обошёл доменных экспертов. Важное замечание: AI или агенты, просканировавшие код, не знают нюансов данных, истории изменений и инвариантов. Это знают только люди, которые сами дежурят и разбирают тикеты поддержки.
3. Нельзя говорить «это глупая идея», нужно говорить на языке рисков
Самый неочевидный навык. Продуктовые аргументы почти не работают. Работают SLA, SLO и последствия: что будет, если сделать, и что будет, если не сделать. Рассказ нужно выстроить так, чтобы он сам приводил к вашему предложению. Тимур признаётся, что язык метрик для него «практически китайский». Но без него архитектуру из другого департамента не поменять, даже если всем очевидно, что решение плохое.
4. Влиять без подчинённых и делегировать по уровням автономии
После согласования архитектуры у Тимура не было ни одного подчинённого. Он разбил проект на части, написал документацию, провёл разборы для команд и месяц вводил в курс дела четырёх senior-инженеров. Только после этого они написали свои технические документы и раздали задачи в своих командах. Делегирование работает по 4 уровням:
- провести человека за руку;
- регулярно сверяться;
- человек приходит только с эскалациями;
- не думать о задаче вообще.
Уровень определяется не тем, что человек senior, а тем, насколько вы ему доверяете. Senior, который вчера пришёл в компанию, — это уровень 2–3. Ещё один момент: если у вас приходится спрашивать статус, это сигнал о слабом лидерстве. Staff сам держит всех заинтересованных в курсе. Кроме того, каждая встреча один на один шла с журналом договорённостей в Google Doc.
5. «Код вообще не так важен» — главная перемена в мышлении
Senior, который сам находит проекты и сам их пишет, попадает в ловушку. За три года у него набирается пять сложных систем, которые поддерживает только он. Команда при этом ничего не узнала, ревью было слабым, а времени на рост больше нет. Staff отдаёт реализацию другим. Код получает владельцев, люди растут, а иногда кто-то получает повышение, потому что вы не сделали проект сами. Отсюда же «pain-driven development»: на system design не нужно сразу хвататься за новые технологии. Если команда работает на Java и Kafka, на них и продолжайте. Важны продукт, надёжность и то, чтобы следующий человек смог в этом разобраться.
Из выпуска: что senior-инженеру стоит знать о staff позиции
1. Staff — это не «очень сильный senior», а работа вне команды
Senior остаётся внутри команды: у него свой engineering manager, свои сервисы и дежурства. Staff подчиняется senior engineering manager, то есть менеджеру менеджеров. Обычные EM для него коллеги на одном уровне. У staff нет «своего» scope, которым он занят с утра до вечера. Его работа — то, что выходит за границы команд:. При этом по навыкам сильный senior и staff почти не отличаются. Отличаются масштаб и роль, а не глубина знаний. Поэтому staff может и не знать, какие колонки лежат в таблицах. Ему достаточно понимать семантику доставки сообщений, отказы и риски.
2. Промо дают и за сложность в согласовании, а не обязательно за техническую сложность
Тимур так описывает проект, за который получил повышение: в нём было больше soft skills, чем техники. Проблему увидел principal. Тимур предложил другую архитектуру: забирать данные заранее, в момент создания заказа, а не в момент выплаты. Затем он защитил её перед principal, архитекторами и senior director, добился, чтобы людей перераспределили на другой проект, и согласовал решение с командами под другими VP. Ещё он неделю готовился к самой защите и обошёл доменных экспертов. Важное замечание: AI или агенты, просканировавшие код, не знают нюансов данных, истории изменений и инвариантов. Это знают только люди, которые сами дежурят и разбирают тикеты поддержки.
3. Нельзя говорить «это глупая идея», нужно говорить на языке рисков
Самый неочевидный навык. Продуктовые аргументы почти не работают. Работают SLA, SLO и последствия: что будет, если сделать, и что будет, если не сделать. Рассказ нужно выстроить так, чтобы он сам приводил к вашему предложению. Тимур признаётся, что язык метрик для него «практически китайский». Но без него архитектуру из другого департамента не поменять, даже если всем очевидно, что решение плохое.
4. Влиять без подчинённых и делегировать по уровням автономии
После согласования архитектуры у Тимура не было ни одного подчинённого. Он разбил проект на части, написал документацию, провёл разборы для команд и месяц вводил в курс дела четырёх senior-инженеров. Только после этого они написали свои технические документы и раздали задачи в своих командах. Делегирование работает по 4 уровням:
- провести человека за руку;
- регулярно сверяться;
- человек приходит только с эскалациями;
- не думать о задаче вообще.
Уровень определяется не тем, что человек senior, а тем, насколько вы ему доверяете. Senior, который вчера пришёл в компанию, — это уровень 2–3. Ещё один момент: если у вас приходится спрашивать статус, это сигнал о слабом лидерстве. Staff сам держит всех заинтересованных в курсе. Кроме того, каждая встреча один на один шла с журналом договорённостей в Google Doc.
5. «Код вообще не так важен» — главная перемена в мышлении
Senior, который сам находит проекты и сам их пишет, попадает в ловушку. За три года у него набирается пять сложных систем, которые поддерживает только он. Команда при этом ничего не узнала, ревью было слабым, а времени на рост больше нет. Staff отдаёт реализацию другим. Код получает владельцев, люди растут, а иногда кто-то получает повышение, потому что вы не сделали проект сами. Отсюда же «pain-driven development»: на system design не нужно сразу хвататься за новые технологии. Если команда работает на Java и Kafka, на них и продолжайте. Важны продукт, надёжность и то, чтобы следующий человек смог в этом разобраться.
Новый список