Меня зовут Олег Кандауров, я руководитель отдела бэкенд-разработки в ЮMoney. Руковожу шесть лет: три года — командой, ещё три — отделом. До этого несколько лет работал бэкэнд-разработчиком, поэтому с пониманием технологий проблем нет.
Чтобы управлять командой, я перестал писать код, но через пару лет всё же пришлось возвращаться в прежний режим, и это было сложно: мозг уже перестроился. Рассказываю, как техническому лидеру не растерять накопленную за годы кодинга экспертизу и научиться управлять людьми.
Как актуализировать знания, чтобы ничего не забывать
Техлид — это больше про работу с людьми и коммуникацию, про выстраивание отношений, лидерство, контроль и менторство. Забрасывать обучение техлиду нельзя: легко потерять форму, а вместе с ней — авторитет у коллег. А это недопустимо, потому что техлид — пример для команды.
Важно соблюдать баланс: продолжать заниматься исследованиями, изучать новые технологии и при этом уделять время пипл-менеджменту. Получается ли у меня? Да.
К тому же я не единственный руководитель в отделе: у меня есть помощники
Им я делегирую часть управленческих задач и работу с людьми. Но команде всегда нужно внимание руководителя.
Когда-то у меня в отделе было много экспертов, которым я передавал технические задачи, а сам в это время занимался командой: нанимал, обучал, растил специалистов. Сейчас ситуация другая: команда уменьшилась, технической экспертизы в отделе стало поменьше, и мне нужно больше погружаться в технологии. Из-за этого приходится жертвовать пипл-менеджментом. Но при этом я продолжаю контролировать работу новичков — у нас очень много молодых разработчиков, которых нужно учить.
Поэтому я пришёл к такой мысли: нужно понимать, что в конкретный момент важно для компании, и направлять на это свой фокус внимания, расставлять приоритеты, оценивать риски.
У меня есть правило — время от времени задавать себе вопрос: что будет, если я не…? Например, не обращу внимания на ошибку или новую технологию, оставлю на потом, отложу в сторону. Что потеряет из-за этого компания, моя команда и я сам?
Руководить командой и оставаться технически подкованным мне помогает дисциплина и работа с восьми утра
Когда я был разработчиком, я приходил на работу к 12 дня, а уходил около девяти вечера. Обычно программисты где-то в такое время и работают: большинство из них — совы. Сейчас я не могу такого себе позволить, и у меня чёткий план дня:
С восьми утра до полудня я погружаюсь в сложные технические темы. В это время в офисе мало людей, никто не отвлекает и не беспокоит.
К 12 часам подтягиваются ребята из отдела, и начинаются встречи, созвоны. Времени на обучение нет.
В пять вечера заканчивается рабочий день, обычно к этому моменту думать сложнее, поэтому вечером я не погружаюсь в новые технические темы.
Когда стал тимлидом, я понял, что с техникой у меня всё хорошо, а вот с людьми не очень
Поэтому перестал писать код. Года два вообще ничего не писал — уделял всё время коммуникациям с командой. Скажу честно, вернуться обратно к коду после такого перерыва было сложно — мозг перестроился, начал работать по-другому. Надо было опять переключаться на новый режим.
Сейчас я стараюсь не уходить в крайности и поддерживать технические навыки, даже когда больше занимаюсь пипл-менеджментом: хожу на конференции, читаю статьи и книги, если нужно глубоко погрузиться в тему. Также считаю важным наблюдать за тем, что делают другие, и спрашивать себя:
Почему они сделали так?
Почему они так не сделали?
Почему мы так не делаем?
Это даёт пищу для размышлений, появляются новые темы, в которых хочется разобраться. Я быстро загораюсь новыми идеями и стараюсь воплощать их в ЮMoney, если это нам подходит.
Особенно меня вдохновляют и будоражат истории компаний, которые рассказывают о своих успехах и достижениях, классных результатах. Всегда хочется, чтобы у нас было так же, чтобы компания получала лучшие инженерные решения, разработчики были счастливы, а клиенты ЮMoney — довольны продуктом.
Как быть техническим лидером для команды
Придётся завоёвывать авторитет и доверие — показывать всё на личном примере, быть рядом с командой и помогать, пробовать то, над чем работает каждый отдельный разработчик. А ещё — всегда практиковать то, что недавно узнал или освоил.
Также нужно уметь продавать решение своей команде. В компании есть ведущие разработчики, которым больше интересен пипл-менеджмент, а есть эксперты, чей интерес преимущественно в технологиях. И тем, и другим важно развивать навык коммуникации. Без него трудно внедрить разработанные решения.
Посмотрите на лидеров мнений — в каждой компании такие есть. Они зачастую похожи на техлидов, но немного отличаются. У них:
не прокачан навык выступлений;
нет желания брать на себя большую ответственность;
нет уверенности в себе.
Но это не делает их мнение менее значимым, ведь у них есть своя аудитория — люди, с которыми они общаются, которым рассказывают про свои идеи.
Я рекомендую больше общаться с командой, получать обратную связь — так можно увидеть проблемные точки и вырасти. А продукт и команда вырастут вместе с вами. И, возможно, на выходе вы получите новое решение, которое будет лучше того, которое изначально задумывалось.
Для открытого взаимодействия техлида с командой важна инженерная культура и соответствующая атмосфера внутри компании. Не везде готовы критиковать решения руководителя. Важно, чтобы все разговаривали на языке аргументов, находились в одном контексте и не переходили на личности. Тогда должности уходят на второй план, и общаться становится гораздо проще.
Выводы
Три главных качества техлида в 2023 году:
Быть примером для команды и иметь желание погружаться в технологии, постоянно учиться новому. Даже если в подчинении 50 людей, которые ждут обратной связи и внимания.
Иметь чёткий распорядок дня с часами для учёбы, самостоятельной работы, встреч и созвонов.
Уметь продавать техрешение команде и принимать критику, чтобы делать продукт лучше.
Если вы тоже техлид или мечтаете им стать, пишите в комментариях, какие качества помогают вам успешно работать в команде и руководить. Во сколько вы начинаете рабочий день и как взаимодействуете с коллегами? Умеете ли балансировать и не уходить в код или пипл-менеджмент? А презентовать техрешение команде? И что посоветуете тем, кто ещё не научился? Ждём всех в комментариях.