You are the first architect at a 200-engineer company with no architecture function. What do you do in the first three months?

Understand before changing anything

The fastest way to become irrelevant is to arrive with recommendations. Nobody has any reason yet to believe them.

Listen widely. Engineers, team leads, product managers, operations, security, and — importantly — the business. Ask what slows them down, what they are afraid of, and what has been tried before and failed. The last question is the most useful and the least asked.

Look at evidence, not documentation. Version history for change coupling; incident records for what actually breaks; delivery metrics — lead time, deployment frequency, change failure rate — for where the constraint is; and network flow logs or service catalogues for the real dependency graph, which will differ from any diagram.

Acquire commercial literacy. How the company makes money, what the executive team is measured on, what the regulatory environment demands. This determines which technical risks matter and supplies the units in which anything must be argued.

Find the constraint

Flow efficiency in most organisations is 5–15%: work spends most of its life waiting. Adding architecture to a system constrained by approval queues or environment contention achieves nothing.

Find what is actually binding — it is often not engineering capability — and be prepared for the answer to be organisational rather than technical.

Earn credibility by removing an obstacle

Fix something teams are visibly blocked on, early, personally. An architect who removes a real obstacle is consulted on the next decision; one who only reviews is routed around.

This is not a detour from the strategic work. It is the precondition for it, because influence without authority rests on credibility and credibility is earned by usefulness.

Introduce the lightest possible structure

Resist building a governance function. Three things, in order:

Decision records in the repository — context, options rejected, consequences. Cheap, immediately useful, and they start building the institutional memory whose absence is causing repeated debates.

Published decision rights, telling teams what they may simply decide. In most organisations this is the single largest governance improvement available, and it costs a page.

Automated policy in CI for the small number of things that genuinely must hold — security configuration, dependency direction, API compatibility. Objective, immediate, and it replaces the review board nobody has asked for yet.

Notably absent: a standards document, a review board, and a target-state architecture. All three would be premature and all three would confirm the fear that an architect is overhead.

Then write down where things are going

Once you understand the constraint and have some credibility, a short direction document: the two or three architectural properties that matter for this business, the current gaps with evidence, and the sequence.

Framed as outcomes with horizons — "deployment lead time under two hours", now/next/later — rather than a Gantt chart of technical projects, which is obsolete in a quarter and indefensible when priorities change.

Set the measurement baseline immediately

Capture delivery metrics, incident rates and cost per unit of business value in the first weeks. It costs a day and without it nothing you do afterwards can be demonstrated — which is how architecture functions become the first cut in a downturn.

What a strong answer adds

Naming the trap: at 200 engineers the failure mode is becoming a bottleneck, not being ignored. The role is to enable good decisions at scale, not to make them all — which means the measure of success is whether decisions get better when you are not in the room.