Different groups within an IT department will have different agendas and levels of understanding. The Architecture team is sometimes seen as being too hypothetical, while the Delivery team may be seen as being too focused on delivery. This drives a different approach to solving the same problem. The Architecture team may envisage an approach that’s too complicated, while the Delivery team may want to implement an approach that’s overly simplified, but gets the job done quicker. Somewhere in the middle, we need to find the common ground, and maintain the “workable” bigger picture.
So, how do we collaborate given these sometimes disparate ideologies? How does the Architecture team educate the members of the Delivery team on the bigger picture approach and the reasons for it. At the same time, how does the Delivery team communicate with the Architecture team members to share with them their pain points and pressures – driving the direction of the bigger picture to something that this easier to accomplish, or at least evolutionary?
The crux of the matter, I believe is grounding or frame-of-reference. We all have history, ideas, notions, experiences; and these help us interpret the message we receive. As groups, we have different responsibilities and therefore carry different messages; our way of speaking and the vocabulary used is based on those responsibilities and frames-of-reference. In other words, what we are trying to communicate across groups and disciplines may not be received in the way it was intended to be delivered because our frame-of-references are different!
One final view to consider is that of the people. In order for a message to be received and understood by the collective, it is important to ensure the individual understands. And this could be the biggest blocker in proper collaboration. Consider an individual who is the master of what they have been doing for a while; every one listens to them and asks their advice because they are the gurus. This elevates their position of seniority in the team (perhaps virtually) and the perception within the team is that if they (the guru) agrees, then it must be so. This individual could be in the Architecture or the Delivery team. Now, consider the scenario where this individual is being challenged on their specific approach and told they need to re-skill in order to allow the organisation to adopt a new methodology. It will be very hard for this individual to let go of their “guru” status and become a “learner”. These individuals will naturally challenge any change to protect their status and often discourage or confuse the other team members.
Albeit from a delivery perspective, I found this article very interesting: https://medium.freecodecamp.org/we-fired-our-top-talent-best-decision-we-ever-made-4c0a99728fdePhoto by rawpixel.com from Pexels