You are the first architect at a 120-engineer company with no architecture function. What do you do in the first ninety days?

Do not start with governance

A review board in month one, from someone with no credibility and no context, gets routed around and defines the role permanently as an obstacle.

Weeks 1–4: understand, and be useful while doing it

Talk to every team. Ask three questions: what slows you down, what are you worried about, and what would you change if you could. Patterns emerge quickly and they are your agenda.

In parallel, build the two artifacts nobody has: a system inventory with ownership and an integration map. Both are genuinely useful to everyone, and building them is how you learn the estate.

Weeks 5–8: fix one thing that hurts

Pick a problem that is real, visible and bounded — the deployment that always breaks, the integration everyone fears, the environment queue. Fix it with the team rather than for them.

This is the credibility that makes everything afterwards possible, and skipping it is the most common way a first architecture role fails.

Weeks 9–12: propose, narrowly

Now write things down, and keep the scope small:

• Decision records, starting with three retrospective ones for choices currently causing confusion.
• A first technology radar, built in a working session with senior engineers rather than published at them.
• Review triggers — what needs a conversation and, importantly, what does not.

The measure to propose for yourself

Not artifacts produced. Time from question to answer, decisions made per week, and whether teams come to you before deciding rather than after.

The thing to say out loud early

That the function exists to make good decisions easy, not to prevent bad ones. It sets the expectation you want to be held to, and it is the version of the role that survives.