“We are from Corp IT and we’re here to help…” Seven tips on how to avoid being THAT Architect

Lessons of Failure - How to Avoid Being the Asshole Architect

“Recently, I was the happy recipient of some very condescending “advice” from the architecture group of a client.  The tone, quality and delivery of the information completely overwhelmed the actual message (some of which was actually relevant, and some was off in left field).  This pleasant experience reminding me why the term “software architect” has come to be synonymous in some circles with “arrogant jerk who forgot what it’s like to code on a real project”.

I realized that I’ve had that exact same attitude at times and it just didn’t pay off at all.  My message was probably lost in the same manner I discarded this guy’s advice in favor of sticking it to The Man and doing whatever I was going to do anyway.

All of this is counterproductive in any development project.  Reflecting on the situation a bit more, I realized that there are a handful of key points that all software architects ought to remember.  Dispelling the “Ivory Tower” mentality can’t be anything but positive for everyone involved.  With that in mind, I bring you the

Five Minute Guide to Avoid Being the Asshole Architect (FMGTABAA):

…

…”

If you’re an application/dev/etc architect here’s something to think about… Are you THAT guy or gal?

I like the first point. If you don’t feel the user’s pain, if you’re not sitting in their seats, walking in their shoes, etc, etc, then be carefully telling them what they need. You SHOULD help them think through a problem, work with them to find the root issue, look beyond their initial requests to find possible real issues, i.e. really fix this issue not just do what they say. Yet don’t cross the line where you think you’re smarting than them, that they don’t “understand” and force something down their throats because you “know better.” [LOL… wow, touched a nerve there, didn’t it? ]

(via nPlus1 - How to Avoid Being the Asshole Architect)