The First 90 Days as a Software Architect

The first three months in a new architect role set the pattern for everything that follows. Move too fast and you make decisions without enough context, creating resentment and technical debt in one stroke. Move too slowly and you are invisible — seen as a passenger rather than a contributor.

This post is a practical framework for navigating the first 90 days. There is also a free 90-day plan template on this site that you can adapt for your situation.

The core principle: earn the right to decide

The most common mistake new architects make is arriving with answers. You have seen this pattern before. You know what good looks like. You can already see several things that need to change. The temptation is to propose solutions immediately — it feels like adding value.

It is almost always the wrong move. Solutions proposed before you understand the context are solutions without buy-in, and they fail for organisational reasons even when they are technically correct. The first 90 days are about earning the right to make consequential decisions by demonstrating that you understand the system, the team, and the constraints well enough to be trusted.

Days 1–30: listen and map

The first month is almost entirely input. Your goals are to understand the system landscape, identify the key people, and build enough context to ask useful questions.

Map the systems. Draw a high-level diagram of every service, database, and integration you can find. Do not worry about getting it perfect — the act of drawing it will surface the questions you need to ask. Validate the diagram with engineering leads.

Identify the stakeholders. Who makes decisions? Who has informal influence? Who are the critical product, engineering, and business contacts you will be working with regularly? Build these relationships before you need them.

Find the history. Understand what decisions were made before you arrived and why. Ask about the technical decisions the team is proudest of and the ones they regret most. The answers will tell you a great deal about the culture and constraints you are working in.

Avoid making commitments. You will be asked for your opinion constantly. It is fine to share observations and ask questions. It is too early to commit to positions or propose significant changes.

Days 31–60: diagnose and prioritise

By the end of the first month you should have enough context to start identifying the real problems. The second month is about prioritisation — distinguishing the issues that genuinely constrain the system from the ones that are annoying but manageable.

Build your risk register. What are the three to five biggest architectural risks? Fragile integrations, single points of failure, areas of high technical debt, unmet quality requirements? Write them down with your current understanding of severity and likelihood.

Identify the quick wins. Are there things that are causing real pain that could be significantly improved with moderate effort? These are worth prioritising — not because they are strategically important, but because delivering visible improvements early builds credibility.

Draft your 90-day goals. By now you should be able to articulate what you want to achieve in your first three months. Share this with your manager and get alignment. It should be specific enough to be measurable and conservative enough to be achievable.

Days 61–90: propose and establish

The final month is where you start to deliver visible architectural output.

Deliver your first proposal. Write an Architecture Decision Record or a design document on something real. It does not have to be the most important problem — it should be something where you have enough context to write something useful, and where writing it demonstrates your understanding of the system and the constraints.

Establish a review cadence. If there is no architecture review process, propose one. Start small — even a monthly session where current architectural decisions are reviewed by the team — rather than nothing.

Make your presence visible. By the end of 90 days, the team should have a clear sense of what you are working on, what you stand for technically, and how to engage with you. This does not require grand gestures — it requires consistent, high-quality engagement with the work.

What to watch out for

The most common failure modes in the first 90 days: trying to redesign the system before understanding it; spending all your time on technical analysis and ignoring the organisational dynamics; being seen as a critic rather than a collaborator; and failing to deliver anything concrete in the first quarter.

An architect who has been in the role for 90 days and has not yet produced any visible output has a credibility problem that is hard to recover from.