In the software development projects where I am involved as an architect I can typically observe different types of software architects. Let me illustrate two extremes:
- Some architects try hard not to decide anything or at least not too early. These architects typically integrate all other project participants in the decision process. On one hand, this can be a very successful approach. If everyone agrees to important decisions, everyone remains motivated. On the other hand, the same habitude leads to the risk of decisions being postponed endlessly. Eventually, architects constantly drawing new UML diagrams or deep diving into technical details are a problem not a solution. In most cases, wrong decisions are better than no decisions, because wrong decisions can be detected very early and all problems resolved. Think of refactoring as a tool!
- Other architects prefer a kind of tyranny. They got a lot of self esteem, believe to know everything, adore the Borgs for their "resistance is futile" strategy. This style of leadership can come very handy in critical situations where project success depends on strong leadership, for example when you require fast decisions. The downside of this dictatorship is that architects behaving this way may not get buy-in from other participants, thus leading to a high level of demotivation. And obviously, too much power in the hands of the wrong persons can lead to projects being doomed to fail miserably. A negative implication might be that those dictators want to get involved in every decision, even in unimportant ones. As no one is able to understand all details in the case the project is large enough, you'll inevitably will experience lots of wrong decisions.
You will argue that these leadership styles are not specific to software architects, and, of course, you are absolutely right!
What I'd like to emphasize in this posting is the importance of leadership skills for software architects. Of course, there are situations where an architect should be dictator, and other situations where democracy might be the more appropriate choice.
Unfortunately, or should I say fortunately, all of us got different personalities. Your leadership style should fit with your personality, because otherwise everyone will recognize the discrepancy.
I won't cover leadership styles in too much detail because there are persons much more knowledgeable than I in this context. Just read this one or that one. A Web search will even yield more material.
What I consider really helpful is a kind of self analysis. For instance:
- Personality: analyze your own personality, try to find your strengths and weaknesses. Ask other people how they assess you as an architect. How do you evaluate yourself acting as an architect? A very helpful tool might be to analyze previous projects: where did you succeed and why and where did you fail.
- Leadership Styles: read about all possible leadership styles. Nothing more to add here.
- Context: Think in your project context what leadership style should be applied in which situation. Of course, you can't act as a dictator in front of your head of R&D. Likewise, always striving for full agreement by every developer can result in endless recursion.
For a software architect, the time spent for communication might be as large as 50%. Communication means interacting with other people, informing them, guiding and mentoring them, or getting their buy-in. Without the right social skills and leadership style, a software architect is doomed to fail.
7 comments:
Great post, benefits for those who follow your advice and do the homework!
Both external links point to the same URL: http://www.nwlink.com/~donclark/leader/leadstl.html. Where should the second one link to?
@Peter;: thanks a lot for your remark. I have corrected the link
-- Michael
I found that marketing yourself as a developocrat while leading with conviction (but not necessarily to the extreme of archidictatorship) tends to yield good results.
I would draw a parallel in the role a scrum master plays to remove functional impediments from the team. If the architect can market himslef as the team's "servant" - while being competent - he will be consulted for removing architecture impediments. And the project wins !
Hi ,
Good one....i have also seen your posts on the architects role...
well, can u also get a post which gets the boudaries on which the architect should restrict to ?
Thanks
Senthil
http://dotnetcrunch.blogspot.com
Your point on communication hit the mark for me. I am a system architect. My most heavily used tool? Powerpoint! I teach, I plan, I conceptualize, I present concepts to senior management at a level they can understand, I present detailed concepts, requirements, design philosophy, etc. to all the teams who will actually build the product. When young engineers (out of school) ask me which of their skills is most important, my most common answer is communication. I've said (many times actually) that I'd rather have a team of engineers who write well, speak well, can expain to others their ideas, designs, and collaborate well with others, then to have a team of engineers who are perceived to be brilliant, but nobody understands them.
Your point on communication hit the mark for me. I am a system architect. My most heavily used tool? Powerpoint! I teach, I plan, I conceptualize, I present concepts to senior management at a level they can understand, I present detailed concepts, requirements, design philosophy, etc. to all the teams who will actually build the product. When young engineers (out of school) ask me which of their skills is most important, my most common answer is communication. I've said (many times actually) that I'd rather have a team of engineers who write well, speak well, can expain to others their ideas, designs, and collaborate well with others, then to have a team of engineers who are perceived to be brilliant, but nobody understands them.
Post a Comment