Стать Staff

В предыдущих сериях вы могли наблюдать мой переход от роли тимлида в разработку. Но вернувшись в разработку, вопрос "Куда расти дальше?" никуда не делся. И ответить на него надо было для себя.

Удивительно, что за 3 года мой взгляд на разработку особо не изменился, я всегда подходил к написанию кода от проблемы: "какую задачу мы решаем" "поможет ли это достичь бизнесу то, что он хочет". Мог с пеной у рта ругаться с руководителями продукта о том, что "я не буду добавлять эту кнопку, она ничего не делает важного".

За годы тимлидства и общения с C-level этот взгляд только укоренился и мне всегда интересно решать именно проблемы, не задачи.

Думая про мой текущий карьерный путь, погружаюсь в то, что нравится делать, что хочу делать и где максимально эффективен.

В роли Senior Frontend Developer мне тесно, в тимлидство возвращаться не хочу. Должен же быть и по мою душу карьерный путь? И он есть – Staff Engineer – это такие лидеры без подчиненных, которые решают проблемы бизнеса и помогают ему добиваться целей.

Staff-инженеры – это своеобразные "инженеры влияния", которые отвечают за широкий спектр вещей: техническое лидерство, кросс-командные взаимодействия, усиливают работу других.

Путь staff-инженера мне нравится, он похож на то, что я делал и хочу делать и это то, где я вижу, как я могу расти. У меня очень сильная "чуйка", что именно нужно делать. Я умею находить больные места, видеть тренды того, куда мы идём, но мне не хватает "умения дожимать", чтобы из локального переходить в организационное.

Несколько примеров для иллюстрации:
• ADR, я внедрил на уровне своей команды практику ADR для фронтенд-решений, это стало стандартом в нашей небольшой грядке. И я остановился и не стал это масштабировать на другие части сервиса, а через полтора-два года у нас появились общие арх-ревью, безумно похожие на то, что делали мы.
• Cycle-time – я был очень обеспокоен тем, как у нас идет доставка фич продукту и внедрял "честный канбан" в своей команде, чтобы иметь представление, как мы работаем, какие у нас узкие места и быть более прогнозируемым, мы отказались от спринтов в пользу борды с приоритетами и классами обслуживания, я следил за метриками cycle-time и находил узкие места. А потом остановился, а через год на уровне сервиса мы стали мерить cycle time и пристально за ним следить.

Среди Staff инженеров есть несколько архетипов, и я сразу узнал себя в одном из них:
• Team lead — растит команду и добивается с ней результата.
• Architect— строит сложные стабильные системы
• Solver— умеет решить любую проблему. Есть продвинутый вариант - Finder → ищет проблемы до их появления. (а вот и я)
• Right hand — «правая рука» директоров: помогает превращать стратегию в технические инициативы

Ровно поэтому мой фокус на том, чтобы развивать своё влияние. И в перспективе, не только быть "решалой", но и научиться доводить свои инициативы до уровня всей организации.

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

Хочется растить своё влияние, делать большие вещи, это то, что меня драйвит.
Я на правильном пути.

💚️️️️