Skip to main content

30-60-90 Plan for Corporate SSA Onboarding

Why 30-60-90​

Every ambitious initiative fails for one of two reasons: it tries to do everything at once, or it plans forever without starting. The 30-60-90 framework avoids both traps by dividing adoption into three phases, each with clear boundaries, concrete deliverables, and visible progress markers.

Think of it like learning to cook. In the first month, you learn knife skills, understand heat, and master a few basic dishes. In the second month, you tackle full meals, learn flavor balancing, and start improvising within recipes. In the third month, you can plan a dinner party, adapt to what is available at the market, and teach someone else the basics. Each phase builds capability that the next phase depends on.

The same logic applies to SSA adoption. You cannot run an architecture review board before people know what a semantic architecture is. You cannot measure SSA impact before anyone has delivered an SSA project. You cannot scale practices before you have proven they work.

This plan is designed for the first adoption cycle -- typically involving one to three pilot teams. Subsequent cycles can be compressed as the organization builds capability and confidence.

Phase 1: Days 1-30 -- Foundation​

Goal​

Establish the conceptual foundation, organizational alignment, and baseline measurements that everything else depends on. By day 30, everyone involved should understand what SSA is, why it matters for this company specifically, and what "good" looks like.

Activities​

Week 1: Alignment and discovery

  • Conduct a discovery session with leadership to map current AI initiatives, pain points, and strategic priorities. This is not a lecture about SSA; it is a listening exercise. Understand what problems the organization is actually trying to solve.
  • Map the existing AI landscape: which teams use AI, for what purposes, with what tools, and with what quality practices (if any). This map becomes the baseline for measuring adoption progress.
  • Identify the two to three pilot cases that will be the focus of the first 90 days. Select cases using the priority matrix from the Adoption Model: prefer high-impact, low-complexity cases that can demonstrate value quickly.

Week 2: Principle alignment

  • Translate the company's existing values, quality standards, and risk policies into SSA terms. If the company values "customer trust," what does that mean for an AI system's behavior? If the company has a zero-tolerance policy for data leakage, what constraints does that create for context engineering?
  • Draft the company's SSA principles document -- a concise statement of what "well-architected AI" means in this specific organization. This document grounds all subsequent work in the company's own language and priorities, not generic best practices.
  • Review the principles document with leadership, legal, compliance, and engineering stakeholders. Getting alignment at this stage prevents costly debates later.

Weeks 3-4: Fundamentals training and baseline

  • Deliver the SSA Foundations training to all pilot team members. This covers the core concepts from the SSA learning track: semantic architecture, domain ontology, semantic contracts, evaluation design, and safety foundations.
  • Conduct a quality baseline assessment of the pilot cases. For each AI system that already exists, evaluate it against SSA quality criteria: Is there an explicit ontology? Are there semantic contracts? Is there an eval suite? Are there safety controls? Document the current state honestly -- this is not a judgment, it is a starting point.
  • Define the quality targets for day 90. What does "good" look like for each pilot case? Be specific: "Eval suite with at least 50 test cases covering the top 5 use scenarios, achieving at least 85% pass rate on semantic accuracy."

Deliverables​

  1. AI landscape map. A visual inventory of all AI initiatives with their current status, team ownership, and quality maturity level.
  2. SSA principles document. A one-to-two page document connecting company values to SSA quality criteria, reviewed and approved by leadership.
  3. Pilot case briefs. For each pilot case, a one-page brief describing the business context, current state, quality targets, and success criteria.
  4. Quality baseline report. An honest assessment of current quality for each pilot case, measured against SSA criteria.
  5. Training completion records. Evidence that all pilot team members have completed Foundations training.

Success criteria​

  • Leadership can articulate why SSA adoption matters for the company in business terms (not just technical terms).
  • Pilot teams can explain the core SSA concepts -- ontology, semantic contracts, eval suite -- and how they relate to their specific work.
  • Quality baseline is documented with specific, measurable targets for day 90.

Stakeholder touchpoints​

  • Day 1: Kickoff meeting with executive sponsor and pilot team leads. Set expectations, confirm commitment, establish communication rhythm.
  • Day 15: Mid-phase check-in with pilot teams. Address questions from training. Validate pilot case selection.
  • Day 30: Phase 1 review with leadership. Present the AI landscape map, principles document, pilot case briefs, and quality baseline. Get explicit go/no-go for Phase 2.

Common pitfalls​

  • Skipping alignment. Jumping straight into training without aligning SSA principles to company values produces technically skilled people who do not know how to apply their skills in the company's context.
  • Picking too many pilots. Three is the maximum. Two is better for the first cycle. Spreading attention across many pilots dilutes impact and makes it impossible to provide adequate support.
  • Setting vague targets. "Improve quality" is not a target. "Achieve 85% pass rate on semantic accuracy eval suite" is a target. If you cannot measure it, you cannot manage it.
  • Ignoring existing work. Teams that already have AI systems in production may feel that SSA is invalidating their previous work. Frame the baseline assessment as understanding the starting point, not judging past decisions.

Phase 2: Days 31-60 -- Implementation​

Goal​

Apply SSA practices to real projects and produce tangible results. By day 60, each pilot team should have delivered one complete SSA architecture and established ongoing evaluation practices.

Activities​

Weeks 5-6: First SSA project kickoff

  • For each pilot case, launch the SSA architecture design process. Begin with domain analysis: what are the entities, relationships, and constraints in this specific domain?
  • Build the first version of the domain ontology. This is a working document, not a final product. It should capture the key entities, their attributes, their relationships, and the vocabulary that the team commits to using consistently.
  • Design the semantic contracts for the system's core behaviors. What should the system do? What should it never do? What are the boundary conditions? What happens in ambiguous cases?

Weeks 7-8: Evaluation and governance foundations

  • Design and implement the eval suite for each pilot case. The eval suite should cover the system's primary use scenarios, known edge cases, and safety-critical behaviors. Start with manual evaluation, then automate progressively.
  • Establish the evaluation baseline: run the eval suite against the current system (or a prototype) and record the results. This baseline is the foundation for measuring improvement.
  • Draft the governance foundations: define which decisions require architecture review, who has decision rights for different types of changes, and how standards will be proposed and approved.
  • Begin weekly Architecture Clinic sessions. These are peer review sessions where pilot team SSAs present their work, receive feedback, and learn from each other's approaches.

Value demonstration:

  • At the midpoint of Phase 2 (around day 45), prepare a value demonstration for stakeholders. Show concrete examples of how SSA practices have improved system quality, caught issues before production, or accelerated design decisions. Use before-and-after comparisons from the baseline assessment.

Deliverables​

  1. Domain ontology v1. For each pilot case, a structured ontology covering key entities, relationships, constraints, and vocabulary.
  2. Semantic contracts. For each pilot case, the core behavioral contracts defining what the system should do, must not do, and how it handles edge cases.
  3. Eval suite with baseline. For each pilot case, a suite of at least 50 evaluation cases with recorded baseline results.
  4. Architecture spec. For each pilot case, a complete architecture specification following the SSA template.
  5. Governance draft. A document defining decision rights, review processes, and standards management for SSA practices.
  6. Value demonstration. A concise presentation showing concrete quality improvements from SSA practices, with data.

Success criteria​

  • Each pilot team has delivered a complete SSA architecture (ontology, contracts, eval suite, architecture spec) for their case.
  • Eval suites are running regularly (at least weekly) and results are tracked.
  • At least one concrete example of SSA practices catching an issue or improving quality that would not have happened without the architecture.
  • Stakeholders can see measurable progress from baseline to current state.

Stakeholder touchpoints​

  • Day 35: Phase 2 kickoff with pilot teams. Review Phase 1 deliverables, set Phase 2 targets, address concerns.
  • Day 45: Mid-phase value demonstration for leadership. Show progress, build confidence, address concerns.
  • Day 60: Phase 2 review with leadership and broader stakeholder group. Present all deliverables. Get explicit go/no-go for Phase 3 expansion.

Common pitfalls​

  • Perfectionism on the ontology. The first ontology is a draft. It will evolve. Teams that try to make the ontology perfect before moving on to contracts and evals run out of time without producing a working system.
  • Skipping the eval suite. It is tempting to focus on architecture and defer evaluation. This is a mistake. The eval suite is what makes quality measurable and improvement visible. Without it, SSA is just documentation.
  • Not demonstrating value early enough. If stakeholders do not see value by day 45, support erodes quickly. Prepare concrete examples, even if they are small.
  • Over-engineering governance. At this stage, governance should be lightweight. A one-page decision rights matrix and a weekly review cadence are sufficient. Do not build a bureaucracy.

Phase 3: Days 61-90 -- Scale​

Goal​

Expand SSA practices beyond pilot teams, standardize what has been learned, and create the conditions for sustained adoption. By day 90, the organization should have a proven playbook, measurable results, and a clear plan for the next quarter.

Activities​

Weeks 9-10: Expansion preparation

  • Identify the next wave of teams for SSA adoption (typically three to five additional teams). Brief their leaders on what SSA involves and what they can expect.
  • Train the next cohort of SSA practitioners. Use the pilot team members as teaching assistants and mentors -- this deepens their own understanding and scales training capacity.
  • Standardize the practices that worked during the pilot. Convert informal practices into documented standards: templates, checklists, review criteria, and process descriptions. Be selective -- only standardize what has been validated through actual use.

Weeks 11-12: Impact measurement and planning

  • Conduct a comprehensive impact assessment. Compare current quality metrics to the day-1 baseline. Calculate time savings, quality improvements, incident reductions, and any other relevant metrics.
  • Prepare the quarterly SSA report for leadership. This report should connect SSA practices to business outcomes using the impact attribution framework from the Metrics section.
  • Conduct a retrospective with all pilot team members. What worked? What was unnecessarily difficult? What would they change? Use these insights to improve the next 30-60-90 cycle.
  • Draft the next quarter's SSA roadmap. Which teams will adopt next? What standards need updating? What capabilities need building? What metrics need tracking?

Weeks 11-12 (parallel): Maturity assessment

  • Evaluate each pilot team's SSA maturity using the maturity model from the Adoption Model section. Where do they fall on the ad-hoc to innovative spectrum?
  • Identify capability gaps that need addressing in the next cycle. Are teams strong on ontology but weak on evaluation? Strong on design but weak on governance?
  • Set maturity targets for the next quarter.

Deliverables​

  1. Standardized practice playbook. A documented set of SSA standards, templates, and processes validated through pilot experience.
  2. Impact assessment report. A data-driven analysis of SSA adoption's impact on quality, speed, cost, and risk, compared to baseline.
  3. Maturity assessment. For each pilot team, a maturity evaluation with current level and target level for next quarter.
  4. Retrospective findings. A summary of what worked, what did not, and recommended changes for the next cycle.
  5. Next quarter roadmap. A plan for expanding adoption to additional teams, with timeline, resource requirements, and success criteria.
  6. Expansion team briefs. For each team joining the next cycle, a brief describing their context, readiness, and onboarding approach.

Success criteria​

  • Measurable quality improvement compared to day-1 baseline (specific targets depend on the pilot cases, but a 20-30% improvement in eval pass rate is a reasonable benchmark for the first cycle).
  • At least three teams ready to begin SSA adoption in the next quarter.
  • Standardized playbook reviewed and approved by SSA Lead and pilot team leads.
  • Leadership has approved the next quarter's SSA roadmap and resource allocation.

Stakeholder touchpoints​

  • Day 65: Expansion team leader briefings. Set expectations for the next cycle.
  • Day 75: Mid-phase progress review with pilot teams. Finalize impact assessment data.
  • Day 90: Quarterly SSA review with executive sponsor and leadership team. Present impact report, maturity assessment, and next quarter roadmap. Secure commitment for continued investment.

Common pitfalls​

  • Scaling before proving. If pilot results are not clearly positive, do not expand. Fix what is not working first. Scaling broken practices just multiplies the problems.
  • Losing pilot momentum. Teams that completed the pilot sometimes feel "done." They need ongoing support, evolving challenges, and recognition to maintain engagement.
  • Creating shelfware. Standards that are documented but not used are waste. Every standard should have an owner, a review schedule, and a clear connection to daily work.
  • Underinvesting in the next cohort. The second wave of teams needs the same quality of training and support that the pilots received. Cutting corners on training to save time produces under-prepared practitioners who discredit the entire program.

Adaptation guidance​

For startups (under 50 people)​

Compress the timeline to 45-60 days. Skip formal governance structures -- they are overhead you do not need yet. Focus on building SSA skills in two or three key people who can influence the entire engineering team. The "pilot" is the entire company. Your deliverables can be less formal -- a shared Notion page is fine instead of a formal report.

For mid-size companies (50-500 people)​

Follow the plan as described, but emphasize the champion network early. In a mid-size company, cultural change depends on a few influential people in each team. Identify and invest in those people. Governance can be lightweight but should be explicit -- write it down, even if it fits on one page.

For enterprises (500+ people)​

Add a Phase 0 (two to four weeks before Day 1) for executive alignment and political mapping. Identify potential blockers and allies. In large organizations, SSA adoption is as much a political project as a technical one. Plan for a longer expansion timeline (six months instead of one quarter). Invest heavily in the internal academy because training at scale requires dedicated infrastructure, not ad-hoc workshops.

For low AI maturity organizations​

If most teams have little or no AI experience, extend Phase 1 to 45 days and add basic AI literacy training before SSA-specific training. People need to understand what AI can and cannot do before they can learn how to architect it well.

For high AI maturity organizations​

If teams already have sophisticated AI systems, focus Phase 1 on gap analysis rather than basic training. These teams do not need to learn what an ontology is -- they need to learn how their existing practices map to SSA concepts and where the gaps are. The framing shifts from "here is something new" to "here is how to formalize and improve what you already do."

What happens after Day 90​

Day 90 is the end of the first cycle, not the end of the journey. The 30-60-90 plan is designed to be repeatable. After the first cycle, you run a second cycle with the next wave of teams, using the refined playbook and expanded training capacity from the first cycle.

Each subsequent cycle should be faster and smoother than the previous one for three reasons:

Accumulated assets. The template library, pattern catalog, and evaluation infrastructure built during the first cycle are available for all future teams. New teams do not start from scratch -- they start with a proven toolkit.

Experienced mentors. The practitioners trained in the first cycle become mentors and teaching assistants for the second cycle. They can share real experience, not just theory. They can answer the question every new practitioner asks: "How does this actually work in our company?"

Organizational muscle memory. The rituals, governance structures, and communication patterns established during the first cycle become organizational habits. People know what an architecture review looks like. They know what an eval suite is expected to contain. They know who to ask for help. This institutional knowledge dramatically reduces the friction of onboarding new teams.

A typical organization runs three to four 90-day cycles before reaching a steady state where SSA practices are fully embedded and self-sustaining. At that point, the 30-60-90 cycle shifts from an adoption tool to an onboarding tool -- used to bring individual new hires up to speed rather than to transform entire teams.

The cycle retrospective​

At the end of each 90-day cycle, conduct a dedicated retrospective (separate from the Phase 3 retrospective) that evaluates the cycle itself as a process:

  • What phases were too long or too short?
  • Which deliverables were essential and which were waste?
  • Where did the plan assume resources that did not exist?
  • What did we learn that should change the plan for the next cycle?

Update the 30-60-90 template based on these findings. Your third cycle plan should look noticeably different from your first cycle plan -- not because the principles changed, but because your understanding of how to apply them in your organization has deepened.

Key takeaways​

  1. Phase by phase, not all at once. Each phase has clear goals, deliverables, and success criteria. Do not skip ahead.

  2. Measure from the start. The baseline established in Phase 1 is what makes Phase 3's impact assessment meaningful. Without a baseline, you have stories instead of data.

  3. Demonstrate value early and often. Stakeholder patience is finite. Show concrete improvements by day 45 at the latest.

  4. Standardize what works, not what sounds good. Only turn pilot practices into standards after they have been validated through real use.

  5. Adapt the plan to your context. A startup and an enterprise need the same principles but very different implementation approaches.