Five Reasons Software Developers Hate Software Architects

I remember it well.

In 2005, after twelve years as a developer and project lead inside HP IT, I agreed to a promotion that gave me the swanky sounding title of "HP.com Chief Architect". I went to a friend of mine who I'd done a lot of both Java and .NET development with to tell him my good news, and what was his reaction? He immediately began to hum the Imperial March from The Empire Strikes Back and congratulated me on joining the software engineering dark side. "You're one of them now," he teased with a nod and a knowing smile.

In just about any online coding discussion board you could choose to follow, this theme recurs. I've seen it first hand myself multiple times too, so I knew the ribbing I took from my buddy was justified. You see someone start out as a front line developer, spending most of their days chained to their desk with their favorite IDE and you get to know the likable human being they are. Then the hard core coding diminishes a bit and, as a lead developer, that person spends a lot more time on design. Maybe someone in this role even begins to do things like analyze defect rates or track the schedule for this single project he spends all his time on.

But something happens when advancement beyond that occurs. When the responsibility escalates to little or no coding and being in charge of the long term direction of multiple projects simultaneously, when that person spends more time in meetings than anything else and gets this "architect" title, the bridges start to get burned and the hate begins to flow. Before long, that guy you used to enjoy going on lunchtime burrito runs with asserts himself in ways you never thought possible and seems to be leading your project team, as well as the others he's been given jurisdiction, over an irrational cliff.

Why does this happen? While every situation is a little different, here are five reasons to consider:

#1 The cockiness

Just because you've proven yourself effective at earlier stages of your career doesn't mean you are above reproach now that you have that "architect" title. When I was a lead, I once questioned my architect on why we were making a particular technical decision on something. I expected to get some rationale that included trade offs among various criteria, but instead he replied, "Because I'm the architect."

Someone I like and respect once described this behavior as NIBM: Not Invented By Me. When you are at the top of the technical chain of command it doesn't mean you have a monopoly on idea generation. Even if you think everybody else is wrong, you still owe it to your relationships with others and to your company to be inclusive and solicit other opinions. You still have to make the call at the end of the day, but by asking others to participate in the process, by having legitimate reasons for your decisions instead of invoking instinct that you alone possess, and by communicating those reasons to everyone involved in a way that shows you really did consider alternatives that other people suggested, you increase the possibility that others will follow your lead.

The result is better decisions and a stronger personal network.

#2 Losing touch with technology

As your responsibilities expand and you spend more of your time in meetings, keeping up with your technical skills becomes a challenge. A common response to this phenomena is to cling to the things you know and apply them to as many problems as possible. COBOL may have been awesome in 1989, but it's not helping that many people today and to suggest something stale (OK, maybe not as stale as COBOL, but you get the idea) for every single solution just because it's what you know, you erode your credibility with the folks on the front lines, and eventually, with management.

It's hard to do because of #1 above, but admit you have a problem. Keep in touch with your best coders and ask them what kinds of things they are starting to play around with so you know what you should begin reading up on. If you can spare it, volunteer for some prototyping duty, which lets you get your feet wet with something without having to deal with details like comprehensive logging or exception handling that a production quality product would eventually demand. Try this a couple of times a year, a week here or there, so you can remind yourself what it's like to be locked in your cubicle with your IDE again. By doing so, you'll learn something and earn some respect along the way.

Speaking of respect . . .

#3 Keeping clean hands by delegating all the dirty work

Some aspects of software engineering are a pain. Only a masochist has a good time with things like filling out firewall configuration requests for the network security people or extrapolating the latest performance test results to see if you have enough machine capacity in your production environment. While you may be empowered to delegate these unpleasant tasks to others below you in the organization hierarchy, it occasionally has to be a two way street.

Your busy meeting schedule one week might force you to ask someone to complete one of these errands for you, but check in when you do get some free time to see if there is something you can take off her plate for her. It doesn't have to be an even swap in terms of the favors exchanged over the course of a year, but you can't always be the one pushing work to someone else and never take any back. That is, of course, unless you want that person to despise you.

#4 Taking credit for everything, even when you did nothing

The higher up you go, the higher up you get to present status and issues to management. A team of 25 people might have contributed to a project, but you are often the lone representative that gets to deliver news to the person who drives around in a company car. You should always share the credit -- to do otherwise is simply malicious.

Maybe you did have the idea to bring in that vendor who made a huge difference, for example, but a whole team of others actually implemented the integration. Telling that Senior Vice President, "I brought in the vendor" sends the wrong message, and a statement like that is made worse if the people who made it happen are listening in by phone or sitting in the meeting room silently, hearing you diminish their efforts.

Even if you are trying to do the right thing, though, is it realistic to mention every single person's name in the time slice you get with that executive? Typically it isn't, but even if you simply take your own name off the title slide (leave it blank or substitute the name of the whole team), have another slide that lists everybody, and verbally emphasize that it was a group effort.  Even if you don't rattle off the individual names, the point is made that lots of people contributed to the success.

#5 Finding opportunities for yourself, but not for others

By getting a wider view of different projects going on within your organization (and potentially in others as well), you can't help but become aware of a wider variety of opportunities than people who are lower in the org chart than you. An extension of having broader responsibility is that you have access to a wider network of people. The best jobs aren't the ones you find listed somewhere, but are the ones that find you. Throw in things like trade publication article authoring, patent submittal, and trade show presentations and it becomes clear that the higher up you advance, the wider variety of opportunities there are.

That said, it is not exclusively a managers job to help people with their career path. To have information about a potential job opening which could help someone stay challenged, or a situation where someone could get wider exposure for his talents, and not use such knowledge for the greater good is irresponsible. Admittedly, these things take time and you might not get a whole lot of credit for for helping others with such things in your next performance evaluation.  But somebody who is a software developer today is going to be a high level manager 5 years from now, and it's a lot better for your long term prospects to have helped that person, or even to have a reputation for such assistance, than to have looked the other way.

In closing

Developers hate architects when they're cocky, when they don't keep up their technical skills, when they don't want to do any of the dirty work and always pass such things off to others, when they take credit where it isn't due, and when they bounce around to all the great jobs without helping anybody else rise through the ranks. Being responsible for multiple assets (like the 34 I am responsible for now) is not an easy job, but it doesn't have to be an isolating one. Above all, that is the root of all these behaviors.

Don't lock yourself up in that ivory tower and throw away the key. Interact with people. Tell them about your challenges and listen to theirs. Asking for an opinion doesn't mean you have to follow it, but it will legitimize whatever decision you do make by your having at least considered the alternatives. Helping someone find a better job that advances her career goals or occasionally shielding her from mind-numbing paperwork so she can focus on creating a solution builds a stronger relationship, so that the next time you ask that person do to something for you, she actually wants to do it.

Doing these things fosters synergy instead of fueling the well known hate stereotype that comes with the "architect" title in the software world. My list is hardly comprehensive, though -- what's yours?



Pete Johnson created one of the first web applications ever built inside Hewlett Packard during the mid 1990's and has had the good fortune to work with over 400 engineers all over the world, write articles for a variety of publications, and present topics at trade shows. He served as the HP.com Chief Architect for two and a half years before a reorganization brought him his present responsibilities as the Marketing and Internet Platform Services IT, Portals and Applications Chief Architect (try fitting that on a business card). He blogs about how improved non-technical skills can accelerate technical careers at http://blog.nerdguru.net.