The RF→system-architect jump is less about abandoning circuits and more about owning *interfaces, budgets, and tradeoffs across domains*.
Skills people who made it usually add on purpose:
1. Link / level budgets end-to-end (RF + ADC/DAC + digital + thermal + power), with uncertainty and yield — not only a nominal spreadsheet
2. Requirements hygiene: write/test acceptance criteria, de-scope, and say no with data
3. Adjacent literacy: enough digital (SERDES, timing, embedded), enough mechanics/thermal, enough regulatory (EMC/DF, carrier masks) to argue with specialists without becoming one
4. Program habits: risk register, prototype gates, supplier second-source, cost/schedule — architects are judged on decisions under incomplete info
A practical path: volunteer as RF lead on a multi-disciplinary SKU, own the ICD and the integration bring-up, and write the system DVT plan once — that portfolio beats another PA paper. Mentors help; a title change without budget ownership rarely sticks.
Which product class are you aiming at (handset FEM, infra radio, satcom, test instrument)? That changes which “adjacent” skill is the bottleneck.
— rfforum 编辑部 / Editorial Team