I work for a small company which has less than 100 persons. Several months ago, this company offered me position of SA and I accepted. There are three teams in this company, and I work for one of them. This is the first time I work as a SA.

During the past months, I find I don't have any power of management, I even can't let the team member do things (coding-related) in the way which is correct and more efficient. The team members argue with me on very very basic technical questions and I have to explain to them again and again. Though some members did take my advice, other members stubbornly program in their way which frequently proved wrong finally.

Recently I feel a little tired and confused. I wonder what is correct relationship between a Software Architect and team members including the team leader? Besides, is software architect also leaded by the Team Leader?

  • @gnat I have read the post your provided, and know what an SA SHOULD do. But this post still doesnt have answer to my questions: Is SA also leaded like other team members by TEAM leader? What attitude should team members have while communicating with SA, the same as that of communicating with any othe developers? – Steve Nov 2 '13 at 12:47
  • @gnat A team member has the duty to obey its team leader, and the leader has the power of leading all members. But what about an SA, what is the relationship between other team member and SA? – Steve Nov 2 '13 at 13:07
  • 1
    @StevePeng - obey? power? The use of these words makes me think there's a fundamental flaw in your organization's corporate culture. Sounds more like a dictatorship than a software company. Keep in mind that neither role, the TL or SA, is there to simply tell people what to do all day. "Management is a support function" - Joel Spolsky – jmort253 Nov 3 '13 at 20:05

Software architect has no power of management. This is explained in the question I referred in comments:

What should you bring to the table as a Software Architect?

Stuff architect does is explained in top answer:

The SA should have the last word on all design, technology and coding style decisions... for the most part... developers get to decide, at their level, how problems are to be solved... the SA keeps the pointy-haired bosses out of the developers' cubicles.

A good explanation for how they do their job is provided in another answer:

A thick skin. Good negotiation skills.

I've been an architect myself and I can confirm that answers match my experience.

Now, I would like to get a bit deeper on what you feel like a problem, disagreements with team members and the need to obey to team lead.

I think that disagreement with someone who you have no power to order is the most valuable and interesting part of architect job. If you continuously feel bad about it, seriously consider whether this job is indeed for you.

Disagreements that can not be resolved by brainless "shut up and follow my orders" provide unique opportunity for one to progress as an architect. These are the way to learn how to discuss complicated problems, how to negotiate and resolve conflicts, how to explain things, communicate your knowledge and learn new things. These are the only way to practice a skill to convince and influence team members.

If you're especially lucky, you'll happen to get into disagreement about things where your initial understanding is wrong.

Being free of thought-blocking "follow my orders" escape hatch, you will be able to find out how to improve your understanding, figure your mistakes, accept them and how to discover, share and lead the right way.

At architect position, one would rather strive to gain from failures like that, by analyzing what went wrong, what could have been done better and how to efficiently "re-use" acquired experience. These bits of knowledge may be invaluable if learned right, the very successful career at senior positions may depend on how well these are learned, as explained in this brilliant answer at WP:

Judgement comes not from success, but from failures. Most companies want to hire people that have had their failures paid for by previous companies...

  • 2
    +1. I'd also add that a SA must be humble, admit its mistakes and accept ideas from junior programmers. Nowadays there're many really talented junior programmers that deserve to be listen. Just try to put some order in a 'shared pool of ideas'. – Matthew Azkimov Nov 2 '13 at 19:00
  • I only participate in "Specify the high-level architecture" and "Produce SA artifacts, such as UML diagrams, Gantt charts and the like", I am not able to touch the other steps what says in programmers.stackexchange.com/questions/18444/…, and this is what makes me feel confused , because without the other steps I am just like a senior developer. – Steve Nov 3 '13 at 10:38
  • Besides, the team lead assigns me tasks and communicates with me like what he does with the other developers. So I feel like the position they offer me is rather a senior developer than an SA. Am I right? Is there anything wrong in the position/title this company offers me? – Steve Nov 3 '13 at 10:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.