Развитие в лидов
Как ИТ-специалисту правильно выбрать карьерный путь
ИТ-индустрия предлагает множество путей для развития, однако требует от специалистов осознанного выбора своей карьеры. Когда сотруднику лучше оставаться техлидом, а когда его нужно развивать в сторону управления — на этот вопрос ответит председатель HR-Клуба АПКИТ Елена Калацей.
Фото: Пресс-служба «Киберпротект»
Фото: Пресс-служба «Киберпротект»
ИТ-отрасль — это не только извечный дефицит высококвалифицированных кадров, «удаленка», широкий спектр льгот и привлекательные заработные платы. В этой отрасли существуют свои подходы к классификации специалистов — грейдовая система, а также особый трек карьерного развития.
Когда разработчики, тестировщики, архитекторы или DevOps-инженеры преодолевают грейды джун, мидл и сеньор, перед тем, кто управляет ИТ-командой, встает ключевой вопрос: кого растить в техлида, а кого — в тимлида? Верное решение усилит команду и бизнес, а ошибка может привести к появлению неэффективного руководителя или потере сильного технического специалиста.
Одна команда — два пути
ИТ-рынок очень динамичен, а грейд, занимаемый сотрудником, имеет для него большое значение — по сути, это признание его компетенций и навыков работы с соответствующим технологическим стеком и инструментарием. Не каждый ставит своей целью карьерный рост, но те сотрудники, которым важна реализация амбиций, в определенный момент приходят к руководителю с вопросом о том, что ждет их дальше. В классическом карьерном треке ИТ-специалиста, уже занимающего грейд сеньор, могут ожидать два варианта: техлид и тимлид.
Техлид — это архитектор решений, евангелист инноваций, хранитель знаний. К техлиду обращаются, когда никто другой не знает, как нужно сделать и можно ли сделать вообще. Сотрудник, становящийся техлидом, обладает крайне высоким уровнем экспертизы, не боится сложных вопросов и чувствует себя комфортно, работая с легаси.
Тимлид — это лидер, тактик и переговорщик, задача которого — сделать так, чтобы цели команды были выполнены, код написан, а все проблемы, мешающие этому, были решены. Сотрудник, становящийся тимлидом, понимает, что в его работе станет меньше кода и работы руками, но появится практически безграничный перечень задач, связанных с управлением командой.
Несмотря на то что названия грейдов похожи и даже содержат общее «лид», задачи и компетенции, которые необходимо развивать для успешной работы в должности, совершенно разные. Отсюда и критичность ошибки: отправить потенциального лидера в техлиды — упустить сильного управленца, а назначить замкнутого технического специалиста тимлидом — получить менеджера, который может демотивировать команду и сам демотивироваться в последствии.
Как не ошибиться в выборе
Работа над определением компетенций, сильных качеств и зон роста сотрудника начинается с момента собеседования в компанию. Проводя интервью, опытный HR и нанимающий менеджер сразу оценивают не только текущий опыт, но и потенциальные возможности и карьерные перспективы кандидата.
Далее такая оценка продолжается в течение всего времени работы сотрудника: в процессе адаптации, в рамках годовой оценки, а также в ходе работы над проектами и по отзывам коллег. Выявляются склонности и предпочтения специалиста, фиксируются те задачи, которые он выполняет успешнее других и делает с особым энтузиазмом, и наоборот — то, что дается с трудом или воспринимается негативно.
Потенциального техлида мотивируют сложные вызовы, связанные с техническим аспектом продукта. Такому сотруднику интересно разобраться в решении, он не боится легаси, охотно берется за нестандартные задачи и не устает от них. Участие в проведении собеседования и оценке кандидатов для такого сотрудника — не самая комфортная и интересная задача, разве что в части обсуждения технических вопросов. По этой причине техлидов все же привлекают к интервью как сильных экспертов: они не обращают внимания на самопрезентацию и личностные качества кандидата, но хорошо оценивают технические навыки, задают правильные вопросы и могут дать экспертное заключение.
Перед вами перспективный техлид, если:
- к этому человеку обращаются коллеги, когда нужно помочь в вопросе, связанном с технологией или инструментом;
- этот человек может наиболее точно оценить, сколько времени понадобится на реализацию той или иной фичи;
- сложная техническая задача вдохновляет его, а административные задачи, отчетность и встречи скорее сковывают;
- технологии и инновации — его страсть, а программирование является не только работой, но и хобби.
Часто техлиды — это те люди, которые не смотрят на часы, когда выполняют интересную задачу. В этой связи руководителю или HR иногда приходится проявлять к ним чуть больше внимания, например, отправить на дэй-офф после успешно выполненной задачи или напомнить о том, как важно ходить в отпуск.
Тимлиду же предстоит отвечать за найм и адаптацию, распределение задач, решение конфликтов в команде и за ее пределами, мотивацию, удержание и увольнение. Это далеко не весь список задач даже в управлении командой, а ведь, помимо этого, есть еще управление ожиданиями заказчика (внутреннего и/или внешнего), выстраивание взаимоотношений с кросс-командами, проведение встреч и, конечно, технические задачи: код ревью, оценка качества выпускаемого продукта, а где-то и написание кода.
Амбиции, лидерские качества и готовность к взаимодействию с другими людьми — вот что помогает тимлиду эффективно справляться с большим объемом разноплановых задач. Коммуникативные навыки являются ключевыми на этой роли: это и отстаивание интересов команды, и эффективные встречи, и мотивация сотрудников.
Распознать хорошего потенциального тимлида можно по следующим признакам:
- умеет объяснять, доносить свою позицию и договариваться даже в непростых ситуациях;
- интересуется не только технической частью продукта, но и более широким кругом тем: результатами продаж, бизнес-процессами, заказчиками;
- задачи по участию в собеседованиях или обучении новичков даются легко и вызывают интерес;
- готов структурировать хаос, перенося его в понятные и доступные процессы;
- активно делится с командой предложениями, инициативами и идеями вместо того, чтобы сосредоточиться исключительно на себе и своем комфорте.
Под управлением хорошего тимлида растет эффективность команды и снижается текучесть, ведь сотрудники довольны: получают обратную связь, могут оперативно решить с руководителем возникающие трудности, имеют все условия для комфортной и продуктивной работы. Конечно, это в идеальной картине. На практике эти условия для эффективной работы определяются корпоративной культурой компании, стилем руководства и особенностями самой команды.
Управляй, или будут управлять тобой
Начинающему руководителю, не имеющему в бэкграунде управленческого опыта, сложно представить, с какими запросами и как часто будут приходить сотрудники. Это могут быть вопросы по рабочему процессу, организационным моментам (отпуска, отгулы, опоздания, больничные и др.), взаимодействию с другими сотрудниками (нет ответа на запрос, не удается найти общий язык), а иногда и по личным обстоятельствам. Несмотря на то что в последнее время все стараются разделять работу и личную жизнь и поддерживать work-life balance, они так или иначе влияют друг на друга.
Пример: тимлид обратил внимание, что один из сотрудников команды стал иначе себя вести, стал более замкнут, ухудшилось качество его работы. В такой ситуации тимлиду следует спросить сотрудника на 1:1 встрече, что могло повлиять на такие изменения. В зависимости от доверия к руководителю, сотрудник может поделиться личными обстоятельствами, на которые, конечно, руководитель вряд ли повлияет, но может предложить, например, взять day off, отпуск или просто неформально побеседовать.
Насколько руководитель готов погружаться в личные обстоятельства подчиненного, определяют обе стороны. Нельзя сказать, правильно это или нет, но мне встречались ситуации, когда простое человеческое общение помогало обоим: руководителю — понять причину изменений и на время изменить отношение к сотруднику, а сотруднику — легче справиться с ситуацией и стать более лояльным к тимлиду. Помимо отпуска, существуют такие инструменты, как перераспределение задач, смена зон ответственности или проектов, временное изменение формата обратной связи, графика работы и другое. Кто-то в сложных жизненных ситуациях нуждается в дополнительных интересных задачах, на которые можно переключиться, а кому-то наоборот необходим отпуск. И здесь руководитель уже превращается в дирижера, который при распределении и оценке задач обращает внимание не только на сильные стороны, но и на текущее состояние своего сотрудника.
Однако чем больше становится таких кейсов, тем быстрее руководитель понимает: угодить всем невозможно. Или это просто неэффективно. К сожалению, бывают ситуации, когда готовность руководителя пойти навстречу сотрудники воспринимают как слабость и уступчивость и используют это в своих личных целях. Поэтому баланс между эффективным управлением и человечным отношением для некоторых становится почти искусством. И это не единственный выбор, который предстоит делать руководителю.
Часто приходится выбирать между собственными принципами и эффективностью работы команды. Яркий пример: работа с токсичным сотрудником, который показывает крайне высокий результат. Эта тема до сих пор становится дилеммой для многих управленцев: попрощаться с таким в ущерб производительности, но сохранить комфортную культуру взаимодействия, или сохранить эксперта, замкнув коммуникацию с ним на себе. В любой кризисной ситуации руководителю нужно отключить эмоции и принять решение, которое приведет к успеху, даже если этот выбор не соответствует его мировоззрению.
Или, например, выбор стиля управления. Генри Форд отправлял руководителей в принудительный отпуск, чтобы оценить, как работает их команда в отсутствие своего лидера. Если в отделе начинался хаос, это говорило о том, что руководитель не смог организовать условия для эффективной бесперебойной работы. И наоборот, Форд поощрял руководителей, которые добились того, что их отсутствие не сказывалось на эффективности работы команды, и она была способна работать самостоятельно.
Это тоже про баланс. Руководитель, который не делегирует, не создает условия для развития сотрудников, чрезмерно все контролирует и не доверяет подчиненным решение задач в своей зоне ответственности, не способствует превращению команды в сильную самостоятельную единицу. Сотрудники могут к этому относиться по-разному: одним в такой команде тесно, а другим рады отсутствию полной ответственности.
На мой взгляд, сильными управленцами не рождаются: это опыт, который приходит с практикой. И если в начале карьеры руководителю может казаться, что отсутствие кейсов со сложными увольнениями, демотивацией, снижением эффективности — это признак хорошего управления, то я вас разочарую: каждая такая ситуация — это вклад в собственные компетенции. Чем сложнее ситуация, тем более закаленным и сильным становится руководитель.
Должен ли тимлид писать код
Но не управлением единым. Один из самых интересных вопросов, который часто делит ИТ-сообщество на два лагеря, состоит в том, должен ли тимлид, выполняющий большое количество административных функций, заниматься и написанием кода.
Разумеется, единственно правильного ответа на этот вопрос нет: это зависит от компании и ее потребностей, а также от навыков самого тимлида.
Если тимлид пишет код, он более осведомлен в технической части продукта. Его продуктовая экспертиза растет, он лучше понимает потребности разработчиков, лучше оценивает сроки и возможные риски. Но во всем должен быть баланс: если сделать фокус на одном, может пострадать другое.
Бывают ситуации, когда тимлид выполняет исключительно управленческие функции, не отвлекаясь на написание кода, но эффективно выполняя работу по распределению и контролю задач, взаимодействию с заказчиком и другими подразделениями. И это тоже рабочая схема.
Существует и третий вариант — гибридный, когда тимлид может участвовать в написании кода время от времени: либо при возросшей нагрузке на команду, либо чтобы его технические навыки не стагнировали.
В любом случае, тимлиду важно фокусироваться на стратегических целях и задачах, уметь комплексно смотреть на любой процесс и ситуацию под разными углами, чтобы принимать продуктивные и взвешенные управленческие решения.
Если даже сама мысль о том, что с кодом придется работать меньше, вызывает у сотрудника тревогу — возможно, роль техлида для него будет более подходящей. Или можно просто с этим смириться.
За деньги — нет
Если в большинстве сфер роль руководителя предполагает более высокий доход, то ИТ-рынок становится исключением. В некоторых случаях заработная плата технического эксперта может быть идентичной или даже выше, чем у тимлида. Это происходит, когда техлид владеет крайне редким набором компетенций. Для бизнеса потерять экспертизу такого человека может быть критичнее, чем потерять хорошего менеджера.
В нашей сфере это, скорее, плюс: заработная плата не ставится главным мотиватором при принятии решения о карьерном развитии, поэтому у разработчика есть возможности ориентироваться на собственные предпочтения: код или команду.
Как избежать неправильных решений
Представьте тимлида, которого раздражают административные задачи, утомляют встречи и коммуникации, который просто хочет сфокусироваться на технической задаче. Это жертва неправильного кадрового решения.
Последствия могут быть разные: от не справляющегося с задачами сотрудника до увольняющейся команды. Для команд новый руководитель — это стресс, а когда это место занимает некомпетентный и не слишком заинтересованный сотрудник, стресс трансформируется в неприязнь, демотивацию, что в конечном итоге может обернуться уходом из компании.
Симптомы неправильного кадрового решения важно вовремя распознать. Для этого необходимо сопровождать сотрудника после перевода на новую роль: собирать обратную связь от него, его руководителя и команды, быть на связи при возникновении вопросов, предоставлять полезную информацию и инструменты. И ни в коем случае не утаивать, если что-то идет не так.
А еще лучше — минимизировать возможные трудности и риски еще до такого перехода. В некоторых компаниях, например, в «Киберпротекте», для этого существует индивидуальный план развития (ИПР) — структурированный план по задачам, рекомендации для развития компетенций, точки контроля с обратной связью. Перед тем как вступить в новую должность, сотрудник погружается в рабочие задачи, изучает необходимые инструменты и получает первые отзывы об успехах. Такой план является подспорьем для успешного входа в должность или своеобразной «демо-версией» потенциальной роли. Уже на этапе ИПР можно понять, что еще необходимо сотруднику для успешного вхождения в роль.
О возможностях карьерного роста, системе грейдов и инструментах профессионального развития компании важно говорить сотрудникам: рассказывать о процессе, делиться историями успеха. Бывают случаи, когда профессионал покидает компанию, чтобы уйти на более высокую должность, так и не узнав, что у текущего работодателя такая возможность тоже есть. Наличие регламентов, инструкций и анонсов возможностей профессионального развития — это забота компании как о сотрудниках, так и о собственных перспективах.
А куда расти — в тимлида или техлида — опытному разработчику подскажет грамотный HR, эффективный руководитель и здравое оценка собственных компетенций и приоритетов.