Мои ошибки и уроки за 1 год работы в должности технического руководителя

Прошел 1 год и 3 месяца с тех пор, как я официально принял вызов занять должность Tech Lead в Zak, должность, к которой я достаточно хорошо подготовился, или, по крайней мере, думал, что достаточно подготовился. Однако по мере того, как шли дни, команда структурировалась, и возникали ситуации, я понял, что не был так подготовлен, как представлял.

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

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

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

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

Не делегирование

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

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

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

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

Непонимание возможностей команды

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

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

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

Без вовлеченной команды ничего не получится

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

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

Быть прозрачным очень важно

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

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

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

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

И мы подошли к концу

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

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

Большое спасибо, что дошли до конца, и до встречи в следующий раз!

Оцените статью
devanswers.ru
Добавить комментарий