A Company Is Organized Conflict
Often everything is planned well — the organization and the technology alike — and still nothing moves. Usually the reason is not a bad plan. It is that the people involved have not been understood well enough to want the same thing. Here is how I try to change that.
A company is organized conflict.
I don’t mean that cynically. I mean it structurally. Marketing wants reach and speed. Finance wants cost control and predictability. Legal wants risk kept small. The people function wants the organization to stay healthy and able to keep its staff. Each of these is a legitimate goal, and they routinely pull in opposite directions. That tension is not a malfunction of the company — it is the company. Organizing that conflict productively is a large part of what management, and enterprise architecture, is actually about.
And it gets one layer more complicated, because departments are made of people. On top of the departmental goals sit the individual goals of the people involved: someone wants to prove a point, someone wants a quieter quarter, someone wants the project they championed to succeed. If you only look at the org chart and the official department objectives, you are reading half the map.
The two weak ways out
When goals collide, most organizations reach for one of two moves.
The first is escalation to a decider. Push the conflict up until someone senior enough picks a side. The second is escalation to a committee. Convene the stakeholders, take a vote or a majority, and declare the matter settled.
Both produce a decision. Neither produces movement.
The problem is the same in both cases: the people who were overruled walk away with little or no commitment to the outcome. They comply, at best. They were not convinced; they were outvoted or overridden. And a plan that half the room is quietly unconvinced by is a plan that stalls in a hundred small ways nobody can quite point to. This is why you so often see the frustrating pattern where everything has been planned well — the organization and the technology alike — and still nothing moves.
Understanding enlarges the solution space
There is a better move, and it is slower up front and far faster over the life of the initiative: enlarge the space of possible solutions until there is one that everyone can genuinely stand behind.
You do that by understanding people — really understanding them, past the position they are defending to the need underneath it. Positions conflict. Needs often don’t. Two people arguing over the same narrow option can frequently both be satisfied by a third option neither had seen, once you understand what each of them actually needs it for.
Abraham Lincoln is supposed to have said, “I don’t like this man. I must get to know him better.” That is the whole discipline in one sentence.
Concretely, this is the work:
- Spend time with people, ideally one to one. The real interests rarely surface in a room of twelve.
- Question what was said in order to understand what was meant. People state positions, not needs. The stated demand is a clue, not the answer.
- Look for the need beneath the department goal and beneath the personal goal. Both are real; both have to be in the solution.
- Invest in empathy. The better you understand someone, the less time this whole process takes — understanding is not the soft part of the work, it is the accelerator.
As the overlaps between people’s real needs become visible, the solution space grows. Somewhere in that enlarged space there is usually a superordinate goal — one everyone recognises as worth more than the local fight — and an action that pays into it that each party can carry.
A recipe I keep coming back to
When I am in the middle of one of these situations, I try to hold on to four steps:
- Understand the said, the meant, and the underlying needs of everyone involved.
- Find options in the overlaps that emerge once those needs are on the table.
- Choose one — a common action tied to a shared, superordinate goal.
- Act.
It looks obvious written down. It is not what most organizations do under pressure, where the reflex is to jump straight to step three by vote or by decree and skip the understanding entirely.
Why an architect cares about this at all
You might expect an Enterprise Architect to be preoccupied with capabilities, data flows and target pictures — the boxes and lines. I am. But I have watched beautifully argued architectures die because the people who had to live with them never wanted them, and I have watched modest plans succeed because everyone involved had a real stake in them.
So I have come to treat this as part of the architecture, not separate from it. The structure of a company is not only its processes and its clearly assigned responsibilities. It is also the individuals inside those roles, with their own goals — and designing for the individuals, not just the roles, is very often the difference between a structure that holds and one that quietly falls apart. Understanding people is not a detour from the real work. On this kind of problem, it is the real work.