Ещё некоторое время назад существовало представление, что разработчику необходимо идти в менеджеры, чтобы продолжить рост по карьерной лестнице. К счастью, времена изменились. Сейчас квалифицированный технический специалист ценится, как правило, выше менеджера среднего звена. Но какой-то процент разработчиков всё равно перестаёт «работать руками» и идёт управлять людьми.
Такой переход может иметь два неприятных последствия. Во-первых, в лице разработчика индустрия теряет ценный технический опыт. Во-вторых, она получает неквалифицированного управленца.
Это, конечно, грубое обобщение. Но фактом остается то, что у разработчика и менеджера различные профессиональные и личностные критерии, порой прямо противоположные.
Хорошо, а если технарь хочет расти дальше, каков для него потолок?
Ответ, который сразу приходит в голову, — Chief technology officer или технический директор. Но есть и другая, менее известная, альтернатива. Это VP of Engineering.
Попробуем разобраться, чем эти две роли отличаются.
Chief technology officer
Если вкратце, то это роль для гика. Им может стать самый умный разработчик в компании. Но, что важно, он должен уметь разговаривать на языке бизнеса.
Очень часто CTO участвует в процессе продаж или получения инвестиций. Тогда его роль — убедить покупателя или инвестора в том, что техническая часть будет сделана на должном уровне. Под управлением CTO может работать небольшая команда.
Если говорить об управленческих функциях в терминах PAEI по Адизесу, то желательный минимум будет выглядеть как p-Ei.
То есть, прежде всего, у CTO должно быть развито чутьё, каким образом можно использовать технологии для реализации различных идей (E). Далее он должен уметь «продать» свои идеи партнёрам, а в идеале и клиентам (i). После этого ему нужно закатать рукава и самостоятельно или с помощью небольшой команды создать прототип, MVP или даже сырую версию продукта (p).
VP of Engineering
В этой роли специалист отвечает за найм, обучение, процессы, успешное выполнение проектов. Это прежде всего менеджер, а не технарь. Он включается в работу стартапа или компании, когда CTO перестает справляться с организационными вопросами.
По Адизесу требования для управленческих функций для этой роли можно описать как pa-I.
Среди личностных качеств в приоритете умение вести за собой и договариваться с большой группой людей (I). Далее — способность наладить рабочие процессы (a). Плюс необходимо уметь выполнять работу своих сотрудников (p), чтобы обеспечить эффективное обучение и менторинг.
Идеальная ситуация, когда в компании есть сильные CTO и VP of Engineering. Теоретически один человек может выполнять обе роли, но результат будет предсказуемо хуже. Невозможно одинаково хорошо поддерживать технологическое лидерство и при этом обеспечивать быстрый рост и функционирование рабочих процессов.
Карьерный путь
К каждой из этих должностей ведут свои ступеньки роста. Следующая диаграмма указывает возможные карьерные пути для разработчика.
Естественно, это очень условная схема, отражающая некие обобщённые сценарии. В разных компаниях могут быть свои особенности и названия ролей.
Возможна ситуация, когда роль CTO не имеет смысла. Например, в крупной аутсорсинговой компании, которая предоставляет множество разноплановых сервисов. В этом случае следует вести речь о различных подразделениях, в которых кто-то должен задавать технологический вектор. Эту роль выполняют Solutions architects.
Очень часто говорят, что нужен CTO, однако по набору требуемых компетенций видно, что необходим именно VP of Engineering.
Путь к VP of Engineering — это фактически путь управленца, который остается технарём. Важным этапом является позиция Team Leader, на которой разработчик и получает буквально все необходимые навыки для движения вверх.
Резюме
Разработчик может оставаться технарём и при этом дорасти до руководителя высшего звена двумя различными путями. Чтобы выбрать правильный вектор, разработчик должен решить, что его больше привлекает — создание технологий или команд.
*Мнение колумнистов может не совпадать с позицией редакции.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.