Don't call them architects! Software architect is a title that many people in the software industry view with suspicion and dread. Once you have been through three or four job interviews for architect positions that turn into design reviews where you are peppered with insults from junior developers who "know better" than you how to design a user interface, you will begin to understand this fear of being called an "architect." I did not create this anti-pattern of hiring for architects any more than many software developers enjoy being called "nerds." At least nerds get to work on cool stuff and we do not have to wear a pocket protector. I guess as architects, we are just out of luck as far as job titles go since the average prospective employee will always be more concerned with what they can do for their career rather than how it reflects on them as an individual.
5 Things Every Good Software needs are:
1. Simplicity
2. Code reuse
3. Modularity/Cohesion
4. Product Architecture (high level design)
5. Communication
The above list of 5 things is essentially a list of 5 benefits software developers get from having an architect involved in their project or team, especially when that person possesses the skill-set listed below that enables them to do all these things without being too general or having to focus on minutiae.
For best digital product management to move forward and dispel some stereotypes about anyone who dares refer to themselves as a software architect, let's begin by defining what a software architect is NOT: Software Architect Is Not A Job Title – The first thing that annoyed me when I saw this title was the fact that most people were referring to the article in its entirety based on the job title alone. It is as if people are inherently unable to separate one's profession from their work and will search out any opportunity to place a label, good or bad, on them. Now let's get down to brass tacks or rather; the fallacy of the "Software Architect"
label itself. Software architects, like most career titles, fall under the typical spectrum of either highly sought after and compensated for their experience and expertise (i.e.: CTOs) or necessary but paid minimally for obvious reasons (i.e.: interns).
The problem we run into with software architect is that it falls somewhere in between these two extremes where the compensation outweighs the required knowledge and skills leaving us squarely in no man's land. To make matters worse, there are many positions that require an architect title but lack the required experience and leadership skills of one (i.e.: Program Managers).
What this leaves us with is a very broad, ill-defined title which can easily be confused for (or simply written off as) another word for "manager". Furthermore, there seems to be little consensus on what knowledge, skills or experience it takes to be worthy of such a lofty job title.
The answer to this question is obviously different depending on who you're asking because, like most titles in IT, the term itself has no official definition or requirements. We could all agree that Steve Jobs was an excellent businessman but did any of his many titles include "businessman"?
To better understand the qualifications, let's take a look at some official job postings for similar positions.
In all cases, you'll find that most people believe that an excellent programmer is what makes a great Program Manager:
"...s/he will be developing and managing large scale initiatives from concept through production."
"In this role you will lead software development projects..."
"The System Software team is looking for a hands-on Senior or Lead Software Engineer who can help guide and manage large cross-functional...projects."
"You must have a minimum of 5 years' experience leading software development teams...We are looking for someone with strong knowledge...of programming languages (Javascript, HTML, XML/JSON, etc.)"
You'll find that the requirements for the PM position include:
"...manage and lead a group of developers and program managers..."
"...working with Senior Management and other project stakeholders to assess and understand business requirements..."
"As a member of both management and technical teams...you will be expected to work effectively with all members of the team."
Yes, people don't expect you to be an expert programmer. They just want you to manage the development process. And it's true that many good programmers aren't at their best when they're trying to define scope, define requirements or get buy-in from senior management. For these tasks you need excellent interpersonal skills. Unfortunately for Program Managers, interpersonal skills are much harder to show when applying for jobs than technical abilities.
Programming skills can be shown in an interview by:
- describing a project you worked on and how you handled certain tasks (such as scope, requirements and so on)
- telling stories about how you demonstrated great teamwork with other developers and/or QA people
- demonstrating how well you understand the technology involved in your existing projects, for example by explaining why a particular solution was chosen or what would happen if that approach had been taken longer term
