Who owns the decisions between departments?
Enterprise change depends on people who answer to different leaders. Effective architecture leadership combines earned trust with clear decision rights.
Some of the most important decisions in an organisation sit between departments. One team owns the data, another depends on it, and a third controls the system through which it moves. When a change affects all three, identifying who can authorise the work is only part of the problem. Someone also has to bring the consequences into one conversation.
I encountered this while leading work that crossed operational and systems boundaries. Progress depended on teams that did not all report to me. Their managers were balancing local priorities and constraints, and a reasonable improvement could still be treated as optional when delivery pressure increased.
My enterprise architecture leadership studies helped me put language around that experience. Enterprise architecture leadership involves helping people make coherent decisions across the business, information, and technology on which it depends. A title can support that work, but adoption also requires credibility with the people who must act.
Understand what each team is protecting
When I began a programme management role supporting a distribution centre, I was initially perceived as corporate oversight. That made it harder to gain support. A process change could be interpreted as interference before people had seen how it would help the operation.
I had to work on the relationship as well as the process: clarify the intended outcomes, understand the trade-offs, build support through early improvements, and establish a dependable rhythm for follow-up. Visible leadership backing also helped clarify the mandate. Neither the mandate nor the relationships could do the whole job alone.
That experience influences how I approach resistance. A team may be protecting a delivery commitment, a customer obligation, a control, or simply the only process it currently trusts. Understanding that concern gives an enterprise leader something concrete to address. Calling it resistance without investigating it can close the conversation too early.
Turn alignment into a decision
A meeting can end with broad agreement while leaving the practical conflict unresolved. Consider an illustrative disagreement about a shared data definition. Operations needs a timely status, finance needs a defensible record, and technology needs rules the system can apply. Asking everyone to collaborate more does not establish which definition governs which decision.
I would make the choice explicit: describe the competing definitions, show the consequences of each, identify the decision owner, and agree where an exception is justified. Record the reasoning so the next team can understand the decision without reconstructing the entire debate.
This is where an architecture view becomes useful. A focused view of the information, affected processes, and dependencies can help leaders see a consequence that their individual reports leave out. The amount of modelling should follow the needs of the decision.
Give influence a structure that lasts
Relationships help people commit, but a recurring enterprise decision needs a repeatable mechanism. Who can decide? Who must be consulted? When does an unresolved disagreement escalate? How will the decision be reviewed if the original assumptions change?
I would start with one recurring issue that crosses functions and agree a short decision brief with the leaders involved. It should identify the outcome, options, dependencies, owner, and next review point. The useful test is whether the brief helps someone act and prevents the same unresolved question from returning unchanged.
Architecture leaders should be able to show how their work improves these decisions. Relevant signs might include less time waiting for an owner, fewer repeated disputes, or better adoption of an agreed approach. The measure has to fit the problem being addressed.
The enterprise perspective becomes valuable when people can use it to make a choice they could not settle from within their own department. That is the leadership contribution I want architecture to make.
Developed from my EA 878 paper, Influence Without Authority as the Defining Skill of Enterprise Architecture Leadership, and its practitioner reflection. The approach below expresses my interpretation and recommendations.