Good leadership is intentional.
Good architecture is intentional.
Those two axioms form the foundation of this article. I have the firm belief that as an architect you are in a leadership position, and you have the unique ability to provide leadership through what you do as an architect.
I wanted to write this article because there seems to be something missing in software architecture and leadership articles that I have read. Certainly, most address the soft skills about building relationships and the need to understand the business concerns. No doubt, a transition does take place in the skill set one needs when stepping into the role of a software architect. At times, though, I feel like I could substitute the term “project manager” for "architect" in those portions of the articles that talk about leadership.
While there is certainly overlap in the general application of leadership principles across disciplines, I believe that an architect has a few unique opportunities that are missed in these homogenous descriptions. For one, developers are more likely to identify with an architect because of the technical skill set, and it’s been well established that common identity is a strong element in leadership roles. In a sense, without being said, the mere presence of an experienced architect is telling developers, "I've been there, and I’m here to help."
So, how can an architect-as-leader strengthen the identity bond? Quite simply, it’s in the craft as it is being practiced. To make my case, I’ll first provide working definitions of software architecture and the role of a software architect. Then, I'll discuss an approach to leadership that complements the activities that are specific to the job of a software architect.
First, my software architecture definition is based on the one found in Software Architecture in Practice :
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.
Second, I offer my definition of an architect for the context of this article:
A software architect is responsible for initiating and maintaining the integrity of a vision for a given software product throughout its development based on the needs of all the stakeholders.
Third, leadership is the art of motivating others to accomplish a goal—a subject of countless books and training seminars. About twelve years ago, I learned about Kouzes and Posner's five practices in their seminal work The Leadership Challenge :
- Model the way
- Inspire a shared vision
- Challenge the process
- Enable others to act
- Encourage the heart
In other words, leadership is not dependent on personality characteristics, such as charisma, which are not within the control of most. Instead, the five practices provide actions I can take to be an effective leader.
It doesn't matter if your architecture is manifested through expensive design tools, on the back of a paper napkin, or through verbal exchanges. Conveying an architectural decision is a leadership opportunity because it is a form of communication. Pick up any book on leadership, and you soon realize this is fundamental. Awareness of this while realizing that developers identify with the architect because of a common interest in technology should influence how you convey the information and motivate others.
While there is overlap between the concepts, I’ll offer specific examples of how Kouzes and Posner's five practices can be leveraged through the very work of a software architect, and I will use a personal experience to illustrate my points.
Within a maintenance environment I once worked in, my team inherited an application that