8.4 Handling Feedback

There is definitely a positive benefit just in the solicitation of feedback from developers. However, unless there is evidence that provided feedback is utilized to improve process and organizational issues, the development team will quickly become disillusioned and much more reluctant to comment on development activities. Therefore, in conjunction with obtaining feedback, it is vitally important to have in place a plan to make the most of feedback. Feedback is generally less useful in evaluating the current performance of an organization than in developing a strategy for future improvements in process and team building.

Admittedly, not all feedback should be acted upon. In the highly stressful software industry, a certain amount of venting commonly takes place. For example, if a deadline slips, there will always be a tendency for a few team members to place the blame (perhaps rightly so) on particular individuals. In such cases, feedback provides an understanding ear to people who have an appropriate sense of urgency in meeting the agreed-upon milestones by a particular date. However, rather than deal with specific instances-often well after the time when action can be taken to resolve the situation-look toward long-term patterns in people's actions and short-term steps in process improvements.

An important realization in dealing with people on a development team is that the personalities of the individual members of a team cannot be changed. The individuals can be encouraged, flattered, and negotiated with; however, ultimately they bear the responsibility for being productive members of a development team. This is true regardless of whether an architect directly supervises them, shares the same level of supervision with them, or is in a lesser position of authority. However, effective software architects may need to change themselves, how they deal with people, and how they react to people. First and foremost, software architects should lead by example and demonstrate the qualities they expect others in the team to share. This includes showing respect for people who are trying to accomplish the same goals, even if their methods are different. It may take time to listen effectively to understand the underlying reasons for a person's behavior. As an architect, it is important to accept responsibility for the efforts of everyone on the team. If the goal is shared by everyone on the team, it is illogical not to accept shared responsibility when various problems arise. Different organizations provide software architects with varying degrees of authority in working with software developers. Those architects who have been given greater authority can be even more effective by making the decisions that no one else on the development team is empowered to make.