You, Sir, Are No Architect

You can quote all the learning management, skills management, performance management and professional development plan statistics you want, but we all know that title misdirection thrives in large Fortune 500 companies. It's like a tapeworm in a Mexican restaurant: it is a target-rich environment. It isn't endemic to IT, but it seems to be especially pernicious in this critical field.

Title inflation isn’t new. It’s well documented that people want other people to think they’re more important than they really are. Frankly I have no problem with that. We can all see it for what it is and call bullshit when it matters.

What’s more insidious is title dilution. This is the casual and willy nilly renaming of positions to better suit the organizational model of the day. If you’re leading a team to conduct project management, then by gum everyone is a project manager (regardless of what they were called prior). The effect of this is to bring folks to the table who lack appropriate skill sets for a given problem. You end up diluting the meaning of titles in general. If we have problems staffing skills based on job description or a general confusion over definitions, then we have a real problem.

You can quote all the learning management, skills management, performance management and professional development plan statistics you want, but we all know that title misdirection thrives in large Fortune 500 companies. It’s like a tapeworm in a Mexican restaurant: it is a target-rich environment. It isn’t endemic to IT, but it seems to be especially pernicious in this critical field.

Most IT organizations are cost-centers, not profit centers. As such the need to constantly justify and rationalize the ‘value’ of a particular IT group is a battle to jockey for position. Titles are a key part of this maneuvering where metrics fail to inform. If your team doesn’t have the proper job descriptions that speak to the inherent value of those positions to the business, then your own security and influence is at risk. Hence the need to ensure all of those technical writers and developers and DBA’s you have are all now known as ‘Architects’. Architecture is, after all, where solution decision making power comes from, right? Clearly to increase one’s authority and importance (and hence, one’s value to the business), one needs lots and lots of architects.

This isn’t to say a person can’t move from writing code to describing architecture. And naturally there are all levels and styles of architects. An ex-developer might make a good application architect. Someone who’s an old DBA might be a good data architect. I’m not quibbling with that. I’m targeting the folks who one day are something and then…poof, without any training or experience, become something else entirely and almost certainly superficially.

I know of a company where it is not uncommon to have a project team consisting of all architects plus one project manager. You might wonder how anything would get accomplished in such a scenario. The answer is that 2/3 of those ‘architects’ aren’t architects at all. They simply have the word architect in their title as a means of misdirection. The role and purpose of “architect” becomes diluted. It is rationale to insert oneself and one’s organization into a place that most likely has a good chance at rich capital funding. The title of architect comes to mean just about anything. And in fact, in the company I referred to earlier, the title of architect is about the most meaningless title one can have. It is almost as bad as being an “analyst”, whatever that is these days.

Ferreting out a superficial architect on a resume or in an interview is fairly straight forward. You simply have to ask what they did as opposed to what they were party to. If architecture is about reasoning the components, relationships and properties of a system, if it is about describing complexity clearly via abstraction and separation of concerns, then one merely has to talk to someone to ascertain their capability to perform an architecture function. An architect has to have had created something that describes a system as a minimum. If they were merely present while someone else did the creation, that doesn’t count.

Figuring out if someone in a large company is a superficial architect is much more difficult. They’re a plague on large IT organizations. They hide behind meetings and conference calls, dive behind Sharepoint sites, dodge and bob and weave about, avoiding any and all responsibility for producing an actual document that can be peer reviewed. They are Fortune 500 parasites. They rely on the anonymity of the massive organization to mask their inability to perform as an architect. Oh sure they produce status reports and whatnot that show how valuable all their work has been. But ask for a link to that work? Oh they’ll email that to you cause, you know, it’s in Sharepoint site that isn’t public and all. Fat chance you’ll ever see it. If you do, don’t be surprised to discover it has been piecemeal assembled from the works of other people. In modern parlance, it was collaborated on. In my view, it was ripped off and plagiarized.

What’s the solution? Sadly as with any massive organization, solutions aren’t fast in the offing. But I encourage you to call these frauds out at every and all opportunity. Might I suggest something along these lines:

Superficial Architect/Parasite: “And that, folks, is how we’re going to drive maximum value by deriving efficiency from a horizontal implementation of role based user provisioning.”

You: “Wow. That certainly does seem to provide some real value. Could I take a look at a logical view or something so I can get my head around the components?”

SA/P: “Yeah sure. No problem. I’ll get that to you offline.”

You: “But our meeting has 45 minutes left in it. Couldn’t you just share it or mail it now?”

SA/P: “Uh yeah. Let me just find it here… Uh, um, ah. Here it is.”

You: “Oh I see it now. But wait. That looks like a white paper from the Oracle website.”

SA/P: “Um..”

You: “Do you have an architecture you can share?”

SA/P: “Well it’s represented in the document.”

You: “But that document doesn’t include an architecture. It’s a whitepaper. In any event, it isn’t your document. It’s Oracle’s.”

SA/P: “Uh. Well.”

You: “Are you the architect for this project?”

SA/P: “Yes, yes I am”

You: “Let me ask you: is there, in fact, any architecture at all?”

SA/P: “Uh. Um. Not at this time.”

You: “Yet you are proposing solution delivery dates and timelines.”

SA/P: “Well, I used to be a project manager.”

You: “Listen. I’ve known architects. Architects have been friends of mine. You, sir, are NO architect.”

That’s right. Call it as it is. It’s like someone pretending they served in the Army in Iraq when in fact they were in 1st year ROTC and then dropped out of college. It is a fraud. It is title fraud. We should never hesitate to call bullshit when we see it and prevent the dilution of architecture’s value as a critical function of information technology.