Selling to an enterprise architect

An enterprise architect rarely signs the contract. But they can kill one in a single meeting.

They're the technical lead on a lot of large services decisions, and they decide whether your firm's approach fits the company's direction. Win them early and the CIO hears your name from someone they trust. Skip them and you'll meet them at the architecture review, where they'll find every gap.

What they own

The enterprise architect owns the target state. Where the company's systems should be in three years, which platforms are standard, which are being retired, and how everything connects.

They run the architecture review board, or sit on it. They write the standards every project has to meet. And they get pulled into every big decision about integration, data, cloud and security.

In plain terms, they own the map. Every project you'd sell is a change to that map.

What they're measured on

Fewer platforms, not more. Less duplication. Lower integration cost. Projects that land without creating new technical debt. Reuse of what's already been built.

They're rarely measured on speed, and they're often the person asked to slow things down. That makes them look like a blocker to sellers. They're not. They're the person who has to live with the consequences long after the vendor has left.

What they ignore

Pitches. Logo slides. Anything that reads like it was written for a business buyer and forwarded to them.

They ignore vague claims about best practices and accelerators. They've seen enough accelerators to know most are templates with a new name.

And they ignore anyone who doesn't understand their stack. If your first note recommends a platform they retired two years ago, you're done.

Which signals matter

Tech stack signals matter most. Job posts that name a platform, a 10-K that mentions a migration or a legacy system, a public tender that lists technical requirements. These tell you what the architect is building toward and what they're trying to retire. The post on the tech stack in job posts shows how to read them.

New leaders matter too. A new CIO or CTO often brings a new target state, and the architect has to redraw the map in a hurry.

And watch what the architect writes. Plenty of them post about integration patterns, platform choices or lessons from a failed migration. That's a topic signal, and it tells you exactly what's on their mind.

The note that works

Write to the architect like a peer. Name the technical fact, state the tradeoff you think they're facing, and let them correct you.

Say a health insurer is posting jobs for engineers with experience on a new cloud data platform, and its last 10-K named a legacy claims system as a risk.

Your recent data engineering posts name a new cloud platform, and the 10-K still lists the claims system as a legacy risk. My guess is the hard design question is how much claims history you move versus leave in place and integrate. Is that the tradeoff on your desk, or has it already been settled?

No pitch. A specific fact, a real architectural question, and an exit they can answer in a sentence.

How to work them in the committee

The architect isn't your economic buyer. The CIO or CTO is. But the architect is often the person the economic buyer calls when your name comes up.

So write to the CIO about the business problem and the architect about the design problem. Same account, same week, different hypothesis. If the architect replies with a correction, carry it into your next note to the CIO. That shows you listened to their own team, and selling to the committee explains why that matters.

Once you're in, show your thinking on paper. A short architecture sketch, the questions you'd answer first, an honest read on what you'd leave alone. Architects trust firms that know what not to touch.