An engineer wants to become an architect. What should they deliberately practise, and what commonly stalls the transition?

What to practise deliberately

1. Writing. Decision records, design documents, proposals. Writing exposes gaps that speech conceals — an argument that sounds coherent aloud frequently falls apart on the page — and it is the primary medium of the role.

2. Operating what you build. On-call experience is the fastest way to develop failure intuition, and an architect without it designs systems that are pleasant to build and unpleasant to run.

3. Breadth deliberately, not accidentally. Work on data, on frontend, on infrastructure, on integration. Architecture is largely about the seams between areas, and depth in one is not enough to see them.

4. Estimating and being wrong publicly. Judgement about effort and risk develops by making predictions and comparing them to outcomes, which requires making them out loud.

5. Explaining to non-engineers. Practising the translation from technical decision to business consequence is what makes an architect fundable rather than merely correct.

6. Reading failure literature. Detailed public postmortems teach failure modes no product documentation covers, and they are the cheapest available source of experience you did not have to live through.

What commonly stalls the transition

1. Remaining the best engineer in the room. Continuing to do the implementation feels productive, scales to one person, and prevents the judgement transfer that is the actual job.

2. Depth without breadth. Deep expertise in one area produces designs that optimise that area at the expense of the system.

3. Being right without being adopted. An architect whose designs are correct and ignored has not learned that influence is the mechanism, and that the paved road beats the standards document.

4. Avoiding the business. Arguing for architecture on technical merit, which does not compete against a roadmap.

5. Avoiding decisions. Waiting for certainty that will not arrive, which lets the architecture be decided by whoever writes the first line of code.

The transition marker

When people bring you problems before they have a solution, rather than asking you to review one. That is the point at which the role has changed from reviewing to shaping — and it is earned through usefulness rather than title.