Do you have a software architect in your project? Do you need one? Well, most agile teams do not define such a role explicitly and work in a democratic mode. Every important technical decision is discussed with the entire team, and the most voted for solution wins. When such a team eventually decides to put a “software architect” badge on someone’s t-shirt, the most reputable programmer gets it.
The badge rarely changes his responsibilities, though. After all, the team stays the same and enjoys having technical discussions together, involving everyone. In the end, a software architect is more of a status than a role with explicitly defined responsibilities. It is a sign of respect, paid by other team players to the oldest and the most authoritative one among them. Right?
Absolutely wrong!
Obviously, an architect is usually someone who has the most knowledge, skills, experience, and authority. Of course, an architect usually knows more than others and is able to communicate his knowledge with diplomacy and pedagogy when required. An architect is usually one of the smartest guys on the team.
This is not, however, what makes him/her an architect.
And this is not what the team needs. My definition of a software architect is this:
An architect is the one who takes the blame for the quality.
You can replace “blame” with accountability or responsibility. Although, I prefer to use “blame,” because it much better emphasizes the fact that every quality issue in the product under development is a personal fault of the architect. Of course, together with the blame he also takes all the credit from happy customers, when the quality is good.
This is what the team needs—someone personally responsible for the quality of the software being developed.
How this guy will delegate this responsibility to others is his job. Whether he will use his knowledge and skills, or quality control tools, or unit testing frameworks, or authority, or coaching, or corporal punishment—it’s his business. A project manager delegates quality control to the software architect, and it is up to the software architect how to delegate it further.
The role of a software architect is crucial for every project, even if there are just two coders working at the same desk. One of them has to be the architect.
An ideal architect has all the merits mentioned above. He listens to everybody and takes their opinions into account. He is a good coach and a teacher, with a lot of patience. He is an effective communicator and negotiator. He is a diplomat. And he is an expert in the technical domain.
But, even if he doesn’t have all these merits, his decision is always final.
And this is the job of the project manager, to make sure that every technical decision the architect makes is not doubted by anyone. This is what delegation is all about—responsibility should always come with power.
As a project manager, you should regularly evaluate the results of your architect. Remember, the quality of the product your team is working on is his personal (!) responsibility. Any problems you see are his problems. Don’t be afraid to blame him and punish him. But, always remember that in order to make your punishments productive you should give your architect full power in his actions. Let me reiterate: his decisions should be final.
If you, as a project manager, are not happy with the quality of the product and the architect doesn’t improve the situation, replace him. Downgrade him to a programmer and promote one of the programmers to an architect. But always remember that there can only be one architect in the team, and that his decisions are final.
That’s the only way of having a chance of building a perfect product.
Does your team have an official role of a Software Architect, who has enough authority to make technical decisions alone? #codeahead
--- Yegor Bugayenko (@yegor256) May 13, 2018
