IBM хотела, чтобы переключение между полями диалогового окна в OS/2 было привязано к другой клавише. Microsoft выбрала Tab. Казалось бы — мелочь. Но спор вышел на уровень вице-президента IBM и потребовал официального ответа от менеджера аналогичного ранга со стороны Microsoft. Инженер Microsoft, работавший в офисе IBM в Бока-Ратон, ответил коротко: «Мама Билла Гейтса не интересуется клавишей Tab». Это был День матери в США. Обсуждение закончилось. Tab остался Tab.
Контекст
OS/2 дебютировала в 1987 году как совместный проект IBM и Microsoft — амбициозная попытка создать следующее поколение операционных систем для корпоративного рынка. IBM привнесла корпоративные связи и статус, Microsoft — скорость и разработческую культуру. На бумаге партнёрство выглядело логично.
На практике столкнулись две организационные культуры, которые с трудом понимали друг друга. По словам Рэймонда Чена, сотрудники Microsoft считали коллег из IBM «увязшими в бессмысленной бюрократии». IBM воспринимала команду Microsoft «недисциплинированными хакерами». Чен не исключает, что оба аргумента были обоснованными — это делает историю честнее, а не веселее.
Организационная структура была лишь одной из точек расхождения, но показательной. В Microsoft технический вопрос решал менеджер первой линии, потому что именно для этого он и был командирован в Бока-Ратон. В IBM один вице-президент уже имел сформированную позицию по клавише Tab — и это означало цепочку эскалаций, формальных подтверждений и ожидания ответа аналогичного уровня.
Аналитика
Эта история часто звучит как курьёз. Но за ней стоит управленческий закон, который не устарел: когда в одном проекте работают организации с принципиально разной скоростью принятия решений, проект тяготеет к скорости более медленной из них. Не к среднему значению — именно к нижнему порогу. Каждый мелкий технический вопрос, требующий эскалации, добавляет дни к циклу итерации.
Для команд, которые сегодня строят AI-продукты, это актуально как никогда. Агентные пайплайны, LLM-конфигурации, MCP-интеграции — всё это требует быстрой итерации: поменял промпт, проверил, откатил, поменял снова. Если рядом есть хотя бы один «IBM-слой» — корпоративный клиент, внутренний IT-комитет, партнёр с многоуровневым апрувом — скорость команды падает пропорционально. Самые живые AI-продукты сейчас строят там, где решение по интерфейсу или конфигурации принимается за минуты.
OS/2 в итоге не стала массовым продуктом. Причин много: техническое отставание от Windows, ценовая политика, маркетинговые просчёты. Но культурное несоответствие партнёров было системным фактором, который инженеры ощущали на уровне каждой рабочей встречи. История Чена — не анекдот, а симптом. И симптом, который легко не заметить на старте партнёрства.
Кейсы применения в бизнесе
B2B-SaaS стартап, интегрирующийся с корпоративным клиентом: зафиксируйте в договоре «технического владельца» — одного человека, который принимает продуктовые решения без эскалации. Иначе каждый UX-вопрос будет ломать спринт. Хорошая формулировка: «все технические решения в рамках проекта принимает [имя] в течение 24 часов».
Корпорация с legacy-культурой, внедряющая AI-инструменты: назначьте внутреннего «AI-чемпиона» — сотрудника, который может менять конфигурацию агентов и промпты без согласования с IT-комитетом. Если каждое изменение промпта требует тикета и апрува на три уровня, итерационный цикл займёт недели вместо часов. Это убьёт ROI ещё до пилота.
SMB или локальный бизнес в КР/СНГ, выстраивающий партнёрство с крупной структурой: на старте явно проговорите «кто принимает операционные решения». Когда это не зафиксировано, мелкие технические вопросы поднимаются до CEO — и убивают темп. Для небольшой команды это особенно болезненно: у вас нет буфера на ожидание.
Кейсы в личной жизни
Разработчик в корпоративной среде: если видите, что технические решения уходят в многоуровневое согласование — предложите явно зафиксировать «право на решение» в рамках своей области. Это не агрессия — это зрелость. Покажите, что умеете брать ответственность, а не ждать апрув на клавишу Tab.
Фрилансер или консультант: при онбординге нового клиента сразу выясняйте: кто принимает решения по продукту, по дизайну, по стеку? Если ответ — «это решает комитет» — заложите это в сроки и стоимость. Комитеты не ускоряются.
Стартап-основатель, оценивающий партнёра: задайте один вопрос: «Кто у вас принимает продуктовое решение за 24 часа?» Если внятного ответа нет — это диагноз. Либо стройте архитектуру партнёрства с учётом их скорости, либо переходите к следующему кандидату.
Как применить сегодня
- При старте любого совместного проекта составьте «матрицу решений»: кто принимает что, на каком уровне, за сколько времени.
- Если вы на стороне быстрой команды — не ждите, что медленный партнёр ускорится сам. Делегируйте им только то, что терпит задержку.
- Для AI-продуктов установите правило: конфигурация агентов, промпты и UX-детали — принимает один человек без согласования.
- Используйте этот кейс как вопрос на собеседовании: «Как вы поступите, если техническое решение заблокировано бюрократией?» Ответ покажет культурный fit точнее резюме.
- Читайте технические истории от практиков — инженеры, работавшие в Microsoft и Google в 80–90-е, оставили достаточно письменных свидетельств о том, как принимались (или не принимались) системные решения. Паттерны повторяются.