У большинства инженеров слово «политика» вызывает неприятное чувство: кажется, что это про манипуляции, карьеризм и бессмысленные игры. Настоящие разработчики должны «писать код, а не влезать в интриги», верно? На самом деле — нет.
Политика в организациях — это не интриги, а способ координации людей и влияния на решения. И если вы решаете её игнорировать, это не значит, что она исчезает. Это значит, что решения будут приниматься без вас.
🤖 Как работает «плохая политика»
Представьте: в компании принимается решение о внедрении новой архитектуры. Вы знаете, что выбранный вариант не масштабируется и создаст проблемы через год. Но на встрече, где это обсуждалось, вас не было. Вы «не занимались политикой».
Итог: ❌ плохое решение прошло, потому что «громкий» человек оказался в комнате и отстоял свою позицию.
Идеи не говорят сами за себя — их продвигают люди.
✅ Что такое «хорошая политика»
На практике хорошая политика выглядит очень технично и рационально:
- ☕ Связи до того, как они нужны — случайный кофе с коллегой из data-команды сегодня = их поддержка завтра, когда вам нужны ресурсы на пайплайн.
- 🎯 Формулировка в терминах стимулов — ваш VP не интересуется «чистой архитектурой», но его волнует «ускорение релизов». Значит, аргументы нужно подавать через бизнес-ценность.
- 📡 Менеджмент вверх — ваш руководитель видит только часть задач. Давайте ему сигналы о рисках заранее, предлагайте решения — и он станет вашим адвокатом на совещаниях.
- 🤝 Win-Win сценарии — вместо того чтобы бороться за ресурсы, находите способы совместных выгодных проектов.
- 🌍 Видимость работы — если вы сделали что-то крутое, но никто не узнал — эффекта нет. Пишите дизайн-доки, выступайте на all-hands, делитесь результатами.
Это не манипуляции — это правильное представление фактов в понятной форме для разных заинтересованных сторон.
🧠 Техническая аналогия
Если перевести политику в инженерные термины:
- Изоляция от политики = написание кода без логирования и мониторинга. Система работает… пока не падает.
- Участие в политике = построение каналов связи и обратной связи. Это как observability в организациях.
Хорошие инженеры часто забывают, что архитектура команды важна не меньше, чем архитектура системы.
💡 Моё видение
Я считаю, что программисту стоит относиться к «политике» так же, как к любому инструменту. Git можно использовать, чтобы аккуратно вести историю изменений, а можно — чтобы запутать коллег. SQL можно писать оптимально, а можно — сделать запрос, который положит базу.
То же и с политикой: она нейтральна. Вопрос — как её применять.
Если инженер отказывается от политики, он передаёт управление менее компетентным людям. И в итоге страдают и код, и команда, и продукт.
🚀 Вывод
Политика — это не грязная игра, а способ влиять на решения.
- 🤝 Стройте отношения.
- 🎯 Говорите на языке бизнеса.
- 📡 Управляйте вверх.
- 🌍 Делайте работу видимой.
Альтернатива «хорошей политике» — не «отсутствие политики». Альтернатива — победа плохой политики.
🔗 Источник: Don’t avoid workplace politics — Terrible Software