Why I Don't Use the Architect Title

I get nervous when I see the title "architect" in IT job roles.

I've had this title before as an employer's standard, but lobbied against it. I instead prefer separating job titles from project roles.

Why?

"Architect" as an IT role descriptor carries an appropriate level of technical expertise and broad experience - but typically, for too long. I don't like "Architect" because it sticks.

The verb "architect" implies a leadership and guidance in big system design decisions.
The noun "architect" can be a bludgeon in a software planning meeting.

Putting egos aside when making platform and architecture decisions can be next to impossible if someone decides to wield the "architect" hammer.

Can you think of a situation when large amounts of dated technical experience did not make for quality technical guidance in the future? I bet you can. I bet you know exactly the type I'm talking about.

Platforms, language versions, feature sets and even product suites change regularly, so a clingy title like "architect" may be appropriate for only one or two projects or generations of a given technology. A few major releases, framework versions or platform changes later, and the "architect" title may be as stale and waning as the technical skillset behind it. Without continuing education, "architect" becomes synonymous with "boat anchor".

When the next project comes, the "architect" resource from the original project may be (not as a rule) more gentrified than skilled. And while the "architect" doesn't need to be the most technically savvy member of a project team, the assumption that "architect" was an applicable title a few years ago - and so shall ever be - is a dangerous trap.

• The "architect" for your SQL 2005 project needs to get up to speed on the latest changes (ex: data types, high availability, and columnstore indexes) before serving in a similar role for your new SQL Server 2014 project.
• The "architect" for your .NET v2.0 project that's now in maintenance would perhaps better serve as a developer for your new .NET 4.5 project. 
• The "architect" for your first-iteration Entity Framework 4 project might not be ready to carry the lead that new EF6 application.
• The "architect" for your SQL Server 2008 R2 SSAS multidimensional business intelligence platform may not be aware of architecture features involved in your new SharePoint-based business intelligence project leveraging SSAS Tabular and PowerBI.

Instead of your top-tier developers assuming the title of "architect", try using the names with transient intent, like Project Lead, Team Lead, Technical Lead, Designer, Analyst or Developer.

In summary, please make sure that you and your coworkers aren't treating "architect" like academia treats tenure. It's not a lifetime appointment, and the ego boost that comes with "architect" needs to give way to honesty, humility and continuing education.