Psychology in IT manifests in everything. Every person has their own base tendencies to dominate. Remember that famous experiment where a group of people was divided into prisoners and guards? Or India with its castes? Well, IT is just like India.
Too often, software architects dwell in ivory towers, sending down specifications to developers and imposing technologies and directions on them. This often leads to conflicts, which are quickly followed by a “popular uprising.” As a result, a software product emerges that has nothing to do with the original requirements. Every software architect should be able to explain the goals and objectives of the software project to their colleagues. The keys to effective communication are clarity and leadership.
Clarity characterizes the communication process. No one in your group will become read a 100-page document justifying your architectural decisions. The ability to express your thoughts clearly and concisely is vital for the success of any software project. From the very beginning of a project, stick to simple explanations and under no circumstances start writing long descriptions in Word. Use tools like Visio to create simple diagrams that explain your ideas. Diagrams should be simple because they will almost certainly be changed frequently.
Another effective means of disseminating information is informal meetings. The best way to convey your idea to the project participants is to gather a group of developers (or other architects) in one room and illustrate your ideas on a board. Be sure to bring a digital camera with you (nothing is more annoying than being asked to vacate the conference room right after you’ve finished drawing). After the meeting, take a photo, duplicate it, and distribute it among the other participants via the wiki.
Put off creating lengthy documents and focus on conveying your ideas to your colleagues first, and only then can you think about a more detailed presentation of your architectural solutions. Most software architects don’t realize that they also need to be leaders. To work in a healthy and productive atmosphere, you as a leader must earn the respect of your colleagues. Keeping developers in the dark about the big picture and the reasons behind specific decisions is a sure path to disaster. On the contrary, by bringing developers on board, you create a collaborative environment where the correctness of your architectural decisions is tested. In turn, involving developers in the architecture creation process ensures their commitment and engagement.
Act together with the developers, not against them. Consider that clarity and leadership are important for interacting with all team members (not only with developers but also with the testing group, business analysts, and project managers). Clarity in information transfer and effective demonstration of leadership improve the quality of communication, fostering a strong and healthy work environment.
If “communication is king,” then clarity and leadership are its loyal servants.