Стратегия, AI и организационный дизайн

⚡️ AI требует перепроектировать организацию

McKinsey выпустили свежее исследование про AI и операционную модель. Компании разделили на три уровня зрелости: доступ к AI-инструментам, автоматизация процессов и переизобретение — перепроектирование самой работы с учетом AI.

Таких компаний всего 13%. AI у них уже затрагивает роли, процессы и операционную модель. Почти половина лидеров из этой группы говорит о заметной ценности AI для бизнеса против 13% на первом уровне.

Особенно интересно, как меняется структура. Компании на уровне переизобретения чаще собирают кросс-функциональные команды с end-to-end ответственностью за создание ценности и меньшим количеством передач работы между функциями.

Форма зависит от стратегического фокуса: при продуктоцентричном команды строятся вокруг ключевых инноваций / фич, при клиентоцентричном — вокруг сегментов / индустрий / ролей, при операционно-центричном — вокруг сквозного бизнес-процесса.

Я писал об этом и разбирал в книге «Дизайн Agile-организаций».

И вот для меня главная мысль. Хотите получить реальную ценность от AI — придется перепроектировать организацию.

AI ускоряет отдельные задачи, но зависимости между подразделениями никуда не исчезают. Все равно нужны end-to-end команды и полуавтономные подразделения с минимумом внешних зависимостей. Иначе получите локальные автоматизации внутри старой структуры.

Так что от Agile, Scrum и организационного дизайна с приходом AI мы никуда не денемся.

Исследование McKinsey прикладываю.

Что об этом думаете?

⚡️ AVSM: как найти потери скорости, определить рычаги и продать изменения

На днях созванивались с одним project-менеджером. Он проектирует процессы для двух департаментов, в каждом из которых несколько команд. Задача — сделать поток работы более предсказуемым.

Он рассказал мне задачу и хотел обсудить, как провести Value Stream Mapping. Я послушал и понял: обычного VSM здесь не хватит. Ему нужен Advanced Value Stream Mapping, AVSM.

Это моя методология end-to-end workshop, которую я постепенно собрал вокруг VSM. В ней мы разбираем поток, операционные зависимости, семь видов потерь Toyota, метрики, разные типы задач и параллельные ветки.

Но главная фишка AVSM — в сквозной фасилитации. Люди сами проходят весь путь: находят потери скорости, определяют рычаги изменений и фактически продают эти изменения сами себе. Поэтому на выходе появляется не только список проблем, но и мандат на изменения.

Мы проговорили про это 40 минут, а потом я записал подробный разбор для участников DAO Практикума. К сожалению, выложить его сюда не могу из-за чувствительной информации, которую мы обсуждали.

Но могу провести открытый часовой эфир и впервые целиком разобрать AVSM: механику, фасилитацию и тонкости проведения такого воркшопа.

Готовы узнать про AVSM? Ставьте + в комментариях.

⚡️ Как, чему и зачем обучать руководителей высшего звена

Хотите успешных организационных изменений — начинайте с обучения руководителей высшего звена. Их ментальные модели определяют организационный дизайн. Ведь именно у этих людей ключи к организационным изменениям и власть.

Вчера прошел Agile Days. И мне присылают фотографию: на сцене Магнит рассказывает, что я обучал их топ-менеджмент. Теперь могу рассказать и я.

В прошлом году я провел серию тренингов для руководителей высшего звена и board−1 Магнита. На первых встречах — генеральный директор и его команда, представители разных форматов. И помню жаркие споры.

Например, каким должен быть стратегический фокус Магнита: операционно-продуктовым или клиентоцентричным? Что считать продуктом?

Вот темы, которые я считаю важными для топов:

1. Связь организационного дизайна, способностей и стратегии.
2. Системное мышление.
3. Теория очередей и бережливое мышление.
4. Широкое определение продукта.
5. Роль настоящего владельца продукта.
6. Взаимозаменяемые фичи-команды и другие гайдлайны по организационному дизайну из моей книги.

За последние десять лет, пожалуй, именно обучение топ-менеджмента удается мне лучше всего. После тренингов регулярно слышу: «Илья взрывает нам мозг».

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

Как вы взрываете мозг руководителям?

Стратегия, AI и организационный дизайн pinned a photo

⚡️ Давайте знакомиться

Привет, я Илья Павличенко. Канал вырос, новых людей много — расскажу, кто я и чем занимаюсь.

Я эксперт по организационному дизайну и AI. Помогаю менеджерам и лидерам проектировать структуру, процессы и правила так, чтобы продукты выходили быстрее, а косты не росли. За плечами Росбанк, Альфа-Банк, Райффайзен, Открытие, ING, МТС Касса, Jusan Bank, Mighty Buildings.

Как я сюда пришёл
Прикладная математика. Несколько лет писал код, дорос до тимлида и понял, что меня больше тянет разбираться, как устроена работа вокруг кода. Перешёл на другую сторону Луны: Скрам-мастер, потом Agile-коуч в Luxoft.

В 2014-м вышел в свободное плавание. Первый в России Professional Scrum Trainer. В 2018-м сделал первый в России официальный кейс масштабируемого Скрама — МТС Касса: за полгода команда выросла с 28 до 60 разработчиков, Time-to-Market упал вдвое. Самый известный кейс — СБП, ускорение в четыре раза.

Индустрия значения не имеет: банки, финтех, логистика, FMCG, дома на 3D-принтерах. Системное мышление и теория очередей работают везде.

Сейчас пишу на вайбкодинге ПО для диагностики организаций, готовлю вторую версию методологии DAO и держу около двадцати AI-ассистентов под свои задачи.

А свежие промпты, скиллы, туториалы и другие AI-фишки складываю в отдельный канал «AI на работе».

Вне работы — мастер спорта по стритлифтингу и сапы всерьёз: зимой тоже, в костюме. Лучшие решения приходят после хорошей силовой. Ещё очень люблю живопись — импрессионистов и авангард.

Книги
«Creating Agile Organizations» — с Cesario Ramos. Как связать стратегию, структуру, процессы и HR-политики в одну систему.

«Дизайн Agile-организаций» — русская книга с инструментами: тепловые карты, области ценности, метрики адаптивности.

Статьи — на agile-organizations.ru и scrum.ru.

Самые популярные посты за полгода
→ Отказ от Спринтов не решает проблему
→ Команды нельзя нанять — только спроектировать
→ Кейс: 58% автономности, 0% поставки
→ Как оценить вклад сотрудника?
→ Скользящие цели: ловушка
→ Две логики AI
→ На выходных снова стал программистом
→ «Я плачу миллиард — а всё едет как черепаха»

Чаще всего ссылаюсь на: стратегический фокус, организационные способности, однопоточная работа, зависимости по Томпсону.

Чем помогаю
Обычно ко мне приходят с задачами: сократить Time-to-Market, пересобрать команды под новую стратегию, защитить оргдизайн перед руководством — и уходят с решением, которое можно внедрить.

→ Персональная консультация — разбираем ваш кейс один на один: где застревает поток, с чего начать. Уходите с планом. Написать @fancydev
→ DAO Практикум — менторинг в группе 4–6 человек. За 4–8 недель проектируете 3–5 вариантов оргдизайна своей компании и выбираете тот, что реально внедрить и защитить перед руководством.
→ Designing Adaptive Organizations — за два дня учитесь проектировать организацию целиком: от макродизайна и связанности на уровне портфеля до структуры команд.
→ Системное мышление — учитесь видеть, почему любая повторяющаяся проблема возвращается снова и снова, где в системе рычаг, который её меняет, и как показать это людям так, чтобы они поддержали изменения.
→ AI Практикум — учитесь закрывать типичные управленческие сценарии с помощью AI и собираете своих AI-ассистентов под свои задачи. То, что занимало дни, начинает занимать часы.
Для связи — @fancydev.

Что еще рассказать?

⚡️ Будущее без узких специализаций

Кажется, наконец случилось то, о чем мы говорили последние лет десять.

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

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

Появляется титул «продуктовый разработчик» для всей команды.

И AI делает такой переход реалистичным. Я сам сейчас с AI занимаюсь всем: маркетингом, продажами, монтажом видео — выполняю активности, которыми раньше не мог заниматься.

Настоящая мультифункциональность становится возможной. Искренне рад, что мы до этого дошли.

Как меняются ваши команды?

⚡️ Кейс: как вернуть топам реальность

Разбирали кейс AI-трансформации. Цели спущены сверху, к середине года их еще ужесточили, команды соревнуются между собой.

Раз в месяц — большое орг-демо, где все показывают, как здорово автоматизировали работу агентами.

Потом приходишь к команде и просишь показать подробнее: хочу перенести к себе. И выясняется, что решение работает при десятке дополнительных условий, о которых на демо не сказали. Хотя выглядело как готовый инструмент. Получаются такие потемкинские деревни AI-трансформации.

Мы нарисовали причинно-следственные циклы, и вылез интересный механизм: чем сильнее давление по целям, тем красивее становится картинка наверх. А чем красивее картинка, тем хуже руководство понимает реальное состояние дел и тем менее адекватные решения принимает.

Например, наверху считают, что здесь уже все реализовано и можно двигаться дальше. А на самом деле здесь еще конь не валялся.

В Scrum на Sprint Review показывают только то, что соответствует Definition of Done. Тогда инспекция имеет смысл: есть прозрачность — работает эмпирический контроль. Нет прозрачности — остается театр, и решения принимаются по картинке, которой в реальности нет.

Если в компании есть общие демо-дни, вывод тот же: у демо-дня должен быть свой DoD.

У меня есть товарищ, который когда-то вел проект именно так: каждую неделю удивлял заказчика новым функционалом и скоростью разработки. Заказчик был в восторге. Потом вскрылось, что под этим лежит техдолг размером с сам проект, и переделывать пришлось почти все.

И еще две вещи, без которых DoD для демо не заработает. Команды не сравнивают между собой. За внедрение не платят премию. Пока за цифру в отчете что-то дают или отнимают, цифра будет рисоваться.

У вас демо или потемкинская деревня?

⚡️ AI-агент сам придумал и продал продукт

Нэт Элиасон дал своему OpenClaw-агенту Felix $1,000 и задачу построить бизнес. Через три недели Felix заработал $14,718.

Самое интересное — откуда взялись первые деньги. Felix сделал Felix Playbook — PDF-гайд о том, как настроить собственного AI-агента, упаковал его и запустил в продажу. Только за первую неделю продукт принес около $3,500.

То есть агент не просто выполнял заранее придуманный человеком бизнес-процесс. Он получил цель, а дальше участвовал в создании продукта, сайта, аккаунта в X и его продвижении.

Чтобы это работало, вокруг модели пришлось построить отдельную систему. У Felix трехуровневая память: ежедневные записи, знания и правила поведения. Heartbeat возвращает его к незавершенным задачам, cron jobs запускают регулярную работу, а сложную разработку он может делегировать coding-агенту и потом контролировать результат.

Отдельно продуманы границы автономности. Telegram владельца — доверенный канал команд. Email и соцсети — источники информации. Для GitHub, Stripe, кошельков и деплоя используются отдельные аккаунты.

И вот это для меня самая интересная часть кейса: автономный AI-бизнес оказался задачей организационного дизайна. Нужно спроектировать память, полномочия, границы, механизмы контроля и взаимодействие между исполнителями.

Что в этом кейс самое интересное / крутое для вас?

⚡️ Системное мышление подорожало

Прямо сейчас у меня параллельно идут четыре потока по системному мышлению — около сорока человек одновременно. И результаты, которые они показывают, впечатляют: люди решают кейсы, вокруг которых ходили кругами не первый месяц, и наконец видят, за какую ниточку тянуть.

Откуда такой спрос — мне понятно. Узкие специализированные навыки дешевеют на глазах, их всё увереннее забирает AI. И на этом фоне дорожает то, что лежит в основании: философия, бережливое мышление, теория очередей, системное мышление. Видеть систему целиком и решить, куда бить, — работа человека.

Элизабет Стоун, директор по продукту и технологиям Netflix, рассказывала об этом у Ленни Рачицкого: при найме она теперь смотрит в первую очередь на системных мыслителей, а глубокая узкая экспертиза отходит на второй план. Логика простая — экспертиза устаревает вместе с инструментом, а понимание взаимосвязей переносится в любой домен.

Заодно я выложил в открытый доступ свой скилл для Claude. Он собирает историю, вытаскивает переменные, определяет архетип, строит диаграмму циклов (CLD) и ищет точки приложения усилий. Внутри 11 системных архетипов, 12 рычагов Медоуз, разбор по айсбергу и девять эталонных кейсов.

Системное мышление становится мощной практикой для лидеров, и для этого есть программа Professional Systems Thinker. Следующий поток собирается на 3 ноября: восемь модулей, от основ до сложных многоконтурных историй. К середине вы берёте свою настоящую хроническую проблему из организации и ведете ее через всю программу как сквозной кейс — с разбором каждую неделю, пока не появится работающее решение. Группы я держу небольшими и стартую от восьми человек: наберётся раньше — начнём раньше, так что заглянуть на страницу лучше сейчас.

В какой системе вам нужно детально разобраться?

⚡️ Взрослые люди сами себя оценивают

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

Потом менеджер говорит: «Люди не готовы к самоорганизации». Но дело не в людях. Просто есть система, в которой взрослые ведут себя как дети. Если только менеджер нанимает, увольняет, оценивает и распределяет деньги, другого поведения ждать странно.

В Haier, компании примерно с 80 000 сотрудников, система другая. Раз в месяц сотрудники получают прозрачную performance-оценку. Все видят, кто сколько получил и за что. Три звезды — нормальный результат. Четыре-пять — выше награда. Две и ниже — ниже доход, меньше шансов на новые контракты, talent pool, в пределе — выход из компании.

Это как рейтинг в Airbnb или Uber. Работа превращается в репутацию, а репутация влияет на деньги и возможности. Оценка не просто социальная, она тотально прозрачная. Она полезна именно потому, что ее видят все.

Армвин Трост описывает тот же принцип через P2P-оценивание, peer recognition и выборные комиссии по зарплатам. Практики разные, принцип один: право оценивать должно принадлежать не боссу, а социальному окружению, а результат оценки должен быть виден всей системе.

Поэтому в моей методологии DAO, версия 2 появился новый гайдлайн — «Социальная оценка вклада».

Хотите взрослых людей — проектируйте взрослую систему.

Как вам такое?

⚡️ Максимизируйте зависимости между командами

Звучит почти как вредный совет. Мы привыкли считать зависимости проблемой и проектировать команды так, чтобы они как можно меньше зависели друг от друга.

Бас Водди, со-создатель LeSS, собрал хороший список практик командной работы. Для контекста: LeSS — это мультикомандный Scrum, когда несколько команд вместе разрабатывают один продукт.

И здесь важна оговорка. Все эти советы имеют смысл, если вам нужны высокая адаптивность и скорость. Если это не ваша цель, часть практик действительно может оказаться плохим советом.

Что стоит избегать внутри команды:
- каждый работает над своей задачей;
- работа идет по цепочке UX → разработка → тестирование;
- каждый держится только за свою специализацию;
- большие фичи растягиваются на много спринтов;
- команда блокируется зависимостями и берет следующую работу.

Что пробовать внутри команды:
- детальная вторая часть Sprint Planning и мелкие задачи;
- несколько Daily Scrum за день;
- несколько пар работают над одной задачей;
- вся команда работает над кодом вместе (моб-программирование);
- вся команда сосредотачивается на одной задаче (сворминг);
- пожертвовать одним человеком: он берет на себя внешние прерывания, пока остальные работают вместе.

И самое интересное — практики между командами:
- никакой предварительной раздачи задач командам;
- максимизировать зависимости: связанные задачи специально брать разным командам;
- временно объединять две команды на спринт;
- проводить общую вторую часть Sprint Planning;
- подключаться ко второй части Sprint Planning другой команды;
- временно переходить в другую команду (путешественник);
- выделять ведущую команду для большой инициативы (Leading Team).

Мне особенно нравится идея максимизации зависимостей. Если постоянно защищать команды от совместной работы, знания и контекст тоже останутся внутри отдельных команд. А здесь зависимость сознательно используют как повод работать и учиться вместе.

Какие практики попробовали бы?

⚡️ Как делить фичи между value areas

Продолжаю допиливать свое программное обеспечение для проектирования организаций, которое собрал с помощью вайбкодинга. Недавно добавил туда области ценности — value areas — прямо в тепловую карту (heatmap).

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

Теперь в инструменте для каждой value area отдельно пересчитываются тепловая карта, 80% самых частотных компонентов и аналитика автономности.

Но дальше возникает практический вопрос: что делать с фичей, которая попадает сразу в несколько value areas?

Предлагаю такую логику:
- если фича подходит нескольким value areas — смотрим на саму фичу и решаем, какая область лучше ее покрывает;
- если необходимые компоненты есть только у команд одной области — команды этой области берут фичу;
- если нужны возможности команд из нескольких областей — команды координируются;
- такое взаимодействие можно использовать, чтобы команды осваивали недостающие компоненты;
- если похожие фичи повторяются, это сигнал постепенно расширять покрытие команд.

Мне нравится этот принцип: границы value areas задают специализацию, но не превращают продукт в жестко нарезанные куски.

Как делите спорные фичи?

⚡️ Семь принципов оргдизайна

Сейчас готовлю вторую версию методологии Designing Adaptive Organizations (DAO) и заодно попробовал сформулировать принципы, на которые в действительности опираюсь, когда помогаю проектировать организации.

Получилось семь.

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

2. Оптимизировать целое, а не части. Максимизировать результат всей системы, даже если локально это ухудшает показатели отдельных команд, функций или подразделений.

3. Оптимизировать поток, а не ресурсы. Минимизировать lead time и время ожидания, даже если специалисты в итоге загружены меньше.

4. Устранять очереди, а не управлять ими. Искать и устранять причины их появления. Kanban, уменьшение рабочих пакетов и управление потоком полезны, но сами по себе источник очереди не убирают.

5. Устранять зависимости, а не управлять ими. Менять границы и формировать e2e-юниты, даже если ради этого приходится дублировать компетенции и терять часть экономии от масштаба.

6. Балансировать автономию и экономию от масштаба. Давать e2e-юнитам достаточно автономии для быстрого потока. Общими оставлять те способности, где выигрыш от масштаба перевешивает стоимость возникающих зависимостей.

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

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

Какой принцип вам ближе?

⚡️ AI ускоряет людей. Компанию — нет

В свежем исследовании McKinsey есть интересное противоречие. 80% респондентов говорят, что AI повысил их личную продуктивность. Но только 37% видят вклад AI в EBIT компании — и эта доля почти не изменилась за год.

Для системного мышления здесь нет ничего удивительного. Рассел Эйкофф формулировал эту мысль примерно так:

«Эффективность системы определяется взаимодействием ее частей, а не эффективностью каждой части по отдельности».

AI сегодня отлично ускоряет отдельные части организации: разработку, аналитику, маркетинг, работу менеджеров. Но это классическая локальная оптимизация. Если работа потом ждет другую команду, согласование или решение руководителя, выигрыш растворяется в очередях.

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

И данные McKinsey хорошо это показывают: почти три четверти AI high performers фундаментально перепроектируют workflows, тогда как среди остальных организаций это делает примерно четверть.

Отсюда мой prediction: маленькие компании и предприниматели могут получить от AI непропорционально большой выигрыш. Им проще менять весь поток работы. Большим организациям придется перепроектировать процессы, границы команд и структуры власти. А на такие изменения они идут гораздо тяжелее.

Как вам такой вывод?

⚡️ RenDanHeYi: каждый становится предпринимателем

С удовольствием прочитал Start-up Factory — книгу Joost Minnaar и Pim de Morree о модели RenDanHeYi в Haier. Это одна из самых радикальных моделей организации работы.

Идея RenDanHeYi — заменить значительную часть иерархии сетью предпринимательских единиц, связанных рынком, контрактами и экономическими результатами.

Вместо привычных функций и департаментов — тысячи microenterprises со своим P&L и широкими правами на решения. Одни работают напрямую с внешним клиентом, другие продают им внутренние сервисы. Отношения между ними строятся через контракты.

Особенно интересно это работает с shared services. В обычной компании HR, Finance, IT, закупки — монополисты. Нужен сервис — выбора нет. В Haier microenterprise может расторгнуть контракт с внутренним поставщиком, выбрать другого или купить услугу на внешнем рынке. Если внутреннюю функцию нельзя заменить, это монополия.

Внутренний рынок касается и денег конкретного человека. Есть базовый доход, своего рода safety net, а существенная часть заработка зависит от того, какую ценность создала microenterprise. Достигли результата — появляется дополнительный пул. Создали больше ценности — пул растет. Дополнительный profit команда распределяет внутри себя.

Поэтому принцип Haier «каждый становится предпринимателем» — не метафора. Система напрямую связывает каждого участника microenterprise с клиентом и экономическим результатом: получил ли клиент ценность, выполнен ли контракт, заработала ли microenterprise.

И здесь интересна связь с проблемой вовлеченности, engagement. Обычно компании пытаются лечить ее опросами, программами вовлеченности и работой менеджеров. Haier меняет экономическую систему, чтобы у человека была прямая связь между клиентом, результатом и собственным выигрышем.

Что интересно, сама идея не новая. Еще Russell Ackoff в Re-Creating the Corporation описывал мультиразмерную организацию и внутреннюю рыночную экономику: клиентские, продуктовые и сервисные единицы взаимодействуют как покупатели и поставщики, а внутренние функции лишаются гарантированной монополии.

Haier довел эту логику до радикальной практики: контракты вместо распоряжений, рынок вместо внутренних монополий, profit sharing вместо фиксированной зарплаты, предприниматели вместо сотрудников.

А вы смогли бы работать в такой системе? Что в ней кажется сильным, а что опасным?

Стратегия, AI и организационный дизайн pinned a photo

⚡️ 5 инструментов для диагностики организации

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

Нужно понять, где застревает работа, почему решения вязнут в согласованиях, а совместное решение задач требует много координации.

Я записал пять коротких видео про инструменты диагностики, которые использую сам:
- Value Stream Mapping — показывает бутылочные горлышки;
- функциональный анализ — конфликты целей;
- карта зависимостей — координацию работы и фрагментацию организации;
- DSM-матрица — тип зависимостей;
- матрица CU — цену задержки.

В каждом видео примерно по пять минут. Разбираю, какие данные собирать, что показывает каждый инструмент и как соединить результаты в общую картину.

По ссылке откроется Telegram-бот:
пять видео

Какие инструменты используете вы?

⚡️ Собирайте свой набор навыков

Дочитал Скотта Адамса «Как потерпеть неудачу почти во всем и все-таки выиграть по-крупному». Книгу пересказывать не буду, но одна идея меня зацепила.

Адамс называет ее talent stack — набор навыков. Его мысль простая: не обязательно становиться лучшим в мире в чем-то одном. Можно стать достаточно хорошим в нескольких вещах, которые усиливают друг друга.

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

Мне эта идея очень отзывается, потому что я, кажется, интуитивно всегда делал примерно так же. Постоянно учился чему-то новому, добавлял новые навыки и соединял их с тем, что уже умею.

И чем дальше, тем больше мне нравится сама логика: ценность создает комбинация навыков, а не один отдельно взятый навык.

Какой стек собираете вы?