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

в этом и ошибка. Вы оправдываете неэффективный менеджмент размером команды, вместо рассмотрения проблемы out of box

проблема сложнее. К таким специалистам периодически накапливается очередь задач, которая растёт со временем. Это убивает рабочий процесс, и требует массу рутинной менеджерской работы для разруливания. Во многом Agile коучи живут именно на системном разрешении таких очередей, после чего рабочий процесс становится существенно прозрачнее и приятнее для участников

Только в оценочной части. "Хорошо" или "неизбежное зло"

Я это формулирую так: "пока одни делают абы что, другие фигачат абы как"

что лучше?

Лучше отсутствие ярлыков и органическая специализация

адаптивная антихрупкость? )

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

Термин существует и это очень хорошо, с этим нет возможности спорить! :)

Либо, если есть желание бодаться, прокачивая менеджерский скилл, то можно и побадаться