Career Change Guide: How to Transition Into a Solutions Architect Role

TL;DR

• The SA transition is a scope-acquisition problem, not a skill-acquisition problem - engineers who stall are typically adding certifications when the actual gap is taking ownership of cross-functional design decisions.
• Use system design mock interviews as a diagnostic: each session surfaces your exact gaps across four dimensions - cloud trade-offs, non-functional requirements, trade-off communication, and failure-mode thinking.
• Companies promote to SA when the scope change is already visible to leadership - the title follows the behaviour, not the other way around.
• The four observable milestones: cross-functional decision ownership, a structured system design feedback loop, a written business case that leadership acted on, and two architecture decision records (ADRs).
• A mentor with SA transition experience compresses the three hardest checkpoints: system design critique at the right level, business case articulation, and portfolio framing for interviews.

Is solutions architect right for you?

The solutions architect role isn't a promotion that adds architectural work on top of engineering work - it's a job that replaces most of the engineering work. Day-to-day: fewer commits, more proposals. Fewer sprint tickets, more design reviews and stakeholder conversations.

I hear this framing in applications regularly - engineers who are strong technically but describe feeling trapped in execution. The "execution-heavy plateau" language shows up across senior-segment applications at MentorCruise. And the aspiration language mirrors it almost exactly: applicants describe wanting to be someone who "not only drives execution but also shapes direction." That gap - from executor to designer - is the actual job change. Everything else is vocabulary.

Two specific wrong-fit signals worth naming directly.

If you love writing code and want to stay deep in implementation, the SA role will frustrate you - the job shifts to whiteboarding systems you hand off to others. That's not a knock on the role. It's a real trade-off that catches a lot of senior engineers off-guard.

If you're expecting a title change to solve a compensation problem without a scope change first, the transition usually stalls. Companies promote to SA when the scope change is already visible, not as a catalyst for it. Engineers who apply externally before they've acquired the scope rarely land the role. And if they do, they struggle.

What solutions architects actually do

Solutions architects spend most of their time making and defending technical decisions across teams and to non-technical stakeholders - not writing code. The core skill isn't cloud knowledge or certification breadth. It's the ability to produce a technical specification that spans multiple teams and constraints, and make it stick. That means selling the decision to sceptics, not just writing it down.

Here's what a typical SA workflow looks like for a customer-facing or cross-team project:

1. A customer discovery call or internal engineering kickoff surfaces a problem. The SA listens for constraints - timeline, existing infrastructure, team capabilities, budget.
2. The SA drafts a preliminary architecture proposal: two or three options with trade-offs, not one solution presented as obvious.
3. A design review with stakeholders follows. The SA defends the recommendation against alternatives. The pushback is the job.
4. The SA writes an architecture decision record (ADR) - a permanent written record of what was decided, what was rejected, and why.
5. The SA hands off to the engineering team with enough specification clarity that implementation doesn't require relitigating the design choices.

Most SAs at enterprise tech companies work directly with sales teams on technical feasibility for prospective customers. System design isn't just an interview skill - it's a daily activity. And the calendar looks nothing like an engineer's.

What does a solutions architect do differently from a software engineer?

A software engineer's job is to build what's been specified. A solutions architect's job is to produce the specification - and defend it to people who disagree. That shifts everything: how you prepare for a meeting, what evidence you need in the room, and what "a good day" means. A good day as an SE is clean code shipped. A good day as an SA is a design decision made and documented that will still hold up in 18 months.

How to transition into solutions architect

The most common mistake I see is treating this as a skill-acquisition problem. Senior engineers go straight to AWS certification prep, or start practising system design problems in isolation, as if the job gap is knowledge. The actual gap is scope. You need to own cross-functional technical decisions - not just have opinions about them - before any external signal (a cert, a title, an interview performance) will carry weight.

Here's the four-checkpoint milestone path, with testable pass/fail criteria for each:

The scope-acquisition phase - before you change your title

The phase I watch senior engineers skip most consistently: acquiring cross-functional scope before they change any title. They go external immediately, or they start cert prep, and they miss the actual lever.

We see the execution-to-direction aspiration in applications from senior engineers across the platform. The gap between that aspiration and the actual transition is almost always about making the direction shift visible before applying for the title - not applying and hoping the shift follows.

To acquire scope before your title changes:

1. Volunteer to write RFCs (requests for comments) or ADRs for in-flight engineering decisions, even when they aren't formally in your scope. The act of writing the proposal is the practice.
2. Request to sit in on architecture reviews, pre-sales technical calls, or engineering leadership syncs as a contributor, not an observer. Prepare a position before you walk in.
3. Identify one cross-functional technical problem in your organisation and write a one-page proposal framing the trade-offs. Share it. Iterate on the feedback - the feedback is the diagnostic.
4. Set a three-month scope check: by month three, you should have influenced at least one decision that required simultaneous input from product, infrastructure, and a business stakeholder. If you haven't, the problem is usually access, not capability.

Milestone test: you've led or heavily influenced a technical decision that crossed two or more team boundaries. You can describe the stakeholders, the alternatives you considered, and why you chose what you chose in three minutes. Pass: yes. Fail: no, or the decision was only one team deep.

System design as a diagnostic - not just interview prep

When I look at applications from engineers targeting the SA role, nearly all of them mention system design practice. What they describe wanting isn't instruction - it's structured feedback on their actual gaps. That distinction matters: each mock session isn't just prep, it's a skills audit that surfaces the exact gaps the SA role demands.

28 of 730 skill areas mentioned in recent MentorCruise application data explicitly named system design - and those applications are coming from engineers who already know the basics. What they're asking for isn't instruction in system design. It's a structured practice loop with expert feedback.

What each mock session actually reveals:

1. Cloud and infrastructure gaps - where your knowledge of AWS, Azure, or GCP service trade-offs is thinner than an SA needs it to be. Most engineers know enough for their current role. SA work exposes the thinner spots fast.
2. Non-functional requirements fluency - whether you default to "make it scale" or can articulate availability targets, RTO/RPO windows, and cost/performance trade-offs with specifics. SAs are expected to hold these numbers.
3. Trade-off communication - whether you can explain why you rejected the alternative architectures in language a product manager or VP of Engineering can evaluate. Technical correctness isn't enough if the explanation requires a decoder ring.
4. Design for failure - whether you address failure modes proactively or only when prompted. Interviewers use this as a proxy for design maturity.

A mentor who has conducted SA-level system design reviews can give feedback across all four dimensions in a single session - and tell you which gap to close first. Find a system design mentor before you start a solo mock loop; the feedback quality difference is significant.

Milestone test: complete three mock system design problems at the senior engineer level and receive structured written feedback on each. Map the feedback to three categories: cloud/infra gaps, non-functional requirement gaps, trade-off communication gaps. Each gap has a named next action. Pass: feedback documents exist with a gap map. Fail: you've done mocks but have no written feedback or gap map.

Certifications as a roadmap scaffold - not a badge

Cert advice for SA candidates is contested. My actual take: no, you don't need a certification to get an SA role. But certifications are useful learning scaffolds because they force you through the non-functional requirements vocabulary - availability zones, fault tolerance patterns, cost optimisation trade-offs - that SAs use in every design conversation.

AWS Solutions Architect Associate, Azure Solutions Architect Expert, and GCP Professional Cloud Architect all work this way. Work through the curriculum and you'll surface knowledge gaps you didn't know you had. The AWS certification has helped people make surprising transitions - there's a first-person case study on the AWS Training blog from a pro athlete who made the move via the certification scaffold, which shows how structured the learning path is even for people starting from further back.

For you, the cert curriculum is a vocabulary-building tool. It's not the evidence that gets you the offer. Scope and demonstrated decision-making do that. But working through the material often surfaces exactly the gaps the system design diagnostic flags.

You can find resources for AWS certifications on MentorCruise if you're working through the material with a mentor.

The business case milestone - when your scope is visible but you can't articulate it

This is the gap we see most often in applications from engineers who are already doing the work but haven't formalised the communication. The language in recent MentorCruise application data captures it directly: engineers describe struggling to "translate that into a prioritised roadmap, make credible business cases to leadership, and scope projects down to something executable." The technical knowledge is there. The communication layer isn't.

The fix is documentation. A written technical business case forces you to hold three things simultaneously: the technical trade-offs, the business constraints, and the leadership's decision-making language. If you can't write it, you can't defend it in a room.

A structure that works:

• What decision needs to be made and by when
• Constraints: technical, cost, timeline, team capacity
• Options considered (2-3 minimum), with trade-offs for each
• Recommendation with rationale - why this over the alternatives
• Risks and mitigations
• What you need from leadership to proceed

Milestone test: you've written a two-page technical proposal for a leadership audience and received a go/no-go decision on it. The document named the alternatives you rejected and the trade-offs you made. Pass: the document exists and a decision was made on it. Fail: verbal recommendations only, no written record of the decision process.

Common roadblocks and how to get past them

The most common stall point for the SA transition isn't a knowledge gap - it's a visibility gap. Engineers who are already doing architectural work but can't demonstrate it in an interview or to their leadership team. The fix is documentation: ADRs, technical proposals, and written design reviews create the portfolio that makes invisible work legible.

Four blockers show up regularly, with a specific fix for each:

• No formal SA role at your company: Build the portfolio of architecture decisions in your current role and validate externally. Target companies with explicit SA tracks - large tech, enterprise software, cloud consulting. Use the external system design interview loop as a skills audit even if you're not ready to accept an offer. The gap analysis is the point.

• Scope-blocked in your current team: The most common structural problem for engineers in narrow feature teams. Volunteer for cross-team initiatives (incident reviews, platform decisions, API design reviews), write unsolicited RFCs, and request to join architecture or technical design meetings. You're not waiting to be assigned scope - you're generating it.

• No mentor who can critique your system designs: External mock interviews with written feedback solve part of it. But the gap between technically correct and defensible to a VP of Engineering requires someone who has been in that room. Find someone who has conducted SA-level design reviews, not just someone who has passed the AWS exam.

• If you're on a work visa: for engineers on H-1B or equivalent visas in the US, an SA title change can affect visa classification - potentially moving from specialty occupation to consulting. Check with an immigration attorney before accepting a title change. The implications vary by employer type and visa category.

For engineers returning from a career gap or a layoff: the scope-acquisition phase is still the path. The first step is rebuilding recency signals - contributing to open-source architecture decisions, writing public ADRs, or participating in technical design discussions in public communities.

Tools, mentors, and next steps

The SA transition has a resource problem - not a shortage of resources, but identifying which ones close the specific gap at each milestone. Kleppmann covers distributed systems vocab. Nygard's ADR format builds the written portfolio. A structured mock session loop with written feedback addresses the system design diagnostic. And a mentor who has run SA-level design reviews closes the gap between technically correct and defensible to a VP. Here's what I'd reach for at each stage:

"Designing Data-Intensive Applications" by Martin Kleppmann is the standard reference for distributed systems trade-offs. It's what SAs reach for when thinking through storage systems, message queues, and consistency models. Read it before you start mock system design interviews - it closes the non-functional requirements vocabulary gap faster than anything else.

For architecture diagram practice, Excalidraw and LucidChart both work. The skill is making trade-offs legible on a whiteboard surface, not mastering a particular tool. Practise externalising your reasoning, not just your conclusions.

For building the written portfolio, Michael Nygard's ADR format is the standard - Context, Decision, Consequences. ADR template repositories are widely available on GitHub. The Nygard format is what most teams and interviewers recognise when you reference it.

For structured system design practice with written feedback, Hello Interview runs SA-relevant mock sessions. The feedback loop is what you're buying, not just the repetition.

One mentor worth considering: Ivan Novak has led engineering teams at multiple startups through hypergrowth. On MentorCruise, he helps engineering managers work through the transition from IC to leader - a path he's walked himself and coached dozens of others through. Here's his profile: Ivan Novak on MentorCruise. For engineers weighing engineering management coaching alongside or instead of the SA track, his profile is worth a read.

If you're making the move from senior engineer to solutions architect, finding a mentor who has already done it cuts a lot of friction. At MentorCruise, we accept fewer than 5% of mentor applicants - the architecture mentors on MentorCruise have typically run design reviews, led cross-functional technical decisions, and worked through the scope-acquisition phase themselves. Most have fielded the SA system design interview from the other side of the table. When you're ready to start, that's where I'd go first.

FAQs

How long does it take to transition from software engineer to solutions architect?

For a senior engineer already operating at the 5+ year level with some cross-functional scope, the transition typically takes 12-24 months - accounting for scope-acquisition, building the portfolio, and a job search cycle. Engineers in narrow specialisation tracks who need to broaden their cloud and systems surface area first should budget 18-36 months. These are realistic ranges, not guarantees. The bottleneck is almost always the scope-acquisition phase, not the job search.

Do you need an AWS certification to become a solutions architect?

No, you don't need one to get the role. But AWS Solutions Architect Associate, Azure Solutions Architect Expert, or GCP Professional Cloud Architect serve as structured learning scaffolds that cover the non-functional requirements vocabulary - availability, fault tolerance, cost optimisation - you'll use in every design conversation. Certs help you get into conversations about the role. Scope and demonstrated decision-making get you the offer.

What's the difference between a solutions architect and a software architect?

Software architects typically own the internal structure of a system - patterns, modularity, codebase architecture. Solutions architects typically own the system's fit within a broader technical environment and business context - often customer-facing or sales-adjacent at enterprise tech companies. The line varies by company; at SaaS startups the roles often overlap. If a job description lists "customer-facing technical design" or "pre-sales engineering," it's describing an SA function.

Can you become a solutions architect without a computer science degree?

Yes. Most SA job descriptions list experience requirements - typically 5+ years in engineering, system design, or cloud architecture - not degree requirements. Certifications help fill the credential gap if a degree is absent. A demonstrable portfolio of architecture decisions (ADRs, design proposals, technical RFCs) carries more weight than degree provenance at most companies. The system design interview is the real gate.

What salary can a solutions architect expect?

Entry-level SA at a mid-market company typically starts in the $120-160K range in the US. Senior SA at major tech companies can reach $200K+ base, with pre-sales SA roles often adding commission. readysethire.com puts the average at $161,480; interviewkickstart.com shows a $120-320K+ range across levels. European SA ranges typically run 30-40% lower in base before adjusting for benefits.

Is it better to become a solutions architect through an internal promotion or an external job search?

Internal transitions tend to be faster when cross-functional scope is already visible to leadership - you skip the portfolio-building phase and move straight to the conversation. External applications require a portfolio of architecture decisions and strong system design interview performance. The most reliable pattern: use the internal path to acquire scope and build the portfolio, then validate externally if the internal path stalls. Don't apply for the title before you've built the evidence.