I'm new to it myself, in my first role with the title "Architect" after a decade of being individual contributor and lead for R&D teams. So take these from some

I'm new to it myself, in my first role with the title "Architect" after a decade of being individual contributor and lead for R&D teams. So take these from someone very early in the position, but I think the important things are: Know your shit and be able to have high level conversations about nearly anything technical. You don't have to know the inner workings of everything, but you should have a good idea and high level understanding of it. For instance, you don't have to know every message queue system on the market, but you should know a few, their relative strengths and weaknesses, how specific ones are often used and how message queues play a role in overall system design. Learn a new language every year or two and keep an eye on the horizon for new technologies that can make you and your teams faster and more efficient. Live and breathe failure. Understand the conditions that the systems you build and work in break down and learn to compensate for that and explain that to others. Be able to talk to others, on their terms, whether thats your top flight engineer or the guys on the business side. Its a bit corporate and soft, but I found the IBM article on it fairly insightful http://www.ibm.com/developerworks/rational/library/mar06/eeles/ http://www.ibm.com/developerworks/rational/library/mar06/eel...