6.2 The Architect as Team Builder

The software architect leads by bringing the team together. As the most visible and technical of the management staff, the architect is in a position to turn the mindsets of the team members in a common direction. All but the most dysfunctional of teams want to be successful. However, where people differ is on the details of what it means to have a successful outcome as well as the best means of achieving it. To correct the first of these issues, the architect must continually communicate the vision of what the final outcome of the development team can be if the management and technical plans are followed. This creates a willingness in team members to give the day-to-day decisions the benefit of the doubt as long as they believe that the end goal is sufficient to satisfy their own personal criteria for project success.

As soon as a team is on the same page as to the overall vision and desired outcome, the common view of where the team is going serves to lessen the contention about the best means to achieve it. Rather than suspecting that the motives of other team members are different from their own, people are more willing to consider various solutions and defined objectives on their technical merit. In a software project, whenever the discussion can be converted into a purely technical discussion rather than one based on personality and ego management, the team takes another step toward accomplishing the project goals. Often, developing an understanding of basic facilitation techniques can be extremely valuable in keeping discussions focused on key technical concerns.

One important lesson software architects must learn is to trust the skills and talents of other people on their team. A common mistake of new software architects is to micromanage other team members. This results in one of two predictable outcomes. (1) The other developers may become resentful of the new software architect's lack of trust and confidence in them, resulting in a significant negative impact on their productivity with regard to the team goal and overall project vision. (2) Even worse, the developers may eagerly allow the architect to assume the bulk of the project responsibilities. This last outcome creates the illusion of working in the short term, but it breaks down quickly as the reality sinks in that the architect cannot work as effectively on his or her own as with a high-performance team of dedicated developers focused on accomplishing the same outcome. Therefore, trusting other team members to execute tasks independently is critical for the overall success of the team. Yes, trust involves undertaking risks that some people, in hindsight, may claim are unnecessary. However, taking the long view, it is important that others accept and live up to their individual and team responsibilities in order to maximize the overall output from a development team.

A software architect is sometimes required to mediate between conflicting demands of project management and higher-level stakeholders in a development project. Often the demands on the software developers were made higher up in the management chain than the software architect without detailed knowledge of the development staff that will be responsible for delivering on whatever claims and expectations were formulated. To be effective, a software architect focuses first and foremost on the needs of the development staff. At some level, every project plan ever made is a fantasy. It is the flesh-and-blood developers who must feel respected and motivated enough to produce the concrete project deliverables. The software architect must be aggressive in serving the needs of developers by communicating with management, overseeing the purchase of productivity-enhancing tools and COTS products, ensuring proper recognition for the team, and so on. After all, the ultimate value the architect adds is to ensure that the developers are efficient and effective in performing their tasks.