Школа выживания технического руководителя в мире бизнеса

Александр Ложечкин руководит информационными технологиями в Райффайзен Банке. На конференции для C-level в IT South HUB 2024 Александр выступил с докладом о взаимодействии бизнеса и технического руководителя.

В этой статье мы собрали главные тезисы:

Существует устойчивая, но ложная дихотомия между IT и бизнесом. Считается, что IT — это творческий процесс, где нужна не только квалификация, но и вдохновение, и где трудно планировать. Бизнес же воспринимается как сфера скучных и занудных людей, часто с жёстким бэкграундом, которым нужен чёткий план, метрики и строгое выполнение задач.

На самом деле, ситуация напоминает знаменитую цитату Черчилля, что англичане и американцы — два народа, разделённые одним языком. Этой фразой можно описать взаимодействие IT и бизнеса. Мы говорим на абсолютно разных языках, хотя думаем, что понимаем друг друга.

Хороший технический руководитель — это человек, который свободно владеет и языком технологий, и языком бизнеса. Для меня Agile — это не карго-культ с методологиями Scrum, SAFe, Kanban и стикерами на флипчартах. Agile — это отсутствие барьеров между IT и бизнесом. Важно, чтобы эти две команды работали вместе как одна, независимо от методологии и инструментов, которые они используют.

Четыре ключевые компетенции любого технического руководителя или CTO:

Важность технических навыков часто переоценивают. Сам CTO — потому что любит быть лидером. Руководители — потому что хотят похвастаться на рынке заслугами своего технического директора. А участникам команды хочется поработать с гением в своей области. Но на самом деле CTO не может не учитывать «не айтишные» интересы стейкхолдеров. Бизнесу нужно, чтобы техдир думал о клиентском опыте. Подчинённым же ещё важна атмосфера в команде и условия работы.

С одной стороны, техническим руководителям не хочется заниматься организационными задачами. Ведь они кажутся скучными и неинтересными. С другой стороны, менее технически подкованные люди отлично справляются с управлением и организацией. Это проблема «быть или казаться». Если первые не развиваются всесторонне, то вторые обходят их по карьерной лестнице.

Сформулировал пять принципов, которые помогут крутому техническому специалисту комфортно чувствовать себя в кресле начальства.

Бен Хоровиц, автор книги «Как строить культуру в компании», верно подметил: доверие определяет эффективность коммуникации. Чем больше доверия, тем меньше понадобится слов. Доверие нельзя попросить или потребовать, его можно только долго строить: быть предсказуемым и понятным, говорить о намерениях, слушать и понимать других людей, не обманывать. Репутация создаётся годами, а разрушается за минуты.

Однажды, в период моей работы в Microsoft, на групповом звонке с руководством я позволил себе открыто обсуждать моего непосредственного начальника. Мне казалось, что он не присутствует на встрече, однако он всё слышал. Отношения были испорчены, и я сделал два вывода. Во-первых, в деловых отношениях не стоит рассчитывать на приватность. Во-вторых, лучше не держать камень за пазухой и говорить в лицо.

Интуитивно представляется, что меньше обещать и больше делать — это путь к доверию. Закрытость кажется признаком серьёзности и авторитета. Мы считаем, что экспертиза в технологиях достаточна для укрепления репутации. Однако ошибки — это не страшно, это часть процесса развития. Избегать их — значит не учиться и не расти. Важно признавать промахи открыто, вместо того чтобы искать виноватых. Это подход, который на самом деле укрепляет авторитет.

Управлять ожиданиями — значит не стоять до конца на своём, а уметь «переобуться», оценивая ситуацию в динамике. Открытость — ключ к доверию. Чем более открыты мы, тем больше нам доверяют.

Мое любимое высказывание Фридриха Ницше: «Тот, у кого есть зачем жить, может выдержать любое как». В бизнесе это сводится к понятию Vision — осознанному ответу на вопрос, зачем мы всё это делаем.

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

Лучший способ нарисовать будущее — общение с клиентами. В Amazon есть установка working backwards from customer needs. Понимая потребности клиента, технический руководитель сможет не только придумать, но и оформить своё видение так, чтобы вдохновлять команду. Дальше понадобится спланировать путь к общей картинке будущего и воплотить план в жизнь. Vision without execution is hallucination.

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

Я пришёл в Райффайзен Банк в 2021 году и собирался быстро написать техническую стратегию. 2022 год внес свои коррективы, создание документа постоянно откладывалось. Работали по принципу «Нас невозможно сбить с пути, нам всё равно куда идти». Позже стало понятно, что даже в условиях неопределённости нужно формулировать стратегию. Больше я не повторю такую ошибку.

Люблю высказывание Дуайта Эйзенхауэра: «Планы бесполезны, но планирование обязательно». Скорее всего, какой бы классный план вы ни нарисовали, он вскоре потеряет актуальность, потому что ситуация изменится. Но, пока вы пишете этот план, вы ответите на множество важных вопросов и обсудите массу проблем.

Планировать тяжело, а действовать по плану ещё сложнее. Agile изобрели программисты, чтобы избежать жёсткого планирования. Но реальный бизнес и клиенты не могут обойтись без этого. Если вы делаете что-то материальное, вам необходимо думать о производстве за год до запуска. Даже если вы создаёте что-то виртуальное, но вовремя не забронируете рекламные площадки, то не сможете эффективно продвигать продукт.

Искусство технического руководителя — сочетать чёткие планы и творческую работу. Невозможно спланировать подвиги или изобретение чего-то гениального. Руководитель должен научиться балансировать между крайностями.

Распространенное заблуждение: в программировании планирование невозможно, поэтому только Agile, только хардкор. На самом деле, это сложно, но возможно. Просто необходимо создавать открытый, прозрачный и понятный план. А затем управлять его реализацией, балансируя между объемом работы (scope), временем (time), стоимостью (cost) и качеством (quality).

В начале моей карьеры, работая над первой версией DocsVision, я пообещал выпустить продукт 1 июля и запланировал мероприятие с участием заказчиков. Уже к 1 января было понятно, что сроки нереальны, но я боялся признать провал. В результате мы работали в режиме овертайма и всё равно пришли к катастрофическому провалу 1 июля. Вместо того, чтобы признать очевидное и предложить изменения, я пытался компенсировать недостатки плана чрезмерной нагрузкой. Так делать нельзя.

Бизнес очень любит KPI, OKR, метрики и цели. Классическая цитата Питера Друкера «what gets measured, gets managed» подчеркивает: если вы хотите чем-то управлять, надо это измерять. Проблема в том, что программирование трудно измерить, так как это творческий процесс.

Из теории метрологии известно, что не существует неразрушающих или бесплатных измерений; все измерения требуют ресурсов. Важно оценивать, что больше — польза от произведённых измерений или их стоимость.

Измерять можно только повторяющиеся процессы, но в творческой работе каждое действие уникально и непредсказуемо. Поэтому я пришёл к выводу, что нужен разумный минимум измерений. Желательно, чтобы полученные результаты не влияли на систему мотивации, так как она может убивать творческий процесс. Если вы поставили метрику в систему мотивации, то ваша организация будет накручивать показатели, даже если эта метрика не полезна.

Моя ошибка была в том, что я думал: нормально считать показатели в программировании невозможно. И убеждал всех вообще ничего не измерять. Но применять метрики нужно, при чём делать это по-умному. Как минимум — предложить измерять по DORA. А в идеале — искать баланс между input и output метриками. Input метрики измеряют усилия и процессы, а output метрики — результаты.

Современные технические руководители учатся измерять, сколько денег заработал бизнес, сколько клиентов пришло и другие подобные показатели. Это единственный способ не считать строчки кода. Хорошо, что этим никто уже не занимается. Но всё ещё существуют люди, измеряющие количество мерж-реквестов на одного программиста или количество выкаток в прод в единицу времени. Чтобы не теряться в мелочах, важно взять на себя ответственность за бизнес-результаты.

Эндрю Гроув заметил в книге High Output Management: «Как мы коммуницируем — это не как хорошо мы говорим, а как хорошо нас слышат и как хорошо нас понимают».

Отправитель всегда несёт ответственность за коммуникацию — это трудно принять, но без этого невозможно обойтись. Важно понимать, что вас воспринимают именно так, как вы передаёте информацию. Поэтому, чем яснее и короче вы выражаете свои мысли, тем лучше они воспринимаются. Мой приём — сосредоточиться на трёх ключевых идеях в любом сообщении, чтобы они остались в голове получателя после встречи.

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

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

Помните короткометражку «Семь красных линий»? В ней заказчики ставят задачу с противоречивыми условиями. Технический специалист доказывает, что сделать это невозможно. Зритель на его стороне: он явно единственный вменяемый персонаж.

Со временем бизнес и технологии научились слышать друг друга. Даже нерешаемая задача из видео не пугает современных специалистов — я легко нагуглил как минимум три разумные трактовки.

В реальности технический руководитель не растеряется в мире бизнеса, если соблюдёт эти пять условий:

Посмотреть запись доклада можно на YouTube-канале South HUB. А чтобы послушать доклады вживую и познакомиться со спикерами и участниками, приезжайте на следующий South HUB — кэмп для C-level в IT, который пройдёт в июне 2025 года. Следите за новостями кэмпа в телеграм-канале.