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

В IT часто случается, что должность тимлида предлагают просто самому хорошему разработчику, либо тому разработчику, который дольше всех работает в компании. "Слушай, кажется, ты всё знаешь, как тут устроено. На тебе коллектив, руководи". Обычно это приводит к результатам, отличным от идеальных. Мне посчастливилось пройти другим путём: с какого-то момента я сознательно подыскивал тимлидскую должность. В этой статье я опишу те метаморфозы, которые происходят с опытным разработчиком, когда он, наконец, попадает в тимлидское кресло. А также, что это вообще такое: быть тимлидом в быстро растущем стартапе.

Предыстория

Вообще, IT – не первая моя сфера деятельности. И в прошлой профессиональной жизни я успел поруководить небольшими коллективами: например, группой сопровождения в клиентском бизнесе в компании-распространителе "Консультант+". Поэтому некоторые знания об управлении людьми и процессами у меня были. Собственно в IT на различных программистских должностях я 12 лет, от верстальщика до ответственного за фронтенд в различных крупных и не очень компаниях. Для части программистов бесконечный путь совершенствования лежит в плоскости разработки: новые фреймворки, новые алгоритмы. Я понял, что хочу вырасти вертикально и поруководить командой. Тем более что за годы работы накопились наблюдения за моими тимлидами: некоторые из них были хорошими, другие нет (те самые "лучшие программисты"). В голове сложился некий портрет "идеального руководителя". Нет, пусть не идеально, но просто хорошего. А если критикуешь – предлагай сам, ещё лучше – показывай делом.

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

И тут наконец пришла пора снова менять работу. Хорошая с точки зрения IT компания "Утконос" фактически развалилась, и все мы, разработчики и руководители, получившие без дураков отличный опыт на современных стеках разработки, полетели в разные стороны (учитывая политическую обстановку, многие полетели в прямом смысле: в Армению, Казахстан, Турцию, Киргизию, Вьетнам и дальше). Мне помогли мои соцсети, я даже не открывал резюме на HH.ru, просто засветил скромное объявление среди знакомых. Мой социальный капитал помог – было много откликов, в том числе от двоих друзей, мол, приходи на тимлидскую позицию. 

Я пособеседовался и в одном месте, и в другом, понравился и там, и там. У меня в кармане два офера: от компании-стартапа поучаствовать в запуске отраслевого маркетплейса (сама компания имеет достаточный опыт в бизнесе, которым занимается, но IT-направление начала серьёзно развивать только сейчас) и от госкомпании, которой нужно развивать цифровой проект в сфере науки. Опущу все перипетии, связанные с моим окончательным выбором, но в итоге я оказался в первой компании. Сильный отраслевой игрок, бизнес среднего размера, который хочет быстро повысить свою позицию в онлайне и для этого запускает маркетплейс. Вот я тут!

Куда я попал

Когда-то внуки меня спросят: дед, а что такое время перемен? И я тогда, медленно раскуривая трубку и покачиваясь в кресле, смогу рассказать, что это такое.

Ты увольняешься из прошлой IT-компании в самый разгар мобилизации, когда мужчин натурально вылавливают возле метро. Устраиваешься в новую IT-компанию, быстро оформляешь отсрочку от армии. В отделе разработки, где ты теперь тимлид, до условно 1-ого числа было только три разработчика, а теперь вместе с тобой, новыми разрабами, QA и девопсом вас 9. С техдиром, который на первых порах часто по делу влезает во все процессы, 10. Одновременно с тобой в компанию устроились два бизнес-аналитика. За неделю до тебя в компанию пришёл тот самый техдир, твой непосредственный начальник, который только начал вникать в хозяйство. Со стороны бизнеса также много новых людей, они приходят буквально все в течение недели-двух. Бизнес-процессы практически не отстроены, никаких формальных правил нет, есть только способ взаимодействия условно "вась-вась", с помощью которого старые сотрудники построили успешный, но не очень большой бизнес. Всё с колёс, всё с людьми, половина из которых едва знают друг друга и видятся по большей части в Зуме.

В основе решения для маркетплейса сторонняя "коробка", которая сама ещё содержит кучу багов и просто недоработок, и с которой параллельно работает её компания-разработчик и их команда. А, и главное: маркетплейс запускается под Новый год, то есть у тебя на всё про всё есть 3 месяца, даже чуть меньше. Ну и понятно, что текущий сайт и остальные сервисы компании тоже нужно поддерживать, а там есть свои баги с историей и требования к доработке. К тебе периодически обращаются люди, которые говорят: "Слушай, нам полгода назад обещали тут поправить, и до сих пор не сделано". Полной картины взаимосвязи этих старых сервисов между собой нет, наверное, ни у кого в компании, и надо узнавать эту информацию в режиме свободного поиска.

Выйти из зоны комфорта

Нормальное такое начало для карьеры тимлида? Все мои представления о том, что я умею чем-то и кем-то управлять, сметены. Я полностью разбит, каждый вечер просто падаю без сил на кровать. Мой рабочий день сильно больше положенных 8 часов: в день одних только синхронизаций по Зуму от 6 до 8, фактически часов 5 в день я говорю-говорю-говорю. И слушаю. Скоро заболело горло, как у профессиональных педагогов. Естественно, синдром самозванца: я пока не очень понимаю бизнес, в который пришёл. Я не знаю языка, на котором написан бэкенд. Я не программировал на Vue, с помощью которого написан фронт. Мне не очень нравится Bitbucket, и я никогда с ним ранее не работал, имел дело только с Gitlab и GitHub. Вероятно, для тех двух программистов, которые тут работают полтора-два года и которые написали большую часть кода, я просто какой-то чудик, которого почему-то поставили ими руководить.

Четыре помощника

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

Конфликты

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

Первый конфликт у меня случился сразу, со своим подчинённым. Он давно в компании, написал практически весь фронтенд. И он себе на уме. У него на всё есть своё мнение. Он в центре мира, главные слова для него – "я" и "мне". Нет, он относительно крепкий профессионал, и знает своё дело, но не командный игрок. Привык работать с бизнес-сущностями "от и до", а тут пришёл какой-то дядя, который нарезает таски и спрашивает про сроки их исполнения. С товарищем у нас – у меня, у техдира, у гендира – были свои разговоры, в которых он сетовал, как неправильно всё устроено, а мы объясняли, что при резких переменах неизбежны трения, но это временно. Мне даже на какое-то время стало казаться, что он принял моё понимание стиля работы в команде и следует новым правилам. Но... что-то в очередной раз его тригернуло, в офис пришло по почте заявление об увольнении, и мы расстались. В его сознании я, видимо, навсегда буду придурком, который всё сломал. В моём сознании это просто человек, который не может принять изменения и ушёл искать для себя более комфортную среду. Это естественно. И главное для тимлида, что нужно понимать насчёт конфликтов, это то, что они не должны затрагивать тебя лично. Конфликт – часть процесса. Не желай зла людям, но старайся добиваться рабочих целей. Кто-то уйдёт, а кто-то более подходящий – придёт.

Проактивность

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

Общение

Как уже сказано выше, в первый месяц у меня бесконечные совещания. Ты постоянно спрашиваешь, объясняешь, споришь, уточняешь. Навыки говорения и слушания прокачиваются очень сильно и очень быстро. Приехал в офис (иногда мы собираемся в офисе для крупных встреч в компании или обсуждений с моим руководством). Видишь, идёт руководитель соседнего отдела. В течение прошлой недели он ставил на твою группу таски, в которых просил исправить то, что уже давно обещали. Ты быстро вник в суть тасок и понимаешь, что нет примерно 50% информации, которая нужна, чтобы хотя бы начать что-то делать. Если ты программист, ты, наверное, снова нырнёшь в код, ещё позадаёшь вопросы, просто подождёшь, пока кто-то что-то разузнает. Или проблема рассосётся сама собой.

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

Самоуверенность

Вообще считается, что это плохое качество. Во всяком случае, самоуверенные люди не склонны видеть свои ошибки. И всё же, почему самоуверенность? – Ответ такой. Если посмотреть трезвыми глазами на то, во что я ввязался в начале октября, то самый верный вывод – это просто не взлетит! По классическим представлениям, невозможно за три неполных месяца собрать несколько больших команд, допилить чужое решение, раскатить своё, и чтобы это всё заработало в проде на клиентах, которые платят многие миллионы и десятки миллионов. Чтобы верить в это, участвовать во всём этом и не убежать на второй офер, нужно быть достаточно самоуверенным. Только своей наглостью перетаскиваешь сам себя за волосы над всеми пропастями. И хорошо, что не ты такой один: все коллеги-руководители отделов живут перед запуском маркетплейса примерно с таким же самоощущением.

Адаптация прошла 

Через какое-то время, 4-5 недель, я вдруг обнаружил, что чувствую себя в новой роли органично. Проработаны все те новые обстоятельства, о которых написано выше. Уже совершенно естественно вести за день по 5-6 рабочих совещаний, быть постоянно проактивным и подлаживаться под других людей сходу, не раздумывая, как это сделать.

Но далее появляются новые препятствия, когда начинается собственно тимлидская работа.

Ты сам – узкое место

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

Например, в моём случае (я сейчас использую послезнание, это читинг) надо было в один момент взять и настроить стенды: dev, qa, preprod. Не то чтобы они у нас совсем отсутствовали, но работали криво. К сожалению, в компании вовремя не появился нужный человек с компетенциями, который смог бы разгрести этот участок работы, настраивать пришлось самим. Но потеряв слишком много времени на малоосмысленную возню и ловлю багов. Изначальные инвестиции в этот участок работы – скажем, "все разработчики на неделю бросают всё и только делают стенды" – окупились бы даже на отрезке в 3 месяца. Надо помнить, что твоё тимлидское время стоит дорого, и когда ты тащить мелочёвку на себе и не занимаешься основными обязанностями руководителя, его потеря мультиплицируется на всю команду. 

Очень важно, кого ты нанимаешь

Одна из основных обязанностей руководителя – набирать нужных людей в команду. Ключевое слово "нужных". Став тимлидом, я понял, что стал смотреть на процесс найма по-другому. Вообще, на Хабре написано очень много статей по поводу найма, но почти все глазами программиста: кому какие задания дают, какие странные вопросы спрашивают, как обещают или не обещают перезвонить. Где-то справедливо ругают HR за формальный подход к делу. Где-то жалуются на слишком долгий или слишком непонятый процесс принятия решения.

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

Правда. Не нужно каких-то выдающихся знаний в области алгоритмов, комбинаторики или владения последними версиями фреймворков: этому можно со временем научиться. Не нужен даже выдающийся интеллект и умение с ходу щёлкать задачки на нестандартное мышление: если этого нет, можно компенсировать усидчивостью. Но если человек способен планомерно трудиться на постоянном уровне и добиваться тех результатов, за которые он принял ответственность на себя, – всё, я такого беру! К сожалению, с ходу отличить такого человека от лоботряса и проходимца возможно не всегда. Советы тут самые общие: изучайте людей, их психологию, присматривайтесь к тем коллегам, которые уже есть, смотрите, какие проявления могут иметь позитивные и негативные черты характера. Наконец, читайте хорошую художественную прозу: Чехов, Достоевский и Брэдбери могут стать вашими отличными советниками в деле поиска нужных людей.

Спустя два месяца после вступления в должность уволил ведущего фронтенда. Вот так получилось в моей команде: один фронт ушёл сам из-за своих неадекватных ожиданий, второму пришлось указать на дверь. Не скажу, что решение далось легко: всё-таки до запуска проекта оставался ещё месяц. Нового, даже с аутсорса, включить в проект и посвятить во все тонкости было нереально. То есть пришлось собственно фронтендерскую работу тащить на себе: благо, я сам в недавнем прошлом senior. Но всё же, почему потребовалось взять и уволить? – Человек оказался прямо-таки антиподом понятия "хороший работник". Наняли его ещё до меня, он мне достался как есть. Пришёл как senior. Но на 3 дня работы сеньором у него выходило две недели работы джуном: то он забыл одно важное условие, то он совсем не прочитал постановку задачи и написал красивый, но бесполезный код. То, казалось, он вовсе загулял и занялся своими делами. На такого нельзя положиться. Совершенно непонятно, как планировать его работу. Неизвестно, сделает ли он свой объём работы до запуска проекта или испортит своим разгильдяйством результат всей команды. Как можно быстрее избавляйтесь от таких людей: любой в вашей команде, и программист в том числе, в первую очередь работник, и только потом творческая и неповторимая личность. Командная работа требует организованности и слаженности, без них у вас постоянная головная боль, а у компании в целом ресурс, часто не отвечающий требованиям всего бизнеса.

Отношения с руководством

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

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

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

Смена парадигмы

Примерно в середине трёхмесячного срока реализации нашего проекта у основателей компании вдруг появилось чувство, что он пошёл немного не по тем рельсам. Это и плюсы, и минусы работы небольших компаний, а также стартапов: с одной стороны, демократичность и владельцы всегда на связи, они переживают за продукт. С другой – они же могут принять быстрое решение, если их бизнес-чуйка говорит, что надо что-то менять, и это может идти вразрез с планами команд. Не скажу, что новая парадигма сильно изменила ход развития проекта, речь шла больше об организационных моментах. Но будучи тимлидом, нужно было сделать две вещи. Первое – как можно быстрее лично принять изменения. Кодер может уйти в лёгкую депрессию, если его код выкидывают в корзину или просят существенно изменить. Но если ты отвечаешь за работу других людей, такой привилегии у тебя нет. И второе: нужно грамотно донести суть изменений до команды. Найти такие слова, чтобы, с одной стороны, тебя самого не посчитали балаболом, который не помнит, что говорил ещё вчера. С другой, добиться, чтобы коллеги приняли новые правила. Короче, сыграть неким демпфером.

Проект запустили, что дальше?

Вот, наконец, настала заветная дата: проект выходит в прод! Получилось это немного криво, немного косо, словили изрядно багов, но в целом всё удалось. Были сказаны всевозможные добрые слова снизу вверх и сверху вниз, выданы премии. Настало время выдохнуть и успокоиться? – Как бы не так!

Выдохнуть, конечно, нужно: на новогодних каникулах я полностью забыл, что такое работа. Элементарно привёл свой организм в порядок, вернул его в трудоспособное состояние после 3-месячного марафона перед запуском. А потом настало время перестраивать работу в команде.

Дело в том, что срочный проект неизбежно искривляет привычные практики: где-то нужно спрямить угол и вмерджить код в develop без должного тестирования. Где-то задача поставлена слишком творчески, и разработчик быстрее делает её на костылях, так как закономерно предполагает, что скоро нужно будет переделывать. Наконец, ты чаще обычного включаешь микроменеджмент, и твои подчинённые стараются к этому приноровиться: кто-то больше нервничает, а кто-то просто включает солдата Швейка.

Нужно заново строить планомерную работу. Больше грумить, больше декомпозировать. Больше обсуждать, меньше торопиться. Думать сначала об архитектуре решения, а уже потом о том, что мы покажем бизнесу на ближайшем прогоне. Хоть это вроде как и возврат к нормальной для IT работе, но нужно осознанно отказываться от вредных привычек, которые ты вынужденно приобрёл в погоне за самым главным результатом – запуском проекта в срок. Задача тимлида – в тои числе вырабатывать тот стиль работы, который наиболее адекватен ситуации. Плохо оставаться заложником однажды сложившихся обстоятельств, команда должна уметь меняться вслед за потребностями всей компании. Этот процесс, естественно, требует совершенно осознанных усилий её руководителя.

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