«Тимлиды не становятся сильнее, они просто реже паникуют»: инсайты аналитика из Авито о переходах между грейдами

Привет! Меня зовут Маша Новикова, я тимлид команды кабинета профессиональных продавцов в Авито. В статье рефлексирую свой опыт и делюсь, как за 4 года выросла из стажёра в тимлида.

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

Общий принцип роста в IT

Стажёр → Джун

Джун → Мидл

Мидл → Сеньор

Сеньор → Тимлид

Вместо выводов

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

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

Теперь расскажу про мой опыт.

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

На ревью джун должен показать, что умеет пользоваться SQL/DWH, визуализировать в Redash/Plotly, знает статистику, математику и может применить знания для анализа простого A/B-теста.

Что происходит после перехода. Вы уже привыкли к миру IT и своей команде. Слова Confluence, схемы баз, A/B, Redash, фичи и их названия уже не кажутся странными. Тем не менее каждая новая задача выглядит как вызов. Что делают люди в соседних отделах — вообще непонятно.

Мои челленджи:

— Научиться работать в команде с продактом. Например, понять, что вопрос «ну как там статус задачи?» — это возможность посоветоваться и поделиться апдейтом, а не контроль дедлайна.

— Не отвечать на вопросы продакта: «всё ок, к среде будет», а дать развёрнутый ответ, что происходит в проекте.

— Научиться спать перед дедлайнами, а не мучиться размышлениями, то ли я вообще сделала.

Особое внимание на этом этапе советую уделить хардам и заложить хороший фундамент. Это можно сделать, например, с помощью курсов:

Постарайтесь заточить знания под конкретную инфраструктуру компании, где вы работаете: станьте профи в конкретном диалекте SQL, инструменте визуализации, платформе A/B-тестов или системе кликстрима. В Авито, к счастью, по всем этим пунктам есть свои онбординговые курсы.

Также не стоит забывать и про софты. Джунам важно погружаться в бизнес-контекст своего продукта — через дипдайвы от команды или вопросы. А ещё найти общий язык с продакт-менеджером.

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

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

Мидлы начинают делиться знаниями с коллегами и берут подопечных. Эти специалисты умеют расставлять приоритеты по задачам и коммуницируют со стейкхолдерами. Результаты исследований мидлов влияют на бизнес: корректируют дискавери и деливери процессы.

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

Мои челленджи. Перестать бояться пушбэков и научиться говорить: «эта метрика — плохая, давайте возьмём другую, вот эту», проактивно предлагать свои идеи по решению задач.

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

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

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

Погружайтесь в продуктовые процессы компании. Чтобы стать проактивным аналитиком, надо самому понимать, что посчитать и кому потом «продать» результаты расчётов. Из этого понимания должен появиться ворох взаимозависимых вопросов: какие шаги нужны, чтобы запустить новый продукт? С кем их согласовать? Какие аргументы и аналитика понадобится для каждого шага? Если таких вопросов нет, значит вы не до конца разобрались с процессами.

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

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

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

Сеньор отвечает за точность формулировок, интерпретирующих результаты исследований, и рассчитывает количественные оценки от внедрения своих рекомендаций. Причём не просто приносит цифры, а переводит их на язык продукта. Результаты презентует самостоятельно или делегирует задачу коллегам, вовлечённым в процесс.

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

Также сеньоры менторят коллег и помогают им, делятся знаниями на внутренних митапах и выступают на внешних мероприятиях.

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

Мой челлендж №1: оставить в покое задачи и подумать: «А в чём вообще смысл того, что я делаю?», «Что я могу сделать, чтобы помочь команде достичь годовой цели?».

Когда вы привыкли закрывать тикеты в джире или другом таск-трекере, страшно остановиться и спросить вслух: «А зачем всё это? Как это помогает нам достичь поставленной цели?». Но это и есть сеньорство.

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

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

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

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

Что происходит после перехода. SQL/Python или R уже не ваши главные инструменты. Их место заняли 1:1, фидбэк, наём и метрики команды — теперь вы отвечаете за систему, а не только за себя.

Мой челлендж: научиться делегировать, даже если «я сама сделаю быстрее». А ещё перестать тревожиться, что я теперь не знаю продукты на уровне логирования всех кнопок и сервисов — теперь в этом нет смысла и не хватает ресурса.

Отпускать задачи и стримы было тяжело, да и сейчас иногда тяжеловато, особенно в ситуации, когда много лет был перформером. Но, по сути, теперь у меня есть новый большой и важный стрим: рост и развитие команды. Теперь уже я поддерживаю своих ребят, когда они хотят выступить на конференции. Особенно классно замечать, когда помогаешь команде решать новые задачи и закрывать новые компетенции — это очень драйвит, а после приходит осознание, что всё было не зря.

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

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

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

Если кратко — то вот вам вся статья одной картинкой ↓

Чтобы в Авито перейти с одного грейда на другой, нужно расти и менять подход к работе.

👉 Чтобы стать джуном, нужно базово владеть аналитическими инструментами и решать простые задачи, которые даёт руководитель. А ещё стараться мыслить чуть шире, чем просто исполнитель конкретной задачи.

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

👉 Сеньоры берут на себя сложные задачи и смотрят на проекты сверху, а не изнутри. В этот момент важно учиться отвлекаться от низкоуровневых задач.

👉 Тимлиды решают ещё более сложные задачи и руководят командой. Здесь нужно сосредоточиться именно на людях: помогать им и передавать опыт.

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

Кстати, я стала тимлидом через промежуточную роль Acting Team Lead, об этом мы тоже писали статью, почитайте: Тест-драйв роли тимлида: как это устроено в Авито.