Нет причин, по которым новые технические руководители должны разбираться во всем самостоятельно
За первые шесть месяцев работы техническим руководителем я выгорел. Стать техническим руководителем всегда было моей целью, но после того, как я достиг этой цели, я какое-то время очень сожалел об этом.
Я работал намного больше часов, выполняя работу технического руководителя днем и догоняя работу с билетами по ночам. Я не очень четко понимал, что влечет за собой эта роль, я просто делал то, что, как я видел, делал последний технический руководитель. Я чувствовал себя совершенно не готовым к этому.
Это было пять лет назад, и за это время я был техническим руководителем и инженером в трех командах. Со временем опыт стал проще, а ожидания технического руководителя стали более ясными. Нет никаких причин, по которым новым техническим руководителям приходится во всем разбираться самостоятельно — вот мой совет, как стать лучшим техническим руководителем.
Во-первых, кто такой технический руководитель?
Технический руководитель может означать немного разные вещи в разных компаниях.
Одной из форм технического лидера является руководитель группы, когда вы отвечаете за повседневную работу и поставку качественного продукта от команды разработчиков, но не имеете права нанимать/увольнять сотрудников.
Вторая форма технического руководителя — это инженер-менеджер, где вы являетесь менеджером с полномочиями по найму / увольнению и обязанностями по управлению людьми, такими как регулярные обзоры производительности. Иногда они пересекаются в одной роли. Я также рассматривал это как две отдельные роли.
Третья форма технического руководителя — это ведущий инженер, когда вы являетесь старшим членом команды, который иногда руководит небольшими проектами, но в основном в технических целях, таких как проверка кода, разработка модели данных для нового проекта или архитектурный проект.
Эта статья будет посвящена первой форме технического лидера, также известной как тимлид. После того, как вы это прояснили, вот несколько принципов, которыми вы можете руководствоваться в своем техническом лидерстве.
Станьте щитом для своей команды
Управляйте всем, что может помешать работе команды, например, отвечая людям в Slack, у которых могут возникнуть вопросы к вашей команде или предстоящим проектам, работая с внутренними группами поддержки по эскалированным проблемам и представляя интересы команды на встречах, где это необходимо.
Это экономит время команды, не позволяя другим людям (например, высшему руководству) напрямую обращаться с запросами к разработчикам вашей команды. Это может отвлечь их и отвлечь разработчиков от важной запланированной работы. Таким образом, ваша цель — выяснить, происходит ли это, и четко сообщить этим людям, что эти запросы должны сначала пройти по надлежащим каналам.
Большая часть этой работы на самом деле просто пытается отсортировать проблему или вопрос и перенаправить их к нужным людям по мере необходимости.
Быть в курсе того, над чем работают другие команды
Встречи — это одно из тех необходимых зол, когда нам нравится говорить о том, как мы тонем в бесполезных встречах, но иногда на некоторых из этих встреч есть полезная информация.
В идеальном мире я получил бы пятиминутный отчет о каждой встрече, в которой я не являюсь активным участником, но этого никогда не произойдет.
Это возможность услышать информацию о том, что происходит в других командах, либо в командах, с которыми вы работаете напрямую, либо в других командах, более не связанных с вашей работой. Вы можете услышать, что какая-то команда разрабатывает новый сервис, и это даст вам возможность сказать: «Привет! Моя команда работает над чем-то подобным. Давай поговорим об этом!" Время от времени такое взаимодействие экономит вам четверть работы.
Способствовать обсуждениям с командой
Вы когда-нибудь были на собрании команды, где большая часть его проводилась в тишине, ожидая, пока кто-нибудь вмешается (особенно в удаленном контексте)? «А не исследовать ли нам эту библиотеку?», — может спросить кто-то, услышав в ответ сверчки. Иногда люди не знают, как реагировать, и боятся выглядеть глупо.
Ваша работа как технического руководителя — способствовать обсуждению с командой, чтобы команда могла принять решение и принять его. Помогите людям получить как можно больше информации, чтобы помочь им принять решение. Вы можете попросить больше ясности или задать глупые вопросы. В половине случаев другие люди тоже задают такие же вопросы, но стесняются их задать, потому что не хотят быть теми, кто задает глупый вопрос.
На ранних этапах вашей роли вам, возможно, придется немного полагаться на своих разработчиков. Вы не будете знать все различные части кодовой базы, но вам все равно нужно уметь отвечать на такие вопросы, как «Возможна ли функция X? У нас есть данные в системе Z». Если вы были в команде некоторое время, вы будете знать, кто знает какие части кодовой базы. Если вы новичок, именно они укажут вам правильное направление.
Если у вас недостаточно информации для принятия решения, скажите именно это и сообщите всем, кому нужно решение, к тому времени, когда вы сможете позвонить.
Имейте стандарты и подавайте пример
Не тратьте время на придирки к стилистическим различиям. Добавьте в проект линтер и/или средство форматирования и перенаправьте разговор на этот инструмент. Одно дело, когда другой разработчик оставляет 15 придирчивых комментариев; совсем другое — спросить, не следует ли нам добавить новое правило в линтер.
Требуйте, чтобы изменения кода сопровождались модульными тестами, где это возможно, и измеряйте охват модульными тестами. Для меня достаточно 70% покрытия для всего проекта.
Конечно, некоторые сценарии сложнее охватить модульными тестами, но это исключения. Любая бизнес-логика или странное специфическое поведение должны иметь модульные тесты — это единственный способ предотвратить случайный взлом кода другими разработчиками, удаляющий код, который, по их мнению, может быть ненужным.
Сосредоточьтесь на общей картине
Вы должны выбирать свои битвы, и есть более мелкие решения, которые в конечном итоге не стоят вашего времени. Если бы разработчик реализовал что-то в процедурном шаблоне, когда вы хотели бы, чтобы это было более объектно-ориентированным, я бы просто прикусил язык и пошел дальше.
Подобные решения в конечном счете не имеют большого значения в долгосрочной перспективе. Важно убедиться, что ваша команда не внедряет неработающие изменения в рабочую среду. Процедурный фрагмент здесь и там не остановит производство.
Это не значит, что вы не должны давать обратную связь. Иногда полезнее задавать вопросы, чтобы убедиться, что предлагаемое ими решение соответствует потребностям проблемы «Вы рассматривали X или Y?», а не личным предпочтениям технического руководителя.
Вы не должны указывать своим разработчикам, как реализовать их изменения (если только они специально не запрашивают обратную связь). Если вы делаете это слишком часто, они могут начать чувствовать себя больше как обезьяны-кодировщики, выполняющие то, что говорит технический руководитель.
Иногда вы можете подтолкнуть их к другому решению, задавая правильные вопросы, что позволяет им владеть идеей и реализацией в большей степени, чем вы говорите: «Сделайте это таким образом». В других случаях вы не можете, потому что их решение также в равной степени отвечает всем потребностям, и выбор между двумя подходами является вопросом предпочтения. В этом случае не парьтесь по мелочам и идите дальше.
Заключение
Как разработчику, вам не часто нужны эти навыки, хотя они полезны. Таким образом, новым техническим руководителям обычно приходится немного учиться, поскольку они выясняют человеческий аспект управления командой, балансируя при этом со своими собственными обязанностями. Поэтому, если вы хотите стать лучшим техническим руководителем в 2022 году, сосредоточьтесь на следующем:
- Быть щитом для вашей команды
- Быть в курсе того, над чем работают другие команды
- Участвуйте в дискуссиях внутри вашей команды
- Имейте стандарты и подавайте пример
- Сосредоточьтесь на общей картине
Если вы новый технический руководитель и чувствуете себя перегруженным всеми своими новыми обязанностями, ознакомьтесь с этой статьей.
