Software Architect responsibilities

Question

I saw some previous posts here abour Software Architect role so decided to ask this question.

About 8 months ago I ended up as a senior .NET developer position on a brand new ASP.NET project building web application from ground-up for a large federal client(US govt). Everything here seems normal except for one thing that I found extremely unusual - person who's offical title was "Senior Software Architect". I worked with architects before, some of them were better, some of them worse, but never seen one who so technically incompetent. Just to give you a better idea on what his technical level is, he recently asked us what's a difference between "IDisposable" and "IEnumerable", or what "Protected" class member variable is. On the other hand he is very good at communicating with client, interpreting their requirements for developers, working with database team when database when we inform him database change need to be made. He does lots of things on a project, just doesn't "architect" software, because technically not capable of doing so. He is also very good at hiding this deficiency from project senior management, usually by deferring technical questions to me and other developers.

My question is - do I understand "software architect" role correctly and what should I do in this situation. My options seem to be:

1) Leave the project.

2) Treat him as great business analyst and just ignore the rest.

3) Inform high level management of this situation as they completely unaware of that.

Which option would you choose in this kind of situation? Are there any other options that I don't see?

Thanks for the answers.

Answer 1

A building architect likely wouldn't know how to wire an outlet. Why do you expect a software one to know the equivalent? If he's effective at managing the technical staff and interpreting client instructions for the development staff, and management isn't seeing any issues, it sounds like things are just fine.

Answer 2

There can be a lot of different types of Architects. Enterprise or System Architects do not need to know application level details. Find out his role / responsibilities and understand it before you go to senior management. I did not quite understand what you are peeved about if he is deferring technical questions to you.

Based on what you mentioned, he seems to be acting either like a System Architect or a Technical project manager.

It seems like you do not like this person from your consideration of some very strong options like leaving the project or skip level with his boss.

Why don't you have a frank conversation with him about your expectations and see what he has to say?

Answer 3

Don't bother worrying about your Software Architect's title.

If your team feels a role is not being fulfilled, see if you can get someone hired to fill that role (regardless of what the new person's title will be).

Answer 4

I would probably pick Option 2, treat him as a great business analyst and ignore the rest.

If he's actually doing something useful for he project, why be bothered over his title?

If nobody in your team is actually architecting software, then you have a great opportunity to step up and fill the role. Your architect seems like a nice Guy who relies on his team a lot - step up and start asking questions, help find ways to make the project better one architectural decision at a time.

In time you will either grow your influence and become recognize as the true architect - or you'll gain valuable experience to take elsewhere.

Just remember that your focus has to be on finding ways to improve he process, and be careful to not go into it with a "evertyhing is broken, I am the smartest coder and will fix all the architects mistakes" attitude.

Good luck!

Answer 5

Don't do your third option. Don't don't don't!! Skipping a level to complain about an employee "above" you is a very drastic step. It may seem reasonable before you do it, but take this from me as somebody who tried it and regretted it. The upper management member may not simply listen to you and accept your judgment. It they don't, you're stuck working with somebody who likely will hear something of your complaint (even if it's just that "some employees seem concerned", s/he may piece together that you complained based on your prior interactions). When I tried this, although my points and examples were plainly laid out, the response I received was:

1. Had I brought this up with the person it concerned? (Which I had not because is it reasonable to tell a person that I wish they could "fix" their own incompetence? I imagine they'd have done so before, if they could or if they agreed with me.)

2. How could I be sure that my own relative lack of experience wasn't clouding my judgment? My "ability to discern incompetence" hadn't been proven enough to make the claims I did, based on the sheer fact that the other person was hired for a higher-responsibility position than I was.

Seriously, don't do number three (especially if you don't plan to also do number one very very soon). I've known several people, myself included, who have tried similar approaches, and none of us benefited from it.

Answer 6

I think you can find a way to bring up his incompetence into your management attention without directly talking to them.

Answer 7

There is another option, but it is a rather risky one to my mind:

Confront him on his technical incompetencies.

Now, this does carry with it many challenges, not the least of which is that this could make your life hard if the guy is really a jerk that will retailate against you for it. How to Win Friends and Influence People has these tips:

1. Begin with praise and honest appreciation.
2. Call attention to other people's mistakes indirectly.
3. Talk about your own mistakes first.
4. Ask questions instead of directly giving orders.
5. Let the other person save face.
6. Praise every improvement.
7. Give them a fine reputation to live up to.
8. Encourage them by making their faults seem easy to correct.
9. Make the other person happy about doing what you suggest.

I'm not saying it's a great option, but it is something that may work in that rare 1 in a million or so times where someone upon confrontation may respond, "You're right, I'm more of a BA and should get my title changed on this project," or maybe there is something else going on here that you don't know. From that link above is the point, "Try honestly to see things from the other person's point of view," which is a good suggestion I think as something to do before jumping into anything drastic.

Answer 8

Sometimes titles don't tell the truth as for what an employee is actually doing. Take for example Microsoft's Program Manager role: link text

What on earth does that even mean? What is it that a Program Manager is actually doing? I tell you what I went on an interview for this position in Seattle and still couldn't figure it out. I think they purposefully try to confuse you or something. Anyways, sometimes it's not about living up to the position you are filling but it is working with your team and picking up the slack where it is needed. Also, find things that others can't do and then you do them so as to benefit the team.

Ultimately, if the team is working, projects are continuously successfully and management is happy with who they have labeled as whatever they want to label them as and the employees are happy with their own labels, then don't break it. "Don't fix what isn't broken!"