Team Lead VS Engineering Manager

Image

Приветствую! Меня зовут Василиса Версус и я в прошлом трижды СТО в небольших стартапах (20–50 чел), а также head of инфраструктуры или разработки в таких компаниях как Яндекс и Сбермаркет

Сегодня мне очень хочется поделиться несколькими мыслями на тему карьерного развития. И недостающими пазлами между позицией тимлида и желаемой многими позиции СтанцииТехническогоОбслуживания.

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

Недавно я писала про свой путь от TL к EM. Подписывайся на мой паблик в тг, там такого будет много, а мы начинаем.

Team Lead

Давай попробую своими словами сформулировать что же такое тим-лид: человек, чья обязанность поставленные перед ним задачи распределять между членами команды, следить за их выполнением и конечно отчитываться перед руководителями и пирами о процессе.

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

Зачем инженеру в лиды?

e3eb1ffe2a0624c93bb5af12fc33f5e6.jpg

ВАЖНО! Каждый отвечает на этот вопрос для себя! Я просто пофантазирую… Вот сидит так Вася и код пишет, все ему нравится и в целом ожидания сбываются у всех сторон. НО в какой-то момент, появляется у него мнение на изменение процесса или же желание помочь руководителю с организационными вопросами. Вот где-то в этой точке появляется джун-лид.

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

Собственно, говоря про себя, у меня это случилось скорее от обратного. Я слишком много задавала вопросов просто в попытке разобраться с плохими тикетами от БА и мне в какой-то момент дали парочку стажеров с задачей уровня срочности «вчера». Пришлось выкручиваться. А после такого стресса и череды успехов, как вообще можно вернуться на позицию тихого спокойного кодерства? Записывайтесь на мои курсы, как преодолеть кризис кодера-белки-летяги (шутка). Я пыталась и не один раз, но вечные пожары где-то и моя любовь решать проблемы сыграли свою роль.

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

Что не так с позицией лида?

9f81f62530a02f52ea46b3522bcc1062.jpg

Чтобы двигаться в сторону тим-лида не обязательно даже быть сеньором, в целом это может случится даже со стажером. Вопрос лишь в том насколько эффективно вы будете выполнять эти функции. И уверяю редко где ожидают что ты будешь отличником во всем, скорее хорошистом или иногда троишником в чем-то, лол.

И это даже еще не проблема, а так, просто затравка. По факту лид совмещает в себе компетенции разных разработчиков, немного выполняет функции qa, часто еще замещает проджект менеджера, а иногда даже дизайнера или продукт менеджера. Уж точно будешь отыгрывать роль бизнес аналитика как минимум к своему начальнику… А еще вспомним про основные обязанности связанные с пипл менеджментом, т.е. найм, обеспечение хороших условий, даже эмоциональная поддержка, хоть в какой-то степени критична, на такой позиции.

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

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

Engineering Manager

Ключевое отличие Engineering Manager (далее EM) от лида в том, что EM это конкретная функция, ближе всего такой человек будет к классическим разработчикам в мире менеджмента. С очень понятной зоной ответственности, а также хард скиллами.

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

Почему EM это круто?

6f0bb79f5c9b8a8ac6646f4ee544bd12.jpg

Начнем с того, что EM направлен на то, чтобы улучшать эффективность процесса разработки. Будем считать что это его основная функция. Чем лучше ты как EM тем лучше будут выбранные показатели. Я считаю что это прям килер-фича. Наконец-то можно заниматься своим конкретным развитием и применять свою солянку знаний сфокусированно.

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

Последнее вообще сложно укладывается в общую картину, но давайте буду прямолинейна, то как код-ревьят, те компоненты которые
переиспользуют, да даже в целом как команды между собой разделены, это же все про общий процесс взаимодействия и узкое горлышко частенько будет находится где-то здесь, а не в том, описана ли адженда на дейлик. Конечно, EM в идеале будет работать в паре с Архитектором и выполнять функцию его консультанта в том какие у нас есть ограничения по ресурсам и с другой стороны будет являться проводником его идей постепенно приводя изящные архитектурные планы в жизнь.

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

Что Было Дальше?

ec3cb2c2a4d92be1c84ffa47dd457997.jpg

Окей. Рада что мы наконец здесь. Ты уже лид? Или пока просто разработчик который мечтает стать СТО? Не так важно.

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

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

Пункт 2. Окей, а о чем договариваться? В целом предварительно я рекомендую попробовать задокументировать процесс своей разработки, например для нужд онбординга, можно прям это и предложить руководителю. Точно будет полезным для новичков в будущем, а также поможет увидеть дыры в процессе. В каком формате это все записывать? Какой конечный результат ставить? Правильные вопросы которые я рекомендую тебе обсудить с коллегами. Скажу так, чем больше ты сможешь описать за меньшее время — тем круче. Опять таки направляю гуглить и хватит копить недовольство, позволь ему быть выраженным. Но помним про Пункт 1.

Пункт 3. Когда получилось что-то описать, постарайся посчитать сколько времени и на каком этапе от того и как приходит идея и до того как она оказывается в продакшене. Найди ту точку где ты мог бы оказать наибольший эффект. Например частенько это какая-то история с CI и код-стайлом, а может быть частый возврат тикетов от QA могут тесты предотвратить? Опять таки, задокументируй мысли, хотя бы в каком-то виде и не стесняйся этим делиться. Я уверена страх быть высмеянным и осужденным только в твоей голове или же тебе срочно стоит искать новое место, если по факту твою инициативу готовы грубо рубить.

Пункт 5. Продай идею об улучшении как в Пункте 1. Нельзя сразу опускать руки и отчаиваться. Нужно изучать возможные стратегии и раз за разом искать в процессе переговоров те точки улучшения которые примет твой руководитель или его руководитель в крайнем случае. В секретном четвертом пункте, я бы предложила иногда пробовать включать подобные оптимизации в свои линейные задачи. Скопом вместе с каким-то ожидаемым рефакторингом можно предложить команде сделать какие-то доп тесты, как пример. И если у тебя получится из этого создать настоящий кейс. Где сможешь показать как выглядит ваш процесс со стороны, какие были цифры до изменения и как изменение сделало процесс работы лучше, то настоящий пункт 5 будет уже простой историей.

Пункт 6. Полагайся не только на свои ресурсы. Главное в работе ЕМ это обозначить проблему и сделать ее простой для решения другими людьми. Старайся искать стратегии для продажи решения другим лидам и разработчикам и даже другим ролям. Выходи за рамки простого кодинга и…

Пункт N. Твоя цель не просто вырасти в иерархии, твоя цель на этом пути найти свои собственные сильные стороны в том, чтобы помогать обьединять людей. CI, метрики и регламенты, процессы разработки, переговоры и прочее это просто твои инструменты, на следующих шагах ты сможешь делать значительно больше. Главное верить в себя и не отчаиваться.

Вместо послесловия

Конечно никто не любит людей которые тычут в проблемы, но поверь, те кто могут обьяснить что проблема на самом деле пустяк и всеми решаема — любимы всеми. Ты что не смотрел серию футурамы где мини-копии бендера смогли свергнуть монстра благодаря Фраю? Ради чего ты смотрел тогда мультики? Хватит. Уже с этой точки я желаю тебе удачи.

© Habrahabr.ru