Often I hear software engineers looking to move up in their organization and setting their sites on a technical architect role. Make no mistake, an architect is a leadership position that can be harder to achieve results than a project manager or development director.

In many organizations, an architect is a role that allows an engineer to stay away from management. I recall one engineer who said “I’m excited to one day become an architect in order to make some of these larger decisions.” An architect feels like a position that allows a developer to progress up in the ranks of their organization without taking on people management.

In my experience, successful architects are good at communication and driving decision through influence. There are a few key tactics that will help you improve the skills necessary to be an effective technical architect.

Improve your written communication. Communication is key to the role of a technical architect, and we live in a world where e-mail and messaging are common ways to communicate. Your ideas will need to be understood well past

Practice presenting your ideas to groups. You may fall into the large group of people that do not like presenting in front of audiences. A technical architect will not be effective simply writing out decisions and sending them off. You will need to persuade others to implement your ideas, and being good at presenting those ideas to a group will be key.

Build relationships with key stakeholders. As an architect, you are most often leading through influence. You rely on your relationship with key stakeholders to get things done. These stakeholders may be technical leaders, and they may also be business leaders. You will need to adapt and build relationships outside the technical organization (sales, for example) in order to effectively bridge the two worlds.

Be proactive. Not everyone will be active and engage you in architecture decisions, even when they know they should. A good observation by my colleague Ed Hughes is to walk around and be nosey to learn what is happening on various project teams in your organization. Be persistent to find out what is happening.

Tailor your message to your audience. The relationships you will build will span farther than those relationships you had as an engineer, and you will need to tailor your messages depending on the audience. You may never have thought about how a salesperson, support representative or the CEO thinks about your decisions. Your effectiveness can be much more when you understand that each audience may want to hear different elements of your message.

Learn about many different technologies. You may have benefited from becoming the expert on a particular technology as an engineer. A technical architect needs to learn about many technologies enough to make recommendations. Go wide not deep. Know the trade offs between four different frameworks than learning the intricate details of only one.

Be willing to get hands on. It can be hard to relate to an architect that only speaks in the abstract. Creating proofs of concept in working software is a great way to demonstrate how something will work. Do not be afraid to jump in to make your point. You can also reinforce relationships if you are willing to jump in and help out when your team is in a pinch.