{"id":14291,"url":"\/distributions\/14291\/click?bit=1&hash=257d5375fbb462be671b713a7a4184bd5d4f9c6ce46e0d204104db0e88eadadd","title":"\u0420\u0435\u043a\u043b\u0430\u043c\u0430 \u043d\u0430 Ozon \u0434\u043b\u044f \u0442\u0435\u0445, \u043a\u0442\u043e \u043d\u0438\u0447\u0435\u0433\u043e \u0442\u0430\u043c \u043d\u0435 \u043f\u0440\u043e\u0434\u0430\u0451\u0442","buttonText":"","imageUuid":""}

Уже не программист, но еще не менеджер

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

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

1. Откуда берутся тимлиды

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

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

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

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

Управлять программистами ≠ программировать

Когда-то я услышал очень классную фразу – “управлять программистами не равно программировать”. Это вообще разные вещи и развитие в одном направлении примерно никак не усиливает тебя в другом.

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

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

Выделение ресурсов

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

2. Откат, камбэк и новый виток кризиса

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

Но уже что-то не то. Ящик Пандоры открыт. Работать просто разработчиком уже скучно, да и полученные скилы ментора пылятся без дела. Вы снова становитесь Тимлидом в новой компании, но уже более осознанно.

Вы уже не совершаете предыдущую ошибку, и сразу распределяете свое время 50/50, где половину времени занимаетесь разработкой, а половину времени менеджерскими обязанностями. В этот момент ваш кризис принимает новую форму: вы все меньше и меньше занимаетесь разработкой. В какой-то момент вы понимаете, что берете только какую-то мелочь, которую успеете сделать между встречами в течение спринта. Вы начинаете с завистью смотреть на коллег, которые берут большие комплексные задачи в разработку.

Компенсация

Решать эту проблему можно по-разному. Один из вариантов – это компенсировать харды. Можно делать пет-проекты и постоянно обкатывать там новые технологии.

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

3. Поиск работы тимлида

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

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

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

Для того, чтобы поменять работу, вам придется все вспоминать и усердно готовиться к техническим интервью, наверстывая упущенное. Чтобы что? Чтобы просто пройти собеседование и снова не писать код.

Вынужденное развитие в двух независимых направлениях

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

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

2 направление – технический бэкграунд. Развитие в этом направлении в меньшей степени улучшит твои позиции на текущем месте. Но без хардов тебе не найти новое место. Если на собеседовании ты скажешь, что уже год не писал код, то для большинства компаний это будет скорее красным флагом. При этом развитие в этом направлении будет увеличивать твои перспективы дальше в случае ухода с текущего места работы.

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

Что в итоге

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

Подписывайтесь на телеграм‑канал Вайтишная — пишу честно про IT и делюсь своим опытом

0
1 комментарий
ИмФам2

ИМХО роль тимлида перепутана с проджект менеджером. У тим лида как раз таки должны быть высокие хардовые скиллы, тимлид должен шарить в том, на каких технологиях должен развиваться проект.

Ответить
Развернуть ветку
-2 комментариев
Раскрывать всегда