Из бэкендера в CTO, минуя корпорации: личный опыт
Привет! Я Мусали Генжеханов, СТО в компании 05.ru. Расскажу о том, как предпочёл офферу мечты путь джедая в Махачкале и почему решил развиваться внутри одной компании.
Геймер = хакер
Мой путь в IT был довольно типичным. С детства любил компьютерные игры, поэтому у нас в городе все считали меня хакером. Потом стал тем, кто может переустановить винду на старом ноуте. А позже — студентом Дагестанского государственного технического университета.
После армии три месяца поработал разработчиком у друга в веб-студии и сделал свой первый проект на Python — переводчик с национальных языков Дагестана на русский. Так я понял, что нужно развиваться именно в этой сфере. Это был 2013 год.
Вообще, в 05.ru у меня было первое «настоящее» собеседование, причём пришёл я на сисадминскую вакансию. Провалил его в той части скиллов, которые были актуальны для сетевого инженера, и ушёл домой в полной уверенности, что второго этапа точно не будет. Через неделю мне позвонили и пригласили на другое направление: стажёром в разработку, и я ухватился за этот шанс.
Мог ли я уехать, например, в Москву? Скорее нет, чем да. Знаю ребят, которые приняли такое решение, но меня на тот момент останавливали несколько причин. Во-первых, ещё не было того кадрового бума, когда корпорации стали пылесосить рынок, предлагая заоблачные зарплаты. Во-вторых, оставалось рабочим правило «больше рынок — больше конкуренция». Таких джунов, как я, в Москве десятки тысяч со всей страны. И если я не мог найти работу в Дагестане, с его не очень высокой конкуренцией, то на трудоустройство программистом в столице особых иллюзий не строил. В-третьих, я чувствую связь с родной землёй, с близкими мне людьми — родственниками, друзьями. Мне здесь комфортно, я хотел бы делать что-то важное для своей малой родины. Чтобы уменьшить пафос, признаюсь: да, и страшно было тоже.
С корабля на прод
В 2013 году 05.ru уже была лидером ритейла в регионе с командой 200+ человек. Я попал в open space, где было ощущение бесконечной движухи: тут разработчики, там маркетологи, здесь менеджеры. Все говорят, звонят, друг к другу ходят, что-то обсуждают. И тут с краю я — в свой первый рабочий день собираю себе компьютер, чтобы начать на нём работать. Какой ментор? Какой бадди? Некому было со мной разбираться.
В тот момент у компании наглухо упал сайт (посыпались HDD, признайтесь, с вами тоже такое бывало), поэтому все занимались тем, чтобы экстренно зарелизить его новую версию. Я ворвался в эти процессы без паузы на раскачку. Было очень стрессово, но, с другой стороны, такое начало сильно меня забустило. Пришлось на реальных задачах очень быстро соображать, выявлять и решать проблемы сырого релиза.
Если смотреть на то, как велась разработка тогда, появляется ощущение романтического хаоса. Проекты умещались в голове каждого члена команды, поэтому мы дружно читали документацию, писали код, могли подхватить разработку любых блоков. Короче, все разбирались во всём.
Кризис, который изменил компанию и меня
В 2019 году, незадолго до ковида, по рынку HR мощным пылесосом прошёлся один из наших конкурентов. Они хантили разработчиков на зарплату х3. Всего за месяц наш отдел практически перестал существовать: ушли многие, в том числе и руководитель отдела. Получилось, что я оказался одним из тех, у кого был и опыт, и глубокое понимание того, чем занимается компания.
В этот момент ко мне подошёл генеральный директор, и мы откровенно и честно обсудили ситуацию. В итоге договорились о важном: раз придётся создавать отдел заново, то нужен совсем другой подход. Больше никакого совмещения функций, перемешивания с сотрудниками из маркетинга, продаж или рекламы. В общем, никакого больше романтического хаоса.
У меня был выбор: пойти в другую компанию или продолжить свой путь тут. Я остался и начал развивать то, в чём у меня была экспертиза, — разработку. Я прокачался за 6 лет в компании и понял, что это возможность использовать мои знания на более высоком уровне.
Начиналось всё без стратегии, но зато я хорошо понимал продукт и то, какими инструментами его можно улучшить. Собрал все свои «боли разработчика» и пошёл к бизнесу защищать видение отдела и свои реформы. Все в компании старались преодолеть кризис, и руководство хорошо откликалось на инициативы, поэтому мы закоммитились на мой план.
На тот момент у меня уже был хороший оффер, несопоставимый по зарплате с тем, что у меня было в 05.ru. Крупная московская компания, больше денег, меньше ответственности. Но я стал взвешивать возможности в моменте. Уйдёт ещё не меньше пяти лет, чтобы дорасти до той карьерной позиции, которая у меня уже есть. Я могу прямо сейчас построить свой отдел разработки — построить так, как считаю правильным, как будет эффективно для бизнеса, в который я уже погружён. Так зачем ждать? И я остался.
Тестовая реформа
Формирование отдела я начал с тестировщиков. Их у нас не было, тестированием занимался обычно самый малонагруженный программист, а иногда и продакт. Получалось, откровенно говоря, не очень. Постоянно что-то выскакивало, и мы регулярно отвлекались, чтобы срочно починить готовый релиз.
Я решил, что хватит жить на действующем вулкане, и согласовал штат специалистов по тестированию.
Согласовать-то согласовал, но теперь их надо набрать в офис. Как водится, кандидатов не было (это сейчас миллион курсов, на которых дают базу, учат каким-то основным понятиям и методикам). Поэтому я фактически набрал себе стажёров, которых мы начали учить своими силами с нуля.
Эффект не заставил себя ждать. Мы ускорили разработку, при этом стали меньше отвлекаться на дебагинг.
Возможно, сейчас я выступлю в роли кэпа, но об этом почему-то мало говорят: тестировщики — одни из самых недооценённых специалистов на рынке. Если доверить тестирование специально обученным людям, освободившиеся ресурсы отдела разработки можно направить на приоритетные задачи — это радикально сократит время на «допиливание» готового продукта, которым уже пользуются клиенты. А ещё улучшить моральное состояние в отделе. Всё-таки тестирование — это довольно монотонная и кропотливая работа, а разработчики её откровенно не жалуют. Если бы я раздавал советы, то здесь было бы: «Не мучайте своих программистов, наймите тестировщиков».
Реформы по-взрослому
После успешного эксперимента с отделом тестирования стала очевидной несостоятельность фразы «не трогай, пока работает». У меня появились инициативные сторонники реформ внутри отдела и веские аргументы за изменения перед бизнесом.
Наш ведущий фронтенд-разработчик наконец получил возможность набрать и лидировать свою команду. С этого момента снежный ком специализированной разработки уже было не остановить. Постепенно backend-разработка отделилась у нас от frontend, сформировался отдел тестирования, появились ops/devops-инженеры, андроид- и ios-разработка.
Всё это, конечно же, имело смысл сделать намного раньше, но потребовался масштабный кризис, чтобы отдел разработки стал обособленным подразделением и начал развиваться согласно собственным болям и приоритетам.
Тогда я мыслил скорее как технарь, как человек с опытом бекэнд-разработки. Меня больше интересовала не польза для бизнеса или клиента, а скорость и качество разработки, стабильность сайта и приложения, внедрение какого-нибудь крутого фреймворка. Компания выросла, и наша реформа стала одним из факторов, повлиявших на это.
Здравствуй, удалёнка
Полномасштабная удалёнка к нам тоже пришла вместе с Covid-19. У нас уже был опыт работы с сотрудниками вне офиса, но он всегда был связан со специфическими компетенциями, которые мы не могли получить в Махачкале.
Для руководителя это стало вызовом скорее не техническим (инструментов для организации процессов достаточно), а психологическим. Нужно было как-то наладить обмен информацией, синхронизацию людей внутри команд, внутри большого отдела. Понадобились новые критерии вовлечённости, эффективности, инструменты контроля и поддержки. Если вы думаете, что ежедневный стендап закрывает большинство вопросов взаимодействия команды, то — сюрприз! — всё гораздо сложнее. Нюансов было миллион: на работоспособность влияла даже включённая на рабочих созвонах камера. Видеть собеседников на экране так же важно, как время от времени поднимать голову и окидывать взглядом open space. Видишь, что не один тут бьешься над своей задачей, здесь все вовлечены в общий результат.
Я выбрал в качестве канала коммуникации мессенджер Discord (привет из моего игрового прошлого): проработали всю его структуру, настроили рабочий сервер, добавили роли и так далее. Ну дальше всё как у всех — VPN и защищённая внутренняя сеть.
В какой-то момент мы научились разрабатывать продукты без личного присутствия в офисе. И это открыло для нас кадровый рынок IT всей страны. Сейчас, когда все снова вышли в офис, у нас около 40% удалённых сотрудников из Москвы, Санкт-Петербурга, Ростова-на-Дону, Перми, Уфы и так далее. У нас нет ограничений, недавно вот подписывал документы на трудоустройство сотрудника из Челябинска.
Часто спрашивают, насколько влияет разница во времени, если команда разбросана по нескольким часовым поясам. Если специалист справляется со своими обязанностями и может подстроить свой личный график под регулярные встречи со всей командой, то не всё ли равно, в каком он часовом поясе? Это его выбор, его способность адаптироваться под наш ритм и стиль работы. Пусть хоть в Антарктиде живёт, если ему норм.
Техдир всегда больше «дир», чем «тех»
Когда я соглашался на эту позицию, мне казалось, что я стану тем особенным руководителем, который полдня кодит, полдня управляет, таким играющим тренером. Оказалось, что это возможно, только если вы работаете в небольшом стартапе или в маленькой семейной веб-студии.
Но я пытался. Правда. Я писал код, но с каждым месяцем это было делать всё сложнее и сложнее. Элементарно стало не хватать времени, оно перераспределилось на управленческие задачи: наём, работу с мотивацией сотрудников, стратегию и оргвопросы. В какой-то момент я понял, что стал обузой для команды. Общая статистика продуктивности портилась, и я точно видел, кто виноват — я.
Да-да, я был тем самым неэффективным программистом, который брал задачи и долго не мог закрыть их. Самым важным было посмотреть на цифры и признать, что проблема именно во мне.
Собрал отдел, сказал, что так дальше не пойдёт. Сначала договорились, что ко мне будут попадать важные, но несрочные задачи. Первое время получалось что-то отрефакторить, что-то реализовать техническое, но в конце концов я понял, что нужно отказываться и от этого. Управление — отдельная работа с отдельными скилами. Вот я, к примеру, интроверт, как и многие разработчики. А теперь прокачался до экстраверта. Жизнь заставила.
Я поддерживаю техническую экспертизу на актуальном уровне. Читаю новости и профильные паблики (список ниже), могу закрыть практически любую задачу отдела, но сделаю это неоптимально по времени. Сейчас всё выстроено так, что я исполняю роль валидатора по внедряемым технологиям. Команда приходит ко мне с предложениями, мы всё обсуждаем и вместе принимаем решение.
Мотивация без принуждения
Самым сложным было научиться работе с мотивацией команды. Я проходил несколько онлайн-курсов, но они мне почти не помогли. Реально крутой оказалась книга по конфликтологии — «Ненасильственное общение. Язык Жизни» Маршалла Розенберга. Конечно, полностью применять этот фреймворк у меня не получается, но пользы в таком подходе много.
«Чтобы работать с мотивацией, представьте себя на месте сотрудника» — об этом говорится в 100% пособий и курсов. Но это получилось у меня не сразу.
Поначалу я был сторонником жёсткого стиля управления. Ну, знаете, в компании кризис, нужны быстрые и решительные действия: отличный повод проявить себя как начальник и всё такое. К примеру, приходит ко мне сотрудник и начинает на что-то жаловаться. Я его слушаю, а сам думаю: «Ну чего ты ноешь? Компании плохо, всем плохо, тебе, конечно, тоже плохо. Но мы делаем что можем — так иди и тоже делай что можешь, хватит ныть!» В общем, тогда у меня с эмпатией было не очень. Быстро выяснилось, что можно и без неё, но недолго.
Более-менее внятная работа с мотивацией начинается тогда, когда коллектив видит в тебе не начальника, не директора, не руководителя, а лидера. И понять это просто, задав себе вопрос: доверяют тебе или нет? Добился доверия — значит, твои усилия по мотивации сотрудников начинают работать.
Нанимай и доверяй
На наём я сейчас смотрю как на элемент качественного делегирования. Это не какое-то знание свыше, этому пришлось сознательно научиться. Концепция делегирования же проще некуда: раз ты не можешь все задачи делать сам, значит, их будут делать другие. Если хочешь, чтобы эти задачи выполнялись качественно, найми людей и отдай им соответствующие полномочия и ресурсы. Очень разумно, но работать начинает только тогда, когда ты заставил себя «отпустить» задачу и пресечь микроменеджмент.
Я читал много историй о том, как руководители не берут сильных сотрудников: опасаются, что те их «подсидят». Выбирая такую тактику, вы должны понимать, что становитесь машинистом, который ведёт поезд компании под откос.
Не вижу никакого смысла брать заведомо слабого сотрудника. Я же не смогу поручить ему важную работу, буду вынужден постоянно ставить задачи, контролировать, доделывать, переделывать. То есть я таким образом за деньги компании организовал бы себе дополнительную головную боль и путь к выгоранию. Зачем?
Но также считаю, что имеет смысл нанимать не просто лучших, а проактивных. Я приветствую, когда человек может самостоятельно работать, брать ответственность и предлагать что-то новое. После того как я нахожу такого хэда для команды, мне не нужно больше всё контролировать: движется там ещё что-то или уже остановилось и нужно принимать меры.
В какой-то момент у нас разросся отдел тестирования, и его возглавляет человек, который в этом разбирается лучше меня. И я не то чтобы переживаю, я считаю правильным, что тестировщики у нас максимально автономны. Взаимного доверия и моего контроля достаточно, чтобы задачи выполнялись эффективно и не отнимали много времени.
Софт-скилы кандидатов также оказались не блажью эйчаров. Принять на работу токсичного сотрудника — это очень дорого для компании. Во-первых, он демотивирует команду, которая может и разбежаться, если запустить ситуацию. А во-вторых, руководителя постоянно отвлекают жалобами, приходится непрерывно решать разнообразные конфликты. В общем, если вы уверены, что нужно нанять гения, с которым коллективу будет сложно общаться, то будьте готовы к издержкам. Сядьте и сведите баланс. Не факт, что прибыль от такого найма перекроет убытки от сопутствующего ущерба.
Хватит дорог, которые приводят куда-нибудь
Хаотичный период становления руководителя уже позади, теперь я выстраиваю более-менее внятный план развития.
В первую очередь хочу прокачать делегирование. Нужно научиться делать это более качественно. Чтобы правильно передать человеку задачу, надо чётко её описать, поставить цели, определить параметры и метрики. Много нюансов, надо учиться.
Во-вторых, меня ждёт риск-менеджмент. Это одно из направлений стратегического мышления, которое поможет принимать решения с более предсказуемыми последствиями.
В-третьих, продолжаю работать над софт-скилами. Сейчас нет-нет да и проскакивают эмоции. В рабочих вопросах это не всегда уместно.
В-четвёртых, публичные выступления. Здесь прогресс большой, но недостаточный. С командой в масштабах компании я справился, но если собирается зал на 500 человек или онлайн-конференция на 3–5 тысяч слушателей, тут мне пока сложно.
Стоило ли всё это отказа от крутого оффера? Однозначно да. Сейчас я вижу, что проделал огромный путь, построив карьеру в региональном бизнесе, и рад тому, что решился на это.
Непрошенные советы
Ресурсы, которые я использую в работе и развитии
Канал Russian Association of Software Architects
Канал Микросервисы — русскоязычное сообщество
Канал Teamlead Good Reads — тимлиды, архитектура, менеджмент людей и разработки
DDDevotion chat
ИТ-архитектура во всех её проявлениях — закрытый чат, из которого почерпнул много интересного.
Книга Изучаем DDD — помогло в контексте бизнес-мышления в некоторой степени.
Книга Высоконагруженные приложения (кабанчик).
