In a recently published episode of Armchair Architects, the speakers discussed the relationship between software architects and the rest of the organisation. They detail how a successful architect can impact others by switching between going into the trenches and zooming into a tree and then being able to zoom out and estimate if that tree still fits into the forest.
Uli Homann, corporate vice president at Microsoft, states the following:
Sometimes architects are considered Ivory Tower Architects because they're not involved in the real trenches. You don't understand what the pressures are, what the realities are, and you're telling me to use this technology and do it this way without having a detailed understanding of what the implications are.
I think the goal of a higher-level architect is to drive the direction of many efforts. When you are in the trenches, you always look at the tree and don't really look at the forest anymore. So you need this balance between a very detailed understanding but also the ability to zoom back out and say, wait a second, are we still on the right path or are we going left where everybody else is going right?
The only way you can avoid getting into this complexity of people not liking you or believing that you are just talking rather than doing is - "do". You have to be part of the conversation, and the trick is to still be able to go back and forth. You understand the tree, then go back and make sure that the tree still fits into the forest and update the enterprise architecture strategy based on the learning you learned in the trenches.
Homann explains that this disconnect happens when architects say something and that something actually makes sense, but then reality hits, and it doesn't quite make sense anymore. If the feedback loop doesn't happen, the architecture doesn't get updated with real-life feedback and drifts apart from reality. "It's OK to give a direction and strategy, but then go deep with the team that has to live with the decision and learn from their detailed conversation if the stuff you're trying to build actually works."
Eric Charran, chief architect at Microsoft, explains how he believes software architects should be part-time civil servants and part-time community organisers. As a civil servant, the architect's goal is to help the team achieve its goal, including getting its hands dirty. "How can I help?" is a crucial question, as well as "Here are some tools and techniques that would help". As community organisers, architects should take what they learned and spread that knowledge to the rest of the organisation, crediting the teams for that knowledge appropriately. He says, "As an architect, I'm successful when teams who stand on my shoulders do real stuff."
When the host, David Blank-Edelman, senior cloud advocate at Microsoft, asks how to get people to listen to you, Charran replies that people want to do a good job and will listen if they see you can help them. He also comments that people don't make factual decisions. They make emotional decisions and look for facts to back them up. "You have to be willing to invest the time to help them get to a comfort state where they can listen to your points. If they're not willing to listen to your points, you might be 100% right, but that's only 50% of the battle."
Charran states that if architects explain the same thing repeatedly to the same people, they should only use their organisational authority and become the "friendly ball thrower" as a last resort. Homann adds that architects should always strive to support their advice with external evidence and finishes by stating that if architects fail to get to people by themselves, they can also try to reach them via others who can.