@romanpostovalov
Developer

Как из Team Lead вырасти до CTO?

Всем привет!

У меня такой вопрос, мое резюме неплохо работает на вакансии в качестве Team Lead, но когда я отправляю на должность CTO, прохожу несколько успешных этапов технического собеседования и перед основателями компаний, но на последнем этапе решение принимают не в мою пользу.

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

Как вы считаете как пройти этот этап становления CTO? На что сделать упор, какие новые знания, умения и навыки стоит приобрести?

Буду благодарен любым советам, личному опыту, как подавать себя правильно на эту позицию и расти.

С Уважением,
Роман
  • Вопрос задан
  • 1469 просмотров
Решения вопроса 2
voidnugget
@voidnugget
Программист-прагматик
Нужно
1. Хорошо понимать как масштабировать приложения, как вертикально так и горизонтально. Как на запись так и на чтение. Внедрять различные наукоемкие вещи по потребности.
2. Понимать недостатки всех существующих решений и как их можно разрешить. Как правило 80% всего-всего - банальный CRUD, и в большинстве случаев это тонны копи-постного кода аля "одна табличка - один контроллер" без 3-4 нормальной формы модели БД. Со стороны браузеров тоже очень много нюансов. Нужно понимать все эти проблемы, некоторые из них пытаться решить - привлекать людей и создавать новые проекты и сообщества.
3. Поддерживать реюзабельность, относительно простую поддержку и внедрение всех компонентов системы, внедрять SOA с хорошим покрытием тестами, не пренебрегая профилированием, фаззингом и нагрузочными тестами. Профилировать всё и вся нужно уже с самого начала работ.
4. Правильно расставлять приоритеты и производить детальную выработку всех требований. Очень много времени в пустую тратится из-за неправильно сформулированных требований и плохо подобранные инструменты.
5. Понимать как мотивировать существующий персонал, пытаться понять что побуждает людей к работе и какие у них внутренние цели, как правило деньги людей не мотивируют. Относится ко всем как к "ослам и морковке" очень глупо.
6. Понимать возможные когнитивные искажения и психологические компенсаторные процессы у существующего руководства и коллектива, быть ключевым звеном на пути к их разрешению.
7. Правильно делегировать свои собственные полномочия - иногда на всё это вас не хватит, нужно давать возможность другим решать все вышеописанные вопросы и проявлять инициативу.
8. Нанимать и работать с людьми которые заинтересованы в развитии и перспективах вашего продукта, а не просто "делать что скажут за деньги" - так вы не сможете построить действительно конкурентоспособный продукт.
9. Вдохновение не вечно - люди не смогут постоянно делать одно и тоже, нужно понимать что программисту лучше чувствовать себя художником нежели мясником в цеху рыбообработки.
10. Понимать что названия должности не должны решать как будет работать коллектив - люди должны быть взаимозаменяемы, и они должны уметь анализировать и предлагать варианты решения задач для других. Чем больше мнений - тем точнее сформулированы требования и подобраны инструменты. Зацикливаясь на специализации и должностях - ваш BusFactor всегда будет 1-2, и в сложную минуту это сыграет злую шутку с вами и вашим коллективом.

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

А вообще дело обстоит так что 80% проектов работают без вменяемого руководства и индивидуального подхода, не имеют жизнеспособной бизнес-модели и MVP, часто продают вакуум, плодят "грибных менеджеров" и "менеджеров-чаек".

Стоит разобраться с существующими антипаттернами и находить их на текущих местах работы, искать пути их разрешения и пытаться объяснить почему подобная деятельность деструктивна.

p.s. мне предлагали CTO, но на практике все обстоит так что организовывать всё-всё приходится с нуля без каких либо гарантий нормального сотрудничества.
Ответ написан
pi314
@pi314
Президент Солнечной системы и окрестностей
Прежде всего, нужно определиться с терминологией. СТО, это, собственно, не столько должность, сколько роль в организации, и ее интерпретация, к сожалению, бывает очень разной. Грубо говоря, от "это чувак, ответственный за снижение стоимости IT и прогулы программистов/админов", т.е. эдакий староста группы придурковатых гиков в свитерах и джинсах, и до "это чувак, от стратегических решений которого зависит наше будущее", т.е. ключевая фигура, на уровне СЕО или безопасника :) Соответственно, от кандидата могут ожидаться совершенно разные качества.

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

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

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

Так что могу посоветовать начинать не с резюме, а с определения собственного представления о должности СТО, на которую лично Вы хотели бы попасть, а потом просто поискать работодателя с таким же пониманием. Тогда вопросы, что конкретно написать в резюме, сказать на собеседовании или какие скиллы подтянуть, прояснятся сами собой.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
@onepavel
Консультация и разработка мобильных приложений
Я думаю смотрят на то, работал ли кандидат на данной позиции.
Т.е берут человека с уже имеющимся опытом.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы