
Five years ago, everybody seemed to want to have the word "architect" in their title. Firstly, they all needed a title and having an A in the acronym was the bomb - EA (Enterprise Architect); IA (Information Architect); and any other term with the "A" word at the end of it.
With this title came a lot of responsibility for whether the project succeeded or failed. Accepting that meant that you couldn't let others fail and take you with them. That's when in some circumstances, the iron fist came out and the right to veto a change became part of the job description. Of course, that made sense when it was your head on the chopping board.
It is commonly argued regularly that the decision making in a group should be centralised in order to make conflict resolution easier to solve. I agree with the idea that there must be away to settle disagreements between members of a team if they come to an impasse. There are many ways to do this but the fastest and most decisive is for one person to have the final word. The other way I have seen work regularly is to have the team decide through majority opinion or vote. When the group decides something for all then that is usually accepted by all.
The group decision method can go wrong if the most popular person and strongest speaker dominates. The one man final decision can also go wrong if... well, if they aren't good enough to make that call.
It is a rare project that I have worked on that is lead by one person with all the technical and high-level knowledge to make all decisions well. I have however often seen teams with a mix of people who can answer all the questions needed and pick the best option. Add to that team an external arbitrator (like a project manager) who can facilitate the decision making process and you have a much more successfully functioning team.
Software engineers are more creative lateral thinkers than they are credited with. Although the other disciplines of engineering are extremely logical, spend some time herding cats and you'll see that devs are more craftswomen (and craftsmen) than they are plodders through an already defined structured process.
With this creativity in mind, software engineers do not want to be mere typists for their architect or technical lead. They need to be allowed to create and use their skills to move the project forward. If you don't allow this, you lose all that is good about working with them. Unfortunately, this is too often the case with the tech leads I have seen since starting my career. Most of us find ways to work with these little dictators and sometimes we simply get fed up and move on to another team, another project or even another job.
Is today's title of "Tech Lead" the new, more acceptable synonym for what is now the dirty word "Architect"?
Yes, it is. Teams build software. Good tech leads and architects will guide their team, support them and remove technical blockers from their path. They won't use the word veto or force their ideas on to their intelligent peers. If they don't see their team as their peers then that's another problem altogether.
Come on tech leads, keep your title but use your powers for good and not evil.