Когда я впервые занял должность CTO, я думал, что моя сильная сторона — глубокое знание кода — будет главным преимуществом. Оказалось, что это почти не важно. Первые три месяца я потратил на попытки писать код вместо того, чтобы строить стратегию, и это стоило команде потерянного времени и моего собственного выгорания. Мне пришлось признать, что CTO — это не senior-разработчик с большей зарплатой, а человек, который отвечает за технологические решения на уровне бизнеса.
Нажать чтобы Перейти на сайт
Первым делом мне пришлось научиться говорить на языке бизнеса. Раньше я измерял успех проектов количеством закрытых задач и временем от коммита до деплоя. Теперь мне нужно было объяснять инвесторам, почему мы выбираем микро-сервисную архитектуру, и показывать ROI от миграции в облако. Я записался на курсы по управлению проектами и основам финансов, чтобы перестать пугаться терминов вроде burn rate и unit economics.
Второе, что я усвоил, — это найм и управление людьми. Как разработчик, я привык работать сам или в паре. Как CTO, мне нужно было строить команду с нуля, выстраивать процессы код-ревью, онбординга и оценки производительности. Я понял, что хороший CTO — это в первую очередь лидер, который умеет мотивировать людей, а не тот, кто знает все фреймворки. Я изучал книгу Рэнди Кона «Системный дизайн» не для себя, а чтобы давать своим инженерам правильные архитектурные задачи и не лезть к ним в код.
Третий урок — приоритизация. В роли разработчика у меня был бэклог задач от тимлида. В роли CTO я сам определяю, какие проекты делаем, а какие откладываем. Первые полгода я пытался взяться за всё: и новый продукт, и рефакторинг легаси, и автоматизацию тестирования, и переход на новые технологии. В итоге ничего не было закончено. Мне пришлось научиться говорить «нет» и объяснять команде, почему мы откладываем их любимые проекты.
Узнать подробнее →
Четвёртое — это безопасность и комплаенс. Как разработчик я думал о безопасности только на уровне SQL-инъекций и XSS. Как CTO мне нужно было отвечать за GDPR, за хранение персональных данных, за доступ к серверам и за инциденты безопасности. Однажды мы пережили утечку данных, и мне лично пришлось разбираться с регуляторами. С тех пор я регулярно прохожу курсы по информационной безопасности и слежу за требованиями законодательства.
Пятый, пожалуй, самый болезненный урок — эмоциональная отстройка от кода. Мне было тяжело смотреть, как мои решения в области технологий влияют на бизнес-метрики, и ещё тяжелее было признавать ошибки. Раньше ошибка была багом, который можно было зафиксировать. Теперь ошибка — это потерянные деньги, недовольные клиенты и репутационный риск. Я научился рассматривать свои технические решения как инвестиционные решения с понятным риском и горизонтом окупаемости.
Что вы считаете самым сложным при переходе от разработки к управлению технологиями? Есть ли у вас собственный опыт перехода в руководители — расскажите в комментариях.
По теме советую почитать: Как мы перестали выгорать на SRE-дежурствах: ротация, алерты, постмортемы
Нажать чтобы Перейти на сайтПервым делом мне пришлось научиться говорить на языке бизнеса. Раньше я измерял успех проектов количеством закрытых задач и временем от коммита до деплоя. Теперь мне нужно было объяснять инвесторам, почему мы выбираем микро-сервисную архитектуру, и показывать ROI от миграции в облако. Я записался на курсы по управлению проектами и основам финансов, чтобы перестать пугаться терминов вроде burn rate и unit economics.
Второе, что я усвоил, — это найм и управление людьми. Как разработчик, я привык работать сам или в паре. Как CTO, мне нужно было строить команду с нуля, выстраивать процессы код-ревью, онбординга и оценки производительности. Я понял, что хороший CTO — это в первую очередь лидер, который умеет мотивировать людей, а не тот, кто знает все фреймворки. Я изучал книгу Рэнди Кона «Системный дизайн» не для себя, а чтобы давать своим инженерам правильные архитектурные задачи и не лезть к ним в код.
Третий урок — приоритизация. В роли разработчика у меня был бэклог задач от тимлида. В роли CTO я сам определяю, какие проекты делаем, а какие откладываем. Первые полгода я пытался взяться за всё: и новый продукт, и рефакторинг легаси, и автоматизацию тестирования, и переход на новые технологии. В итоге ничего не было закончено. Мне пришлось научиться говорить «нет» и объяснять команде, почему мы откладываем их любимые проекты.
Узнать подробнее →Четвёртое — это безопасность и комплаенс. Как разработчик я думал о безопасности только на уровне SQL-инъекций и XSS. Как CTO мне нужно было отвечать за GDPR, за хранение персональных данных, за доступ к серверам и за инциденты безопасности. Однажды мы пережили утечку данных, и мне лично пришлось разбираться с регуляторами. С тех пор я регулярно прохожу курсы по информационной безопасности и слежу за требованиями законодательства.
Пятый, пожалуй, самый болезненный урок — эмоциональная отстройка от кода. Мне было тяжело смотреть, как мои решения в области технологий влияют на бизнес-метрики, и ещё тяжелее было признавать ошибки. Раньше ошибка была багом, который можно было зафиксировать. Теперь ошибка — это потерянные деньги, недовольные клиенты и репутационный риск. Я научился рассматривать свои технические решения как инвестиционные решения с понятным риском и горизонтом окупаемости.
Что вы считаете самым сложным при переходе от разработки к управлению технологиями? Есть ли у вас собственный опыт перехода в руководители — расскажите в комментариях.
По теме советую почитать: Как мы перестали выгорать на SRE-дежурствах: ротация, алерты, постмортемы