30-60-90 day plan for solutions architects

A 30-60-90 day plan for a new solutions architect should spend the first month mapping the systems, the architecture decisions already made and the people who own them; take over design reviews and record decisions in the second month; and by day 90 deliver one approved design that ships or is in build, reviewed against a well-architected framework, plus a short list of architecture risks with owners. The plan does not ask for a new target architecture by day 30: architects who redraw everything before learning why it looks that way lose the teams who build it.

This plan is for an engineering leader, CTO or head of architecture hiring a solutions architect inside a company or a delivery consultancy. Pre-sales architects follow the 30-60-90 day plan for sales engineers. The engineer's ramp is in the 30-60-90 day plan for software engineers.

What makes a solutions architect's first 90 days different?

A solutions architect has influence without much direct authority. Engineers build what they agree with, product managers decide priorities, and security and operations can block a release. The architect's output is decisions that other people carry out, so the first 90 days are about earning the right to make them: knowing the systems well enough to be right, writing decisions down so they can be challenged, and showing one design through to production.

The second difference is that the hard problems are rarely the diagram. They are the non-functional requirements nobody wrote down (availability, data residency, recovery time, cost limits) and the decisions made years ago whose reasons left with the people who made them.

Which frameworks and credentials should a new solutions architect use?

The cloud providers' well-architected frameworks give design reviews a shared checklist, and their certifications are the most common evidence of platform knowledge. Details below are from each provider's own pages as of October 2026.

What does the 30-60-90 day plan look like?

30-60-90 day plan — [Name], Solutions Architect, [team / domain]
Reports to: [head of architecture / CTO / engineering director]
Start date: [date]   Domain: [e.g. payments, data platform, customer apps]
Platforms: [cloud / on-premises / hybrid]   Teams supported: [N]
Current initiative needing a design: [ ]

DAYS 1-30 — Map the systems and the decisions
Goals:
- Draw the current architecture of the domain from code, infrastructure
  and runbooks, then check it with each team
- Read existing architecture decision records (or reconstruct the five
  most important decisions with the people who made them)
- Read the last six months of incident reviews and the top cost items
  on the cloud bill
- Meet product, engineering, security, operations, data and finance
  partners; sit in on design reviews and planning
- Collect non-functional requirements that exist only in people's heads:
  availability, recovery time, data residency, compliance, cost limits
Deliverables by day 30:
- Current-state diagram the teams agree is accurate
- Top three architecture risks with evidence
Check-in: day 30, with the hiring manager

DAYS 31-60 — Take over design review
Goals:
- Run design reviews for the domain using a short checklist built from
  the relevant well-architected framework
- Write decision records for every significant decision from now on:
  context, options, decision, consequences
- Start the design for the current initiative with the delivery team;
  agree non-functional requirements with product and security
Deliverables by day 60:
- Design review checklist adopted by the teams
- Draft design for the initiative, reviewed by security and operations
Check-in: day 60

DAYS 61-90 — Ship one design; set the roadmap
Goals:
- Design approved and in build or released, with the architect
  available to the team during build
- Architecture roadmap for the domain: risks, target state for the next
  12 months, what not to change
- Review cost and reliability of the new design against its targets
Deliverables by day 90:
- One design in production or build, with its decision records
- Roadmap reviewed by engineering and product leaders
Check-in: day 90 — full review

Which numbers should a new solutions architect track?

The standards below are examples only. Architecture is judged partly on outcomes that appear months later, so track both the process measures the architect controls and the outcomes of the designs they approve.

How should the hiring manager use the plan in the final interview?

Give every finalist the same brief: the domain, the platforms, a simplified current diagram and one initiative that needs a design. Score the plan with the rubric in how to evaluate a 30-60-90 day plan in an interview. A strong plan learns the current state and the reasons behind it before proposing a target, and names non-functional requirements and decision records. Follow-up questions:

• "The team built the service on a database you would not have chosen. When do you push to change it, and when do you leave it?"
• "Product wants the feature in six weeks; your design needs ten. What do you offer?"
• "Security rejects your design a week before build. What went wrong in your process?"
• "Walk me through a decision record you wrote that turned out to be wrong."

For hands-on cloud depth in earlier rounds, the cloud engineer screening questions cover identity, networking, migrations and cost.

What should each check-in cover?

A filled example

What does the hiring manager owe the new solutions architect?

• A clear decision scope: which decisions the architect makes, which they recommend, and who breaks ties.
• Access to code repositories, infrastructure accounts (read), incident reviews and the cloud bill.
• A real initiative to design in the first 90 days, not only reviews of other people's work.
• Introductions to the security, operations and finance partners who can block or fund a design.

Common mistakes

• Target state first. A new architecture before understanding the old one reads as criticism of the people who built it.
• Designing without non-functional requirements. Availability, recovery and cost targets decide most of the design.
• Decisions in meetings only. Without records, the same debate returns every quarter.
• Leaving after approval. Designs change during build; the architect needs to be there when they do.

How do you adapt the plan?

• Consultancy or systems integrator: replace the internal domain with the client's estate; add the statement of work, client architecture board and handover documents.
• Pre-sales at a vendor or partner: use the sales engineer plan and add reference architectures for common deals.
• Security-heavy domain: agree the design review checklist with the CISO; the CISO plan covers the risks they will raise.
• Working with an agile team: the product owner plan shows how architectural work gets into the backlog.
• Architect who also manages engineers: combine with the engineering manager plan.