A new business architect's hardest problem is not modeling. It is credibility — earning the right to be in the room before anyone has seen a single map. The first 90 days are where that is won or quietly lost.

Business architecture has a credibility problem that has nothing to do with its merits. The discipline produces its value slowly and invisibly, while the organization rewards speed and visibility. A new architect who disappears for a quarter to build a comprehensive capability model emerges to find the strategy has moved, the sponsor has been reorganized, and the model answers a question no one is asking anymore. The first 90 days are not for building the architecture. They are for earning the right to.

Days 1-30: listen, and map the people first

The most useful thing to map in month one is not capabilities — it is stakeholders. Who actually makes the decisions you want to influence? Who controls the budget? Who has been burned by a previous architecture effort and is quietly waiting for this one to fail? Spend the first thirty days in conversations, not in modeling tools. Ask each person what decision they are struggling with and what would make their next planning cycle less painful. You are doing two things at once: learning where the real pain is, and signaling that this architecture function starts from their problems rather than its own frameworks.

Resist the strong urge to demonstrate expertise by producing a deliverable in week two. The fastest way to be filed under "more overhead" is to arrive with a methodology before you have shown you understand the business. Listening is not a delay before the work; in this role it is the work.

Days 31-60: find one real decision and attach to it

Architecture earns trust by helping with a decision someone already cares about, not by announcing a program. By month two you should have heard, in those conversations, a live decision the organization is wrestling with — a funding trade-off, a build-versus-buy, a reorganization, a question about whether the strategy is actually resourced. Pick one. Deliberately scope it small enough to deliver inside the 90 days. Then bring exactly enough architecture to help: not the enterprise capability model, but the slice of it that makes this one decision clearer.

This is the inversion that separates architects who land from architects who stall. The comprehensive map is the output you eventually want; it is the worst possible thing to lead with. Lead with a decision improved. The map can grow afterward, pulled into existence by demand, instead of pushed onto an organization that did not ask for it.

Days 61-90: deliver something small and real

By the end of the quarter, the goal is a single, concrete artifact that helped a real decision and that a senior person would describe, unprompted, as useful. A focused capability view that exposed an unfunded but critical area. A cross-map that showed two initiatives building the same thing. A value-stream view that located where a customer outcome actually stalls. One piece of work, narrow and genuinely used, is worth more than a complete model nobody asked for — because it converts a skeptic into a sponsor, and sponsors are what let the architecture practice exist at all.

A worked example: the slice that bought a year

A newly hired enterprise architect at a manufacturer faced the usual choice: spend the first quarter building the comprehensive capability model everyone vaguely expected, or find a live decision and help with it. In the listening tour she heard the same tension repeatedly — two expensive programmes, one in operations and one in IT, both quietly building a "supplier management" capability, neither aware of the other. She did not model the enterprise. She mapped exactly that one corner: the capability, the two initiatives, the budgets, and the overlap. One page. She brought it to the steering committee not as architecture but as a question — "are we sure we mean to fund this twice?"

The page paid for her role for a year. It did not prove the value of business architecture in the abstract; it saved a specific, visible sum on a decision the committee already cared about, and it did so in week ten rather than month ten. The comprehensive model came later — pulled into existence by people who now wanted more of what that one page had done, instead of pushed onto people who had not asked for it.

Managing up, not just mapping

The first 90 days are as much about relationships as artifacts, and the relationship that matters most is with whoever sponsors the function. A new architect often assumes the work will speak for itself; it will not, because architecture's value is diffuse and slow while the demands competing for a sponsor's attention are sharp and fast. Spend deliberate time translating what you do into the sponsor's terms — decisions improved, money saved, risks surfaced — and never into the vocabulary of frameworks and meta-models, which signals overhead to everyone who does not already believe. The architect who can say "here is the duplicate funding I found" keeps a sponsor; the one who can only say "here is our level-three capability taxonomy" loses one.

It helps to set expectations explicitly and early. Tell your sponsor what you will deliver by day 90 and, just as important, what you will not — no enterprise-wide model, no tooling rollout, no standards mandate, but one real decision made measurably better. Naming the small scope up front converts a potential disappointment ("is that all?") into a kept promise ("you said one decision, and you delivered it"). In a role whose credibility is its scarcest resource, a kept small promise compounds faster than an impressive large one that slips.

A simple cadence holds all of this together. Use the first thirty days to listen and map stakeholders, the next thirty to pick a live decision and scope it ruthlessly, and the last thirty to deliver the one artifact that improves it — then, and only then, propose what the function should build next, to a sponsor who has now seen it work. The shape is deliberately the inverse of the instinct to prove competence through volume. You are not trying to demonstrate how much architecture you can produce; you are trying to earn the standing that lets you produce it at all.

What to consciously avoid

Three failure modes account for most stalled starts. The big-bang model: months of comprehensive modeling before any value is shown, finished just in time to be irrelevant. The tooling detour: time spent selecting and configuring a platform before there is any content or constituency to put in it. And the standards crusade: arriving to enforce a framework and naming conventions on people who do not yet believe the function is worth listening to. Each feels like progress to the architect and like overhead to everyone else. The throughline of a good first 90 days is the opposite instinct — earn belief with a small, real result, then let the rigor follow the credibility rather than precede it.

None of this means the comprehensive work never happens. It means the order is reversed from what most architects' training suggests. Credibility first, decision next, artifact after, framework last. Get that sequence right in the first quarter and the rest of the role has room to exist. Get it wrong and you spend the next year being the person with the maps no one opens.

Most enterprise architects don’t have decision authority. They don’t own the budget. They don’t hire the engineers. They don’t set the roadmap. This is structurally true in most enterprises, and complaining about it is a waste of time.

What architects have, when they’re effective, is influence. Influence is what you wield when you can’t command. It’s built slowly, through credibility, helpfulness, and good calls under pressure. It can be spent or saved. It compounds with use.

The architects who succeed are not the ones who clamor for more authority. They’re the ones who build influence so substantial that authority becomes redundant. When the VP of Engineering routinely asks your opinion before deciding, you have authority — it just doesn’t appear on the org chart.

Stop wishing for the title. Build the influence. The title, if you want it, follows. If you don’t want it, you may find you don’t need it.

A stakeholder map is a structured view of the people and groups who affect, or are affected by, a piece of work — capturing each one's interest, influence, and current stance. For a business architect it is often the most valuable map to draw first, before any capability modeling.

It typically positions stakeholders by two factors: how much influence they hold over the decisions you care about, and how supportive they currently are. That placement turns a vague sense of office politics into an explicit plan — who to keep close, who to convert, who simply to keep informed.

It differs from an org chart, which shows formal reporting lines. A stakeholder map shows real influence and disposition, which often cut across the hierarchy — the quiet finance director whose buy-in unlocks the budget rarely sits at the top of the chart. Architects use it to spend their scarce credibility where it will compound.

A LinkedIn post, humble and bright,
Said, “I’m thrilled to announce my new flight!”
Same role, slightly tweaked,
The algorithm peaked —
And recruiters all messaged that night.