Как ты считаешь, руководитель — логичный этап в развитии IT-специалиста?

Я бы не сказал, что это обязательный этап. Иногда человек через него проходит, чтобы понять, что ему не хочется быть руководителем. Нет ничего странного в том, чтобы писать код по 10–15 лет.

У меня есть свой подкаст. Недавно записывал выпуск с «олдами» — людьми, у которых 10 лет опыта в разработке. Некоторые из них со временем поняли, что руководитель и технический специалист — не одно и то же. И что им нравится оставаться технарями.

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

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

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

1. Побыть ментором для стажёра в компании.

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

3. Пойти ментором на образовательную платформу. Например, в Академии Яндекса есть Школа разработки интерфейсов, Школа бэкенд-разработки и другие программы, где мы организовываем командную работу студентов. Можно попроситься ментором в такую команду.

Дальше нужно понаблюдать за своими ощущениями: легко ли даётся общение с другими людьми — наполняет или опустошает, комфортно ли вам нести больше ответственности.

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

До какой руководящей должности может вырасти разработчик в Яндексе?

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

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

Если вы тимлид, вам нужно развивать тех людей, что у вас есть. Вы заинтересованы в том, чтобы эти люди выросли и у них всё стало хорошо.

Если я разработчик и хочу стать тимлидом или техлидом, что мне делать?

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

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

Должен ли тимлид продолжать развиваться как разработчик?

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

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

Хорошо, а если меня повысили, как одновременно быть требовательным к своим коллегам и не растерять хорошие отношения с ними?

В Яндексе такая культура, что не получится вести дела в директивной манере. Сложные задачи требуют высокой степени автономности от подчинённого, поэтому руководителю важно «продать» задачу, убедить человека, объяснить ему, что и почему нужно сделать.

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

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

Требования — это гантели, которые тренируют подчинённого, чтобы он эффективно выполнял задачи и развивался сам. Задача руководителя — правильно подобрать гантелю, чтобы она не была лёгкой и развивала человека. Тогда обратная связь будет как независимый измерительный прибор. Например, человек метнул молот на 60 м. Да, вы можете где-то закрыть глаза и сказать, что на 65 м, всё отлично. Но это будет неправдой. Это не даст человеку понять, где его реальный результат и на что он способен.

Кажется, очень сложно увольнять людей, если у вас хорошие взаимоотношения

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

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

Как считаешь, ты часто допускаешь ошибки как руководитель?

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

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

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

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