Как staff-инженер находит проблемы, которые стоит решать
How I find problems to solve as a staff engineer
Инженер, готовящийся к роли staff, спросил автора, как тот находит задачи, над которыми стоит работать. Вместо того чтобы планировать время для стратегического мышления, автор впитывает проблемы из повседневного шума, накапливает их и ищет общие закономерности. Он объясняет, как отличить реальные потребности от конкретных запросов, проверять гипотезы и убеждать команду. На примере инструмента Perfetto он показывает, как несколько разрозненных запросов привели к созданию макросов и extension servers.
Поглощая проблемы, я оставляю их в фоне, и со временем связи между, казалось бы, несвязанными вещами становятся очевидными.
- wpasc
Автор отмечает:
> Одна оговорка: мой опыт в основном связан с работой над инфраструктурой и инструментами для разработчиков в крупных компаниях, в командах, где инженеры обладают большой свободой снизу вверх влиять на свои дорожные карты. В более иерархичной среде сверху вниз возможностей для такой работы может быть просто меньше.
Интересно, является ли общей тенденцией в технологиях то, что инженеры испытывают все меньше автономии снизу вверх и все больше контролируемых сред сверху вниз. Мне было бы любопытно узнать, сколько технологических компаний (или каков средний опыт инженера) перешли от подхода, где технологии ведут за собой и инженеры обладают автономией, к подходу, где доминирует управление продуктом. Мое подозрение, не подкрепленное доказательствами, заключается в том, что инженерная автономия в целом снизилась с годами, поскольку культура технологий (на мой взгляд) сместилась с фокуса на технологии к большему фокусу на бизнес, менеджмент и продукт, где инженеры — просто винтики, которым поручено выполнять цели бизнеса, менеджмента и продукта.
Все это гипотезы, только анекдотические данные.
- stevepotter
Я советую молодым людям искать небольшие компании, в идеале те, которые проходят стадию product/market fit. Например, они недавно придумали что-то для продажи и начали это продавать. Ограниченные ресурсы, хороший рост, не слишком взрывной. Таких компаний много. В такой среде вы быстро научитесь делать больше с меньшими затратами, выявлять реальные проблемы, быстро доставлять результат, напрямую работать с клиентами и создавать хорошие продукты. После этого, если хотите, идите работать в большую компанию — и вы будете поражены тем, насколько хорошо у вас получается.
- 9dev
Забавно, что у людей есть такая проблема. Я провел большую часть своей карьеры в стартапах, и мой опыт неизменно показывает, что количество проблем, которые нужно решить, значительно превышает то, что я могу реально сделать за время бодрствования.
Так что я не ищу проблемы для решения, я пытаюсь оценить, какие проблемы наиболее срочные или какое решение решает сразу несколько из них. Научиться правильно расставлять приоритеты, чтобы все команды и клиенты были довольны и продуктивны, — вот чем я очень горжусь в своей карьере.
- CSMastermind
Все это очень хорошие советы, но я бы предостерег любого, кто задает этот вопрос в начале эссе, от мысли, что им, вероятно, не стоит быть Staff Eng. Если только вы не находитесь в компании, где этот титул — просто ступенька в карьерной лестнице без дифференцированных обязанностей (таких много).
Каждый человек, с которым я работал и который успешно работал на уровне Staff+ Engineer, продвижение для него обычно было скорее формальностью, поскольку он уже явно выполнял эту работу. Каждый человек, которого я видел «поднявшимся до уровня своей некомпетентности», стремился получить звание/повышение зарплаты и пытался «играть в игру», чтобы этого добиться.
Если ваша мотивация решать проблемы людей — это получение повышения, а не то, что вам нравится решать проблемы, то, вероятно, это не та работа для вас.
- rr808
Хотелось бы, чтобы наши самые старшие штатные инженеры/архитекторы действительно работали над чем-то полезным. Они любят возиться с новыми технологиями, которые не имеют никакого отношения к нашей текущей платформе или к тому, куда мы движемся. Иногда они пытаются исправить то, что начал предыдущий архитектор, прежде чем они тоже перейдут на другую работу.
- ronnier
Я думаю, что почти вся технологическая отрасль раздута, и массовые увольнения вряд ли сильно повлияют на большинство компаний (хотя это навредило бы жизни людей, поэтому кажется жестоким так поступать). Меньше людей в командах означает меньше переключений контекста, и разработчики владеют большим. Им не нужно искать работу, она будет у них перед глазами. Во многих крупных технологических компаниях, где я работал, я видел слишком много людей, у которых не было достаточно работы. Они в итоге создают встречи и другие расточительные вещи (написание документов), чтобы занять свое время. Менеджеры и директора, похоже, хотят большие раздутые команды: чем больше у них подчиненных, тем больше они могут требовать и продвигаться по службе.
- intoXbox
Сложная часть в сумеречной зоне между senior и staff для меня в том, что наличие глубоких технических знаний означает, что я могу быстро и эффективно решать краткосрочные проблемы, просто как запросы.
Автор упоминает, что нужно тратить время на понимание трудностей других команд, но это отнимает массу времени, и мне не нравится быть человеком, который говорит и говорит, но не пишет код и не выпускает функции. Я бы хотел услышать, как другие пережили это.
- napo
Я некоторое время работал на уровне Staff, и думаю, что ключ в том, чтобы подчиняться директору, который управляет менеджерами. Каждый раз, когда я так делал, у меня все было хорошо: проекты было легко определять, а людей легко убеждать. У меня был тот же уровень с несколькими менеджерами, которые управляли другими индивидуальными сотрудниками, и это никогда не работало. Другие индивидуальные сотрудники пытаются конкурировать за задачи, люди не приходят к вам со своими потребностями, вы узнаете о разных проектах часто слишком поздно, другие команды территориальны и не очень хотят вашего вмешательства.