Из программиста в тимлиды — личный опыт

Вступление

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

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

Пара слов обо мне

Чтобы у уважаемого читателя сложилась более полная картина, я расскажу немного о себе и своем профессиональном пути.

В IT-индустрии я достаточно давно (по меркам современного IT), больше 10 лет. В юности увлекался программированием, писал всякое на Pascal и Visual Basic (на том, который еще не знавал .NET’а), потом закончил институт по IT-специальности, а пока учился — параллельно работал на своей первой серьезной работе, программировал в одном из московских НИИ. К слову сказать, эта работа отбила у меня любовь к программированию, и следующие несколько лет я занимался совершенно не связанными с IT вещами в абсолютно другой области (но это уже совсем другая история). Однако в какой-то момент я все же решил вернуться в программирование, и вот тогда, пожалуй, и началась моя настоящая работа в IT-индустрии.

Хватит уже воды, давай что-то по теме

Так что же такое, товарищи, дебют и что такое, товарищи, идея? Дебют, товарищи, — это «Quasi una fantasia»…
Я имею в виду, зачем вообще становиться тимлидом? На этот вопрос за меня уже ответил классик: если можете не становиться тимлидом — не остановитесь им. В IT-индустрии бытует мнение, и я не однократно с ним сталкивался, что тимлид — это вершина эволюции разработчика, и все программисты рано или поздно должны дорасти до тимлида. Как вы уже могли догадаться, это мнение ошибочно. Тимлид — это одна из ступеней, до которой может дорасти программист, но только если он этого действительно хочет. Ведь тимлид — это не столько про технологии, сколько про управление. Управление людьми, управление проектами, управление планированием, рисками… Разумеется, тимлид должен быть технически подкован, и подкован достаточно хорошо. Однако, он может и не быть самым скилловым разработчиком в команде. Да-да, вау, срыв покровов! Гораздо важнее чтобы он имел хороший технический кругозор, чувствовал куда дует ветер в индустрии и в целом понимал куда она движется, умел смотреть на проекты и возникающие проблемы с крупна, и, конечно же, умел общаться с людьми и управлять ими. На словах это все звучит довольно просто и тривиально, однако это действительно важные навыки хороших тимлидов.

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

Так почему же я выбрал тимлидство? Так вышло, что на предыдущей работе я, хоть и числился «старшим программистом», выполнял чуть больше обязанностей. Начал заниматься развитием продукта в целом, даже в какой-то момент стал руководить разработчиками, как говорится, «пока тимлид не видит». И именно тогда я понял, что мне нравится этим заниматься, а главное — у меня получается. И вот, когда пришло время менять работу (а оно всегда когда-то да приходит), я решил попробовать поискать в первую очередь вакансии тимлида. И нашел!

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

Что я понял, став тимлидом

Первое, что я понял став тимлидом — это то, что кода в моей жизни будет в разы меньше, чем было до этого. К счастью, мне удалось в итоге стать «играющим тренером», то есть я все же продолжил писать код (в том числе чтобы не потерять хард-скиллы), но этого стало в разы меньше.

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

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

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

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

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

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

Выводы

А вывод предлагается сделать самому уважаемому читателю. Стоит ли менять уютное кресло программиста на кресло тимлида? Да. Или нет. Тут каждый должен решить для себя сам. Но если вы выберете вариант «да», то скучно вам точно не будет! В конце концов, если не понравится — всегда можно вернуться писать код. Главное не забывайте поддерживать свои хард-скиллы на должном уровне!

P.S. в комментариях приглашаю обсудить тематику, проблематику, покидать в меня тухлыми помидорами и попостить смешные картинки — в конце концов мы же на vc!

0
29 комментариев
Написать комментарий...
Александр Соколов

Мало цифр)) сколько % получил прибавку, какие технологии, сколько людей было, сколько сейчас?
Чем занимаешься сейчас ? Код ревью, внешние встречи, программируешь ли? В с отличие от техлида например?

Ну и какую-нибудь литературу. Я например с удовольствием прочёл книгу "Мама, я тимлид" ))

Ответить
Развернуть ветку
Sam Beckett
Автор

Вопросы денег как раз хотелось обойти. Но если интересно - процентов на 45 зарплата выросла.
По людям - отдел пока что не расширялся, была стандартная текучка. Кто-то уходил, кого-то пришлось уволить, на их место набирались новые разработчики.
По технологиям - это net core + angular, но в целом для тематики данной статьи это не так важно, здесь скорее взгляд с крупна )
По книгам - читал "Дедлайн" Тома Демарко, пробовал читать что-то по психологии, из серии "как научиться располагать к себе людей" и прочее, но не зашло.
За наводку по "Мама, я тимлид" спасибо, обязательно ознакомлюсь!

Ответить
Развернуть ветку
Сергей Добрицкий

А что скажете насчёт Брукса "Мифический человеко-месяц" и "Как пасти котов"?

Ответить
Развернуть ветку
Sam Beckett
Автор

Мифический человеко-месяц я начал читать сразу после Дедлайна, потому он не зашел, и я отложил его до лучших времен. Надеюсь, они скоро наступят ) Про котов вообще не читал, надо ознакомиться будет, спасибо!

Ответить
Развернуть ветку
Sam Beckett
Автор

А, и да, чем занимаюсь - код ревью, встречи с заказчиками (у нас параллельно несколько проектов в разработке), помощь программистам, если необходима. Код тоже пишу, причем довольно активно. Это было лично мое пожелание, мне пошли навстречу.

Ответить
Развернуть ветку
Александр Соколов

Дедлайн тоже отличная книга)
Про деньги я именно в % отношении, цифры не нужны)
А как ещё время то остаётся на код, если много организационных моментов и встречи, а ещё наверно и найм?)

Ответить
Развернуть ветку
Sam Beckett
Автор

Найм, к счастью, не так часто происходит. Команда пока что не растет, тк справляемся с задачами. Найм только при увольнении разработчика.
А так да, бывает довольно сложно переключиться с оргмоментов и встреч на код, уходит до получаса чтобы войти в "поток" и начать писать код. Но со временем привыкаешь. По-крайней мере я привык )

Ответить
Развернуть ветку
Ivan Komskyy

Ребят всех денег не заработаешь))) Тим лидство это работа с людьми - а это подставы ваших коллег и горящая ваша жопа за 30% выше зп))

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

Тут каждый должен решить сам для себя готов ли он брать ярмо на себя за большие бабки или хватает и так, зато нервам спокойнее;)

Ответить
Развернуть ветку
Sam Beckett
Автор

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

Ответить
Развернуть ветку
Сергей Добрицкий

А разве не все руководители между молотом и наковальней)))?

Ответить
Развернуть ветку
Санжар

Я часто слышал мнение, что выгоднее работать Senior разработчиком (в плане затрат и того что эти затраты дают), чем расти дальше в тимлиды, потому что прибавка не настолько ощутимая, это действительно так или в этом плане все лучше?

Ответить
Развернуть ветку
Sam Beckett
Автор

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

Ответить
Развернуть ветку
Ivan Komskyy

Вот согласен на 100%

Ответить
Развернуть ветку
Бабка в засаде

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

Ответить
Развернуть ветку
Sam Beckett
Автор

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

Ответить
Развернуть ветку
Олег Миронов

Похоже самое интересное было в пункте 5..

Ответить
Развернуть ветку
Sam Beckett
Автор

Кстати ценное замечание, спасибо! Действительно при переносе текста пятый пункт где-то потерялся. Сейчас добавил его, для полноты повествования )

Ответить
Развернуть ветку
Юзер Юзерович

"Cиндром самозванца несколько месяцев" - так это немного.
Надеялся на "много букв", к сожалению подробностей нет, хотя это и не habr.

Ответить
Развернуть ветку
Sam Beckett
Автор

Не хотел особо растягивать статью, тк было непонятно будет ли тут кому-то вообще это интересно, ресурс все же не айтишный.
А каких подробностей хотелось бы?

Ответить
Развернуть ветку
Fletcher Christian

За что разрабов увольняете?

Ответить
Развернуть ветку
Sam Beckett
Автор

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

Ответить
Развернуть ветку
Fletcher Christian

Как долго вы это терпели?

Ответить
Развернуть ветку
Sam Beckett
Автор

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

Ответить
Развернуть ветку
Путник

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

Ответить
Развернуть ветку
Sam Beckett
Автор

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

Ответить
Развернуть ветку
Путник

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

Ответить
Развернуть ветку
Sam Beckett
Автор

Это был не супер топовый разработчик )

Ответить
Развернуть ветку
Юзер Юзерович

Хотелось бы прочитать описание пути (становления) с неудачами и успехами. Плюсы и минусы этого выбора. Можно и не на этом ресурсе.

Ответить
Развернуть ветку
Сергей Добрицкий

Поддерживаю

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