Как не оказаться в ситуации, что через три месяца всё «разворочено» и ничего не работает, если лид решил радикально переписать код (например, выкинуть Boost)?

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

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

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

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