How to find a solutions architect.

Solutions architecture splits into two jobs that share a title and little else. One is commercial: working with prospects, running proofs of concept, and often carrying quota alongside a salesperson. The other is technical delivery: designing systems that engineering teams actually build.

Within delivery architecture there is a second screening problem that adverts never mention but hiring managers always worry about — the architect who produces diagrams disconnected from what is buildable. Engineers detect that quickly and route around the role, which wastes it entirely. Recent hands-on evidence is worth more than any list of systems architected.

Job titles worth searching

Grouped by what the person actually does, because searching all47 at once produces a result set you cannot triage. Decide which group you need first — that decision does more for the search than any string below.

Certifications and what they signal

Platform certifications matter here for a reason unique to this role: consultancies must maintain certified headcount to keep partner status, so certification is sometimes a commercial requirement independent of capability.

Where solutions architects actually are

Vendor conference speaker lists are unusually useful for this role. Presenting at re:Invent, Ignite, or Dreamforce demonstrates technical depth and the ability to explain a design under scrutiny — precisely the combination the job requires, and the one that is hardest to assess from a CV.

Published architecture work reveals reasoning rather than résumé claims. Reference architectures, architecture decision records, and detailed case studies show which trade-offs someone made and what they rejected, which is the actual substance of the role. For delivery architecture specifically, recent public code answers the question hiring managers most worry about.

Consultancies and systems integrators are a strong and predictable pool. Their architects encounter many environments and build pattern knowledge quickly, and a steady proportion want to move in-house. The motivation is almost always travel burden and billing targets rather than money, so an in-house pitch built around stability lands better than one built around variety.

Boolean search strings

Written to be pasted as-is. Each one is built around an intent rather than a platform, since the useful question is what you are trying to find, not which site you happen to be on.

site:linkedin.com/in/ ("solutions architect" OR "solutions engineer" OR "technical architect") (AWS OR Azure OR Salesforce OR TOGAF) "{city}"

("solutions engineer" OR "pre-sales architect" OR "sales engineer") ("demo" OR "POC" OR "proof of concept" OR "RFP") -jobs -hiring

site:github.com ("architect" OR "principal engineer" OR "staff engineer") ("reference architecture" OR "terraform" OR "sdk") -awesome

("speaker" OR "session" OR "keynote") ("re:Invent" OR "Ignite" OR "Dreamforce" OR "Summit") ("architect" OR "solutions") 2024..2026 -jobs

("Solutions Architect Professional" OR "AZ-305" OR "Certified Technical Architect" OR "Professional Cloud Architect") "{city}" -jobs -training

("reference architecture" OR "architecture decision record" OR "well-architected") ("we designed" OR "case study") -jobs -vendor

("consulting" OR "consultancy" OR "systems integrator") ("solutions architect" OR "technical architect") ("leaving" OR "in-house" OR "travel") -jobs

("architect") ("PCI DSS" OR "HIPAA" OR "GDPR" OR "regulated" OR "high availability" OR "disaster recovery") -jobs -vendor

Mistakes that cost the most time

1. Not separating pre-sales from delivery

   These are different jobs sharing a title. Pre-sales architects work with prospects, run demos and proofs of concept, and often carry quota alongside an account executive. Delivery architects design systems that get built and work with internal teams. The skills overlap partly, but the personalities and compensation structures differ substantially, and a shortlist mixing both satisfies neither role.

2. Hiring architects who no longer build

   The most common complaint about architecture hires is that they produce diagrams disconnected from what is buildable. Engineers detect this quickly and route around the architect, which wastes the role entirely. Recent hands-on evidence — public code, a technical exercise, or a detailed design discussion — is worth more than any list of systems architected.

3. Confusing enterprise architecture with solutions architecture

   Enterprise architects work on technology strategy, standards, and portfolio-level decisions. Solutions architects design specific systems for specific problems. TOGAF certification is genuinely relevant to the first and largely irrelevant to the second, where practitioners often view it sceptically. Requiring it on a hands-on role signals a mismatch to exactly the candidates you want.

4. Underestimating the platform anchor

   An AWS solutions architect and an Azure solutions architect are not interchangeable at depth, and a Salesforce architect is anchored to that ecosystem entirely. General architecture principles transfer; the specific service behaviours, integration patterns, and platform limits do not. For roles needing immediate credibility with customers or teams, match the platform.

5. Ignoring communication as a core requirement

   Much of an architect's value lies in explaining a design to engineers, executives, and sometimes customers, and in defending trade-offs under challenge. Technically excellent architects who cannot do this are ineffective in the role. Conference talks and published writing are useful evidence, and a design presentation is a better interview than a whiteboard puzzle.

6. Missing the consultancy pool and its motivations

   Consultancy architects see far more environments than in-house ones and build broad pattern knowledge quickly. Many want to move in-house, and the reason is usually travel burden and billing targets rather than money. Pitching an in-house role on variety misunderstands what they are trying to leave.

Common questions

What job titles should I search for when hiring a solutions architect?

Establish first whether the role is pre-sales or delivery, because the titles diverge. For customer-facing work, search Solutions Engineer, Sales Engineer, Pre-Sales Consultant, and Field CTO. For delivery, Technical Architect, Delivery Architect, Principal Engineer, and Staff Engineer. Platform-anchored roles use their own terms — AWS Solutions Architect, Azure Solutions Architect, Salesforce Architect — and that experience is much less transferable than it appears. Specialised architecture uses Data Architect, Security Architect, and Integration Architect.

What is the difference between a solutions architect and an enterprise architect?

A solutions architect designs a specific system to solve a specific problem, working close to implementation and often with the team that will build it. An enterprise architect works at portfolio level on technology strategy, standards, and how systems fit together across an organisation, much further from code. The distinction matters for certification too: TOGAF is genuinely relevant to enterprise architecture and largely irrelevant to hands-on solutions work, where practitioners frequently view it with scepticism. Requiring it on a delivery role signals a mismatch.

What is the difference between pre-sales and delivery solutions architects?

Pre-sales architects work with prospective customers — running discovery, building proofs of concept, presenting demos, and responding to RFPs — and frequently carry a quota alongside an account executive, with commission forming part of their compensation. Delivery architects design systems that are actually built, working with internal engineering teams through implementation. Both need technical credibility, but pre-sales weights presentation and commercial instinct while delivery weights depth and buildability. The compensation structures differ enough that the offer itself must be constructed differently.

How do I tell whether an architect can still build?

Look for recent hands-on evidence rather than a list of systems architected. Public code — reference architectures, Terraform modules, SDK contributions — establishes it directly. Failing that, a detailed technical discussion about a recent design, probing why specific trade-offs were made and what was rejected, distinguishes people who made decisions from people who documented them. This matters because engineers detect a disconnected architect quickly and route around them, which wastes the role entirely.

Where can I find solutions architects outside LinkedIn?

Vendor conference speaker lists are unusually informative for this role, because presenting at events such as re:Invent, Ignite, or Dreamforce demonstrates both technical depth and the communication ability the job requires — a combination that is otherwise hard to assess. Published reference architectures and architecture decision records reveal trade-off reasoning directly. Consultancies and systems integrators are a strong pool, since their architects see many environments; the ones open to moving are usually motivated by travel burden rather than by pay.