Разногласия между основателем и CTO: не втягивайте в это команду

Почему это так быстро бьёт по команде

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

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

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

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

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

Урон растёт, когда финальное решение меняют дважды. Команда может пережить один сложный поворот, если руководители объяснили его ясно. Но два быстрых отката ощущаются иначе. Люди начинают думать, что сам процесс принятия решений ненадёжен. Доверие падает, оценки раздуваются, и всё меньше людей говорит прямо на встречах.

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

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

Определите, какие споры остаются приватными

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

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

Перед любой планёркой основатель и CTO должны договориться о четырёх вещах:

• Какое решение нужно принять сегодня
• Кто принимает финальное решение, если спор не снят
• Какие факты нужны команде
• Какое одно сообщение оба руководителя будут использовать в комнате

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

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

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

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

Используйте одно правило на каждой встрече руководства

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

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

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

Хорошо работает простая схема:

• Один человек принимает решение
• Один или два человека дают прямой совет
• Все остальные задают вопросы только если им нужна ясность для работы

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

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

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

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

Команде не нужна идеальная гармония от руководителей. Ей нужен ясный сигнал, которому можно доверять и по которому можно действовать.

Проведите жёсткий спор, не расколов комнату

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

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

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

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

• Вариант A
• Вариант B
• Прямая стоимость
• Прямой риск
• Последний момент, когда нужно принять решение

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

Затем назначьте дедлайн для решения. Не «скоро». Не «после того, как подумаем». Назначьте реальное время, например сегодня в 16:00. Жёсткий срок снижает шанс второй публичной перепалки, потому что оба человека знают, когда обсуждение закончится и кто примет финальное решение, если они всё ещё не согласны.

Одно правило очень помогает: спорьте полностью в приватном формате, а потом один раз говорите публично. Не повторяйте этот же кейс перед командой. Не говорите частичную поддержку вроде «у меня всё ещё есть сомнения, но делаем так». Такая фраза провоцирует людей выбирать сторону.

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

Команды выдерживают напряжение. Чего они не выдерживают, так это смешанной власти.

Сообщите команде, что изменилось, а что нет

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

Ясное обновление звучит так: «Мы переносим работу над дашбордом на следующий спринт. Сейчас команде важнее исправить checkout, потому что там выше риск для релиза». Это даёт людям направление в двух предложениях. Им не нужен подробный пересказ того, кто за что настаивал.

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

Третий пункт важнее, чем думают многие руководители. Инженеры нервничают, когда слышат о переменах, но не понимают, затронула ли она их собственную работу. Скажите это прямо: дата релиза всё ещё в пятницу, ежедневная встреча остаётся как была, Priya по-прежнему отвечает за API, а support по-прежнему получает ежедневные обновления по багам. Мелкие детали успокаивают людей.

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

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

Люди нормально переносят перемены. Они ненавидят только неопределённость, которая тянется днями. Короткое спокойное сообщение с одним владельцем и одним местом для вопросов помогает команде работать, а не гадать.

Пример спора о дорожной карте перед релизом

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

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

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

Теперь важна публичная часть. Команда должна услышать один план от обоих руководителей: что выходит, когда выходит и почему победил именно этот вариант. «Мы выпускаем отчёт только для просмотра в следующий четверг. Остальную часть работы по отчётам мы сократили, чтобы команда успела закончить исправления базы данных, нужные для пикового трафика». Этого достаточно для engineering, product, sales и support.

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

Ошибки, из-за которых инженеры выбирают сторону

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

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

Другая ошибка — просить инженеров голосовать по спору руководства. Команда может дать оценки, риски и факты. Команда не должна решать, кого из руководителей поддержать. Как только вы просите о голосовании, люди начинают задавать другой вопрос: «С кем мне нужно согласиться, чтобы быть в безопасности?»

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

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

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

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

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

Быстрая проверка до и после встречи

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

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

До встречи

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

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

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

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

После встречи

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

Следите за противоречивыми указаниями. Один руководитель говорит: «Выпускаем в пятницу». Другой говорит: «Не экономьте на качестве». Звучит разумно, но многие инженеры слышат: «Вас в любом случае сделают виноватыми». Чёткий курс это исправляет. Лучший вариант звучит так: «Выпускаем в пятницу с объёмом A и B. C переносим на следующую неделю. Любые риски фиксируем сегодня».

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

Установите правила до следующего конфликта

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

Запишите правила простым языком. Одной страницы достаточно. Большинству команд нужно три правила принятия решений:

• Дорожная карта: кто принимает финальное решение по объёму и когда это решение фиксируется для текущего релиза
• Найм: кто может настаивать на срочности, кто проверяет уровень и соответствие роли, и кто говорит «нет», если позиция неясна
• Инциденты: кто ведёт реакцию в моменте, кто отвечает за сообщения клиентам или инвесторам и кто проводит разбор после

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

Полезно также отрепетировать паузу. Точные слова важны меньше, чем привычка. Чистая формулировка звучит так: «Мы не согласны, и вынесем это за рамки встречи. Пока продолжайте работать по текущему плану до 15:00». Коротко, спокойно и конкретно — лучше, чем грязный спор при десяти инженерах.

Возьмите один недавний конфликт и разберите его, пока ставки невысоки. Не пересказывайте всю историю заново. Просто найдите слабое место. Знала ли команда, кто владелец решения? Кто-то снова поднял спор публично после того, как решение уже было принято? Люди вышли из комнаты, не понимая, что делать дальше?

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

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