Карьерные треки: эксперт, менеджер, архитектор, фриланс, свой продукт

Года через три-четыре после первой работы почти каждый упирается в один и тот же разговор. Задачи стали понятными, код пишется, ревью проходят, но неясно, куда двигаться дальше. На этот момент обычно приходит совет из двух вариантов: «расти в тимлида» или «расти в сеньора». Совет плохой, потому что вариантов не два, а как минимум пять, и они отличаются не престижем, а тем, из чего состоит рабочий день и за что вам платят.

Эта статья — карта. Не «кем стать», а «что там внутри, во что это обойдётся и как проверить заранее». Про грейды внутри инженерного трека уже было в Грейды, про механику роста и ревью — в Как расти, про деньги — в Зарплата и своя цена. Здесь — про развилки между разными видами работы, а не между ступенями одной.

Лестница — плохая метафора. Решётка — лучше

Карьеру рисуют лестницей: junior → middle → senior → lead → и дальше вверх. Метафора врёт в двух местах. Во-первых, наверху лестница разветвляется, и ветки — это не «выше/ниже», а «другая работа». Во-вторых, по лестнице ходят вверх, а по реальной карьере ходят во все стороны, включая назад, и это нормально.

Более честная картинка — решётка (термин из книги Cathy Benko «The Corporate Lattice»): две оси, по одной растёт масштаб последствий, по другой меняется способ влиять на мир — своими руками или через других людей.

Из этой картинки следуют три вещи, которые экономят годы.

1. Движение вправо — не повышение. Менеджер не «старше» сеньора. Это другая профессия с другими навыками, другими метриками успеха и другим набором того, что вас злит.
2. Движение обратно влево — не провал. Человек, поработавший год менеджером и вернувшийся в инженеры, стоит дороже, чем был: он теперь понимает, откуда берутся сроки и почему его любимый рефакторинг не приоритизируют.
3. Пунктирные прямоугольники сверху — фриланс и свой продукт — вообще не про место на решётке компании. Там вы меняете не работу, а её экономику: кто несёт риск и кто ищет клиента.

Три вопроса, которые определяют выбор лучше любых тестов

Профориентационные опросники здесь бесполезны. Работают три конкретных вопроса, на которые надо отвечать не «как правильно», а честно.

Первый: от чего вы устаёте больше — от людей или от неопределённости? Менеджерский день состоит из разговоров: пятнадцать контекстных переключений, чужие эмоции, конфликты, повторяющиеся объяснения. Экспертный день состоит из задач, которые никто не знает как решать, и долгого сидения в неприятном состоянии «я не понимаю». Обе усталости реальны, но они разные, и одна для вас переносима, а другая — нет.

Второй: что для вас «сделал»? Инженер закрывает день с ощущением «работает». Менеджер часто закрывает день, ничего не сделав своими руками: результат — в том, что три человека не заблокированы. Если вам физически нужен артефакт в конце дня, менеджмент будет мучением первые полгода минимум, а у части людей — всегда.

Третий: готовы ли вы, чтобы ваш доход зависел от продаж? Не от вашей квалификации, а от того, нашли ли вы клиента в этом квартале. Это водораздел между наймом и фрилансом/своим продуктом, и он гораздо важнее, чем «люблю ли я свободный график».

Дальше — по трекам. Для каждого: что там делают на самом деле, зачем это компании, где ломается, и как проверить, ваше ли это, не увольняясь.

Типичные траектории во времени

Ни одна из них не обязательна и ни одна не «правильная». Полезно видеть, что развилка случается не один раз.

Важная деталь, которую редко говорят: средний срок в одной роли — 2-4 года, и почти никто не идёт по одной ветке всю жизнь. Возврат из менеджмента в инженеры — настолько частая история, что в крупных компаниях для неё есть отдельная процедура и негласное правило «дверь остаётся открытой год».

Трек 1: эксперт (individual contributor, staff/principal)

Что это на самом деле

Расхожее представление: эксперт — это человек, который очень хорошо пишет код. Неправда. Выше сеньора код перестаёт быть главным продуктом. Главный продукт staff-инженера — решённые проблемы, которые никто не хотел брать, потому что они слишком размытые.

Типичные задачи реального staff-инженера:

• «У нас растёт время сборки, релиз занимает три дня, никто не знает почему» — и через два месяца релиз занимает два часа, а половина работы была не в коде, а в убеждении четырёх команд поменять свои пайплайны.
• «Мы третий год не можем выкатить единую авторизацию» — потому что это не техническая задача, а миграция, затрагивающая семь сервисов и три команды с разными приоритетами.
• «Надо решить, переезжаем ли мы на новую очередь сообщений» — и результат работы это документ на восемь страниц, а не прототип.

То есть работа эксперта — тоже про влияние на людей, но валютой служат не поручения, а аргументы, прототипы и репутация. Tanya Reilly в «The Staff Engineer’s Path» называет это «влияние без полномочий»: вы не можете никому приказать, но можете сделать так, чтобы правильное решение стало очевидным.

Как выглядит неделя

Грубая раскладка, которая держится у большинства знакомых мне staff-инженеров:

Если в вашей компании staff-инженер пишет код 80% времени — скорее всего, это не staff, а сеньор с красивым титулом. Это не оскорбление, просто разные вещи; см. про расхождение титула и содержания в Грейды.

Где ломается

• Титул без полномочий. Вам дали «principal», но решения по-прежнему принимает CTO на кухне, а вас зовут постфактум. Диагностика простая: посмотрите, кто последний говорит в спорном обсуждении и меняется ли что-то после ваших документов.
• Эксперт по одному легаси. Вы стали незаменимы для системы, которую никто больше не понимает. Внутри компании это власть, на рынке — ноль. Проверка: если вашу текущую специализацию невозможно описать в двух строках вакансии, у вас проблема.
• Одиночество. Задачи всё более размытые, обратной связи всё меньше, «сделал» наступает раз в квартал. Часть людей от этого выгорает быстрее, чем от переработок; про механику — https://courses.digitable.life/post/time-management/15-burnout/.
• Отсутствие трека выше сеньора. В компаниях меньше 50-70 инженеров staff-уровня просто нет: некому делегировать, нечего координировать. Это структурное ограничение, а не ваша проблема, но менять придётся компанию, а не себя.

Как проверить, не увольняясь

Возьмите одну «ничейную» проблему — не задачу из бэклога, а именно проблему, на которую все жалуются и никто не отвечает. Доведите до документа с вариантами и рекомендацией. Если вам понравился процесс (а не только результат) и если документ реально изменил чьё-то поведение — трек ваш.

Трек 2: менеджер (tech lead → engineering manager → head)

Что меняется в первый же месяц

Первое открытие новоиспечённого менеджера: у вас больше нет своей работы, у вас есть чужая. Ваш результат — это то, что сделала команда, и вы влияете на него косвенно. Camille Fournier в «The Manager’s Path» описывает это как смену единицы измерения: раньше вы мерили себя задачами, теперь — тем, стало ли команде проще работать.

Второе открытие: время фрагментируется. Классическое эссе Пола Грэма Maker’s Schedule, Manager’s Schedule объясняет, почему это не «плохой тайм-менеджмент», а устройство роли: менеджерский календарь нарезан часовыми слотами, и попытка удержать в нём инженерный блок в четыре часа обычно заканчивается тем, что вы кодите вечером и злитесь на всех.

Обратите внимание, что в этой цепочке менеджер не сделал ничего технического — и при этом без него разработчик потерял бы неделю. Если такая работа кажется вам «ничем», это важный сигнал. Про роли и их границы подробнее — Кто есть кто в команде, про постановку задач и делегирование — https://courses.digitable.life/post/management/task-delegation/.

Из чего состоит менеджерская работа

• Люди. Регулярные 1:1, обратная связь, план развития, разговоры о деньгах и повышениях, иногда — увольнения. Последнее не обсуждают в статьях про карьеру, но это часть работы, и первое увольнение помнят все.
• Найм. Скрининг, интервью, калибровка оценок, оффер. Целиком разобрано в Как проводить собеседования — это отдельный навык, и плохие менеджеры чаще всего плохи именно здесь.
• Процесс и поставка. Планирование, приоритеты, риски, отчётность наверх. Пересекается с проектным управлением; методы — в треке Управление проектами.
• Защита команды. Отбивать нерелевантные запросы, добывать ресурсы, объяснять наверх, почему квартал техдолга — не блажь (см. Поддержка и техдолг).

Типичные ошибки первого года

1. Остаться главным разработчиком. Самая распространённая. Вы забираете самые интересные задачи, команда деградирует, вы не успеваете ни там, ни там. Правило: если задача на критическом пути релиза, вам её брать нельзя — вас в любой момент выдернут.
2. Стать диспетчером. Пересказывать задачи из Jira в чат и обратно. Такой менеджер не нужен ни команде, ни компании, и это первая роль, которую сокращают.
3. Дружить вместо руководить. Особенно больно, когда вас повысили внутри своей же команды. Отношения меняются в тот же день, независимо от вашего желания; лучше проговорить это вслух, чем делать вид, что ничего не произошло.
4. Копить обратную связь до ревью. Человек узнаёт о проблеме через полгода, когда исправить уже нельзя. Механика нормальной обратной связи — в Как расти.
5. Считать, что технические навыки теперь не нужны. Нужны, но иначе: не чтобы писать код, а чтобы отличать оценку «две недели» от оценки «две недели, потому что страшно».

Обратный переход

Про него надо знать заранее: примерно каждый третий уходит обратно в инженеры, и это хорошая новость, а не грустная. Условия удачного возврата: не запускать технические навыки полностью (ревью, участие в дизайне), уходить до того, как начнёте ненавидеть работу, и честно сказать причину — «мне не подошло», а не изобретать легенду. Компании, где возврат считается позором, обычно плохи и во всём остальном.

Трек 3: архитектор

Почему это самое запутанное слово в отрасли

«Архитектор» означает три разные должности, и на собеседовании обязательно надо уточнять, какую именно имеют в виду.

Разница огромная. В аутсорсе solution architect половину времени проводит с клиентом и в презентациях — это ближе к пресейлу, чем к инженерии (см. Какие бывают проекты). В энтерпрайзе enterprise architect может годами не открывать IDE (см. Энтерпрайз изнутри). В продуктовой компании архитектор чаще всего просто самый опытный инженер, который держит целостность системы — и тогда трек сливается с экспертным.

Что реально составляет работу

Главный артефакт архитектора — зафиксированное решение с явными компромиссами. Не диаграмма, не красивый слайд, а документ формата ADR: контекст, варианты, выбор, последствия, что мы осознанно приносим в жертву. Как это устроено — подробно в https://courses.digitable.life/post/architecture-patterns/11-architecture-decisions/, а базовые приёмы проектирования систем — в https://courses.digitable.life/post/architecture-patterns/12-system-design/ и https://courses.digitable.life/post/ddd/01-strategic-design/.

Второй артефакт — границы. Где проходит шов между сервисами, кто владеет какими данными, кто с кем разговаривает и по какому контракту. Это то, что дороже всего менять потом, — и именно поэтому за это отвечает отдельный человек (см. Проектирование).

Ключевой момент — цикл «ОбсуждениеСКомандами → Варианты». Архитектор, который рисует решение в одиночку и приносит готовое, получает саботаж: команда не считает решение своим и обходит его при первой возможности.

Где ломается

• Ivory tower. Классический антипаттерн: человек не пишет код три года, рисует схемы, которые невозможно реализовать, и не узнаёт об этом, потому что ему никто не говорит. Лечится участием в дежурствах и в разборах инцидентов (см. Релиз и эксплуатация): архитектор, которого будят ночью из-за собственного решения, проектирует заметно осторожнее.
• Архитектура как бюрократия. Архитектурный комитет, куда надо приносить каждый чих, превращается в очередь согласований и убивает скорость. Здоровый вариант: комитет решает только то, что дорого откатить, остальное — на усмотрение команд.
• Отсутствие обратной связи от продакшена. Решение принято, последствия наступят через два года, к тому времени автора уже нет. Отсюда практика ревизии ADR через квартал/год.

Как проверить

Напишите ADR на решение, которое ваша команда принимала недавно, — задним числом, честно, с вариантами и минусами выбранного. Дайте почитать тому, кто в нём участвовал. Если получилось описать компромисс так, что человек сказал «да, ровно так и было, но я это не формулировал», — у вас есть склонность к этой работе.

Трек 4: фриланс и консалтинг

Что здесь меняется по-настоящему

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

Полезная оценка, которую стоит сделать до прыжка: сколько часов в неделе вы реально сможете продать. Ответ у большинства — 20-25 из 40. Остальное съедают поиск клиентов, созвоны, оценки, счета, налоги, простой между проектами и то, что вы не робот.

Диаграмма — это и есть суть фриланса. Заметьте: собственно «Работа» — одно состояние из тринадцати. Всё остальное — то, чем на найме занимаются другие люди.

Экономика: как считать ставку

Здесь важно не выдумывать числа, а понимать метод. Вилок я не называю намеренно — рынок меняется быстро, а по нишам и странам разброс кратный. Считать надо так:

годовая потребность = желаемый доход после налогов
                    + налоги и взносы
                    + отпуск и болезни (то есть неоплачиваемые недели)
                    + оборудование, софт, обучение, бухгалтер
                    + резерв на простой между проектами
                    + плата за риск (у вас нет оплачиваемого больничного и выходного пособия)

продаваемые часы в год = недели работы x реально продаваемые часы в неделю

минимальная ставка = годовая потребность / продаваемые часы в год

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

Ориентиры по рынку берите там же, где и для найма, — открытые источники, разобранные в Зарплата и своя цена: Хабр Карьера, getmatch, levels.fyi, отчёты рекрутинговых агентств, публичные ставки на биржах. Плюс специфичное для фриланса: смотрите, за сколько ваши будущие конкуренты продают похожие проекты целиком, а не по часам.

Модели оплаты

Практическое правило: фикс берут только на то, что делали раньше. Всё новое — почасово или через оплачиваемый этап оценки/дискавери.

Красные флаги клиента

• Не может назвать, кто принимает финальное решение.
• Просит «сначала посмотреть, что получится», без оплаты этапа.
• Отказывается от предоплаты и от поэтапной приёмки.
• Скоуп меняется трижды за время переговоров — он изменится ещё десять раз в работе.
• Предыдущий подрядчик «оказался мошенником» (иногда правда, но чаще — вы следующий в списке «оказавшихся»).

Плюсы, о которых говорят реже

Не только деньги и свобода. Фриланс даёт разнообразие контекстов: за три года вы увидите десяток кодовых баз и способов организовать работу, тогда как на найме — одну-две. Это делает вас заметно быстрее в диагностике: вы уже видели этот тип боли. Многие возвращаются в найм после фриланса на позицию заметно выше именно поэтому.

Минусы, о которых говорят реже

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

Трек 5: свой продукт

Две очень разные версии

Их постоянно смешивают, а стратегии там противоположные.

Микро-продукт (indie/bootstrapped). Делаете сами или вдвоём, живёте на выручку с первого дня, цель — доход, сопоставимый с зарплатой, без внешних денег. Реалистично, но медленно; типичный срок до заметной выручки — год-два, и большая часть работы — не код, а поиск канала привлечения.

Стартап с инвестициями. Цель — быстрый рост и следующий раунд, вы берёте на себя обязательства перед инвесторами, доля размывается, работа регулируется метриками роста. Устройство изнутри, включая опционы, вестинг и почему «доля в стартапе» не равна деньгам, — в Стартап изнутри.

Чем занят основатель-разработчик

Распределение времени у выживших микро-продуктов примерно такое: разработка — от четверти до трети, всё остальное — поиск клиентов, поддержка, контент, продажи, платежи, юридическое, переписка. Разработчики стабильно ошибаются в одну сторону: строят фичи, потому что это знакомо и приятно, и откладывают то, где страшно, — разговоры с людьми, которые могут сказать «мне это не нужно».

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

Честная статистика и как её читать

Формулировки вроде «90% стартапов умирают» бесполезны: считают по-разному, выборки кривые. Что полезно знать точно: у CB Insights есть регулярно обновляемый разбор причин смерти стартапов, и первая причина стабильно — не техническая, а «нет потребности на рынке» и «кончились деньги». То есть умирают не от плохого кода. Разработчику это неприятно, потому что именно код — единственная часть, которую он контролирует полностью.

Реалистичный вход без прыжка в пропасть

Обратите внимание на порядок: деньги и спрос проверяются до написания продукта, а увольнение стоит последним, а не первым. Обратное («уволюсь и полгода буду делать продукт») — самый дорогой способ узнать, что продукт никому не нужен.

Про юридическую сторону: до первых денег стоит разобраться, как у вас оформляется самозанятость/ИП/компания, что написано в трудовом договоре про интеллектуальную собственность (во многих договорах код, написанный в период работы, может считаться принадлежащим работодателю — формулировки различаются, читать надо конкретный документ) и с какого момента возникают налоговые обязанности.

Гибридные и смежные направления

Пять треков — не весь список. Несколько направлений, куда часто уходят и о которых редко пишут в статьях про карьеру:

• SRE / платформенная инженерия. Инженерный трек с фокусом на надёжность и на инструменты для других команд. Клиенты — свои же разработчики. См. https://courses.digitable.life/post/devops/16-observability-and-oncall/.
• Data / ML-инженерия. Требует докупить математику и работу с данными, но вход из бэкенда относительно логичен: https://courses.digitable.life/post/data-engineering/00-overview/.
• AI-инженерия. Быстро формирующаяся ниша на стыке продукта и LLM: https://courses.digitable.life/post/ai-engineering/00-overview/. Осторожно: часть вакансий здесь — переименованный бэкенд, надо смотреть содержание.
• QA-автоматизация и качество как специальность: https://courses.digitable.life/post/testing/15-qa-career/.
• DevRel, техписательство, преподавание. Если вам нравится объяснять и вы замечаете, что коллеги приходят за объяснениями, — это может стать основной работой. Риск: навыки разработки без практики деградируют за 1-2 года.
• Продакт-менеджер из разработчика. Переход реален, особенно в B2B и в инфраструктурных продуктах, где технический бэкграунд — преимущество. Что придётся освоить: https://courses.digitable.life/post/product-management/03-prioritization/ и метрики.
• Скрам-мастер / agile-коуч. Отдельная профессия, а не «менеджер без власти»: https://courses.digitable.life/post/scrum-master/00-overview/.

Как выбирать: не решением, а экспериментом

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

Практический алгоритм, если вы застряли на развилке.

Все «эксперименты» на схеме объединяет одно: они занимают от месяца до квартала, не требуют увольнения и дают настоящий сигнал вместо фантазии о профессии.

Деньги по трекам: как думать, а не какие цифры

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

• Эксперт. Оклад плюс бонус, привязанный к грейду; в компаниях с длинной инженерной лестницей потолок сопоставим с директорским. Где лестницы нет — упирается в senior быстро.
• Менеджер. Тот же оклад, но больше доля переменной части, привязанной к целям подразделения; выше по уровням растёт доля долгосрочных инструментов (акции, опционы).
• Архитектор. Сильно зависит от вида: в интеграторах и вендорах часто есть привязка к продажам и пресейлу, что меняет структуру дохода.
• Фриланс. Ставка вместо оклада, ноль в отпуске, полная ответственность за налоги и за простой. Средний доход считать по году, а не по хорошему месяцу.
• Свой продукт. Долгий отрицательный участок, потом либо ноль, либо хвост, который не ограничен ничем. Медиана по индустрии — ближе к нулю, чем к историям успеха.

Как исследовать рынок под конкретный трек: смотреть агрегаторы (Хабр Карьера, getmatch, levels.fyi), отчёты рекрутинговых агентств и зарплатные обзоры, изучать формулировки вакансий именно на целевой роли — по требованиям видно, что компания подразумевает под «архитектором» или «staff». Метод сбора данных и подготовка к разговору о деньгах подробно разобраны в Зарплата и своя цена и Переговоры об оффере; при смене трека почти всегда работает правило: обсуждать надо не только сумму, но и содержание роли, иначе купите титул и получите старую работу.

Типичные ошибки при смене трека

1. Уходить от, а не к. «Надоел легаси» — не причина становиться менеджером. Уход от проблемы приводит в другую роль с другими проблемами, а вы к ним ещё и не готовы.
2. Соглашаться на роль без проверки содержания. Спросите на собеседовании: чем занимался человек на этой позиции последние три месяца, по неделям. Ответ «ну, разное» — сигнал, что роль не определена. Как задавать такие вопросы — Как проходить собеседования.
3. Считать первый месяц показательным. В любом новом треке первые недели ужасны — вы некомпетентны в вещах, которые казались простыми. Судить стоит месяца через три-четыре; про механику адаптации — Первые 90 дней.
4. Сжигать мосты. Индустрия маленькая, и через пять лет ваш бывший тимлид будет собеседовать вас или покупать ваш продукт.
5. Ждать разрешения. Никто не придёт и не скажет «ты готов». Обычно роль сначала делают неофициально, а титул приходит потом — и это правильный порядок.
6. Менять трек ради денег в моменте. Разница в доходе между треками на одном уровне обычно меньше, чем разница между «занимаюсь тем, что переношу» и «занимаюсь тем, от чего тошнит через год».

Что делать прямо сейчас, если до развилки ещё далеко

Даже если вы недавно начали, есть дешёвые действия, которые расширят выбор потом.

• Ведите журнал работы — что делали, что получилось, что решили. К моменту развилки у вас будут данные, а не ощущения. Формат — Как расти.
• Пишите. Дизайн-документы, ADR, разборы инцидентов, посты. Все три инженерных трека выше сеньора требуют письменного мышления, и это единственный навык, который одинаково полезен во всех пяти направлениях.
• Берите разное. Раз в год — задача из незнакомой области: инфраструктура, аналитика, работа с клиентом. Дешёвая разведка треков.
• Разговаривайте с людьми на треках. Не «как стать архитектором», а «расскажи, что ты делал вчера по часам». Второй вопрос даёт в десять раз больше информации.
• Не выбирайте окончательно. Через пять лет часть этих ролей будет называться иначе, а часть появится заново — сравните, как выглядела карьера мобильного разработчика в 2010-м и в 2020-м.

Мини-итог

• Карьера — решётка, а не лестница: движение вбок и назад так же нормально, как вверх.
• Эксперт влияет аргументами и артефактами, менеджер — через людей, архитектор — через зафиксированные границы и компромиссы. Это три разные профессии, а не три ступени одной.
• Фриланс и свой продукт меняют не должность, а экономику: вы берёте на себя риск и функцию продаж, и это стоит считать до, а не после.
• Выбирать надо экспериментом на квартал, а не решением на всю жизнь; почти все переходы обратимы, разница только в цене отката.
• Деньги в каждом треке устроены по-разному по структуре, а не только по величине; цифры надо брать из свежих открытых источников под конкретную роль и регион, а не из чужих историй.

Источники и что почитать

• Camille Fournier, The Manager’s Path — что происходит с человеком на менеджерском треке, от tech lead до CTO, включая честные главы про то, кому это не подходит.
• Tanya Reilly, The Staff Engineer’s Path и noidea.dog/staff — подробный разбор экспертного трека выше сеньора и «влияния без полномочий».
• Will Larson, Staff Engineer и блог lethain.com — как устроены роли staff/principal в разных компаниях и почему они везде разные.
• Charity Majors, The Engineer/Manager Pendulum — основной текст про переходы туда-обратно между инженерией и менеджментом.
• Paul Graham, Maker’s Schedule, Manager’s Schedule — почему менеджерский и инженерный день несовместимы по структуре.
• Gregor Hohpe, The Software Architect Elevator и architectelevator.com — лучшее объяснение того, чем архитектор отличается от старшего разработчика.
• Michael Nygard, Documenting Architecture Decisions — первоисточник практики ADR.
• Rob Walling, Start Small, Stay Small — методичная книга про bootstrapped-продукты без историй про единорогов.
• CB Insights, Top reasons startups fail — регулярно обновляемая аналитика причин закрытия.
• progression.fyi — публичные карьерные лестницы реальных компаний; полезно посмотреть, как разные компании описывают одни и те же треки.
• Открытые зарплатные данные для исследования рынка: Хабр Карьера, getmatch, levels.fyi — и обязательно сверяйте дату сбора данных, рынок меняется быстрее, чем публикуются отчёты.

Что дальше

На этом трек заканчивается. Вы прошли путь от «что вообще происходит, когда делают софт» до «куда двигаться, когда основы освоены»: устройство SDLC, требования, проектирование, разработка, тестирование, релиз, поддержка, роли, типы компаний, грейды, деньги, найм с обеих сторон стола и карьерные развилки. Если хочется вернуться к началу и посмотреть на карту целиком — Как на самом деле делают софт.

Куда идти дальше, зависит от того, какой трек показался вашим:

• Тянет в инженерную глубину — Архитектурные паттерны, Принципы разработки, DDD.
• Тянет к процессу и команде — Управление проектами, Скрам-мастер, а также материалы в разделе https://courses.digitable.life/post/management/development-approaches-and-methodologies/.
• Тянет к продукту и своему делу — Продуктовый менеджмент.
• Тянет к эксплуатации и надёжности — DevOps.
• Не хватает личной системы работы — Тайм-менеджмент.

А общая карта всех треков портала с рекомендованным порядком — Роадмап.