From Software Engineer to Architect: seven practices that get you there

Most engineers I meet think of "architect" as a job title they might get promoted into one day. I'd flip that around. Architecting is something you start doing on a Tuesday afternoon, in the code you're already working on. The title follows the practice, not the other way round.

So let me make two arguments: why the move is worth making, and how to make it without waiting for permission.

Why bother

Your decisions outlive your code. The class you wrote last year has probably been rewritten. The decision to split that service, or not to, is still shaping how the team works. Architecting is where your leverage per hour of thinking is highest — and it stays high long after you've moved on.

It's the fastest way to stop being frustrated. Every senior engineer I know has a list of things that make their work harder: the deployment that takes a week, the coupling nobody will untangle, the database everyone shares. Those are architectural problems. You can complain about them or you can become the person who is allowed to fix them.

You stop optimising a component and start optimising an outcome. Good architects think in terms of what the business is actually trying to survive — the audit, the peak load, the acquisition, the regulator. That's a different conversation, with different people in the room, and it changes what your career looks like.

The skills compound and travel. Languages and frameworks rotate. The ability to weigh trade-offs under uncertainty, and to explain them to people who don't code, transfers to every technology you'll ever touch.

And one honest caveat: architecting means less time writing code and more time in ambiguity, disagreement and meetings. Some brilliant engineers try it and hate it. That's a legitimate answer. Try the practices before you chase the title.

Seven practices to embed

None of these need a new job. All of them will be noticed.

1. Start with drivers, not solutions. Before you propose anything, write down what actually constrains it: the quality attributes that matter (latency, availability, changeability, compliance), the business goals behind them, and the hard constraints you can't negotiate. Most bad architecture isn't a bad answer — it's a good answer to a question nobody checked.

2. Treat decisions as the unit of work. Diagrams describe a system. Decisions create it. Get into the habit of naming the decision you're actually making — "we will use asynchronous messaging between order and fulfilment" — separately from the picture that shows it. Once you see your work as a stream of decisions, you can start managing which ones matter, which are reversible, and which you're allowed to defer.

3. Always develop at least two options. One option is an opinion. Two or more is an architecture. Force yourself to write down a real alternative — not a strawman — and the criteria you're judging them by. This single habit does more to raise the quality of technical conversation than any tool or notation.

4. Record the reasoning, not just the outcome. A short decision record with the context, the options, the choice and the consequences takes twenty minutes. Eighteen months later it's the difference between a team that can safely change the design and a team that's afraid to touch it. Write it for the colleague who joins after you leave.

5. Make consequences explicit — including the ones you don't like. Every decision buys something and costs something. Say the cost out loud: "this gets us independent deploys and costs us transactional consistency." Stakeholders trust architects who name the downside. It also protects you when the downside eventually shows up, because it was on the record.

6. Communicate in the listener's language. Learn to present the same architecture three ways: a view for developers, a view for operations, and a view for someone who cares about money and risk. If your only artefact is a box-and-line diagram that needs you standing next to it, you're not communicating — you're presenting.

7. Validate against reality, early and cheaply. Prototype the risky part. Run a load test on the assumption everything rests on. Walk the design through a concrete scenario with the people who'll operate it. Architecture that has never been tested against anything real is just a hypothesis in a nice font.

Where structure helps

You can build all seven of these on your own projects. What structured training adds — the iSAQB CPSA-F path is designed around exactly this — is vocabulary shared with other architects, a systematic way of moving from drivers to decisions to documentation, and the confidence that comes from being tested on it rather than assuming you've got it.

But start with the practices.

Pick the one you're weakest at, and apply it to whatever you're building this week.

Which of the seven would your current team notice first if you started doing it tomorrow?