More than a few people have written about being a software architect. It's a surprisingly diverse role in the industry. The title rarely means the same thing from one company to the next. The stereotype is someone who designs stuff and then hurls it over the fence to engineers, who do the actual work of building it. If that's the only kind of software architect you've met, you've been short-changed.

I am currently a software architect at Salesforce, working on the Pardot product. Pardot is a Business to Business (B2B) Marketing Automation tool. It enables marketers to find and capture potential leads (people to sell stuff to). It also allows marketers to build rich workflows around their engagement with those leads. It is a large and complex application with a reasonably large engineering organization behind it.

I came up as a software engineer at Salesforce, making individual contributions. I wrote code. That's also what I did before coming to Salesforce. I love writing code.

When I was promoted to be a software architect, my job changed. The change didn't happen overnight, but what I found is I spent less time writing code and more time helping people write code. That's how I describe my job when people ask what I do for a living. My job as a software architect is about communication and enablement. It's through those that I help engineers write code. It sounds simple enough, but how do I do this?

As a software architect, I am constantly having conversations. I pose questions that test proposals and work with engineers to explore different angles of their projects. I try to promote best practices wherever I can. I also make sure that the engineers I work with know what is going on in other engineering teams. Sometimes this means pointing them to another effort. Other times, it means showing them a pattern to follow or even leveraging an existing system built by a different team.

If you get five engineers into a room, odds are you will have five very different opinions on how to solve the same problem. As a software architect, I try to peel the layers of those opinions back to find commonalities. Then I use those commonalities to try to build consensus. Building consensus is often one of the most complex parts of my job. It's a critical aspect, though, because you often wind up with better results when you can establish consensus.

I spent a lot of time working with other stakeholders in our organization, helping them understand how our technology works. I lead meetings and make presentations and write lots of documents. Enabling everyone to understand the technology we use and are building is critical to building even broader consensus across an engineering organization.

As a software architect, I am not a people manager. I'm still an individual contributor, but my contributions tend to deal more with people than code. Because of my title, I have a different sphere of influence, which often involves organizational leadership. That sphere allows me to advocate for the engineers and ensure leaders hear their concerns. At the same time, I help managers and leaders understand the tradeoffs and the complex decisions our engineers make.

A few years ago, I helped started a mentorship program for engineers. I believe that mentorship is a vital part of being a software architect. Mentoring helps engineers learn how to grow their careers and hopefully advance to new challenges. It's also essential to the organization because it helps develop the next set of technical leaders. A formal program isn't a necessary part of the job, but it helps give structure to make mentorship happen.

Lest you think I don't code at all, I do. I just code less than I did before. I prototype solutions to problems. I also contribute code to different teams, sometimes augmenting their bandwidth. Even when I am not directly writing code, I am still in the code because I do a lot of code reviews. I am also in constant conversation with engineers about the code they are developing.

Being a software architect takes time and patience, and lots of communication. Sometimes that means endless meetings. Other times it means documents and slide decks. It's worth it when it comes together in the end because if I've done my job, there's a connectedness between teams and stakeholders. Everyone knows what's happening and understands the ins and outs of the technology we're building together.

To summarize, a software architect:

• Poses questions and tests proposals.
• Promotes and encourages best practices.
• Informs engineers about what is happening in other parts of an organization.
• Builds consensus.
• Enables stakeholders to understand the technology.
• Advocates for engineers with leadership.
• Mentors engineers.

Stay tuned! I'll be writing more about being a software architect in future posts.