Привет, Хабр!

Меня зовут Ваня Антипин, я Deputy CTO в компании AGIMA. Сегодня я постараюсь вам рассказать про роль техлида в компании. Напомню, что в октябре 2020 года мы говорили о роли тимлида в компании и команде. Если кратко от тимлида зависит многое, включая эффективность команды, достижение поставленных целей, оперативное решение рабочих тасков.

А что насчет техлида? Об этой специальности говорят не так часто, но техлиды важны и нужны не менее тимлидов. Более подробно я рассказываю об этом на курсе Руководитель команды разработки и делюсь реальными кейсами. Но не будем отвлекаться, приступим!

Техлид не специальность, а роль

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

Что касается формальной или номинальной роли, то в классическом Scrum, например, нет роли техлида, а вот в проектах и командах, которые живут по Scrum, техлид есть.

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

А что насчет обязанностей?

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

Пример разработка мобильного приложения. Если проект большой, то здесь обязанности техлида и тимлида редко пересекаются. Так, техлид отвечает за архитектуру мобильных приложений под две платформы, iOS и Android, за проектирования REST API в контексте разрабатываемой мобильной архитектуры. А вот за управление проектом, разработку серверной реализации API и результаты всего проекта отвечает тимлид.

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

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

Техлиды и тимлиды зоны ответственности

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

Мы сразу провели границу между тимлидами и техлидами. Техлид это упор на Hard-скиллс, а тимлид на Soft-скиллс. Граница в соотношении этих навыков, причем в зависимости от контекста, заданного проектом и командой.

Для того чтобы прояснить ситуацию, приведу пример. Это кросс-платформенные проекты с сервис-ориентированной архитектурой по разработке омниканальных цифровых витрин. В рамках такого проекта разрабатываются web&mobile-приложения, сервисы управления контентом, сервисы интеграции и реализации бизнес-логики (API). В таком проекте может быть целая команда лидов:

• Тимлид, управляющий процессами, коммуникациями и бюджетом.

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

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

1. Списком задач в бэклоге управляет руководитель проекта. Задачи по разработке уходят в работу на тимлида.

2. Тимлид получает задачу, проверяет точность и полноту требований в задаче, при необходимости уточняет детали или дополняет описание задачи описанием уточнением требований или описанием возможной реализации. Задача уходит в работу на техлида. При этом на проекте работает три техлида: фронт, бэк, мобилка; и тимлид понимаем из описания, на кого делегировать задачу.

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

4. Техлид определял исполнителя и отдаёт задачу в работу.

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

В таком процессе за техническое качество реализации отвечает техлид, а тимлид за сроки и бюджет.

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

Знания, умения и скиллы поговорим конкретнее

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

Базовый набор Soft-скиллс:

• Поиск и подбор кандидата, собеседование.

• Постановка личных целей.

• Стратегическое видение развития.

• Отношения с людьми: эмпатия и эмоциональный интеллект.

Базовый набор Hard-скиллс:

• Знание языков разработки и опыт программирования. Знание сопутствующих и окружающих этот стек технологий.

• Понимание архитектуры проекта: принципы проектирования архитектуры, паттерны и инструменты.

• Процессы и инструменты тестирования. Оптимизация тестирования, метрики и мониторинг.

• Управление инцидентами.

Теперь стоит поговорить технологии и инструменты, которыми должен владеть хороший техлид. Его зона ответственности технологии, IT-ландшафт проекта и технологический стек, реализующий бизнес-логику в контексте проекта. Соответственно, технологий много, а их сочетаний еще больше, причем для каждого конкретного проекта это сочетание уникально. Поэтому имеет смысл говорить не о конкретных программах, а сразу о классах решений и инструментов:

• Текстовые редакторы и интегрированные среды разработки.

• Инструменты для создания схем в разных графических нотациях и офисные программы.

• Системы управления задачами и проектом.

• Системы управления знаниями и документаций.

• Системы управления версиями кода и инструменты CI/CD.

• Системы контейнеризации и инструменты DevOps.

• Системы мониторинга и управления инцидентами.

• Серверные операционные системы и их сервисы.

• Скрипты и собственные наработки кода.

Кто может стать техлидом?

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

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

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

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

Хочу сказать отдельное спасибо Алисе Мироненко за подготовку транскрипта. Видео версия доклада:

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

Мне часто встречаются люди с такой карьерной историей: в новую компанию приходит разработчик с десятилетним опытом работы. В 2010 году онпришел в компанию Х,быстро развился до синьора, он талантливый, крутой. Так как онталантливый, ему дали тимлида.

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

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

Потом человек с таким опытом приходит к нам на позицию разработчика.

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

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

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

Но расстояние между лидоми менеджером такое же, как междуджуномилидом.

У наснет времени учиться на менеджеров это главнаяпроблема.

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

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

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

Раз мы решили пойти в менеджмент, давайте получатьсоответствующиенавыки, знания.А то есть менеджеры, которые не знают основ как делегировать и прочее.

Если мы решилиуглубиться в разработку, у нас должна быть инженерная нагрузка, хотя бы 30%. Возникает вопрос: А разве эти 30%насспасут? Да, об этом сегодня и поговорим как добиться этих 30% эффективной работы, чтобы мы продолжали развиваться как настоящие инженеры.

Давайте начнем с того,когда тимлиду стоит заниматься разработкой. Я сделал небольшойчеклист.

Возможно, у вас есть время на разработку, если:

1. Вы занимаетесьмикроменеджментом.

2. Пишете много документации в стол.

3. Вы единая точка коммуникациина проекте.

4. Ваша команда только пишет код.

5. У вас много тет-а-тет митингов.

6. Вы инициатор большинстваэтих митингов.

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

В целом ясчитаю, что совмещениеролейуправленцаи инженера зависит от трех вещей:

1) Стадии развития вашей команды

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

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

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

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

2) Уровня квалификации и мотивации ваших сотрудников

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

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

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

Есть классическая табличка на эту тему:

Единственный возможный вариант освободить себе время на разработку делегировать задачи достаточно мотивированной и квалифицированной команде.

3) Уровня коммуникации на проекте

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

Например,mushroommanagement(управление по принципу меньшезнаешь крепче спишь), когда вы являетесь единой точкой коммуникации и никто больше не знает, что происходит.

Очевидно, что в таком случае у вас не будет времени на инженерную деятельность.

Как настроить коммуникацию?

Вариант:если я единая точка коммуникации,я возьму и самоустранюсь.

Главная проблема будет в том, что появится неформальный лидер. Понятие неформальный лидер неприятное, потому чточасто неформальные и формальные лидеры не одно лицо. Это становится проблемой для формального лидера.

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

Как перестать быть единой точкой коммуникации?

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

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

• Познакомьте заказчика с командой через task manager.

• Организуйте встречу с командой в привычном для заказчика месте и времени. Не приводите сразу всех.

• Ведите первые митинги как обычно, тет-а-тет с заказчиком, но с командой на фоне.

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

• Поднимайте на встречах вопросы, которые можно адресовать команде. Пусть на них отвечают, не ожидая вас.

• Позвольте вашим коллегам вести митинги и переписки напрямую с заказчиком, но в первое время будьте рядом.

• Всегда будьте в копии и на связи с заказчиком.

• Это было про коммуникацию, теперь прото,как делегировать.

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

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

Не забывать, чтоваши функции не очевидны другим.

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

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

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

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

Давайтетеперь подумаем,как бороться с отвлечением и управлять вниманием

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

Но что делать с вопросами коллег? Важно отвечать на них хотя бы в течение получаса.

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

Для тимлидов отметим важный момент: пишем через 15 минут правильно.

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

Рассмотрим еще одну проблему возврат в контекст.

Вы программируете, у вас в голове: Задача-метод-класс. Вас отвлекли, контекст пропал. Выответили сотруднику, нужно вернуться в контекст.

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

Мультитаскинг большая проблема тимлида, и здесь могут помочьвиртуальные рабочие столы.

На виртуальном рабочем столе программирования у вас может быть открытIDE, браузер, требования.

На виртуальном столе, где у вас релиз в продакшен, Jenkins/TeamCity, Splunk/Kibana, чат с DevOps. То же самое с обсуждением требований: Skype/Teams, Jira, Confluence.

Легче перескакивать между виртуальными рабочими столами, чтобы менять контекст.

Пора программировать

Мы настроили время, коммуникацию, справились с отвлекающими факторами, налили чаёк Имы парализованы.

У насантипаттерн аналитики-паралитики.

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

Как вы думаете, о чём будет думать архитектор нефтекомплекса, когда ему надо чинить трубу? Пройдет ли этот биметаллэконормы? А как на давление повлияет всжигателе? В данном случае архитектор просто не сможет починить эту трубу, потому что не справится с такой когнитивной нагрузкой.

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

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

Напоследок хотелось бы поговорить про выбор программерскойроли, когда вы тимлид

Давайте рассмотрим основные роли:

Ключевой разработчик, который делает основную бизнес-логику, разрабатывает ядро продукта.

Если вашабольшая команда,времени на это может не быть. Стоит вовремя отдать эту роль, когда команда растет, иначе вы можете превратиться впрототипщика(человек, который пилитпрототипы,а доведение проекта до ума оставляет на откуп команде).

Затыкательдыр человек, который приходит, когда нам чего-то не хватает для полного счастья.

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

Еще одни руки еще один программист,которыйпросто еще что-то делает фикситбаги, например.

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

И мое любимое кодерскийбалласт. Человек, которого лучше бы не было.

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

Резюмируя: как быть тимлидом и продолжать программировать.

Когда?

• Когда команда на стадиинормингаилиперформинга.

• Когда люди квалифицированы и мотивированы.Когда настроена коммуникация.

Как?

• Прямая коммуникация.

• Делегирование.

Рекомендации

• Управлять отвлекающими факторами.

• Микродекомпозироватьзадачи.

• Облегчить переключение фокуса внимания.

• Трезво выбирать роль.

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

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

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

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

Каковы финансовые показатели компании?

Является ли компания прибыльной или тратит деньги инвесторов? Или даже до инвесторов ещё не дошло, и основатели пока платят из своего кармана? Как выглядит бизнесовый план развития?

Если компания имеет представительство в РФ, официальное ли (по ТК РФ) трудоустройство и полностью ли "белая" зарплата?

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

Расскажите про ваше понимание хорошего тимлида

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

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

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

Кто ещё (кроме Вас) будет меня собеседовать и зачем?

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

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

Почему и как уволился / был уволен последний ушедший сотрудник?

Ответ на этот вопрос дополнит ответ, данный на вопрос о "качествах хорошего тимлида", а заодно покажет, какое отношение в компании к подобным вопросам.

Внимание: Вопрос может быть быть расценен как провокационный, осторожнее с ним.

За что вообще могут уволить? Что является провалом в плане работы / результатов / поведения?

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

Какие показатели текучести персонала в компании? Удовлетворяют ли они вас? Если нет, что делаете для улучшения показателей?

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

Кто будет заниматься моей адаптацией и каков её процесс?

Часто нового тимлида не адаптируют вообще никак "на тебе команду, плыви дальше". Иногда же бывает полноценный выстроенный процесс адаптации, с целями и задачами (чаще всего перекрещивается с положением об испытании).

Есть ли положение об испытании или нанятый сотрудник сразу считается прошедшим испытательный срок?

Станет понятно, как работает испытательный срок в компании, что в рамках этого срока нужно выполнить, чтобы его пройти, а также оформлено ли испытание по ТК РФ или же на словах.

Об испытательном сроке и особенностях его оформления я напишу отдельно.

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

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

Также стоит прояснить и потенциал роста и развития какие дополнительные роли и обязанности можно брать и какие есть критерии оценки качества исполнения этих обязанностей и какие есть критерии оценки качества исполнения этих обязанностей.

Есть ли схемы дополнительной финансовой мотивации?

Есть ли в компании система премирования, если да, то каковы размеры премий и на основании чего они выплачиваются каким категориям сотрудников?

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

Выдаётся ли оборудование для работы?

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

Какой уровень контроля тимлида над ФОТом команды, каковы процедуры работы с ним?

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

Иногда бывают готовые процессы работы с зарплатами performance review, например, где-то есть правила, что при попытке уйти контрофер делают, где-то просто зарплату за выслугу лет индексируют, где-то зарплата остаётся плюс-минус одна, а вот RSU всякие накидывают изрядно.

Обладает ли тимлид полнотой полномочий в найме, росте/развитии и увольнении сотрудников?

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

Можно добавить сюда же вопрос "кто является хорошим разработчиком, а что неприемлемо?".

Есть ли на предприятии СКУД, является ли график работы жестко заданным или гибким? Есть ли дистанционка, какие правила?

График и условия труда стоит прояснить прямо сразу.

Как осуществляется целеполагание и контроль результатов? Есть ли учёт времени?

Кто ставит цели / задачи, в каком виде? Бывают всяческие виды целеполагание OKR, KPI, прямые указания и документально оформленные приказы руководства.

Как компания обслуживает больничные и отпуска?

У каждой компании своя политика кто-то оплачивает 100% зарплаты во время длительного больничного, кто-то действует по ТК РФ.

В плане отпусков многие компании требуют планировать отпуск на год вперёд, некоторые же более гибкие.

Оплачивает ли компания полис ДМС, если да, то какой компании?

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

Какие процессы разработки в команде и почему? Есть ли у тимлида возможность менять их?

Этот вопрос перекликается с вопросом о полномочиях тимлида в найме/развитии сотрудников и может показывать ожидаемый уровень компетенций тимлида.

Также важно услышать ответ на вопрос "почему" такие процессы установлены будет виден уровень компетенций руководителя в принятии решений о внедрении чего бы то ни было.

Расскажите про значимое изменение процессов, инициированное и проведенное кем-нибудь из тимлидов

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

Опишите весь процесс производства ПО

На основе ответа на этот вопрос можно "закопаться" глубже и составить более полную картину уровня компетенций и знаний руководителя.

Есть ли в компании переработки, как часто? Боретесь ли вы с ними и если да, то как?

Внимание: вопрос может показаться провокационным, можно смягчить до "есть ли в компании переработки?"

А можно и добавить "Когда это было в последний раз и по какой причине? Как были оплачены переработки сотрудникам?"

Есть ли бюджет на обучение сотрудников? Каким образом выделяется?

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

Список будет обновляться вечно, сама работа ведется на гитхабе, присоединяйтесь. Пул-реквесты, форки всё welcome.

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

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

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

Каковы финансовые показатели компании?

Является ли компания прибыльной или тратит деньги инвесторов? Или даже до инвесторов ещё не дошло, и основатели пока платят из своего кармана? Как выглядит бизнесовый план развития?

Если компания имеет представительство в РФ, официальное ли (по ТК РФ) трудоустройство и полностью ли "белая" зарплата?

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

Расскажите про ваше понимание хорошего тимлида

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

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

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

Кто ещё (кроме Вас) будет меня собеседовать и зачем?

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

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

Почему и как уволился / был уволен последний ушедший сотрудник?

Ответ на этот вопрос дополнит ответ, данный на вопрос о "качествах хорошего тимлида", а заодно покажет, какое отношение в компании к подобным вопросам.

Внимание: Вопрос может быть быть расценен как провокационный, осторожнее с ним.

За что вообще могут уволить? Что является провалом в плане работы / результатов / поведения?

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

Какие показатели текучести персонала в компании? Удовлетворяют ли они вас? Если нет, что делаете для улучшения показателей?

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

Кто будет заниматься моей адаптацией и каков её процесс?

Часто нового тимлида не адаптируют вообще никак "на тебе команду, плыви дальше". Иногда же бывает полноценный выстроенный процесс адаптации, с целями и задачами (чаще всего перекрещивается с положением об испытании).

Есть ли положение об испытании или нанятый сотрудник сразу считается прошедшим испытательный срок?

Станет понятно, как работает испытательный срок в компании, что в рамках этого срока нужно выполнить, чтобы его пройти, а также оформлено ли испытание по ТК РФ или же на словах.

Об испытательном сроке и особенностях его оформления я напишу отдельно.

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

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

Также стоит прояснить и потенциал роста и развития какие дополнительные роли и обязанности можно брать и какие есть критерии оценки качества исполнения этих обязанностей и какие есть критерии оценки качества исполнения этих обязанностей.

Есть ли схемы дополнительной финансовой мотивации?

Есть ли в компании система премирования, если да, то каковы размеры премий и на основании чего они выплачиваются каким категориям сотрудников?

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

Выдаётся ли оборудование для работы?

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

Какой уровень контроля тимлида над ФОТом команды, каковы процедуры работы с ним?

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

Иногда бывают готовые процессы работы с зарплатами performance review, например, где-то есть правила, что при попытке уйти контрофер делают, где-то просто зарплату за выслугу лет индексируют, где-то зарплата остаётся плюс-минус одна, а вот RSU всякие накидывают изрядно.

Обладает ли тимлид полнотой полномочий в найме, росте/развитии и увольнении сотрудников?

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

Можно добавить сюда же вопрос "кто является хорошим разработчиком, а что неприемлемо?".

Есть ли на предприятии СКУД, является ли график работы жестко заданным или гибким? Есть ли дистанционка, какие правила?

График и условия труда стоит прояснить прямо сразу.

Как осуществляется целеполагание и контроль результатов? Есть ли учёт времени?

Кто ставит цели / задачи, в каком виде? Бывают всяческие виды целеполагание OKR, KPI, прямые указания и документально оформленные приказы руководства.

Как компания обслуживает больничные и отпуска?

У каждой компании своя политика кто-то оплачивает 100% зарплаты во время длительного больничного, кто-то действует по ТК РФ.

В плане отпусков многие компании требуют планировать отпуск на год вперёд, некоторые же более гибкие.

Оплачивает ли компания полис ДМС, если да, то какой компании?

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

Какие процессы разработки в команде и почему? Есть ли у тимлида возможность менять их?

Этот вопрос перекликается с вопросом о полномочиях тимлида в найме/развитии сотрудников и может показывать ожидаемый уровень компетенций тимлида.

Также важно услышать ответ на вопрос "почему" такие процессы установлены будет виден уровень компетенций руководителя в принятии решений о внедрении чего бы то ни было.

Расскажите про значимое изменение процессов, инициированное и проведенное кем-нибудь из тимлидов

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

Опишите весь процесс производства ПО

На основе ответа на этот вопрос можно "закопаться" глубже и составить более полную картину уровня компетенций и знаний руководителя.

Есть ли в компании переработки, как часто? Боретесь ли вы с ними и если да, то как?

Внимание: вопрос может показаться провокационным, можно смягчить до "есть ли в компании переработки?"

А можно и добавить "Когда это было в последний раз и по какой причине? Как были оплачены переработки сотрудникам?"

Есть ли бюджет на обучение сотрудников? Каким образом выделяется?

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

Список будет обновляться вечно, сама работа ведется на гитхабе, присоединяйтесь. Пул-реквесты, форки всё welcome.

Как часто вы взрываетесь хохотом, прочтя что-нибудь вроде "Тимлид, синьор, архитектор ПО и просто красавец. Ванька, 18 лет"? Оу, я правда об этом пишу? Эйджизм? Комплексы? Зависть? Кхм, ну скорее сочувствие. Ведь за такими историями чаще стоитзагубленная, а не головокружительная карьера. Одним такой статус навязал работодатель, другие с самого начала в поисках такой участии путают горе с коронацией. Однако, правда в том, что взрывной рост и слишком стремительная карьера, скорее всего, убьютв вас профессионала. Быть лучшим здорово, но быть худшим в команде настоящих профессионалов лучший выбор.

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

Допущение, как отправная точка

Дальше я руководствуюсь допущением, что каждый из нас стремится стать выдающимся профессионалом, чем бы он ни занимался. Иначе не совсем понятно зачем что-то делать и тогда любые мысли будут разбиты лаконичным "и чё?" в комментариях. Еще кое-что, давайте вспомним, как работает формальное образование:

Мы погружаемся в какую-то область знаний на протяжении 4-7 лет и с горящими глазами идем на работу и... работаем? Увы. Мы еще непригодны к выполнению должностных обязанностей. Нас вручают куратору/наставнику, под чьим чутким руководством мы получаем необходимые навыки и знания. Поправьте, но похоже это справедливо для любой деятельности. Конечно, вместе с тем, нам просто необходимы знания и понимание теории, но факт остается фактом вчерашний студент, без должного присмотра, испортит все до чего дотянется.

Необоснованная потеря

Что произойдет, когда вчерашний середняк повяжет на себя капитанскую повязку?

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

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

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

Последствия

В итоге, новый капитан остается бестолковым студентом-практикантом после такого отказа. Что скажете? Он будет учиться на своих ошибках? Ну... если повезет. А если нет? Что вероятнее, так это то, что он будет закреплять неверные решения и переводить ошибки (плохие решения), которые чудом сработали в ранг принятых в команде практик. "И так сойдет" станет новым девизом команды. Он навредит не только себе, но также компании и молодым ребятам, которые пришли, чтобы стать лучшими, но останутся заурядными никем. Возможно, с такой командой станет невыносимо работать и ее разгонят. Но наш Ванька теперь лучший и с этим знанием он пойдет разрушать другие команды, по пути создавая таких же бестолковых непрофессионалов, как и он сам. У этого даже есть название эпидемия.

Оставайтесь худшими, пока...

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

Быть худшим бесит. Быть худшим это страшный стресс. Но только в начале, к тому же это абсолютно мизерная плата за _величие_ в профессии. Контролируемый рост приведет вас к цели с большей вероятностью. И тут я вспомнил давно прочитанную книгу "Великие, а не большие", потому скажу: будьте великими, а не большими или как говорил сам автор небольшими гигантами. Играйте с лучшими, берегите свою карьеру, себя, читайте твиттер.