Конфликт между основателем и CTO: спокойный сценарий для ранних команд

Почему этот конфликт начинается так рано

Ранние стартапы живут в условиях нехватки времени, слабых процессов и большого количества предположений. Основатель видит окно на рынке и хочет двигаться прямо сейчас. CTO видит код, найм и системы, которые могут сломаться, если команда слишком сильно сократит путь. Ни одна из сторон не ведет себя иррационально, но разрыв между этими взглядами очень быстро становится личным.

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

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

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

Споры о скорости часто маскируют проблемы доверия. Когда основатель говорит: «Почему это так долго?», он может на самом деле иметь в виду: «Могу ли я положиться на твое суждение?» Когда CTO говорит: «Мы не можем продолжать менять scope», он может на самом деле иметь в виду: «Я не доверяю тому, как здесь принимаются решения». Если никто не произносит это вслух, оба продолжают спорить о сроках, а реальный ущерб нарастает под поверхностью.

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

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

Что каждая сторона считает проблемой

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

Именно поэтому разговор так быстро становится запутанным. Основатель говорит: «Мы слишком медленные». CTO отвечает: «Мы принимаем слишком рискованные решения». Оба утверждения могут быть правдой, но они описывают разные проблемы.

Основатель обычно говорит о скорости, потому что именно скорость первой начинает болеть. Срывается запуск. Клиент ждет. Конкурент выпускает что-то простое и забирает внимание. Под этим давлением основатель может не сказать: «Я боюсь, что мы пропустим свое окно». Он говорит: «Почему это так долго?»

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

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

То, что боится потерять CTO, — это власть, уважение и возможность защищать продукт от краткосрочных решений, которые создают долгосрочные проблемы. Он также может бояться стать человеком, который просто говорит «да», пока кодовая база каждую неделю становится все сложнее для изменений.

Доверие заставляет обе стороны подозревать худшее. Основатель начинает воспринимать осторожность как торможение. CTO начинает воспринимать срочность как безрассудство. Потом проблема скорости превращается в спор об ответственности, а спор об ответственности — в проблему доверия.

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

Подготовьте разговор до того, как все пойдет плохо

Большинство срывов начинается еще до того, как кто-то входит в комнату. Размытое приглашение в календаре вроде «нужно обсудить execution» дает обоим людям время собрать аргументы, подготовить защиту и вспомнить все старые раздражители. К моменту начала встречи никто уже не решает одну проблему. Все пытаются выиграть суд.

Выберите одну встречу, одну цель и одного человека, который будет принимать решение в конце. Сузьте задачу. «Нам нужны лучшие отношения» — слишком широко. «Нам нужно правило, кто может менять scope после sprint planning» — уже ясно. Если никто не отвечает за итоговое решение, тот же спор вернется на следующей неделе с новыми примерами и большим напряжением.

Задайте правила до встречи, а не во время нее. Без обвинений. Без попыток читать мысли. Без подсчета старых обид за последние шесть месяцев. Оставайтесь в рамках недавних событий, того, о чем просил каждый человек, что произошло дальше и какой была цена для команды. Если доверия и так мало, нейтральный советник или Fractional CTO может следить за временем и останавливать боковые споры.

Попросите обоих прийти с конкретными примерами. Фразы вроде «ты всегда нас тормозишь» или «ты никогда не слушаешь» никуда не ведут. Гораздо полезнее простые данные: один недавний релиз или запрос на функцию, который создал напряжение, точное решение, которое показалось поспешным или заблокированным, что каждый ожидал в тот момент, что произошло после решения и что каждый сделал бы иначе сейчас.

Так у вас появляется то, что можно проверить и исправить. И это же делает startup leadership conflict меньше, потому что разговор остается привязанным к действиям, а не к личности.

Первую встречу держите короткой. 30–45 минут достаточно для одной проблемы. После этого люди начинают складывать проблемы друг на друга, повторяться или тащить в разговор старую историю. Завершите встречу одним письменным следующим шагом, одним владельцем и одной датой, когда вы проверите, сработало ли новое правило. Этого часто достаточно, чтобы остудить конфликт между основателем и CTO, прежде чем он превратится в проблему доверия, которую почувствует вся команда.

Используйте спокойный сценарий в комнате

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

Хорошее вступление простое: «Мы оба хотим, чтобы компания двигалась быстрее, и мы оба чувствуем, что что-то этому мешает. Давайте назовем это без обвинений». Это снижает градус, потому что ставит обоих по одну сторону стола.

Держите круг узким. Основатель, CTO и один человек, который ведет заметки. Без аудитории, без переписки в Slack, без длинной подготовки. Если конфликт между основателем и CTO уже воспринимается как личный, лишние люди заставляют всех играть роль вместо того, чтобы говорить прямо.

Используйте короткие вопросы и жесткие ограничения по времени. Одной минуты каждому достаточно. Спросите основателя: «Какое бизнес-давление вы чувствуете прямо сейчас?» Спросите CTO: «Какой технический риск волнует вас больше всего, если мы ускоримся?» Потом спросите обоих: «Где решения замедлились за последние две недели?»

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

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

Финал тоже держите коротким. Не гонитесь за идеальным процессом. Выберите одно соглашение на ближайшие две недели, например: «Основатель задает приоритет до вторника 12:00, а CTO принимает решение по реализации, не открывая scope заново, если только риск не изменился». Небольшие договоренности легче соблюдать и легче проверять.

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

Разделите скорость продукта и техническую ответственность

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

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

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

Обычно работает простое разделение. Основатель решает, какая проблема на этой неделе важнее всего. CTO решает, каким самым безопасным способом это построить. Оба решают, когда дедлайн меняет scope, риск или надежность. Команда фиксирует, кто принял окончательное решение.

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

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

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

Командам часто нужна внешняя помощь, чтобы выстроить такие границы без эго. Спокойный советник или Fractional CTO может сделать это разделение нормальным, а не личным. Цель не в том, чтобы убрать напряжение. Цель в том, чтобы скорость не превращалась в спор об ответственности.

Простой пример стартапа

Лена — основательница небольшого B2B-стартапа. Demo day через девять дней, и она хочет добавить в продукт еще одну функцию: общий dashboard, который делает приложение более завершенным в живом питче.

Арман — CTO. Он уже видел, как команда за последние две недели трижды меняла направление. Каждое изменение по отдельности выглядело небольшим, но каждое ломало тесты, сдвигало другую работу и оставляло команду в догадках, что теперь главное.

В понедельник утром Лена подходит к Арману и говорит: «Нам нужен dashboard к demo day. Я уже сказала инвесторам, что они его увидят». Арман на секунду замолкает, а потом отвечает: «Если ты уже это пообещала, почему спрашиваешь меня только сейчас?»

Именно в этот момент доверие начинает проседать.

Лена слышит: «Ты никогда не двигаешься достаточно быстро». Арман слышит: «Твоя задача — разгребать мои обещания». Они уже спорят не об одной функции. Они спорят о том, кто имеет право решать и кто несет риск, если что-то пойдет не так.

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

Лена начинает снова, но уже точнее. «Я хочу, чтобы демо выглядело завершенным. Я протянула с этим до последнего, потому что боюсь, что продукт будет выглядеть слишком пустым». Арман отвечает в том же тоне. «Я заблокировал это, потому что команда уже потеряла два дня на поздние изменения. Если мы добавим это сейчас, думаю, демо станет менее стабильным, а не лучше».

Именно это меняет атмосферу. Никому не нужно защищать свой характер. Они могут решить настоящую проблему.

Они заново фиксируют ожидания простыми словами:

• Лена отвечает за цель демо и сообщение для инвесторов.
• Арман отвечает за scope, технический риск и за то, что команда успеет сделать, не сломав сборку.
• Новые запросы после среды должны быть согласованы ими обоими.
• Если они не согласны, по умолчанию выбирается более безопасный вариант для demo day.

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

В этой встрече не произошло ничего магического. Они просто перестали воспринимать скорость, ответственность и доверие как один запутанный спор.

Ошибки, которые делают конфликт хуже

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

Именно поэтому споры о ценностях так разрушительны. Большинство конфликтов между основателем и CTO начинается с реальной операционной проблемы, а не с морального провала. Один человек беспокоится о выручке, давлении клиентов или сроке жизни компании на деньгах. Другой беспокоится о надежности, переделках или хрупкой кодовой базе. Держите разговор на уровне решений, затрат и рисков.

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

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

Еще одна частая ошибка — закончить встречу в дружелюбном тоне, но без четкого владельца. На день это кажется приятнее, а потом тот же спор возвращается.

Перед тем как кто-то уйдет, запишите четыре вещи:

• кто отвечает за дату поставки
• кто отвечает за технические решения по этому релизу
• что выходит сейчас
• что ждет позже

Этот короткий список убирает много повторяющихся конфликтов.

Последняя ошибка — пообещать полный reset без реальных действий. Люди говорят, что хотят начать с чистого листа, а потом продолжают делать то же самое: поздние изменения scope, скрытое раздражение, разговоры в обход друг друга и отсутствие письменных компромиссов. Доверие не возвращается от того, что обе стороны один раз сказали правильные слова. Оно возвращается, когда следующие два-три решения выглядят иначе.

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

Короткая проверка после разговора

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

Начните с простого теста: попросите каждого записать, кто за что решает. Сделайте это коротко. Кто задает приоритет продукта? Кто может остановить релиз из-за реального технического риска? Кто утверждает изменения после того, как команда уже начала работу? Если ответы все еще различаются, конфликт пока только поставлен на паузу.

Короткая письменная проверка помогает лучше, чем еще один длинный разговор:

• Оба человека могут назвать окончательного владельца приоритетов продукта, технического риска и решений по поставке.
• Они согласны с одним темпом на этот месяц, а не с расплывчатой идеей «двигаться быстрее».
• У них есть одно правило для change request после старта работы.
• Они назначили одну еженедельную встречу в одно и то же время и с одной и той же повесткой.

Темп продукта важнее, чем думает большинство команд. Один человек может представлять себе еженедельные релизы. Другой — две более крупные поставки с меньшим количеством багов. Выберите одно. Если не определить темп, каждая задержка снова превращается в тот же конфликт.

Правило для change request должно быть жестким и скучным. Если основатель добавляет что-то срочное, что-то другое уходит из плана. Если CTO видит риск, он должен назвать временную стоимость и понятный вариант, а не давать расплывчатое предупреждение. Так product speed vs engineering не превращается в спор о доверии.

Еженедельная встреча должна быть короткой, примерно на 20 минут. Обсудите, что вышло, что изменилось, что сдвинулось и нарушил ли кто-то новые правила. Не используйте эту встречу, чтобы снова открывать старые споры.

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

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

Что делать дальше

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

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

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

Простой формат дальнейшей работы работает лучше, чем большой процесс:

• Пересматривайте правила раз в неделю в течение месяца.
• Отмечайте один момент, когда правила помогли.
• Отмечайте один момент, когда они не сработали.
• Меняйте только одно правило за раз.

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

Для небольшой команды внешняя помощь не обязательно означает долгий контракт. Сфокусированная сессия с Fractional CTO или startup advisor может помочь пересмотреть роли, темп продукта и рабочие правила с понятной внешней перспективой. Если вам нужна такая помощь, Oleg Sotnikov на oleg.is работает со стартапами над техническим лидерством, архитектурой продукта и практическими управленческими решениями.

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