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

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

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