The post has been translated automatically. Original language: Russian Russian
What is antifragility?
Antifragility is when a certain system becomes only stronger from blows and mistakes, that is, when stress is, to a certain extent, a source of growth and development. The term was coined by Nassim Taleb: unlike a stable system, for which the goal is to withstand the load and not break, an antifragile system evolves and strengthens due to failures.
Why exactly is it needed in IT?
Because here in IT, unlike in traditional business, there is no stable foundation. Everything is constantly being shaken up by new technologies, frameworks, and architectural approaches. Today your track is called revolutionary, tomorrow it goes into oblivion like ICQ.
Mistakes are treated differently in IT than in traditional business. A failure there can mean disaster: the plant stops the line due to an improperly designed conveyor line, the bank will lose millions due to an incorrect financial model. In IT, bugs and flaws are a natural part of the cycle. The code will always contain errors, analytics will contain noise and distortion, and plans will collapse when confronted with reality.
Dependence on people in IT is higher than in most industries, because people and their skills are the main asset of a business, whose work generates value. It is not uncommon for one "hero" to carry a product, but his departure at any moment turns into a disaster. This dependency makes teams fragile.
Finally, at any moment, a competitor with a radically new product may appear, the infrastructure may collapse, and the regulatory framework may change. The scalability of IT means that the impact is always immediate and strong. It is impossible to play stability here, you need to learn here so that every crisis raises the system to a new level.
What might antifragility look like in IT?
An antifragile product never comes out into the world monolithic and "perfect". It develops through short iterations and hypotheses, where failure is not fatal, but beneficial. Instead of the illusion of infallibility, the product builds the possibility of errors into the architecture itself: feature flags, instant rollback, and A/B tests. This allows you to experiment without risking killing the system. Moreover, unexpected user behavior is not perceived as a bug here, but becomes a source of insight: the team can turn the error into a new feature or into an understanding of what the market really wants.
The fragile team is supported by a superhero who drags the project. Leaving such a person breaks the system. An antifragile team is built differently: everyone has T-shaped skills, areas of responsibility overlap, code review and task rotation make knowledge a common capital. Mistakes and crises are seen not as a reason to look for the guilty, but as a training stress test. In retrospects, the team learns to react faster and coordinate better. Responsibility is distributed: there is no bottleneck in the person of one architect or team leader, there is a joint ability to withstand a blow.
Manual approvals and regulations make the system fragile: one link falls out and the whole chain breaks. Antifragile processes are automated as much as possible: CI/CD, alerts, monitoring. But the main thing is flexibility. Scrum or kanban is not a religion here, but tools that adapt to the situation. Each incident is used as material for improvement: post-mortem does not turn into a formal report, but gives rise to new practices. An error in production should not just be closed with a patch, but increase the overall stability of the system.
The most dangerous illusion in IT is betting on "one big idea," technology, or customer. A fragile strategy relies on stability. Antifragile is based on a portfolio: some projects bring profit here and now, some test hypotheses, and some provide long-term R&D. This reduces dependence and creates the ability to adapt to an unpredictable future. The strategy is not focused on "how it will be," but on the fact that the organization will be able to adapt to any "how it will be."
Что такое антихрупкость?
Антихрупкость - это когда некая система становиться от ударов и ошибок только сильнее, то есть когда стресс в определенной мере это источник роста и развития. Термин ввёл Нассим Талеб: в отличие от устойчивой системы, для которой цель - выдержать нагрузку и не сломаться, антихрупкая система эволюционирует и укрепляется благодаря сбоям.
Почему именно она нужна в IT?
Потому что здесь, в IT, в отличии от традиционного бизнеса, нет стабильного фундамента. Всё постоянно перетряхивается новыми технологиями, фреймворками, архитектурными подходами. Сегодня твой трек называют революционным, завтра он уходит в забвение, как ICQ.
В IT к ошибкам относятся иначе, чем в традиционном бизнесе. Там сбой может означать катастрофу: завод останавливает линию из-за неправильно спроектированной конвейерной линии, банк потеряет миллионы из-за неверной финансовой модели. В IT же баги и недочёты - естественная часть цикла. Код всегда будет содержать ошибки, аналитика -шум и искажения, планы - рушиться при столкновении с реальностью.
Зависимость от людей в IT выше, чем в большинстве отраслей, ведь люди и их навыки - основной актив бизнеса, чья работа и генерирует ценность. Не редка история, когда один «герой» может протащить на себе продукт, но его уход в любой момент превращается в катастрофу. Эта зависимость делает команды хрупкими.
И наконец, в любой момент может появиться конкурент с радикально новым продуктом, может рухнуть инфраструктура, может измениться регуляторика. Масштабируемость IT означает, что удар всегда мгновенный и сильный. Здесь невозможно играть в стабильность, здесь нужно учиться так, чтобы каждый кризис поднимал систему на новый уровень.
Как может выглядеть антихрупкость в IT?
Антихрупкий продукт никогда не выходит в мир монолитным и «идеальным». Он развивается через короткие итерации и гипотезы, где провал не губителен, а полезен. Вместо иллюзии безошибочности продукт закладывает возможность ошибок в саму архитектуру: feature flags, мгновенный rollback, A/B-тесты. Это позволяет экспериментировать без риска убить систему. Более того, неожиданное поведение пользователей здесь не воспринимается как баг, а становится источником инсайта: команда может превратить ошибку в новую фичу или в понимание, чего на самом деле хочет рынок.
Хрупкая команда держится на супергерое, который тянет проект. Уход такого человека ломает систему. Антихрупкая команда строится иначе: у каждого есть T-shaped навыки, зоны ответственности пересекаются, код-ревью и ротация задач делают знания общим капиталом. Ошибки и кризисы рассматриваются не как повод для поиска виноватых, а как тренировочный стресс-тест. На ретроспективах команда учится быстрее реагировать и лучше координироваться. Ответственность распределена: нет бутылочного горлышка в лице одного архитектора или тимлида, есть совместная способность выдерживать удар.
Ручные согласования и регламенты делают систему хрупкой: одно звено выпадает - и вся цепь рвётся. Антихрупкие процессы автоматизируются настолько, насколько это возможно: CI/CD, алерты, мониторинг. Но главное - гибкость. Scrum или kanban здесь не религия, а инструменты, которые подстраиваются под ситуацию. Каждый инцидент используется как материал для улучшения: post-mortem не превращается в формальный отчёт, а рождает новые практики. Ошибка в продакшене должна не просто закрываться патчем, а повышать общий уровень устойчивости системы.
Самая опасная иллюзия в IT - это ставка на «одну большую идею», технологию или клиента. Хрупкая стратегия полагается на стабильность. Антихрупкая строится на портфеле: часть проектов приносит прибыль здесь и сейчас, часть тестирует гипотезы, часть - долгосрочный R&D. Это снижает зависимость и создаёт способность адаптироваться к непредсказуемому будущему. Стратегия ориентирована не на то, «как будет», а на то, что организация сможет адаптироваться к любому «как будет».
Share
