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.
5 comments:
I've been inflicted with the "architect" title three times, and yes, I do mean inflicted. In every case, possessing the title immediately means you get pulled away from the actual project to focus on "the big picture". Sure, you still get to be the "owner" of the design, but the team building it is at least a few corridors over - if you're lucky. You get isolated from where your design works and where it breaks (and every design breaks somewhere), and you can't see if the team is making mistakes. If the project runs into technical issues, it runs the risk of finger-pointing blame.
As a tech lead, however, I'm working on one project. I'm helping to code it. The rest of the coders, as well as the analysts and testers, are in the room with me. As lead, I'm responsible for the design, but that doesn't mean I bring it into existence by myself - I collaborate with the other people in the team, seeking ideas and looking to validate my own.
I've been a developer with an architect and with tech leads, I've been an architect, and I've been a tech lead. Tech leads are not architects. And that's a good thing.
Good post. I agree that good tech leads should see their team as peers and instead of dictating ideas and forcing practices on them, they should foster an environment of creativity and autonomy.
A recent example of this for me was a simple enhancement requirement to a table to stored timestamp information. I said to my team lead, sure no problem ill just create a new field to stored the value. His reply was NO i want you to append it to the comment field, to which after I found out there was no reason for this apart from “its easier” that I continued to recommend we store the timestamp in a separate field so that it’s easily searchable and doesn’t unnecessarily demoralise the data. He simply replied NO, you’ll do it my way. Ive never felt so useless and undervalued in a team before.
Robert is right, there is a difference, and I've encountered exactly what you have encountered.
Plus, Tech Leads are cheaper than architects :)
Georgi, your team leader is a moron. That's gotta be the dumbest idea I've heard of.
What about "Technical Experience Strategist"? :)
Calling in from 2016. As a Tech Lead I find myself daily educating technically the last remaining architects. They still have hard time programming so most of them got fired or quit, the remaining ones we keep in the Technology Archaeology section.
Post a Comment