Your First 90 Days as a Software Architect

---

Most new architects arrive with something to prove. That instinct is the first thing to override. Organizations that hire architects have usually been running without one — which means they have accumulated local decisions, undocumented constraints, and political landmines that will not appear in the onboarding docs. The architect who moves fast in the first 30 days is almost always moving fast in the wrong direction.

The 90-Day Timeline

Days 0–30: Map the System and the Politics, Change Nothing

The first thirty days have one deliverable: a map. Not a diagram — a written artifact that captures the state of the system as it actually is, the decisions that produced its current shape, and the political constraints that govern what can change and when.

What to build:

Service inventory. Every service or major component, its owner, its primary dependencies, and its known failure modes. You are not auditing — you are orienting. If you discover a service with no clear owner in week one, write it down and move on.

Decision archaeology. Find three to five significant architectural decisions made in the last two years. Read the code, read the commit history, talk to the people who were in the room. For each one: what was the problem, what options were live, what got chosen, what is the current status of the assumption that drove the choice. You are not evaluating whether the decisions were good — you are learning the decision culture of the organization.

Political map. Which teams have strong opinions about cross-team technical decisions? Who has informal veto power over architectural changes without a formal title? Who are the implementation skeptics — engineers who push back on changes not from principle but from past experience with failed migrations? These people are not obstacles; they are signal. They have watched previous architects make expensive mistakes.

What not to do in the first 30 days: propose solutions, schedule architecture workshops, write a vision document, or announce that you are going to modernize the architecture. All of these commit you to a direction before you have the information to know whether that direction is right.

Days 30–60: Find the Highest-Leverage Problem, Write Your First RFC

At the thirty-day mark, you have enough context to see the actual problems rather than the presenting symptoms. The question is not "what is broken?" — something is always broken. The question is "what problem, if addressed, unlocks the most value for the most teams?"

Criteria for the first RFC:

• It affects at least two teams. A single-team problem is not an architectural problem.
• It is tractable in 90 days. Your first RFC should describe a change that can be shipped, not a roadmap for the next year.
• There is an existing stakeholder who already feels the pain. If you have to convince people the problem exists, pick a different problem.
• It is not a rewrite. The first RFC should demonstrate that you understand the system as it is, not announce that you are replacing it.

Write the RFC with the structure from the decision-making article: context, options, trade-offs, decision, consequences. Include the constraints you learned in the first 30 days explicitly. This signals to the organization that you did the map work — and that your proposal is grounded in actual constraints, not imported patterns.

Circulate to affected teams before it is final. The goal is not approval — it is to find the assumption in your RFC that is wrong before you are committed to it.

Days 60–90: Ship a Visible Win, Establish Review Cadence

"Ship" in the architect's context means getting something adopted and working — not necessarily writing the code yourself. The visible win in days 60–90 is the RFC that moved from proposal to implementation, the cross-team alignment problem that got resolved, the documentation gap that is now filled.

Visible wins matter disproportionately in the first 90 days because the organization is forming a model of what you do and how you operate. A tangible outcome in the first three months establishes the pattern: this architect produces things that move.

In parallel: establish the recurring cadence. A fortnightly architecture review that is 30 minutes long and requires one written proposal per session is more valuable than a monthly two-hour meeting that requires a deck. Lightweight and regular beats comprehensive and sporadic.

The review cadence serves a second purpose: it creates a designated space for cross-team technical decisions. Teams learn that the mechanism exists. They start bringing proposals to it instead of making unilateral decisions and hoping nobody notices.

Anti-Patterns to Avoid in the First 90 Days

The big rewrite. The single most common first-90-days mistake. The system is a mess, the cleanup feels urgent, and the rewrite proposal arrives before the new architect has learned why the mess exists. Messy systems usually have structural reasons for their shape — architectural constraint, team ownership history, compliance requirements. Rewrites proposed before the map is complete are almost always scoped wrong.

The ivory tower and the unreadable diagram. Two failure modes with the same root: output that has no visible connection to what teams are actually building. Architecture documents nobody reads. Review meetings that are pro-forma approval ceremonies. System diagrams that accurately represent reality but carry no narrative — no explanation of why the structure is what it is, what constraints it satisfies, what the evolution path is. A diagram without a legend is a map teams cannot use. The fastest way to become irrelevant as an architect is to make your output optional. Make it useful first.

Copying the last company's architecture. Every system has a context: team size, operational maturity, traffic patterns, org structure, historical constraints. The first 30 days exist specifically to prevent this mistake — to learn the actual constraints before applying the familiar pattern.

For the parallel dynamics in a leadership context — specifically the first-90-days framework for someone entering at a senior level — the post on the first 90 days CTO playbook covers the political and organizational dimensions that apply even when the title is architect rather than CTO.

Key Takeaways

• Days 0–30: map, don't propose. Build the service inventory, the decision archaeology, and the political map before you form an opinion about what should change.
• Days 30–60: pick the right first RFC. Multi-team problem, tractable in 90 days, existing stakeholder who already feels the pain.
• Days 60–90: ship something visible. A tangible outcome in the first 90 days establishes the operating pattern the organization will use to model what architects do.
• The big rewrite is always wrong in the first 90 days. You do not have enough map to scope it correctly.
• Diagrams without narrative are decorations. Architecture artifacts need context, constraints, and evolution path — not just boxes and arrows.
• Next step this week: If you are in the first 30 days, write one paragraph describing the system you inherited — its shape, its decision history, and one undocumented constraint you have already discovered. If you are planning for a future role, ask the hiring team what the three most important architectural decisions of the last two years were and what the current state of the assumptions behind those decisions is.