A while ago I realized that I can actually speak as someone who has played this role before. So when I found the above question on Quora, I wrote an answer:
Your best path to an architect position is to work your way up into it.
I say that because to really succeed in the architect position you need to know four things:
- What works and what doesn’t in terms of design, and how to draw out and clarify the needs of the group you are designing for.
- What is easy to implement and what is hard, so you can design something that fits within your customer’s timeframe, AND so you can tell who below you is bull***tting you and who’s making real progress, and actually be CORRECT on both fronts. The consequences for being wrong are ugly. You don’t want to get into an argument with a project manager about how long your design “should” take to implement - you will lose that argument, almost by definition.
- What components to choose for a given situation (frameworks, development workflows, what’s compatible, what’s maintainable, what has a future, what you should insist on, what you can compromise on)
- How to earn and keep the respect of the developers and managers whose roadmap, and work hours, you are laying out.
The best way to learn all these things at once is to take a development job that also has the need, and the room, for a good software architect. Then, if your ideas are good, and you can responsibly expand your work to contribute design ideas as well as implementation, you can change the shape of your role.
With hard work and good ideas, and a good disposition, you will find that you have become de-facto lead programmer on one or more projects, and are making major design decisions.
Whether you choose to expand that role at your current employer (if there is room), or jump to another that is explicitly looking for an architect role, is up to you. But having risen to that skillset organically, you will be very well prepared to succeed either way.