7.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, a plan to make the most of feedback is vitally important to have in place in conjunction with obtaining 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 it is common for a certain amount of venting to take place. For example, if a deadline slipped, there will always be a tendency for a few team members to look to place 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 you cannot actually change the people you are working with. You can encourage them, flatter them, and negotiate with them; however, ultimately they bear the responsibility for being productive members of a development team. This is true regardless of whether you directly supervise them, share the same level of supervision, or are in a lesser position of authority. However, to be effective you can change yourself, how you deal with people, and how you react to people. First and foremost, a software architect should lead by example and demonstrate the qualities he expects others in the team to share. This includes acknowledging that you respect that people are trying to accomplish the same goals as you are, even if their methods are different. It may take time to listen effectively to gain an understanding of 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 the software architect with varying degrees of authority in working with software developers. When you have greater authority as an architect, you can be even more effective by making the decisions which no one else on the development team is empowered to make.