Moving from shipping features to shaping systems: diagrams, design reviews, estimates, and guiding teams without becoming a bottleneck — a first-person look at the Assistant Solution Architect role.
I spent years as a full-stack and backend engineer. Success was measurable: tickets closed, PRs merged, latency charts trending down. When I stepped into an Assistant Solution Architect role supporting a Solution Architect on AI-backed products, that scoreboard quietly disappeared.
Nobody asked me to write the feature anymore. They asked whether the feature belonged in this service, whether the data should leave the trust boundary, and what it would cost to run at 10× traffic. My job shifted from building the path to making the path safe to build on.
The architect’s job is not to have all the answers — it is to make the right questions impossible to skip.
That line sits on a sticky note above my monitor. It is the shortest description of the role I have found.
As an engineer I owned code paths. As an Assistant Solution Architect I own artifacts and decisions:
I still write code — usually spikes, reference implementations, and proof that a pattern works. I do not try to be the busiest committer on the team. If I am, something about the system of work is broken.
Here is how a real week often flows when we are shaping a new AI-assisted workflow product I will call Northline Assist — a fictional internal name for a chat-driven assistant over company documents. No client specifics; the shape will look familiar if you work on RAG or agentic backends.
I start by listing decisions that are still living only in Slack. Anything older than a week without an owner becomes a candidate for an Architecture Decision Record. I sync with the Solution Architect on which decisions are theirs to close and which I can drive to a recommendation.
One service wants to call the LLM vendor synchronously from the request path. Another wants a queue and a worker. We review both with the same checklist: latency budget, failure modes, cost at projected QPS, and what the user sees when the model times out.
I draft the ADR, attach a Mermaid data-flow diagram, and open a PR against docs/adr/. The review is the point — not the prose. Developers comment on consequences; DevOps comments on ops burden; product comments on user-visible failure.
I turn the preferred option into effort and infra cost ranges. Not a single magical number — a range with assumptions. “If we cache embeddings and reuse sessions, token cost stays under X; if every turn re-embeds the full corpus slice, we blow the budget by week three.”
Office hours. Short pairing on a NestJS module boundary. A comment on a PR that says “this violates ADR-003; either update the ADR or split the concern.” Then I write down what I learned so next Friday’s questions are shorter.
Transfers well: API design, database trade-offs, observability instincts, knowing when sync HTTP is a distributed monolith waiting to happen. My earlier work on NestJS services, PostgreSQL schemas, and event-driven flows still pays rent every day.
Surprises you: Soft power. You rarely “assign” work. You create clarity so the right work becomes obvious. You also learn to say “I don’t know yet — here is the spike” without losing credibility.
Must grow fast: Facilitation. A design review that turns into a debate about taste wastes eight people’s hour. A review with a written agenda and an explicit decision/parking-lot split ends on time with an owner.
Working near AI products does not mean every diagram needs twelve agent boxes. Most of the hard problems are still systems problems:
type ArchitectureQuestion = {
decision: string;
userVisibleImpact: string;
failureMode: string;
costDriver: 'tokens' | 'cpu' | 'storage' | 'ops';
owner: 'asa' | 'sa' | 'team';
};
const northlineAssistQuestions: ArchitectureQuestion[] = [
{
decision: 'Sync LLM call on chat turn vs queue + worker',
userVisibleImpact: 'Time-to-first-token vs “thinking” state',
failureMode: 'Provider timeout leaves orphaned UI state',
costDriver: 'tokens',
owner: 'asa',
},
{
decision: 'Shared Postgres vs dedicated vector store',
userVisibleImpact: 'Search quality and cold-start latency',
failureMode: 'Index drift after document updates',
costDriver: 'storage',
owner: 'sa',
},
];
I keep a list like this in every initiative. If a question has no owner, it will be answered accidentally in a Friday hotfix.
I am not a junior title with architecture cosplay. The Solution Architect owns the largest bets: multi-team contracts, vendor strategy, compliance posture. I own the preparation: options, diagrams, trade-off tables, spike results, and a clear recommendation.
When I bring a recommendation, I bring the losers too. “We rejected Option B because cold-start retrieval exceeded the p95 budget in the spike” is more useful than “Option A feels cleaner.”
If you want the artifact side of this role next, read Architecture Decision Records in Git and C4 Diagrams for the Right Audience. For the communication patterns that still show up in every review, Microservices Communication: Sync vs Async remains relevant.
The title on LinkedIn changed in a day. The craft takes longer. I am still learning when to draw, when to decide, and when to get out of the developers’ way — and that tension is the job.