Ты принял решение. Потом принял другое. Потом третье — уже под давлением партнёра.
Потом оглянулся и не понял, кто из вас троих вообще управляет компанией.
Управляющий партнёр в IT — это должность, которая звучит как ответ, но внутри устроена как вопрос без конца. Фреймворки принятия решений, которые ты читал, написаны для другого человека. Для одиночного CEO с советом директоров. Для основателя без партнёра. Для менеджера с чётким мандатом.
Не для тебя.
Есть иллюзия, которую создаёт слово «управляющий». Будто оно что-то фиксирует. Будто за ним стоит реальная архитектура власти — кто решает, кто исполняет, где граница.
В большинстве IT-партнёрств этой архитектуры нет.
Есть договорённости, которые работали на старте и перестали работать на масштабе. Есть неформальные иерархии, которые никто не называет вслух. Есть партнёр, который «не вмешивается в операционку» — и вмешивается каждый раз, когда ставки становятся высокими. Есть ты, который формально принимает решения — и фактически проводит значительную часть времени в том, что я бы назвал «управлением согласием».
Это не патология. Это структурная особенность партнёрской конструкции.
Но именно здесь классические фреймворки принятия решений начинают давать сбой. Они предполагают, что у тебя есть мандат. Что решение — это твоё решение. Что после него ты двигаешься вперёд, а не идёшь объяснять партнёру, почему ты принял именно это.
Один управляющий партнёр — IT-компания, разработка на заказ, около 80 человек — рассказал мне историю, которую я слышал в разных вариациях уже несколько раз.
Три месяца он «принимал решения». Нанимал людей, менял процессы, перестраивал структуру продаж. Всё это было согласовано с партнёром — формально. Партнёр кивал. Иногда говорил «давай попробуем». Иногда молчал, что тоже читалось как согласие.
Через три месяца партнёр сказал: «Я не понимаю, что происходит с компанией».
Не «я не согласен». Не «ты принял неправильные решения». А именно — «я не понимаю».
И тут выяснилось, что все эти три месяца управляющий партнёр принимал решения в одной системе координат, а партнёр наблюдал за ними из другой. Согласие было. Понимания — не было. А значит, и решений — в полном смысле — тоже не было. Были действия, которые в какой-то момент потребовали пересмотра.
Это дорого. Не только в деньгах.
Канеман разделил мышление на две системы — быструю и медленную. Это полезная модель, но она описывает то, что происходит внутри одной головы.
В партнёрской IT-компании у решения есть три слоя, и они редко совпадают.
Первый слой — решение как факт. Ты выбрал опцию А, а не Б. Подписал контракт. Нанял человека. Закрыл направление. Это то, что видно снаружи.
Второй слой — решение как процесс. Как ты к нему пришёл. Какие данные смотрел. Кого спрашивал. Сколько времени дал себе. Это то, что видно тебе изнутри.
Третий слой — решение как сигнал. Что это решение говорит партнёру о тебе, о твоей позиции, о том, как ты видишь компанию. Это то, что партнёр читает — независимо от того, объяснял ты ему что-то или нет.
Большинство управляющих партнёров работают с первым и вторым слоем. Третий они игнорируют — или замечают только тогда, когда что-то идёт не так.
Но именно третий слой определяет, будет ли решение реализовано или застрянет в бесконечном цикле «давай ещё раз обсудим».
Вот вопрос, который стоит задать себе до того, как ты принял решение:
Если партнёр увидит это решение без моих объяснений — что он про меня подумает?
Не «согласится ли он». Не «правильно ли это решение». А именно — что он подумает про тебя как про человека, который управляет этой компанией.
Если ответ на этот вопрос тебя беспокоит — это сигнал. Не обязательно сигнал отменить решение. Но точно сигнал, что что-то в архитектуре партнёрства требует внимания.
Есть ещё один момент, который я наблюдаю регулярно.
Управляющий партнёр принимает решение под давлением — дедлайн, клиент, команда ждёт. Давление реальное. Времени нет. Он выбирает. Потом, когда давление спадает, понимает, что выбрал не то, что выбрал бы без давления.
Это не слабость. Это механика.
Талеб называл это «хрупкостью под стрессом» — системы, которые выглядят устойчиво в спокойное время, разрушаются именно тогда, когда от них требуется максимум. Решения — не исключение.
Вопрос не в том, как избежать давления. Давление в IT — это не форс-мажор, это рабочая среда. Вопрос в том, как отличить своё решение от решения, которое ты принял, потому что другого выхода не было.
Разница важна. Потому что с первым ты можешь работать. Со вторым — только справляться.
Когда люди говорят «мне нужен фреймворк принятия решений», они обычно имеют в виду инструмент. Матрицу. Алгоритм. Что-то, что можно применить и получить ответ.
Я понимаю этот запрос. И я не буду делать вид, что он неправильный.
Но вот что я заметил за годы работы с управляющими партнёрами в IT: те, кто принимает решения хорошо, не используют фреймворки как инструкции. Они используют их как зеркала.
Зеркало не говорит тебе, что делать. Оно показывает, откуда ты смотришь.
Есть три вопроса, которые я считаю базовыми для управляющего партнёра в IT. Не потому что они дают ответ. А потому что они делают невозможным принять решение, не заметив, из какой позиции ты его принимаешь.
Вопрос первый: это моё решение или решение, которого от меня ждут?
В IT-партнёрствах есть культура консенсуса. Она выглядит как зрелость — «мы всё обсуждаем, мы слышим друг друга». Иногда это действительно зрелость. Иногда это механизм, который размывает ответственность до полной неразличимости.
Управляющий партнёр, который всегда принимает «согласованные» решения, рискует однажды обнаружить, что он не принимал решений вообще. Он их оформлял.
Вопрос второй: я принимаю это решение сейчас — или я откладываю более сложное решение?
IT-компании работают в условиях постоянной неопределённости. Это создаёт соблазн принимать «промежуточные» решения — те, которые не закрывают вопрос, но дают ощущение движения. Нанять ещё одного разработчика вместо того, чтобы пересмотреть продуктовую стратегию. Поменять процесс вместо того, чтобы поговорить с партнёром о том, куда идёт компания.
Промежуточные решения накапливаются. Через год ты смотришь на компанию и видишь слои этих решений — каждое из которых было разумным в моменте, и все вместе они создали конструкцию, которую никто не проектировал.
Вопрос третий: если это решение окажется неправильным — кто будет это знать первым?
Не «кто виноват». А именно — кто узнает первым. Команда? Клиент? Партнёр? Ты сам — через полгода, когда будет поздно что-то менять?
Этот вопрос — про обратную связь. Про то, как устроена система, в которой ты принимаешь решения. Если ты узнаёшь о последствиях своих решений последним — это не проблема конкретного решения. Это проблема архитектуры.
Теперь про IT-специфику. Потому что она меняет всё.
В IT есть культ данных. «Данные решают» — это не просто фраза, это операционная философия. И она работает — в определённых контекстах. Когда у тебя есть данные. Когда данные релевантны. Когда вопрос вообще поддаётся измерению.
Но управляющий партнёр регулярно принимает решения, которые не поддаются измерению. Уволить ли ключевого разработчика, который токсичен для команды, но незаменим технически. Входить ли в новый рынок, где нет данных по определению. Менять ли партнёрское соглашение, когда отношения с партнёром стали другими.
Здесь культ данных становится ловушкой. Потому что отсутствие данных начинает читаться как отсутствие основания для решения. А это не так.
Некоторые решения принимаются не потому что есть данные. А потому что есть ты — с твоим опытом, с твоим пониманием людей, с твоим чувством того, куда идёт рынок. Это тоже данные. Просто другого рода.
Управляющий партнёр, который умеет работать с обоими типами — и с цифрами, и с интуицией — принимает решения лучше, чем тот, кто умеет работать только с одним.
Я работаю с управляющими партнёрами в IT достаточно долго, чтобы видеть паттерны.
Те, кто принимает решения хорошо, не обязательно принимают правильные решения. Правильных решений в условиях неопределённости не существует — есть только решения, которые оказались удачными постфактум.
Но есть кое-что, что их отличает.
Они знают, откуда принимают решение. Не в смысле «из какого кресла» — а в смысле из какого внутреннего состояния. Из страха или из понимания. Из усталости или из ясности. Из желания закрыть вопрос или из желания принять правильное решение.
Это звучит как психология. Отчасти так и есть. Но это также и стратегия.
Потому что управляющий партнёр, который не понимает, из какого состояния он принимает решения, рано или поздно принимает решение, которое разрушает то, что он строил. Не потому что оно было неправильным по содержанию. А потому что оно было принято из состояния, которое он не заметил.
Те, кто принимает решения плохо, обычно делают одну из двух вещей.
Первое — они принимают слишком много решений. Каждый день, по каждому поводу, не давая себе времени понять, какие из них действительно требуют их участия. Это выглядит как активность. Это ощущается как контроль. На самом деле это способ не принимать решения, которые действительно важны.
Второе — они откладывают одно решение бесконечно. Оно висит. Все знают, что оно висит. Партнёр знает. Команда знает. Клиенты иногда тоже знают. И каждый день, пока оно не принято, оно стоит — в энергии, в фокусе, в доверии.
Хороший фреймворк не даёт ответа.
Он делает невозможным притвориться, что ты его уже знаешь.
Это не для тех, кто ищет матрицу решений. Это для тех, кто уже понял, что матрица — не проблема.
Если тема резонирует — есть рассылка. Раз в две недели, без SEO-логики, ближе к разговору. Форма подписки — в футере.
Смежные материалы по теме: Фреймворк принятия решений для сооснователя в e-commerce · Инструмент для принятия решений под неопределённостью в IT-компании · Фреймворк для фаундера в B2B-услугах
Апрель 2026. Автор — Виталий Ветров.