Первые 30 дней в качестве CTO

Будучи признанным техническим директором (CTO), имея частичную занятость в качестве технического директора в пяти разных компаниях, а также являясь бывшим техническим директором, работающим уже на полную ставку в трех разных стартапах, и, наконец, как человек, который в настоящий момент руководит агентством по разработке программного обеспечения и запускает свои собственные продукты, я могу с уверенностью сказать, что в течение первых 30 дней работы в качестве CTO у вас не будет времени на шутки.

Я расскажу вам, как извлечь максимум пользы за это время…

Проявите инициативу

Вам стоит понять, что вас наняли, чтобы вы несли ответственность за выполняемую работу. Раньше я ждал поддержки от команды или CEO, чтобы меня ввели в курс дела. Теперь же я не жду, а просто беру инициативу в свои руки. Меня наняли для того, чтобы я выполнял свою работу, и именно от меня зависит в каком направлении поплывет этот корабль. Например, организуйте ланчи с командой в неформальной обстановке и без промедлений планируйте выездное развлекательное мероприятие. 

Определяйте паттерны, элементы дисфункции и ведите подробные записи. Будьте Шерлоком Холмсом и начните распознавать, что люди на самом деле подразумевают под своими словами. Прислушайтесь к тому, о чем шепчутся люди вокруг… Я знаю, что это ужасно, но вам придется играть в эту игру.

Если у членов вашей команды есть какие-либо недостатки, вам нужно знать о них СЕЙЧАС, прежде чем вы встанете у штурвала.

СОВЕТ ОТ ПРОФИ: делайте записи. Создайте систему показателей для каждого из ваших подчиненных и начните определять, какие у них цели и насколько они в этом преуспели.

Задавайте вопросы «Почему, Что, Как и Кто»

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

Вопрос «Почему?»

Почему мы создаем именно этот продукт? Поговорите с руководителями компании. Узнайте какое у них видение. Чаще разговаривайте с продакт-менеджерами, и поймите, на каком этапе они находятся. Будьте с ними по-настоящему честны. Дайте им знать, что ваши отношения крайне важны для достижения успеха этой компании.

Ошибка очень многих компаний заключается в том, что продакт-менеджеры и руководители отдела технологий обвиняют друг друга в недочетах. В прошлом мне удавалось избегать этого хаоса благодаря объединению отдела по продукту и отдела по технологиям в один технологический отдел. Хотя многие терпеть не могут эту стратегию, она полностью оправдала себя в компаниях, с которыми я работал. В вашей компании может не быть такой гибкости и возможности объединения, поэтому вам лучше всего работать в согласии с командой по разработке продукта.

Несколько вопросов, которые вы можете задать:

• Почему мы создаем этот продукт?

• Почему этот продукт найдет отклик у наших клиентов?

• Почему он важен для рынка?

• Почему именно наша команда подходит для создания этого продукта?

• Почему кто-то другой не создал этот продукт до нас?

• Почему нас воспринимают всерьез?

• Почему люди готовы работать день и ночь для реализации этой идеи?

• Почему наши коллеги доверяют нам быть лидерами?

Советы:

• Узнайте о каждом проекте, которые планирует реализовать ваша компания.

• Узнайте о всех текущих проблемах, с которыми сталкивается команда по разработке продукта.

• Распишите все цели на год, шесть и три месяца и проанализируйте стратегии на эти периоды.

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

Вопрос «Что?»

После того, как вы получили ответы на вопрос “Почему”, пора переходить к следующему вопросу “Что?”. Что именно мы создаем? Узнайте о каждой составляющей вашего флагмана. Если вы начинаете с нуля, пора перейти к чертежной доске и определить, что мы пытаемся создать.

Сильно не мудрите. Цель состоит в том, чтобы НЕ переусердствовать. Достаточно будет нарисовать на доске несколько блоков, чтобы мы понимали, что мы создаем.

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

Несколько примеров вопросов “Что?”, которые вы можете задать:

• Что мы создаем?

• Что из себя представляют подсистемы?

• Что является основным направлением развития этой системы?

• Что из себя представляет минимально жизнеспособный продукт (MVP)?

• Что именно в нашем продукте будет вызывать удивление у клиентов на ежедневной основе?

• Что мы предприняли для измерения соответствия продукта рынку?

• Что не дает тебе уснуть по ночам? Что НЕ работает?

• Что из себя представляет процесс приема на работу?

• В чем заключается процесс утверждения нашего продукта?

• В чем заключается процесс разработки программного обеспечения?

• Что есть процесс управления релизами?

• В чем заключается процесс управления изменениями?

• Что из себя представляет общение в нашей команде?

• Какие из процессов работают действительно хорошо?

Вопрос «Как?»

Когда вы получили ответы на вопросы “Почему?” и “Что?”, переходите к вопросу “Как?”. Здесь все вращается вокруг процессов.

• Как мы строим наш флагманский проект?

• Как мы будем его внедрять?

• Как мы собираемся выходить на рынок?

• Как мы объединяем все наши команды для реализации подсистем, которые мы определили, когда отвечали на вопрос “Что?”?

• Как обстоят дела?

• Как мы можем стать лучше?

• Как мы измеряем успех/неудачу?

• Как мы празднуем наши победы? (И ДА — если вы этого не делаете, вам нужно изменить политику)

• Как мы автоматизируем процессы?

• Как не изобретать велосипед заново?

• Как мы относимся к нашим партнерам/поставщикам?

• Как мы работаем с нашими партнерами/поставщиками?

• Как часто мы делимся своим видением с командами?

• Как часто мы взаимодействуем с окружающим нас техническим сообществом?

• Как мы позиционируем наш продукт?

• Каков уровень согласованности технического отдела с остальными?

Я мог бы продолжать и продолжать еще долго, но суть вы уловили…

Вопрос «Кто?»

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

Для растущих компаний я очень рекомендую книгу “Traction” Джино Викмана (Gino Wickman). В ней говорится о том, как подобрать нужного человека на подходящую ему должность.

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

Вы уверены, что люди в вашей команде “Понимают”, “Хотят” свою работу и “Довольны ее результатом” ?

Вы уверены, что остальные отделы (по крайней мере, те, с которыми вы взаимодействуете) также “Понимают”, “Хотят” свою работу и “Довольны результатом”? Вы не можете изменить направление развития других отделов, если эти моменты не совпадают. Однако очень важно, чтобы вы постоянно расставляли плюсы и минусы в столбцы “Понимают”, “Хотят” и “Довольны результатом” для всех членов команды, с которыми вы работаете.

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

СОВЕТ: Вот почему я обычно не работаю CTO на полную ставку, если только я не являюсь владельцем акций с очень высокой долей участия. Я отказываюсь работать в компаниях, где я не могу влиять на решения в других отделах или где другие отделы имеют слишком большое влияние на CEO, в то время как техническое руководство не может влиять на решения. Если вы разбираетесь в продуктах, продажах, маркетинге, технологиях и лидерстве, вам также следует серьезно задуматься над этим.

Вопросы “Кто?”, на которые у вас должны быть ответы:

• Кто тот человек, который понимает все подсистемы?

• Кто работает здесь дольше всех? (СОВЕТ ОТ ПРОФИ: сходите вместе с ним на ланч)

• Кто тот человек, который поднимет трубку посреди ночи, если что-то пойдет не так?

• Кто тот человек, к которому прислушивается CEO? Хорошо это или плохо, но с этим человеком нужно дружить.

• Кто на самом деле главный? Сюрприз… вы поймете, что ваш CEO не всегда является главным, даже если его все заставляют думать, что это так.

• Кто проявляет наибольший оптимизм в отношении этой компании?

• Кто наиболее пессимистичен в своих взглядах?

• Кто управляет DevOps?

• Кто является ведущим/главным архитектором?

• Кто отвечает за прием на работу?

• Кто отвечает за утверждение бюджета? СОВЕТ ОТ ПРОФИ: подружитесь с ними. Вам это пригодится.

Повторюсь, я мог бы продолжать и дальше… но вы меня поняли.

Теперь, когда вы разобрались в положении дел, пора сделать следующее.

Переварите все

Не торопитесь. Вы только начали свою работу. Ваши первые 30 дней работы не изменят направление развития компании, и от вас этого не ждут.

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

Увидимся через 30 дней.

Материал подготовлен в рамках курса «Microservice Architecture».

Всех желающих приглашаем на бесплатное demo-занятие «Паттерны декомпозиции сервисов». На открытом уроке мы разберем разные подходы к декомпозиции микросервисов: Monolith first, разбиение по агрегатам, по бизнес-возможностям, функциональную модель и разбиение по транзакциям. Немного поговорим про Event storming, BDD/User story, а также рассмотрим подходы к описанию сервисов.
>> РЕГИСТРАЦИЯ