Приветствую! Меня зовут Василиса Версус и я в прошлом занимала позицию СТО в небольших стартапах (20-50 чел), отвечала за внутренние сервисы в Яндекс.Вертикали и работала как Head of Frontend Platform в Сбермаркет.

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

Сразу хочу сделать ВАЖНОЕ уточнение, все сильно зависит от компании и в целом всегда условно, а «лычки» лишь теги как точки для гугления, фильтрации вакансий и некий старт для построения ожиданий. И конечно я делюсь сугубо своим опытом, уверена, что не права и в целом жду ваших комментариев!

Недавно я писала про свой путь от TL к EM у себя в паблике ТГ, там я частенько делюсь рефлексией, втч карьерной. Итак, начинаем!

Team Lead

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

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

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

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

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

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

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

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

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

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

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

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

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

Engineering Manager

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

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

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

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

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

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

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

Про последнее хочется говорить отдельно и много: обучение тим-лидов, проведение 1:1, налаживание онбординга, а также построение грейдовых систем часто были моими обязанностями. Буду об этом больше писать у себя в ТГ. А пока предлагаю двигаться дальше.

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

Окей, рада что мы уже тут. Давай подведем промежуточные итоги:

• Team Lead и Engineering Manager очень похожи роли

• TL может (и часто будет) совмещать работу PM, для EM это необычно и неправильно

• TL будет чаще сосредоточен на тактическом управлении командой, EM занимается в основном стратегическим планированием

• EM несет больше ответственности за качество и стандарты выполнения работ

• TL больше отвечает за сроки и локальные приоритеты конкретных задач и проектов

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

Предлагаю проделать гипотетический путь от инженера к TL и потом к EM, на примере конкретных активных действий. В квотах буду указывать вопросами на частые ошибки в процессе такого перехода. ВАЖНО это не значит что эти шаги каждому нужно проделывать, я лишь «дебажу» путь и пытаюсь подсветить в чем суть ролей и отличие на примере такого маршрута.

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

Уже здесь многие споткнутся. Главное не отчаиваться. А твое предложение может иметь компромиссы или ты ставишь ультиматумы? Это только ТЫ считаешь что что-то нужно поменять или это собранное мнение разных людей? Твое предложение в каком-то виде задокументировано или существует только на словах? Есть ли какие-то метрики или возможность как-то провалидировать результат? Ты следишь за своей тональностью и невербальной коммуникацией?

Пункт 2. Возьми на себя часть забот твоего руководителя. Как_подсидеть_руководителя.pdf ситуация. Но если серьезно, то я не могу представить что в хорошем коллективе осудят запрос на предложение помощи в описании задач как пример, а также в менторинге коллег или вообще подавят инициативу без ведения переговоров. Даже в целом на вашем 1:1 вполне резонно спросить тим-лида, а с чем у него самые большие сложности и какая помощь могла бы сделать его жизнь лучше. Пусть это будет опорной точкой и так раз за разом можно попробовать в безопасной зоне исполнять все функции своего руководителя.

А что вообще делает твой руководитель, какие у него в твоей компании конкретные обязанности? С кем он взаимодействует и как выглядит это взаимодействие? Предлагая помощь ты обозначаешь что хочешь помочь, а не предъявляешь претензии?

Пункт 3. Фиксируй & Наблюдай. Не просто делай что-то полезное вне своих привычных обязанностей, но документируй как ты это делаешь для остальных. Старайся искать наблюдаемые метрики и строить из них какие-то показательные мониторы для коллег. Рефакторите? Построй CI которая будет отправлять количество затронутых строчек/файлов и оставшихся куда-то, откуда можно построить график для команды. Помогаешь обновить онбординг? Добавь какую-то форму обратной связи (напр. анонимной) чтобы собирать фидбек для дальнейшего улучшения. Хочешь улучшить скорость загрузки приложения? Добавь в доку как ты оцениваешь эту самую скорость загрузки.

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

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

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

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

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

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

Как твоя активность помогает бизнесу? Какие выделенные и оптимизируемые метрики влияют на выручку? Насколько эффективна твоя команда? У тебя есть менторы и менти? А коллеги видят ценность твоих действий, ты продаешь им эти изменения или просто навязываешь?

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

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

Уже где-то с готовности отвечать на вопросы из 6‑го пункта ты вполне без проблем можешь устроиться как СТО в небольшую компанию и двигаться дальше как равный бизнес партнер. Но это другая история. А пункты изначально, как я считаю, подсвечивают частые дыры и ошибки начинающих TL. Вполне можно быть руководителем забив на все советы и просто «попав» в место где нужен срочно руководитель, но без системного закрывания дыр в своих компетенциях стать EM уже точно не получится.

TL и EM это немного про разное, но про что-то очень похожее со стороны. Не обязательно из тим-лида двигаться в сторону ЕМ, но я считаю что очень важно освоить инструменты и подходить к своей работе системно на любой роли. Как и не обязательно ЕМ будет руководить руководителями или направлениями, можно вполне себе распределить «тактические» обязанности между командой и быть руководителем-стратегом двигаясь эффективнее рядового TL.

Я желаю тебе удачи и спасибо, что дочитал до этого момента. Я надеюсь что статья была интересной и хоть немного полезной.

UPDv2: переделала статью добавив больше деталей, подводя адекватно выводы и проследив за структурой.