Первые шаги в работе руководителем 

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

Как пройти первый шаг и стоит ли вообще делать этот шаг или стоит откатиться обратно? 

Начнем со второй части вопроса: стоит ли вообще идти в менеджерскую ветку развития? 

В менеджерскую ветку стоит идти в следующих случаях 

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

2. Создание очерченного экрана в приложении не приносит удовольствия 

3. Вам нравится проектировать решения, а не возиться с деталями реализации 

Эти 3 пункта говорят о том, что вам пора идти в tech lead/architect  

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

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

6. Вы не горите от постоянных созвонов и общения с большим количеством людей 

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

Эти 4 пункта говорят, что вы готовы к позиции team lead/head of 

Если понимаете, что вам это не близко — лучше не стоит :) 

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

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

Основных задач руководителя всего 5

1. Планирование целей и задач работы команды и контроль их выполнения 

2. Найм, удержание, увольнение 

3. Мотивация, демотивация сотрудников

4. Формирование культуры, проработка процессов, установка ограничений

5. Развитие команды

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

Для того чтобы на начальном этапе побороть этот синдром самозванца я могу выделить несколько советов 

1. Логировать свои активности, «внедрил PBR», «описал структуру собеседования» и тд. В моменте времени это кажется несущественным и не приносит ощутимой пользы, но на длинной дистанции можно возвращаться к своим активностям и анализировать как они повлияли на компанию в целом. Когда я начинал, я этого не делал и довольно долго фрустрировал с проблемами «а нафиг я вообще тут нужен?» 

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

3. Создать/вступить в «орден Тимлидов». Так или иначе все руководители сталкиваются с одними и теми же проблемами. В виду разного бекграунда решение проблем даются всем с разной степенью сложности. Когда у вас есть community рядом, вы, 

- во первых, поймете, что вы не одни, 

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

- в третьих вам будет просто проще и быстрее развиваться 

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

В третьих 

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

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