From Developer to Solution Architect: The Skills Gap Nobody Talks About

As a developer the problem usually arrives defined: build this, fix that, make this faster. The skill is solving it well. In architecture the problem arrives undefined and often misstated. Someone says they need microservices when what they have is a release-coordination problem, or asks for a data warehouse when they need three reports.

So the first new skill is refusing to answer the question as asked until you understand the situation behind it. That felt obstructive when I started — people want an answer, and asking what they are actually trying to achieve sounds like stalling. It is the single highest-value habit in the role, because solving the stated problem precisely and the real problem not at all is the most common way architecture fails.

Developers can usually resolve uncertainty by reading the code. Architects routinely cannot: the decision depends on how many customers there will be in three years, whether a team will be hired, or what a vendor will do. Waiting for certainty is not an option because the decision has a deadline and not deciding is itself a decision, usually a worse one.

What helped was separating reversible from irreversible choices. A reversible choice should be made quickly and revisited; spending three weeks choosing something you can change in an afternoon is waste. An irreversible one — a data model, a partitioning key, a vendor with lock-in — deserves genuine investigation. Most decisions are more reversible than they feel in the moment.

The habit that changed my effectiveness most was recording decisions: what was decided, what alternatives were considered, what the trade-offs were, and what would make us revisit it. A short document per significant decision, written when it is made.

It pays off twice. Six months later, when someone asks why the system works this way, the answer exists and is not a reconstruction. And the act of writing exposes weak reasoning — a decision that cannot survive one page of plain prose usually should not survive at all. This is also what makes an architect's work reviewable rather than authoritative-by-title.

A CFO does not want to hear about eventual consistency. They want to know what it costs, what it risks, and what happens if we do nothing. Translating a technical trade-off into that language is a distinct skill, and one most engineers have never had to practise.

The framing that works is options with consequences: here are two or three paths, here is what each costs in money and time, here is what each buys, here is what I recommend and why. Presenting a single option with technical justification invites either rubber-stamping or rejection. Presenting real options with honest trade-offs invites a decision, which is what stakeholders are actually for.

This was the hardest adjustment. As a developer, if I wrote good code, I had done my job. As an architect, the design can be sound and the outcome still poor because a team implemented it differently, a deadline forced a shortcut, or a dependency never arrived. The outcome is still partly yours.

That means staying involved after the diagram is delivered. Architecture handed over at the design stage and never revisited becomes fiction within a month. I review implementations, sit in on the awkward trade-off conversations mid-build, and expect the design to change as reality intrudes. An architect who is not present during implementation is producing documents, not architecture.

You do not need permission to start. Write a decision record for the next significant choice your team makes. Ask what problem we are actually solving in the next planning meeting. Volunteer to explain a technical trade-off to a non-technical stakeholder, and notice which parts of your explanation land.

And deliberately learn the parts of the system you do not touch — how it is deployed, monitored, paid for, and secured. Architecture is largely about the interactions between areas, and you cannot reason about interactions between areas you have never looked at. That breadth, more than any pattern catalogue, is what the role actually requires.