So You Want to Be a Solutions Architect: What the Role Really Involves
The skills, the day-to-day, and how to actually get there.
Hey, it’s Lefteris 👋 I’m the voice behind the weekly newsletter “The Cloud Engineers.”
Solutions Architect might be the most misunderstood title in tech. Ask ten engineers what an SA does and you’ll get ten answers: “they draw diagrams,” “they’re pre-sales,” “they’re just senior engineers who stopped coding.” None of these are quite right, and the gap between the perception and the reality is exactly why so many talented engineers either avoid the role or struggle when they step into it.
I’ve spent four years as a Solutions Architect at AWS, working alongside hundreds of customers. Before that, I was a Software Engineer building and shipping production systems. So I’ve lived on both sides of the whiteboard. This article is the honest breakdown I wish someone had given me: what the role actually involves, the skills that matter, and a practical path to get there.
What a Solutions Architect Actually Does
Strip away the title and an SA does one thing: translates business problems into technical solutions, and technical realities into business decisions. You sit at the intersection.
On a typical week, that looks like:
Discovery. Sitting with a customer or team to understand what they’re actually trying to achieve. The best SAs are relentless about the “why” behind the “what.”
Design. Producing an architecture that balances the four forces you’re always juggling: scalability, performance, cost, and operational simplicity. There’s rarely a “correct” answer, only trade-offs you can defend.
Communication. Writing the doc. Presenting to stakeholders who range from hands-on engineers to VPs who just want to know the risk and the cost. Translating up and down the stack.
Enablement. Helping teams build the thing by reviewing their approach, unblocking them, and handing off enough context that they own it after you leave.
Notice what’s not on that list: writing production code all day. That surprises people. Which brings us to the biggest misconceptions.
The Misconceptions, Corrected
“SAs don’t code.” False. You may not ship production features, but you build proofs of concept, reference implementations, and demos constantly. If you can’t open an editor and prove an idea works, your credibility evaporates. The coding shifts from building the product to proving the pattern.
“It’s just a senior engineer role.” Not quite. Seniority in engineering rewards depth, going deep on a system and owning it. SA work rewards breadth and translation, being conversant across many services, and turning ambiguity into a defensible design others can execute. Different muscle.
“It’s a sales job.” In a vendor context (like AWS), there’s a commercial dimension. You’re helping customers succeed, which supports adoption. But the technical bar is real; you can’t hand-wave. And plenty of SA roles exist entirely inside product companies with zero sales involvement.
The Skills That Actually Matter
Here’s where I’d tell my younger self to invest. In order of how much they move the needle:
Communication, especially writing. This is the single most underrated skill in the role. If you can write a crisp one-pager that a VP and a staff engineer both understand, you will outperform architects with deeper technical knowledge who can’t. Learn to write.
Trade-off reasoning. Anyone can list AWS services. The value is in knowing when not to use one. “Do we even need Lambda here, or is a direct API Gateway integration cleaner?” That instinct, reaching for the simplest thing that works, is the core of the job.
Breadth over depth. You need working knowledge across compute, storage, networking, data, security, and cost. But have two or three areas where you go genuinely deep. Breadth earns you the conversation; depth earns you trust.
Cost fluency. Being able to reason about what an architecture costs, and redesign it when the bill doesn’t justify the elegance, separates architects who get invited back from those who don’t.
Empathy and listening. The best design is worthless if it solves the wrong problem. Discovery is a listening skill before it’s a technical one.
Solutions Architect vs. Senior Engineer: Which Path Is Yours?
Both are excellent, senior, well-compensated paths. The question is what energizes you.
Lean Solutions Architect if you:
Enjoy variety like new problems, new domains, new people, constantly
Like the moment a diagram makes a room go “oh, now I get it”
Are energized by ambiguity and translation, not annoyed by it
Want breadth across the stack more than mastery of one system
Lean Senior/Staff Engineer if you:
Get satisfaction from owning and perfecting a system over time
Prefer depth and craft over breadth and context-switching
Want your primary output to be shipped, running code
Find long meetings and stakeholder management draining rather than fun
Neither is “more technical” or “more senior.” They’re different shapes of the same seniority.
A Practical Path to Get There
If the role sounds like you, here’s how to move toward it from an engineering seat — starting today, without waiting for a title change:
Start architecting where you are. Volunteer for the design docs. Own the “how should we build this?” conversation on your team. You don’t need permission to think like an architect.
Write in public and internally. Publish design write-ups, share trade-off analyses, document decisions. This builds the exact muscle the role demands and creates visible evidence you can do it.
Go broad deliberately. If you’re a backend engineer, spend a quarter getting genuinely comfortable with networking or data. Fill the gaps in your T-shape.
Get in front of stakeholders. Ask to present your team’s design to another team or to leadership. Reps at translating technical detail to a mixed audience are gold.
Build reference implementations. Take a common pattern and build a clean, well-documented example. This is exactly the kind of artifact SAs produce — and a portfolio piece that proves the skill.
Certifications help as a floor, not a ceiling. The AWS Solutions Architect certifications signal breadth and are worth having. But they get you considered, not hired. The design thinking and communication get you hired.
Conclusion
Being a Solutions Architect isn’t about knowing every service or drawing the prettiest diagram. It’s about turning ambiguous business problems into defensible technical solutions and being able to explain those solutions to anyone in the room. The fundamentals are the same ones that make any great engineer: reach for simplicity, understand the trade-offs, and always design for the real problem, not the fun one.