Разбор: как работает метод Mochary Method в российских реалиях: что важно знать

Артём пришёл с распечаткой. Не с запросом, не с проблемой — с распечаткой на сорок страниц. Это был перевод Mochary Method, сделанный кем-то из команды. Он положил её на стол и сказал примерно следующее: хочу внедрить, скажи, что не так.

Я посмотрел на распечатку, потом на него.

Не так было почти всё — но не в методологии. В том, как он собирался её применять.

Артём — фаундер и CEO IT-сервиса, который он строил больше семи лет. Бизнес вырос до среднего по меркам рынка: оборот под полмиллиарда, несколько десятков человек в команде, продукт с реальными клиентами и реальной выручкой. Не стартап, не корпорация — то самое место, где всё держится на одном человеке, даже если этот человек уже давно хочет, чтобы не держалось.

Про Mochary Method он узнал от знакомого фаундера, который «внедрил и всё изменилось». Это важная деталь: источник информации — не книга, не статья, а чужой восторженный рассказ. Восторженные рассказы о методологиях работают как реклама — они продают ощущение, а не инструмент.

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

Это нормальный запрос для фаундера на его стадии. Mochary Method — не худший ответ на него. Но прежде чем говорить о методе, нужно было понять, зачем он ему вообще нужен именно сейчас.

Запрос звучал как «помоги внедрить методологию». Это поверхностный слой. Под ним — «помоги перестать тушить пожары». Это разные задачи, и путать их дорого стоит.

Mochary Method — система управления, которую Мэтт Мочари разработал для кремниевых стартапов. Её ядро: асинхронная коммуникация, структурированные один-на-один встречи, списки приоритетов, культура письменной обратной связи. Всё это работает в среде, где люди привыкли к горизонтальным структурам, доверяют процессу больше, чем иерархии, и умеют давать прямую обратную связь без того, чтобы это разрушало отношения.

Артём работал в другой среде.

Из сорока страниц распечатки он выделил три элемента, которые хотел взять. Первый — еженедельные один-на-один с каждым из топ-менеджеров по структурированному шаблону. Второй — top-of-mind list: каждый участник команды ведёт список того, что занимает его голову прямо сейчас. Третий — async-first: договориться, что большинство вопросов решается письменно, а не через «зайди на минутку».

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

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

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

Мы взяли три элемента, которые Артём выделил, и прошлись по каждому.

Еженедельные один-на-один. Это работает. Работает почти везде, не только в кремниевых стартапах. Структура встречи по Mochary — сначала говорит сотрудник, потом руководитель — требует небольшой настройки: российские менеджеры среднего звена часто ждут, что начальник задаёт тон. Первые две-три встречи будут неловкими. Потом привыкают. Артём провёл пробный раунд один-на-один со своим операционным директором — и обнаружил, что тот держит в голове три проблемы, о которых никогда не говорил вслух. Не потому что скрывал — просто не было формата.

Top-of-mind list. Здесь сложнее. Идея хорошая: каждый участник команды перед встречей записывает, что сейчас занимает его голову — задачи, тревоги, вопросы. Это снижает когнитивную нагрузку на встречах и делает их предсказуемыми. Проблема — дисциплина ведения списков. В командах, где нет культуры письменной фиксации, это умирает на второй неделе. Мы адаптировали: вместо отдельного инструмента — два абзаца в начале письма перед встречей. Не красиво, зато работает.

Async-first. Это самый сложный элемент для адаптации — и самый ценный, если получается. Артём хотел договориться, что «зайди на минутку» заменяется на письменный вопрос с контекстом. Мы не стали вводить это как правило. Вместо этого — Артём сам начал отвечать на устные вопросы письменно. Не всегда, но часто. Это медленнее, но моделирует поведение лучше любого регламента. Через месяц двое из четырёх топ-менеджеров начали делать то же самое.

Что выбросили. Mochary предлагает систему оценки настроения команды через регулярные опросы — что-то вроде пульс-чека. В кремниевом стартапе это работает: люди привыкли к прозрачности, данные воспринимаются как инструмент. В команде Артёма первый же опрос вызвал тревогу: «зачем он это спрашивает, что-то случилось?» Убрали. Заменили на неформальный разговор раз в месяц — без анкет, без метрик.

Самое неожиданное случилось не там, где мы ждали.

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

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

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

Что не изменилось. Масштабирование — третий запрос из исходного списка — осталось открытым вопросом. Mochary Method не решает задачу роста. Он решает задачу управления командой при росте. Это разные вещи. Артём это понял, и это тоже результат — пусть и не тот, который он ожидал.

Где метод сработал неожиданно хорошо: в отношениях с операционным директором. После первых один-на-один выяснилось, что тот давно хотел взять на себя больше ответственности, но не знал, как об этом сказать. Артём не знал, что тот хочет. Формат дал им язык для разговора, которого раньше не было.

Та распечатка до сих пор лежит у Артёма. Он говорит, что использует страниц десять из сорока. Это честный результат.

Это четвёртый раз за последний год, когда ко мне приходит фаундер с методологией вместо запроса. Не с проблемой — с решением. Mochary Method, OKR, Holacracy, EOS — названия разные, структура одна: человек прочитал или услышал, загорелся, хочет внедрить целиком.

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

Из Mochary Method в российских реалиях реально работают примерно 30–40% инструментов. Это нормально. Это не провал методологии и не провал команды — это нормальная адаптация.

Три вопроса, которые стоит задать себе перед внедрением любой западной методологии:

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

Второй. Какие культурные предпосылки нужны для работы этого инструмента — и есть ли они в моей команде прямо сейчас?

Третий. Что я готов адаптировать, а что — внедрить как есть? Если ответ «внедрить как есть» — это тревожный сигнал.

Параллельный случай. Примерно в то же время я работал с фаундером производственной компании, который хотел внедрить OKR. Та же история: распечатка, восторг, «хочу как у Google». Мы взяли из OKR один элемент — квартальный разговор о приоритетах между собственником и топ-командой. Без метрик, без каскадирования, без всей системы. Этого оказалось достаточно, чтобы команда перестала работать в разные стороны. Полное внедрение OKR они не осилили бы — и не потому что плохая команда. Просто не та стадия.

Подробнее о том, как адаптировать западные фреймворки под российский МСБ — в материале «Фреймворк X: применение в практике российского МСБ». А о том, как выглядит выход из операционки изнутри — в кейсе «Выход из операционки за 6 месяцев».

Mochary Method вообще применим в России или это изначально не для нас?

Применим — частично. Инструменты один-на-один, top-of-mind list и async-коммуникация работают в большинстве команд при правильном введении. Элементы, завязанные на горизонтальную культуру и прямую публичную обратную связь, требуют серьёзной адаптации или замены. Брать методологию целиком — почти всегда ошибка. Брать из неё 3–4 инструмента под конкретную задачу — разумно.

Это единичный случай или такое встречается часто?

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

Что делать, если я вижу у себя похожее — хочу внедрить методологию, но не уверен, с чего начать?

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

Не обязательно про Mochary. Достаточно про «хочу внедрить систему, но не понимаю, что из неё реально работает в моём бизнесе».

Работаю с фаундерами и CEO бизнесов от 80 миллионов выручки. Беру до трёх advisory-запросов в месяц — не потому что так принято писать, а потому что больше не успеваю делать хорошо.

Если узнал себя в этом кейсе — заполни заявку на /services/consulting/: кто ты, что за бизнес, с чем пришёл. Дальше разберёмся.

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

P.S. Если ты уже читал Mochary и хочешь обсудить конкретно его применение в своей команде — это тоже разговор. Но сначала заявка.

Апрель 2026. Автор — Виталий Ветров, стратегический советник и управляющий партнёр юридической фирмы.