What Makes a Great Software Architect

In TSConf 2019, the keynote speaker and legendary language designer Anders Hejlsberg, was asked "what makes a great software architect?" I was there in-person at the time and his response resonated with me since it reminded me of all the great software engineers I've worked with in the past. He said:

I’ve always found that the people who do truly great at programming tend to be the ones that care a lot about the details but they also know how to connect it to the big picture.

You often get people who are visionaries, and they can paint out visions, but they can’t lay down the long path of incremental steps that will ultimately get you to the vision. And so it’s not enough to have a brilliant idea. You also have to understand how to get from nothing to the ultimate implementation of that idea in attainable steps along the way.

Here is how I've come to understand it. Ideally great software architects can come up with a design like this:

A────────────────>B

In actuality, you have gaps in your knowledge and you may not even have enough experience to know how to finish the project:

A   ─  ─ ─       >B

You begin to develop expertise in specific areas:

A   ──────        B

As you progress in your career, you are exposed to more areas of knowledge and more experienced coworkers. So even though you've specialized in one area, you know enough at a high level to be able to design a project from A to B:

A─  ──────  ─ ─ ─>B

Eventually, you reach mastery in many different topics and you've developed your communication skills to a point where you can either describe things at a high level:

A─  ─   ─  ─  ─ ─>B

Or describe all the minute implementation details:

A────────────────>B

The former is what you use to get buy-in from your management chain. The latter is what you use to get the trust and respect of the engineers you are working with.

I think this imagery of mastery is a useful way of describing to people what makes a great software architect or senior engineer. I realized, all of the engineers or managers I've enjoyed working with are the ones who are capable of having deep discussions about low-level implementation details but can also effortlessly zoom out to the big picture to connect the dots.

Gaps in implementation knowledge will lead to unrealistic, fluffy design docs that fail to de-risk our understanding of the project. Gaps in the big picture will lead to building the wrong thing or nothing at all.