Saboteur

К примеру на Java пишут банковский софт, в котором учитывают ценные бумаги, и программист закрывает таски, например, создать кнопочку (написать модуль) для списания с баланса реализуемых ценных бумаг по методу ФИФО. А потом появляется новое требование к модулю, чтобы можно было и по методу ЛИФО, а потом решили все переделать по указке бухгалтерии и сделать все по средней себестоимости.

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

Вы реально считаете, что программирование возможно без этой "мути" ?

1. Нанять программистов на свои деньги и манаджить ими.
2. Понятие "джуниор менеджер" конечно существует, но таких открытых вакансий практически нет, поскольку заполнить их довольно легко. Из кодера в менеджеры - никак. Из разработчика - ну хотя бы уверенный мидер, который активно проявил себя в организации работы, чаще тимлид.
3. Учить - английский - хороший разговорный upper intermediate просто минимум.
4. Управление проектами - разные виды SDLC, софт для работы с этим (JIRA, excel, MSProject, да и поверпоинт пригодится).
5. Софт-скиллы - коммуникацию, организацию, политику и понимание внутренней кухни работы компаний (этому часто помогает образование с экономическим или юридическим уклоном)

Архитектор - в первую очередь опыт работы, в идеале в разных проектах, чтобы понимать на практике разницу между реализацией разных SDLC.

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

Архитектор, бизнес-аналитик и менеджер - три звена, которые создают основу работы проекта, каждый со своей стороны.
Бизнес-аналитик - должен максимально разбираться в бизнесе заказчика, чтобы понимать значение требований и переводить их для исполнителей.
Архитектор - должен как минимум немного разбираться в бизнесе, но его основная задача - решить как воплощать требования бизнеса. Определять железо, технологии, требования. Говорить, что "вот для этого нужно использовать 10 этого и 20 этого, и использовать вот такие языки, библиотеки, платные решения". Техническое hi-level видение проекта.
Менеджер - по согласованию с бизнес-аналитиком и архитектором должен решать кадровые вопросы. Количество людей, качество людей, работу команды, тайминги, офис и оборудование - все денежные вопросы. Отчеты. Договариваться, убеждать заказчика о ценах и сроках. Выбивать новые задачи и развивать проект. Следить за настроением в команде.

Переход программист-архитектор не всегда последователен. Он должен быть инициирован программистом.

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

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