Каково быть CTO (Chief technology officer) или техническим директором? Пожалуй, одна из самых высоких ступеней развития инженера. Насколько становится жизнь прекраснее в такой должности? Как раз об этом я сегодня и хочу поговорить.
В начале хочу отметить, что всё очень субъективно и зависит от компании. Я расскажу о своём опыте в относительно небольших компаниях и стартапах. Конечно, у многих опыт может отличаться.
В самом начале у меня не было толпы инженеров, которыми надо управлять, мне пришлось собирать команду самому. Я сразу окунулся в найм сотрудников, распределение бюджета и организацию рабочего пространства и прочее.
Что движет человеком, когда он стремится на эту должность? Одним из факторов могут быть деньги, но тут не всё однозначно. Если посмотреть на Москву и Петербург, то зарплаты очень классных инженеров могут быть выше директорских. То есть деньги далеко не решающий аргумент. Например, лично для меня это было возможностью по-другому влиять на разработку. Если раньше от меня зависело качество кода и самого продукта, то с приходом на новую должность степень влияния значительно расширяется: появляется возможность управлять бюджетом и выбирать глобальные технические решения, мотивировать команду и организовывать весь рабочий процесс. Всё это даёт возможность быстрее достигать целей, выбирать стратегии развития и методологии для компании.
Я подметил такой факт, что если раньше, когда я был разработчиком, эффект от моей работы был заметен почти сразу, максимум после спринта, то теперь должно пройти не менее трёх месяцев, а чаще требуется минимум полгода, чтобы увидеть результаты. Зато куда ярче факапы — обычно они заметны сразу и всем. Да и обходятся компании в разы или даже на порядки дороже, чем ошибки рядовых инженеров, аналитиков или даже проджект менеджеров.
Момент моего становления в новой должности был наполнен силой и энтузиазмом. Был боевой настрой, хотелось всё переделать. Но это была типичная ошибка неофита. Казалось, что всё работает не так, надо переписать и починить. Чем крупнее компания или сложнее проект, тем сильнее кажется, что больше проблем. Но на практике покопавшись во всём этом, начинаешь остывать — не всё так просто и однозначно, как кажется на первый взгляд.
Вроде как вы хотите всё исправить и сделать лучше, но натыкаетесь на стену непонимания со стороны команд. Они это видят так: пришёл какой-то реформатор, целыми днями занимается какой-то фигнёй, внедряет там что-то, не даёт писать код, а ведь работало же всё нормально.
Дальше я постепенно погружался в работу CTO, думал, что вот оно, счастье: полный контроль над разработкой, принятие решений, наконец можно делать именно так, как считаешь лучше. А не как тот начальник с прошлой работы. Но вместе с этим в довесок прилетают и другие не очень интересные обязанности: распределение бюджета, ФОТ (фонд оплаты труда), бытовые проблемы, найм людей и многое другое.
Когда я только стал CTO, то не представлял, о многих обязанностях. Например, требуется ещё один инженер в команду. Вам надо донести до HR, какой именно специалист нужен, что он должен уметь. Также у вас есть устоявшийся ФОТ, и вам надо как-то выкроить зарплату новому сотруднику и не превысить бюджет. А потом надо следить за рынком, чтобы его не схантили конкуренты. При этом ошибки могут иметь печальные последствия, если плохо оценишь его, он может уйти и ещё потом рассказать всем, какой ты козёл. А если ещё и некуда его посадить, арендовать новый офис? А туда ещё надо будет закупить мебель и установить кондиционеры и т.д.
Если раньше для вас все ресурсы появлялись чудесным образом, как в игре из ящика брались бюджеты на сервер, какие-то продукты и прочее, то CTO добывает их сам. Надо ходить «на ковёр», защищать свои решения и пытаться объяснять, что сейчас нужно для разработки. При этом вы просто обязаны доказывать прямую пользу для бизнеса.
Когда требуется принимать стратегические решения, то оказывается, особенно на первых порах, что не всегда хватает знаний. В этот момент понимаешь, что надо качать скиллы во всех областях знаний, причём срочно.
Отдельно стоит сказать про длину рабочего дня. У меня сложилось впечатление, что оно растёт вместе с должностью. Если инженеры сидят по 8 часов и иногда задерживаются, то на позиции CTO находиться на связи с 8 до 23 стало нормой. Ещё иногда звонят по выходным, а в виде бонусов звонят, когда ты в отпуске. И вроде ты шёл на пляж, но сидишь за ноутом в номере и что-то делаешь. При этом 70–80% рабочего времени занимают совещания, встречи, переписка и решение проблем. Только в остальное время ты пытаешься сделать что-то полезное.
Думал, что буду заниматься вещами, связанными только с управлением разработкой, но на деле приходится общаться со всеми: от охранников до топ-менеджеров. Со всеми техническими проблемами шли ко мне.
Мне иногда нужно было вести переговоры с крупными компаниями типа Auto.ru или Avito. Там было крайне важно не ударить в грязь лицом и показать, что вы представляете серьёзную компанию.
Но случается и наоборот: как-то начальство отправило на переговоры с партнерами, вроде (ключевое слово) договорились, что я встречусь руководителем отдела разработки. В итоге приехал в другой город, оказалось, что меня никто не ждёт, начальник отдела вообще уехал на другое совещание. Чтобы поездка не была совсем бесполезной, пришлось как-то налаживать контакт с их разработчиками. Рассказать, что мы хотим, да и вообще добиться, чтобы они просто тебя слушали, стало той ещё задачей. В итоге кое-как разговорил их, еле выкрутился, получив нужную информацию и уладив принципиальные технические вопросы.
Дальше — больше трэша. Ездил в другой город, чтобы обсудить технические моменты интеграции другой компании с нашей системой. Приезжаю, а там оказывается, что это семейный подряд. Меня встретила микрокомпания, даже без офиса. Беременный аналитик, главный разработчик в майке-алкоголичке, по квартире бегают дети, и во время обсуждения вокруг меня летает говорящий попугай.
Когда ты разработчик, то думаешь, что было бы круто что-то переписать с использованием новой технологии или заюзать крутую СУБД. Теперь это работает по-другому: о каждой новой идее ты думаешь в иной плоскости, а именно, как это «продать» начальству. Например, вы захотели какую-то часть сервиса переписать с PHP на Go. Для начальства это пустой звук, на который нельзя тратить ни копейки. Ведь гендир мыслит другими категориями — сроками и бюджетом. Поэтому ходить к нему без сроков и ресурсов и просить реализовать какую-то идею — гиблое дело. Ты учишься сам сразу представлять, как это поможет бизнесу. Если какое-то технологическое решение не позволит бизнесу больше продать или сэкономить, то план заведомо провальный. Плюс в голове надо держать возможные риски реализации. Ибо если что-то пойдёт не по плану, то по голове получаешь именно ты.
Теперь вопрос баланса бизнеса и разработки стоит ещё острее. В любую задачку добавляется ещё одна важная переменная — стоимость решения. При этом технические аспекты никуда не пропадают, перекос в сторону бизнеса тоже вреден. Техдир должен осознавать, насколько это решение удачно в перспективе, будет ли конкретная технология развиваться и поддерживаться в будущем, каков порог входа в неё, по зубам ли она инженерам текущей команды или надо идти мониторить рынок и нанимать новых. Тут как раз и пригодится технический бэкграунд. А если CTO вырос из менеджера и не знает разницы между Java и JavaScript? Увы такое тоже бывает, и это печально.
CTO так и живёт между Сциллой и Харибдой. С одной стороны «голодные» до крутых технических решений программисты, с другой — бизнес, который хочет максимально экономить на разработке и не может ждать, пока запиливаются фичи. Первые постоянно хотят внедрить что-то новое или переписать старое, а вторые требуют ускорения разработки и снижения риска. Надо не обидеть инженеров и не облажаться перед начальством.
Без компромиссов никуда. Иногда откровенные костыли помогают делать хорошие продажи. Тогда они оправданы, и разработчикам приходится мириться с ними. А иногда приходится перед начальством «продавливать» какие-то решения и выбивать на них бюджет, чтобы сэкономить в будущем.
Также сталкивался с тем, что вроде наладил какой-то процесс и перестал его мониторить. Вроде всё должно идти хорошо, но должного эффекта нет. На деле сотрудники могут просто забивать на что-то. Я понял, что надо следить за всеми процессами и не отпускать вожжи. А если и отпускаешь, то надо быть на 300% уверенным, что этим кто-то будет заниматься, и всё будет идти по плану.
Отдельно хочется осветить ещё один момент. В должности техдира вы уже не пишете код, вся работа сводится к выбору решений и распространению знаний среди тимлидов, которые в свою очередь занимаются обучением рядовых инженеров. Естественно, навык программирования теряется. Даже если на позиции CTO и не требуется писать код руками, то всё равно надо разбираться в технологиях. Поэтому надо как-то успевать следить и за этим, читать книги, слушать доклады. Если в чём-то плохо разбираешься, то инженеры могут понять это и подкинуть какую-нибудь фигню, типа «начальник дурак, значит прокатит». Ещё бывает, когда вам проще что-то сделать самому руками, а не пытаться объяснить проблему команде и добиться от них решения. Это заканчивается плохо, люди могут перестать стараться и сесть на шею.
Вроде совсем недавно ты работал программистом или тимлидом и ходил пить пиво с ребятами по пятницам, а вот ты уже дорос до CTO, а они превратились в твоих подчинённых. И кто-то из них приходит к тебе: «Братан, а подними мне зарплату». Тут личные отношения начинают мешать, возникает некоторая неловкость. В таких ситуациях надо корректно себя вести. Если человек жёстко накосячил, то может и стоит лишить его премии.
Надо отстаивать свой авторитет, но и не быть тираном, то есть нужен адекватный баланс. Да, теперь есть генеральские погоны, но ты не можешь взять и что-то сделать, потому что взбрело в голову. Демократией в таком случае и не пахнет. И любить вас после этого никто не будет.
Многое, как мне кажется, должно держаться на доверии. Поэтому повторюсь, нужно внимательно относиться к обещаниям. В противном случае кредит доверия падает, это в конечном итоге приводит к негативным последствиям. Причём этот принцип должен одинаково работать как в сторону разработчиков, так и бизнеса. Например, обещал поднять зарплату, но бюджет урезали. Приходилось правдами и неправдами выбивать другие бонусы и плюшки. Лучше не давать пустых обещаний, а то будут считать пустозвоном, репутацию сложно будет отмыть.
Раньше у нас был бравый парень, который защищал тебя от всего, а теперь защиты нет, потому что этим бравым парнем стал я. И ещё ни в коем случае нельзя показывать, что тебя расплющивает от проблем. Если это будет проявляться внешне, то негатив мгновенно почувствуют рядовые сотрудники. А это уныние и отравление рабочей атмосферы. Сейчас ты отвечаешь за каждый чих.
Когда сильно косячишь, надо уметь признавать это. По своему опыту, скажу, что надо уметь собрать всех, встать на табуретку и сказать: «Коллеги, я облажался». А если к этому добавляешь: «Но я знаю, как это исправить», то это уже воспринимается нормально, и уважение со стороны ребят растёт. Да и люди будут относиться к этому с пониманием.
Как ни странно, количество вакансий на позицию СТО довольно большое. Но их обычно не размещают на hh и подобных ресурсах, чаще всего техдиров ищут, ну или по крайней мере присматриваются, на конференциях или по рекомендациям знакомых. Почему? У меня нет чёткого ответа, но мне кажется, что всё дело в оценке способностей. Нельзя дать задачку и посмотреть результат, даже если она будет связана с архитектурой. CTO не пишет код. Попросить показать, как человек будет выстраивать процессы и внедрять Agile? Можно, только эффект придётся ждать полгода. Тем более, что люди часто не могут адекватно оценить положение вещей, считают, что у них всё круто, а как немного копнёшь, там хаос.
Если подумать, что компания хочет получить от специалиста? Если это разработчик, тимлид или ПМ — всё понятно. А если CTO? Конкретного перечня обязанностей нет. На самом деле есть, он должен обеспечивать работу всех перечисленных выше и нести за это ответственность. Но дело в том, что это всё очень сильно зависит от компании.
Когда искал работу, ходил по собеседованиям на позицию CTO и наблюдал такую картину. В одной компании хотят, чтобы ты по сути выполнял функции Team Leader, выстраивать процессы им не надо, хотят, чтобы ты просто писал код. В другой как раз наоборот, хотят, чтобы ты занимался исключительно процессами, всякая архитектура им не нужна. Третьей нужен управленец, на техническую сторону им плевать. В четвёртой требуется человек, который будет тестировать бизнес-идеи. В пятой хотят, чтобы технический директор помимо всего ещё и занимался продвижением и знал маркетинг. Хорошо если компании вообще понимают, что хотят получить. Есть такие, которым надо, чтобы просто всё стало хорошо.
Как-то смеялся, мне скинули тестовое задание: надо было просчитать стоимость и срок создания интернет-магазина с корзиной и витриной, руководствуясь средними рыночными ценами за разработку. В общем-то, это всё ТЗ. Я мысленно пожелал им удачи в поисках кандидата.
А ещё есть особый вид компаний с диким уровнем бюрократии, где чихнуть без одобрения пяти отделов не дадут.
Так что перед тем, как идти искать работу CTO, стоит не один раз подумать, что вы хотите. Самое главное, чтобы в компании чётко понимали, что от вас хотят. На одном из собеседований я не выдержал и спросил: «Я вижу, что вы не понимаете того, о чём меня спрашиваете. Как вы собираетесь оценивать меня?» Они ответили, что мы пару умных книжек прочитали и спросили знакомых из другого бизнеса про их техдира, такого же как у них и ищем.
Так что выбирайте основательно и с умом, в противном случае оно того может не стоить.
В заключение хочу сказать, что всё субъективно и нет правильных и неправильных решений, это зависит от многих факторов. Если обобщить всё, о чем я говорил, то я бы свёл к тому, что СТО — это тот человек, который решает все вопросы, от самых мелких до стратегически важных, работает в режиме нон-стоп, чтобы все остальные могли работать и давать результат. И чаще всего от него хотят то, с чем он ещё не сталкивался, поэтому нужны гибкость, умение подстраиваться и быстро обучаться. По крайней мере для меня эти качества оказались ключевыми. Конечно, эта работа не состоит из одних минусов. Должность CTO позволяет реализовать себя, свои амбиции,
В начале хочу отметить, что всё очень субъективно и зависит от компании. Я расскажу о своём опыте в относительно небольших компаниях и стартапах. Конечно, у многих опыт может отличаться.
В самом начале у меня не было толпы инженеров, которыми надо управлять, мне пришлось собирать команду самому. Я сразу окунулся в найм сотрудников, распределение бюджета и организацию рабочего пространства и прочее.
Для чего вообще туда идти?
Что движет человеком, когда он стремится на эту должность? Одним из факторов могут быть деньги, но тут не всё однозначно. Если посмотреть на Москву и Петербург, то зарплаты очень классных инженеров могут быть выше директорских. То есть деньги далеко не решающий аргумент. Например, лично для меня это было возможностью по-другому влиять на разработку. Если раньше от меня зависело качество кода и самого продукта, то с приходом на новую должность степень влияния значительно расширяется: появляется возможность управлять бюджетом и выбирать глобальные технические решения, мотивировать команду и организовывать весь рабочий процесс. Всё это даёт возможность быстрее достигать целей, выбирать стратегии развития и методологии для компании.
Я подметил такой факт, что если раньше, когда я был разработчиком, эффект от моей работы был заметен почти сразу, максимум после спринта, то теперь должно пройти не менее трёх месяцев, а чаще требуется минимум полгода, чтобы увидеть результаты. Зато куда ярче факапы — обычно они заметны сразу и всем. Да и обходятся компании в разы или даже на порядки дороже, чем ошибки рядовых инженеров, аналитиков или даже проджект менеджеров.
Новые обязанности — новые открытия
Момент моего становления в новой должности был наполнен силой и энтузиазмом. Был боевой настрой, хотелось всё переделать. Но это была типичная ошибка неофита. Казалось, что всё работает не так, надо переписать и починить. Чем крупнее компания или сложнее проект, тем сильнее кажется, что больше проблем. Но на практике покопавшись во всём этом, начинаешь остывать — не всё так просто и однозначно, как кажется на первый взгляд.
Вроде как вы хотите всё исправить и сделать лучше, но натыкаетесь на стену непонимания со стороны команд. Они это видят так: пришёл какой-то реформатор, целыми днями занимается какой-то фигнёй, внедряет там что-то, не даёт писать код, а ведь работало же всё нормально.
Дальше я постепенно погружался в работу CTO, думал, что вот оно, счастье: полный контроль над разработкой, принятие решений, наконец можно делать именно так, как считаешь лучше. А не как тот начальник с прошлой работы. Но вместе с этим в довесок прилетают и другие не очень интересные обязанности: распределение бюджета, ФОТ (фонд оплаты труда), бытовые проблемы, найм людей и многое другое.
Когда я только стал CTO, то не представлял, о многих обязанностях. Например, требуется ещё один инженер в команду. Вам надо донести до HR, какой именно специалист нужен, что он должен уметь. Также у вас есть устоявшийся ФОТ, и вам надо как-то выкроить зарплату новому сотруднику и не превысить бюджет. А потом надо следить за рынком, чтобы его не схантили конкуренты. При этом ошибки могут иметь печальные последствия, если плохо оценишь его, он может уйти и ещё потом рассказать всем, какой ты козёл. А если ещё и некуда его посадить, арендовать новый офис? А туда ещё надо будет закупить мебель и установить кондиционеры и т.д.
Если раньше для вас все ресурсы появлялись чудесным образом, как в игре из ящика брались бюджеты на сервер, какие-то продукты и прочее, то CTO добывает их сам. Надо ходить «на ковёр», защищать свои решения и пытаться объяснять, что сейчас нужно для разработки. При этом вы просто обязаны доказывать прямую пользу для бизнеса.
Когда требуется принимать стратегические решения, то оказывается, особенно на первых порах, что не всегда хватает знаний. В этот момент понимаешь, что надо качать скиллы во всех областях знаний, причём срочно.
Отдельно стоит сказать про длину рабочего дня. У меня сложилось впечатление, что оно растёт вместе с должностью. Если инженеры сидят по 8 часов и иногда задерживаются, то на позиции CTO находиться на связи с 8 до 23 стало нормой. Ещё иногда звонят по выходным, а в виде бонусов звонят, когда ты в отпуске. И вроде ты шёл на пляж, но сидишь за ноутом в номере и что-то делаешь. При этом 70–80% рабочего времени занимают совещания, встречи, переписка и решение проблем. Только в остальное время ты пытаешься сделать что-то полезное.
Думал, что буду заниматься вещами, связанными только с управлением разработкой, но на деле приходится общаться со всеми: от охранников до топ-менеджеров. Со всеми техническими проблемами шли ко мне.
Переговоры
Мне иногда нужно было вести переговоры с крупными компаниями типа Auto.ru или Avito. Там было крайне важно не ударить в грязь лицом и показать, что вы представляете серьёзную компанию.
Но случается и наоборот: как-то начальство отправило на переговоры с партнерами, вроде (ключевое слово) договорились, что я встречусь руководителем отдела разработки. В итоге приехал в другой город, оказалось, что меня никто не ждёт, начальник отдела вообще уехал на другое совещание. Чтобы поездка не была совсем бесполезной, пришлось как-то налаживать контакт с их разработчиками. Рассказать, что мы хотим, да и вообще добиться, чтобы они просто тебя слушали, стало той ещё задачей. В итоге кое-как разговорил их, еле выкрутился, получив нужную информацию и уладив принципиальные технические вопросы.
Дальше — больше трэша. Ездил в другой город, чтобы обсудить технические моменты интеграции другой компании с нашей системой. Приезжаю, а там оказывается, что это семейный подряд. Меня встретила микрокомпания, даже без офиса. Беременный аналитик, главный разработчик в майке-алкоголичке, по квартире бегают дети, и во время обсуждения вокруг меня летает говорящий попугай.
Баланс бизнеса и разработки
Когда ты разработчик, то думаешь, что было бы круто что-то переписать с использованием новой технологии или заюзать крутую СУБД. Теперь это работает по-другому: о каждой новой идее ты думаешь в иной плоскости, а именно, как это «продать» начальству. Например, вы захотели какую-то часть сервиса переписать с PHP на Go. Для начальства это пустой звук, на который нельзя тратить ни копейки. Ведь гендир мыслит другими категориями — сроками и бюджетом. Поэтому ходить к нему без сроков и ресурсов и просить реализовать какую-то идею — гиблое дело. Ты учишься сам сразу представлять, как это поможет бизнесу. Если какое-то технологическое решение не позволит бизнесу больше продать или сэкономить, то план заведомо провальный. Плюс в голове надо держать возможные риски реализации. Ибо если что-то пойдёт не по плану, то по голове получаешь именно ты.
Теперь вопрос баланса бизнеса и разработки стоит ещё острее. В любую задачку добавляется ещё одна важная переменная — стоимость решения. При этом технические аспекты никуда не пропадают, перекос в сторону бизнеса тоже вреден. Техдир должен осознавать, насколько это решение удачно в перспективе, будет ли конкретная технология развиваться и поддерживаться в будущем, каков порог входа в неё, по зубам ли она инженерам текущей команды или надо идти мониторить рынок и нанимать новых. Тут как раз и пригодится технический бэкграунд. А если CTO вырос из менеджера и не знает разницы между Java и JavaScript? Увы такое тоже бывает, и это печально.
CTO так и живёт между Сциллой и Харибдой. С одной стороны «голодные» до крутых технических решений программисты, с другой — бизнес, который хочет максимально экономить на разработке и не может ждать, пока запиливаются фичи. Первые постоянно хотят внедрить что-то новое или переписать старое, а вторые требуют ускорения разработки и снижения риска. Надо не обидеть инженеров и не облажаться перед начальством.
Без компромиссов никуда. Иногда откровенные костыли помогают делать хорошие продажи. Тогда они оправданы, и разработчикам приходится мириться с ними. А иногда приходится перед начальством «продавливать» какие-то решения и выбивать на них бюджет, чтобы сэкономить в будущем.
Также сталкивался с тем, что вроде наладил какой-то процесс и перестал его мониторить. Вроде всё должно идти хорошо, но должного эффекта нет. На деле сотрудники могут просто забивать на что-то. Я понял, что надо следить за всеми процессами и не отпускать вожжи. А если и отпускаешь, то надо быть на 300% уверенным, что этим кто-то будет заниматься, и всё будет идти по плану.
Отдельно хочется осветить ещё один момент. В должности техдира вы уже не пишете код, вся работа сводится к выбору решений и распространению знаний среди тимлидов, которые в свою очередь занимаются обучением рядовых инженеров. Естественно, навык программирования теряется. Даже если на позиции CTO и не требуется писать код руками, то всё равно надо разбираться в технологиях. Поэтому надо как-то успевать следить и за этим, читать книги, слушать доклады. Если в чём-то плохо разбираешься, то инженеры могут понять это и подкинуть какую-нибудь фигню, типа «начальник дурак, значит прокатит». Ещё бывает, когда вам проще что-то сделать самому руками, а не пытаться объяснить проблему команде и добиться от них решения. Это заканчивается плохо, люди могут перестать стараться и сесть на шею.
Манёвры управления
Вроде совсем недавно ты работал программистом или тимлидом и ходил пить пиво с ребятами по пятницам, а вот ты уже дорос до CTO, а они превратились в твоих подчинённых. И кто-то из них приходит к тебе: «Братан, а подними мне зарплату». Тут личные отношения начинают мешать, возникает некоторая неловкость. В таких ситуациях надо корректно себя вести. Если человек жёстко накосячил, то может и стоит лишить его премии.
Надо отстаивать свой авторитет, но и не быть тираном, то есть нужен адекватный баланс. Да, теперь есть генеральские погоны, но ты не можешь взять и что-то сделать, потому что взбрело в голову. Демократией в таком случае и не пахнет. И любить вас после этого никто не будет.
Многое, как мне кажется, должно держаться на доверии. Поэтому повторюсь, нужно внимательно относиться к обещаниям. В противном случае кредит доверия падает, это в конечном итоге приводит к негативным последствиям. Причём этот принцип должен одинаково работать как в сторону разработчиков, так и бизнеса. Например, обещал поднять зарплату, но бюджет урезали. Приходилось правдами и неправдами выбивать другие бонусы и плюшки. Лучше не давать пустых обещаний, а то будут считать пустозвоном, репутацию сложно будет отмыть.
Раньше у нас был бравый парень, который защищал тебя от всего, а теперь защиты нет, потому что этим бравым парнем стал я. И ещё ни в коем случае нельзя показывать, что тебя расплющивает от проблем. Если это будет проявляться внешне, то негатив мгновенно почувствуют рядовые сотрудники. А это уныние и отравление рабочей атмосферы. Сейчас ты отвечаешь за каждый чих.
Когда сильно косячишь, надо уметь признавать это. По своему опыту, скажу, что надо уметь собрать всех, встать на табуретку и сказать: «Коллеги, я облажался». А если к этому добавляешь: «Но я знаю, как это исправить», то это уже воспринимается нормально, и уважение со стороны ребят растёт. Да и люди будут относиться к этому с пониманием.
Поиск работы на позицию CTO
Как ни странно, количество вакансий на позицию СТО довольно большое. Но их обычно не размещают на hh и подобных ресурсах, чаще всего техдиров ищут, ну или по крайней мере присматриваются, на конференциях или по рекомендациям знакомых. Почему? У меня нет чёткого ответа, но мне кажется, что всё дело в оценке способностей. Нельзя дать задачку и посмотреть результат, даже если она будет связана с архитектурой. CTO не пишет код. Попросить показать, как человек будет выстраивать процессы и внедрять Agile? Можно, только эффект придётся ждать полгода. Тем более, что люди часто не могут адекватно оценить положение вещей, считают, что у них всё круто, а как немного копнёшь, там хаос.
Если подумать, что компания хочет получить от специалиста? Если это разработчик, тимлид или ПМ — всё понятно. А если CTO? Конкретного перечня обязанностей нет. На самом деле есть, он должен обеспечивать работу всех перечисленных выше и нести за это ответственность. Но дело в том, что это всё очень сильно зависит от компании.
Когда искал работу, ходил по собеседованиям на позицию CTO и наблюдал такую картину. В одной компании хотят, чтобы ты по сути выполнял функции Team Leader, выстраивать процессы им не надо, хотят, чтобы ты просто писал код. В другой как раз наоборот, хотят, чтобы ты занимался исключительно процессами, всякая архитектура им не нужна. Третьей нужен управленец, на техническую сторону им плевать. В четвёртой требуется человек, который будет тестировать бизнес-идеи. В пятой хотят, чтобы технический директор помимо всего ещё и занимался продвижением и знал маркетинг. Хорошо если компании вообще понимают, что хотят получить. Есть такие, которым надо, чтобы просто всё стало хорошо.
Как-то смеялся, мне скинули тестовое задание: надо было просчитать стоимость и срок создания интернет-магазина с корзиной и витриной, руководствуясь средними рыночными ценами за разработку. В общем-то, это всё ТЗ. Я мысленно пожелал им удачи в поисках кандидата.
А ещё есть особый вид компаний с диким уровнем бюрократии, где чихнуть без одобрения пяти отделов не дадут.
Так что перед тем, как идти искать работу CTO, стоит не один раз подумать, что вы хотите. Самое главное, чтобы в компании чётко понимали, что от вас хотят. На одном из собеседований я не выдержал и спросил: «Я вижу, что вы не понимаете того, о чём меня спрашиваете. Как вы собираетесь оценивать меня?» Они ответили, что мы пару умных книжек прочитали и спросили знакомых из другого бизнеса про их техдира, такого же как у них и ищем.
Так что выбирайте основательно и с умом, в противном случае оно того может не стоить.
P.S.
В заключение хочу сказать, что всё субъективно и нет правильных и неправильных решений, это зависит от многих факторов. Если обобщить всё, о чем я говорил, то я бы свёл к тому, что СТО — это тот человек, который решает все вопросы, от самых мелких до стратегически важных, работает в режиме нон-стоп, чтобы все остальные могли работать и давать результат. И чаще всего от него хотят то, с чем он ещё не сталкивался, поэтому нужны гибкость, умение подстраиваться и быстро обучаться. По крайней мере для меня эти качества оказались ключевыми. Конечно, эта работа не состоит из одних минусов. Должность CTO позволяет реализовать себя, свои амбиции,
