Кто такой CTO, как им стать и почему это не всегда венец карьеры
2026-02-21 05:54 Diff
https://skillbox.ru/media/code/kto-takoy-cto-kak-im-stat-i-pochemu-eto-ne-vsegda-venets-karery/

#статьи

  • 13 мар 2023
  • 0

Виктор Корейша — о своём пути от школьника до совладельца компании, отличиях техдира от тех- и тимлида и о том, за что нужно увольнять разработчиков.

Иллюстрация: Jason Strull / Unsplash / Wikimedia Commons / Colowgee для Skillbox Media

Фанат Free Software Foundation, использует Linux и недолюбливает Windows. Пишет истории про кодинг и программы на Python. Влюблён в Lisp, но пока что не умеет на нём программировать.

Руководитель отдела Message Bus в Ozon Tech, ведущий подкаста «Кода Кода».

Привет, я Виктор Корейша. Сейчас я возглавляю отдел Message Bus в Ozon. До этого успел побывать в роли CTO и одного из двух сооснователей веб-студии «Феникс». Занимался разработкой сайтов, программировал на нескольких языках, работал в рекламном бизнесе, в техническом руководстве нескольких крупных IT-компаний. Я автор и соведущий медиаподкаста «Кода кода». Возможно, мой опыт и мои представления об отрасли будут вам интересны.

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

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

Дальше — больше. Начал делать сайты — сперва брал готовые CMS, потом стал разрабатывать сам, пробовал разные технологии. Хотя уже тогда понимал, что это не совсем настоящее программирование — мне хотелось highload, каких-то интересных вещей, новых вызовов.

Через некоторое время устроился в компанию, где делали вещи уже совсем другого уровня. Мы занимались интернет-магазинами — там уже была серьёзная автоматизация, много товаров, большой поток заказов, взрослая логистика, сложная логика исполнения. Позже появилось тестирование, системы контроля версий — в общем, я был уже в профессии.

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

Могу выделить два этапа, когда прыгнул выше головы. Первый — переход из разработчиков в тимлиды — а я на тот момент был даже не сеньором. В лучшем случае мидлом, с большой натяжкой, или скорее очень продвинутым джуном-плюс, который всё уже прочитал, но руками почти ничего не пробовал и, в принципе, как-то может реализовать любой проект — пусть и криво-косо. И вот меня позвали руководить. «Почему бы нет?» — решил я.

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

Допустим, сам я могу написать проект размером X. А с командой — не просто 10X, а что-то гораздо крупнее, потому что её участники умеют то, чего я не умею вообще. И это само по себе потрясающе — управляя руками команды, я могу создавать проекты, которые сам бы не потянул никогда — ни по времени, ни по знаниям.

Причём в итоге я буду управлять этим проектом, словно программист кодом в IDE. Только в качестве моих инструментов — написание техзадания, процессы разработки, инженерная культура, дизайн и куча других процессов.

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

Потом это случилось во второй раз. У меня уже был больший технический бэкграунд, я умел управлять людьми. Но руководить проектом, технологическим стеком, нанимать людей — этого я не умел совершенно. Мне подвернулась возможность стать техническим директором — и я снова решил, что отказываться нельзя. И снова наломал таких дров! Но выше меня уже никого не было, у меня особо и не было вариантов. То есть я должен был строить технологический стек — я его строил.

Мне очень повезло: первые два или три человека, которых я нанял — хотя делал я это абсолютно неправильно, оказались просто замечательными ребятами, которые помогли, в том числе и в моём развитии.

Техдир — это человек, который, по сути, объединяет все перечисленные в подзаголовке компетенции.

Например, кто такой тимлид? Это человек, который эффективен как программист и пипл-менеджер, плюс он немножко занимается проект-менеджментом.

Техлид принимает решения о выборе технологии. Ему говорят: «Пора нам переходить на PHP 8?» Или: «Стоит ли использовать Grid в CSS, хотя он не везде поддерживается?» И техлид может аргументированно ответить. Или, допустим, его спрашивают: «Как бы нам организовать такую систему, чтобы микросервисы заводились и могли масштабироваться?» Он чешет репу и выносит вердикт: «Ну, давайте заведём Kubernetes».

Технический директор — это и техлид, и тимлид, и проект-менеджер. Чем он отличается от них всех? Тем, что он — последняя инстанция. Он может быть технически слабее, чем его техлид. Менее организован, чем проект-менеджер. Не идеально разбираться в пипл-менеджменте, в программировании — это всё неважно. Важно, что он принимает итоговое решение и несёт за него ответственность.

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

Первое, с чем я столкнулся, — чувство вины за то, что перестал кодить сам: «Блин, ребята работают, а я занимаюсь какой-то фигнёй, отвечаю на письма или задачки перекладываю из одной колонки в другую».

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

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

Управленцу-новичку часто кажется, что все подчинённые — его клоны: они должны выполнять задачи так же быстро, анализировать так же точно и так далее. Это полная ерунда — все люди разные.

Начнём с того, что они разного уровня: очевидно же, что бесполезно требовать от джуна того же самого, что от мидла или от сеньора. Кроме того, у каждого человека свои сильные стороны. Кто-то пишет медленнее — но зато его код лучше проходит тест или в нём сразу предусмотрена возможность расширения. Или, может быть, он пишет медленнее, но зато так хорошо понимает техзадание с первого раза, что ему ничего не приходится переделывать. У всех есть какие-то плюсы.

И эти сильные стороны нужно учиться видеть в людях. Искать нужных людей и давать им проявлять себя по полной.

Признавать их, конечно, не очень приятно. Не столько сам факт, сколько то, что ситуацию чаще всего уже не исправить.

Например, в моей биографии был момент с чисто техническим факапом, когда я вынужден был прийти и сказать: «Система, которую мы построили, до сих пор могла масштабироваться, но дальше без серьёзного рефакторинга она масштабироваться не будет. Какое-то время мы справлялись за счёт „костылей“, но теперь набралась критическая масса. Так что нам придётся либо вкладываться, либо выбросить эту систему на помойку и писать новую».

Легко заявить — вкладываться; а где взять деньги на рефакторинг? Нужно было или вытаскивать их из собственной фирмы, или идти к клиенту, каяться в своём факапе и пробовать договориться.

Ехали мы с исполнительным директором в некоторым опасении: а вдруг клиент сейчас просто встанет и больно нас стукнет? Или делегирует это каким-нибудь то��арищам из своей охраны? Пришлось включать все наши софт-скиллы.

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

В один прекрасный день я почувствовал, что мне не хватает знаний, — и начал повсюду их искать. Хорошо помню свою первую платную консультацию — она была по пипл-менеджменту. Когда шёл отдавать денежку, чувствовал себя полным дурачком, который попался на какую-то непонятную удочку и платит непонятно кому. А когда шёл обратно, чувствовал себя таким просветлённым! Мне буквально за час-полтора объяснили то, вокруг чего я месяцами вертелся, но не мог дойти сам.

Потом стал использовать тот же принцип и в технических вопросах. Не понимал чего-то — просто искал того, кто понимает, и общался с ним. Очень часто это можно сделать без всяких проблем.

Люди очень легко отвечают на вопросы. Достаточно написать какому-нибудь товарищу, имеющему репутацию классного эксперта по интересующему вас вопросу: «Привет! У меня проблема. Не посоветуешь, как её решить?»

Конечно, теоретически он может отписаться в духе: «Бесплатно только гугл консультирует». Но в большинстве случаев реакция будет такой: «Без проблем. Рассказывай, в чём твой вопрос». И если вопрос у вас конкретный, деловой, то вам, скорее всего, на него ответят.

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

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

Как показала практика, когда что-то катится само — оно однозначно катится в ад. Если ты не занимаешься сотрудниками, не проводишь one-to-one, не обсуждаешь их рост — с каждым месяцем сотрудникам работается всё печальнее.

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

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

Тогда я очень сильно пересмотрел отношение к тому, как нужно общаться с командой, как нужно развивать команду. Этот факап перед моими глазами стоит до сих пор. Я, как человек, который принимает решения, мог нанять отдельного HR, который будет с ними общаться. Мог сам проводить какие-то one-to-one. Мог ввести процесс пересмотра зарплаты раз в полгода. Но я всего этого не сделал. Просто на всё это забил. Не знал, что это важно. И отхватил.

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

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

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

Когда-то это задевало. Теперь даже не реагирую — привык))).

Увольнение людей — один из самых сложных навыков. Когда ты смотришь на ситуацию постфактум, тебе всегда понятно, мол: «Чего я тянул? Давно было пора расставаться». Но в моменте ты никогда не уверен: «А действительно ли это та самая ситуация? Может быть, я неправ и оцениваю человека необъективно?»

Абсолютно однозначные причины для увольнения действительно можно перечислить по пальцам. Понятно, что, если человек приходит в офис пьяным и начинает дебоширить, — наверное, не стоит продолжать сотрудничество. Хотя и здесь тоже есть всякие оговорки: вдруг у него раз в жизни случилась какая-то трагедия?

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

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

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

Хотя, конечно, во всех этих историях с увольнениями я ещё точно не эксперт. Мне ещё учиться и учиться. Вообще, конечно, одно из главных различий между российскими и европейскими компаниями — это «культура ошибок».

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

К таким понятиям, как «счастье сотрудника», «счастье команды», я сам пришёл не так давно — может быть, около года назад. И понял, что это одна из самых главных метрик: что может лучше, чем продемонстрировать, насколько ты крут как руководитель?

Можно измерить общий перфоманс команды. Но это очень сложно. В чём его измерять — стори-пойнтах? Они везде разные.

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

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

Человек может сидеть в регионе, работать тестировщиком за 30 000 рублей и быть совершенно счастливым. А может сидеть в «Москва-Сити» получать какие-то дикие миллионы — и быть беспросветно несчастным.

В чём же, собственно, измеряется счастье команды? Лично я задаю сотрудникам два вопроса. Первый: «Оцените по шкале от 1 до 10, насколько вы готовы дальше работать в этой должности в этой компании. 10 — „Я готов работать здесь всю жизнь“, а 1 — „Я уже написал заявление об уходе и сейчас тебе его покажу“».

Второй вопрос: «Хочется ли вам идти на работу?» Если человек не думая отвечает «да» — это для меня условно 5 баллов, если «нет» — 1 балл.

Конечно, эти цифры сами по себе ничего не значат. То есть если я заявлю: «Счастье моей команды — 8 баллов», никто ничего не поймёт. Но я оцениваю счастье конкретного сотрудника на протяжении года и вижу, что в первом квартале у него было 5, потом 6, потом 8 — я понимаю, что мы движемся в правильную сторону. Для этого конкретного человека мы создали более приятные условия.

Если вы — технический директор, это ещё не значит, что жизнь удалась. В моём случае я был главным технарём в небольшой компании, рост которой не мог быть взрывным: я бы сильно удивился, проснувшись однажды утром и увидев, что мы на том же уровне, что Google или даже «ВКонтакте». А мне хотелось чего-то большего.

Хотя уходить было долго и сложно. С одной стороны, если порвать резко, то точно навредишь команде. Но если тянуть бесконечно — можно и вовсе никогда не уйти. Думаю, я нашёл лучший вариант и остался в роли играющего тренера, неким внешним консультантом.

Опыт «самого умного в комнате» помогает не бояться ответственности. А то, что я научился получать внешнюю экспертизу, — помогает получать её и в других ролях.

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

Мой путь в этом направлении был долог и тернист. В какой-то момент я решил вести блог на замечательном движке «Эгея» от Ильи Бирмана и команды неравнодушных. Стал постить какие-то мысли — но читали их примерно 10 человек, которым я лично скидывал ссылочку. Сейчас перечитываю свои статьи пятилетней давности — некоторые мне хочется удалить, а некоторые я даже и удалил.

Пытался писать в соцсетях. Тоже не увенчалось особым успехом. У меня есть статья на «Хабре»; эта история закончилась тем, что моя карма ушла в глубокий минус. Пробовал в Open Source удариться. Думаю: «Блин, сейчас сделаю какую-нибудь опенсорсную штуку, все увидят мою фамилию, и я стану известным и знаменитым». Спойлер: не стал.

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

Когда перешёл ко второму, понял, что хочу транслировать не только точку зрения своих спикеров — я хочу ещё и свою высказывать! Причём не просто как ведущий — хотелось, чтобы со мной спорили, чтобы меня притормаживали, приводили в адекват. В общем мне нужен был оппонент. Я посмотрел на гостей первого сезона, выбрал тех, с кем мне было легко, комфортно, от кого я действительно получил какую-то пользу, — их было несколько. Откликнулся Женя Антонов, и мы стали вести вместе.

Хочу порекомендовать «Тимлид Очевидность» — канал моего соведущего Жени Антонова. Мне кажется, что вещи, которые он там пишет, — супермастхэв, особенно для начинающих тимлидов.

Из других Telegram-каналов посоветую «Записки из горящего дома», которые ведёт топ-менеджер «Яндекса» Анастасия Абрашитова. Мне кажется, это тоже совершенно потрясающий и сильно недооценённый контент.

Ещё я слушаю подкасты. Мне нравятся «Запуск завтра» и «Потом доделаю». Очень нравится «Подлодка», потому что там целый букет: конференции, обучения, движухи.

Хотя, если вы хотите изучить конкретную технологию, — нет способа лучше, чем фигачить на этой технологии. Если не получается на основной работе — сделайте pet-проект. Не выходит сразу начать pet-проект — откройте Codewars, выберите язык, который вы хотите учить, — и попробуйте порешать какие-то простые алгоритмические задачки.

Возможностей применить язык миллиард. Или даже не язык, а какой-то конкретный фреймворк, библиотеку — всё что угодно. Просто берите и пробуйте — никакого другого способа вообще не существует.

Бесплатный курс по Python ➞
Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу