The enterprise architect job description is not the mandate
There is a specific failure mode that runs through the first three months of many enterprise architect engagements. The architect produces technically excellent work. The reception from stakeholders is warm and professional. Nothing moves. The work is good. The impact is invisible. And from the inside, the whole situation looks like a communication problem or a stakeholder alignment issue rather than what it actually is: a fundamental misread of why the architect was hired in the first place.
This article expands on my video about the Mandate Origin Diagnostic, a four-bucket framework I developed from direct experience of getting this wrong. The video walks through two specific engagements where I misread the mandate and the cost that followed. Here, I want to go deeper into the diagnostic structure itself and give you the practical application steps that make it usable in Week 1 of any new role.
If you have just accepted a new enterprise architecture position, or if you are currently sitting in one and something feels slightly off about how your contributions are landing, this is written for you. It is also relevant if you manage architects and want to understand why well-qualified people sometimes produce work that does not connect with the organisation's actual needs.
Why enterprise architect roles are defined by pain, not aspiration
Enterprise architect job descriptions are written to recruit, not to describe. That distinction matters more than most hiring processes acknowledge. The language that attracts strong candidates, words like "shape architectural direction," "bring fresh perspective," and "drive transformation," tends to cluster around aspiration. The language that accurately describes the operational problem the organisation needs solved tends to be more mundane: "absorb the review backlog," "fill a specific technical gap," "tell us what we have stopped noticing."
Organisations are not being dishonest when they write aspirational descriptions. They are responding to a real incentive: aspirational language recruits more effectively than operational language. A description that reads "we need someone to clear the architectural change backlog our current team cannot absorb" will attract a different candidate pool than one that reads "bring strategic architectural perspective to a function at an inflection point." Both might describe the same role. Only one of them fills the position quickly.
The consequence for architects is that the gap between the description and the actual mandate is structural, not accidental. It is built into the way organisations write and publish these roles. And because architects are trained to read documentation carefully and take written framing seriously, the gap tends to catch exactly the people best qualified to fill the role.
In my experience, the cost of misreading the mandate is not a single catastrophic failure. It is a slow accumulation of misdirected effort. Work produced against the wrong mandate is not rejected. It is received politely, noted, and quietly set aside. The architect continues producing. The organisation continues nodding. Nothing connects. By the time the pattern becomes visible, three months of credibility-building time have been spent on the wrong target.
The Mandate Origin Diagnostic exists to close that gap before it opens. It does not replace the formal onboarding process. It runs alongside it, asking two questions the formal process almost never asks, in the first week when the answers are still accessible and the stakes of a wrong read are still recoverable.
The Mandate Origin Diagnostic: four buckets and two questions
The four mandate buckets
Every enterprise architect role, regardless of how it is described, fits into one of four mandate buckets. Understanding the buckets is what gives the diagnostic questions their meaning.
The first bucket is capacity. The organisation has more architectural work than the existing team can absorb. The architect is hired to carry load: review changes, clear backlogs, and free senior attention for higher-order problems. The success metric is throughput. The political position is relatively safe because the architect is additive. Nobody loses influence or status when the capacity hire succeeds.
The second bucket is expertise. The organisation is facing a specific technical challenge it does not have the internal knowledge to navigate. The architect is hired because they have solved this class of problem before. The success metric is the quality of the solution to that specific problem. The political position is also relatively safe, provided the architect stays inside the expertise boundary. The risk appears when the architect begins offering opinions beyond the domain they were brought in to address. In my experience, expertise hires who drift into broader advisory territory before establishing the specific credential they were hired for tend to generate quiet resistance from people who were not expecting a generalist.
The third bucket is perspective. The organisation believes its architecture function has become too internally focused. The architect is hired to notice what the existing team has stopped seeing. The success metric is insight quality and its influence on decisions. The political position is more complex than the first two buckets because the perspective hire is implicitly being asked to tell people that some of what they have been doing could be better. That message lands differently depending on how the architect carries it and how much relational credibility they have accumulated before delivering it.
The fourth bucket is change-delivery. The organisation has a transformation it needs to execute and wants an architect who will drive it. The success metric is change adoption. The political position is the highest-risk of the four. The architect hired to drive change is also the architect who, when change becomes unpopular, becomes the casualty. Change-delivery mandates are real and necessary. They are also the ones where misreading the actual organisational appetite for change can end an engagement faster than any technical mistake.
Why descriptions use the wrong bucket's language
Job descriptions frequently use the language of one bucket to recruit for another. Perspective language sounds more senior than capacity language. Change-delivery language sounds more strategic than expertise language. Organisations write descriptions in the language that recruits best, not the language that describes most accurately.
In my experience, most architects can identify which bucket sounds most like their job description within five minutes of reading it. The diagnostic problem is not identification. It is verification. The bucket the description points to and the bucket the organisation actually needs are frequently different. The two diagnostic questions are designed to surface that difference before it becomes expensive.
The first question: what the manager needed to stop doing
Within Week 1, ask the hiring manager directly: "What was the thing in your week that you most wanted to stop doing yourself when you decided to hire for this role?"
This question works because it bypasses the aspirational framing of the job description and asks for a specific operational pain. If the answer is concrete and operational, "I have been personally reviewing every architectural change for two years and the volume has become unsustainable," the mandate is almost certainly capacity, regardless of the language used in the description. If the answer is strategic and forward-looking, "We need someone who can see where our practice needs to go that we cannot see from the inside," the mandate is more likely perspective or expertise.
I learned this question from a specific failure. In one engagement, I spent eight weeks producing structured observations about the architecture function because the job description used perspective language throughout. The hiring manager's responses in our one-to-ones were warm, but they consistently steered toward the backlog within minutes. How many changes had I reviewed. Which ones were stuck in governance. Whether I had capacity for a particular stream of review work. I kept interpreting those questions as administrative. The real work, I told myself, was the strategic observations.
After eight weeks of that pattern, I asked the manager what they had most wanted to stop doing themselves. The answer was immediate: they had been personally reviewing every architectural change in their unit for two years and were exhausted by it. The job description had used perspective language because it recruited better. The actual mandate was capacity. I had been producing a perspective deliverable for a manager who needed their calendar freed.
I shifted focus, absorbed the review work, and freed the manager's time. Within a month, the dynamic changed entirely. And here is the part that still surprises me: the perspective observations I had been producing started landing. Not because they had become better observations, but because they were now coming from someone who was visibly carrying load. Credibility of insight changes when the person delivering it is not just observing.
The second question: what the team will actually receive
The manager question surfaces the operational pain the hire is meant to address. It tells you the manager's mandate. It cannot reach the second layer: what the team can actually receive, independent of what the manager intended to hire.
Ask three internal peers separately, in different conversations: "What word would you have used to describe the previous person in this seat?"
One word forces a felt response rather than a diplomatic summary. Three separate answers that converge are not coincidence. They are the team's honest signal about what the previous framing of the role produced and what they are prepared to receive from the next person in it.
In one engagement, the formal job description used change-delivery language throughout. I had learned enough by then to verify before committing publicly to that framing. I asked three peers the word question across three separate conversations. All three answers converged on the same word. The word was not "change agent" or "transformation lead." It was "burden."
That word told me more than any briefing document had. The team had already been through a change-delivery framing. It had not gone well. They had absorbed the disruption, outlasted the person driving it, and they were not interested in repeating the experience. The manager's mandate was real. The transformation was genuinely needed. But the team would resist another change-delivery framing actively, and that resistance would be invisible until it was too late to recover.
I reframed my visible work for the first three months: expertise and perspective, not change-delivery. I carried things. I made myself useful in ways the team could see and appreciate. I accumulated what I think of as relational currency, the kind that only comes from being present and helpful over time without an agenda attached. Only after the team was treating me as collaborative rather than imposed did I begin making change-delivery moves. The resistance that had ended the previous engagement did not materialise. Not because the changes were smaller, but because the person proposing them was no longer a stranger.
Reading the two answers together
If the manager answer and the peer answer point to the same bucket, the mandate is clear. If they point to different buckets, the situation is more complex, and in my experience the peer signal is the more reliable guide to how visible work should be framed in the first three months. Managers position. Peers reveal. The manager describes the mandate they intended to hire. The peers describe the mandate the work will actually be received under.
These are not interview questions in the traditional sense. You would not ask them in the hiring conversation. They are the diagnostic that starts where the formal process stops, designed for the first week when the people around you are still willing to answer honestly and before the political dynamics of the role have fully crystallised.
Applying the diagnostic in practice
The Mandate Origin Diagnostic is not a guaranteed decode. It is a starting frame that significantly narrows the range of costly misreads in the first three months. Applying it well requires attention to a few practical considerations.
On the manager question: ask it in a one-to-one conversation, not in a group setting. The question works because it invites a candid operational answer, and candour about personal workload is easier in a private conversation. If the manager deflects toward aspirational language in their answer, that deflection is itself diagnostic. It suggests either that the operational pain is not the primary driver of the hire, or that the manager is not yet comfortable being specific with you. In either case, you have a signal worth tracking.
On the peer question: space the three conversations across the first week rather than conducting them on the same day. Answers given independently over time are more reliable than answers given in quick succession, where earlier conversations can influence later ones. If the three answers diverge rather than converge, that divergence is also informative. It suggests the team does not have a shared experience of the previous role framing, which may mean the role is genuinely new rather than a replacement, and the change-delivery risk profile is lower than it would be in a replacement context.
The most common pitfall is treating the diagnostic as a one-time exercise rather than a continuous read. Mandates shift. A capacity hire who successfully clears the backlog may find the manager's needs evolving toward perspective as the operational pressure eases. A perspective hire who accumulates enough relational credibility may be invited into change-delivery territory that was not accessible at the start. Revisiting the diagnostic questions informally every quarter, in the natural flow of one-to-one conversations, keeps the read current.
The success metric for the diagnostic is simple: by the end of Week 1, you should be able to name the bucket you are actually in, with enough confidence to frame your visible work accordingly. If you cannot name it, the diagnostic questions have not yet produced a clear signal, and the right response is to ask them again rather than default to the job description's framing.
Mandate reading as a compounding career skill
The technical skills that qualify someone for an enterprise architect role are table stakes. Every strong candidate in the hiring process has them. What separates architects who consistently move things from architects who consistently produce excellent work that nobody quite acts on is the ability to locate the real mandate quickly and accurately, and to frame visible work against it from the start.
In my experience, this skill compounds over a career in a way that technical skills alone do not. Each engagement where you read the mandate accurately early builds a pattern of recognition that makes the next read faster. Each engagement where you misread it and recover teaches you something about the specific signals you missed. The Mandate Origin Diagnostic is a structure for accelerating that learning rather than waiting for enough engagements to accumulate the pattern naturally.
Your mileage may vary on which bucket you land in and on how cleanly the two questions separate the signal from the positioning. Some managers are unusually self-aware and will name the operational pain directly without prompting. Some peer groups are more guarded and the word question will take a second attempt to land. The diagnostic is a frame, not a formula.
Before your next one-to-one with your current or hiring manager, take fifteen minutes and write down your honest answer to this question: "What specific operational pain was I hired to absorb?" Then, in the next peer conversation you have, ask the word question. One peer, one word, one honest answer. You will have a clearer read of your actual mandate than most architects get in their first three months. If you are evaluating a new opportunity, hold the job description loosely. Read it for the language it uses, not the mandate it describes. The mandate is in the people. These two questions will find it.
