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 [1]:
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 [2]:
- 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 supported a retail distribution operation. It was a middleware application that created a cache of record information to provide greater responsiveness to client programs that needed to quickly acknowledge receipt and produce label information for cases and pallets as they rolled of the trucks. The complexity of the original design resulted in developers who didn’t want to "fix" it, never-ending trouble ticket calls, and literally the loss of good people from the team. Let’s examine how a software architect can apply each of the five practices to this scenario.
Model the Way: For the architect, this is about using modeling to model the way. That play on words is meant to highlight two perspectives of modeling. The engineer’s understanding of modeling is to capture the essence of a problem through various viewpoints. That act supports Kouzes and Posner’s concept of modeling in the sense that you should live according to the vision you want others to follow.
Think about it. When modeling in the architectural sense, you are establishing standards, guidelines and constraints that should be followed by all the developers. In other words, if you decide to do a last minute "hack" that runs against the grain of your standards, don't be surprised if you have opened the door for others to do the same.
Further, by adopting patterns and explaining them, you are communicating an expectation. At the same time, the developer is growing professionally through the exposure of best practices. Indeed, in Just Enough Architecture [2], George Fairbanks notes that the constraints "are a means of transferring wisdom." By sharing knowledge, you are encouraging others on the team to do the same.
In my personal example, a critical success element was openness to each other's ideas. For instance, once team members agreed on basic patterns, it was critical that they saw buy in from me for their suggestions as well as mine.
Inspire a Shared Vision: In Working with Emotional Intelligence, Daniel Goleman cites research that suggests that leaders who facilitate teams are more effective than managers who supervise. There is a fine line between supervising and facilitating. You know you are seen as a supervisor when you receive very little feedback because everyone assumes you will make the decision. Facilitating, on the other hand, is the art (and courage) of stepping back and putting the decision-making process in the hands of others while keeping everyone focused on the problem.
For me, the best approach is to come to the table with a proposal whether it is a deployment diagram or prose of some kind, a practice inspired by Frederick Brooks in The Mythical Man Month [5] where he notes that once something is written down it takes on a life of its own. The art of being an architect is awareness that this is to start the conversation.
Again, after I presented my idea of the major structural change to the application, we certainly debated and questioned some assumptions. More importantly, much of the ownership of the design transitioned from me to the team as others began adding details. It was that sense of ownership that brought others into the shared vision.
I should add that this worked because as a group we instinctively respected each other, and the ongoing dialog reinforced this.
Challenge the Process: This does not imply going rogue. It does place the responsibility, though, on the leader’s shoulders to be vigilant of decisions done purely out of convenience. An example of this is in the use of a presumptive architecture described by Fairbanks. Often, a presumptive architecture is one that is already in place and many assume its reuse. Identifying the failure of presumptive architectures is a form of Challenging the Process.
Going back to that specific experience, the troublesome application was based heavily on a third party's object libraries. The pattern of objects in a hierarchy of linked lists essentially took a query from the database and renormalized the result set. Up to this point, everyone assumed that approach was essential because of the legacy nature of the application. The approach I suggested was to use a block of shared memory to cache the query results. That high-level redesign change created enthusiasm among the developers because it was understandable. That positive feedback from the developers was also encouraging to the higher management levels (more stakeholders) to support the rewrite of the application.
Enable Others to Act: This is where we begin to see the already discussed practices support each other. By working through critical decisions with the developers, the architect has set the stage for more effective development. In other words, developers have a known starting point.
Further, there is a parallel human element for each architectural decision made. For example, good architecture clearly identifies boundaries where interfaces are needed. Behind each interface on paper, there are often people on each side of those interfaces that represent another set of interests. So, identifying the interfaces is also providing a map of "relationships" with specific information to team members of conversations they should initiate.
Encourage the Heart: This practice represents the synergy created by the preceding four. In essence, architecture communicates the big picture, and, because there is a big picture, all stakeholders have the sense that the goal is attainable.
Encouraging the heart is also accomplished through the assignment of work. The simple act of partitioning is not only modeling, it also becomes the basis of assigning work to developers. That distribution of work should clearly communicate that you believe in that developer’s ability.
Another consideration is inspired by Donella Meadows, the author of Thinking in Systems: A Primer [6]. She notes that the higher level of a hierarchy is designed to serve those in the lower levels. Quite simply, an architect's general availability to discuss alternatives or just answer a question adds a sense of confidence to the general working atmosphere. The architect’s availability should not be seen as a crutch for developers. Instead, it is the foundational scaffolding to nurture the craft of software development in others.
Finally, architects encourage the heart by bringing a passion for technology into the group. Others will sense that level of energy and often respond in kind.
If you consider yourself an architect, I have no doubt that there is a sincere pride manifested in your intentional efforts to hone the skills of your craft. I believe intentionally considering Kouzes and Posner’s five practices with each architectural decision you make will take you to the next level.
REFERENCES:
1] Bass, Len; Pal Clements, and Rick Kazman. Software Architecture in Practice. Addison-Wesley, 2003.
2] Kouzes, James and Barry Posner. The Leadership Challenge. Jossey-Bass, 2008.
3] Fairbanks, George H. Just Enough Software Architecture: A Risk-Driven Approach. Marshall & Brainerd, 2010.
4] Goleman, Daniel. Working with Emotional Intelligence. Bantam, 2000.
5] Brooks, Frederick, P. The Mythical Man Month. Addison-Wesley Professional, 1995.
6] Meadows, Donella H. Thinking in Systems: A Primer. Chelsea Green Publishing, 2008.
