Understanding the Role and First 90-Day Plans Questions

Situation: A high-priority 30-day deliverable failed acceptance testing right before client handoff.

Detection:

• Automated CI/CD pipeline and acceptance test suite flagged failures; QA reported mismatches against acceptance criteria and regression alerts from staging monitoring.
• Triage: I convened an emergency cross-functional huddle (engineering lead, QA, PM, delivery lead, security) within 1 hour.

Immediate containment (first 24 hours):

• Freeze new code and configuration changes in the delivery branch.
• If production-facing, toggle feature flags or roll back to the last known-good release to stop customer impact.
• Capture forensic artifacts: logs, test runs, build artifacts, config diffs, database snapshots, and relevant telemetry.

Root-cause analysis approach:

• Use a structured Fishbone + 5 Whys process to separate symptoms vs root causes across People, Process, Platform, and Requirements.
• Reproduce the failure in an isolated environment using the recorded artifacts.
• Trace through CI artifacts, dependency versions, infra-as-code diffs, and acceptance test assumptions to identify the minimal failing change set.
• Validate hypotheses with short experiments (unit/test-only fixes) to confirm causality.

Remediation priorities (triaged by risk and business impact):

1. Safety/stability fixes (rollbacks, config corrections) — immediate
2. Acceptance-criteria gaps (test fixes, requirement clarifications) — short-term (24–72 hrs)
3. Root engineering fixes (code, infra changes) — medium-term (1–2 weeks), with patch releases
4. Process fixes (release gate additions, enhanced tests, pipelines) — longer-term and tracked as OKRs

Communication to stakeholders:

• Within 2 hours: initial status brief to client and exec sponsor — facts only: detection, impact, containment actions, owners, ETA for next update.
• Daily updates until resolution with transparent artifacts and mitigation proof points.
• Post-resolution: full post-mortem document and executive summary with timeline, RCA, remediation plan, and how acceptance will be revalidated.

Restoring confidence:

• Deliver a clear remediation roadmap with milestones, owners, and success criteria; run a joint validation session with client to re-verify acceptance criteria.
• Implement immediate process safeguards: tightened release gates, mandatory acceptance-test pass in CI, dependency pinning, and runbooks.
• Offer a limited pilot/parallel run with client-facing monitoring dashboards and SLA/SLO commitments for a probationary period.
• Measure and report improvements (reduced regression rate, pipeline green-time) and incorporate learnings into onboarding and architecture reviews so the client sees sustained improvements.

Requirements (clarify first): capture knowledge artifacts (designs, trade-offs), decisions (architectural, security), runbooks (operational playbooks), searchable & discoverable, auditable ownership, lightweight for sales enablement, integrated with CI/CD and incident tooling.

High-level tooling stack

• Documentation platform: Confluence or Notion for narrative docs + decision logs; Git-backed docs (Docs-as-Code) in a repo (Markdown) for runbooks and architecture diagrams that need versioning. Use Mermaid/PlantUML for diagrams.
• Roadmapping: Aha! or Productboard for strategic roadmaps tied to opportunities; integrate key milestones into Confluence pages.
• Issue tracking: Jira (or Linear) for delivery tasks; link epics/issues to design pages and decision records.
• Diagrams/collab: Miro + draw.io; store canonical exports in docs repo.
• Runbooks/Oncall: GitHub/GitLab repo with CODEOWNERS, and PagerDuty/Opsgenie links for triggers.
• Storage/archival: S3 (versioned) + Glacier for long-term archives; enable lifecycle policies.

Structure & naming conventions (consistent, search-friendly)

• Top-level: /docs/{client}/{engagement}/{component}
• Page/filename: YYYYMMDD_type_scope_title e.g., 20251103_DECISION_AuthService_OIDC-vs-SAML
• Runbooks: /runbooks/{service}/{runbook-name}.md and include metadata frontmatter: owner, last-tested, severity, runbook-version
• Diagrams: {component}_v{semver}.svg

Ownership & governance

• RACI per artifact: Author (creator), Reviewer (architecture owner), Approver (SA lead), Maintainer (Dev team). Use CODEOWNERS for repo enforcement; Confluence page property for owner and review cadence.
• Onboarding checklist (first 100 days): access requests, mapping key artifacts, runbook sanity-check, 1-week shadowing with oncall, 30/60/90 documentation sprints.
• Templates: Decision Record template (ADR), architecture template, runbook template with step-by-step actions and verification commands.

Retention & archival policy

• Active docs: 0–24 months — editable, indexed, linked to Jira/Aha.
• Cold archive: 24–60 months — moved to S3 "archive" bucket, read-only, searchable via metadata catalog (Glue/Elastic).
• Long-term retention: >60 months — Glacier Deep Archive for compliance; maintain manifest in Confluence.
• Delete policy: Auto-delete only when contract ends and legal permits; require approvals. Maintain audit logs of edits and archival activities.

Operational practices

• Enforce CI for docs: PRs for changes, required reviewers, automated linting (markdownlint), link-checks, diagram build.
• Decision hygiene: ADR per major change; record alternatives, pros/cons, owners, date.
• Runbook testing: Quarterly tabletop & runbook execution validation; annotate last-tested.
• Search/Discoverability: Central index page, tags, and Elasticsearch/Confluence search tuned with synonyms (customer names, service codes).

Why this fits a Solutions Architect

• Balances narrative (sales-friendly) and code-backed artifacts (ops-ready)
• Ensures traceability from roadmap → design → tickets → runbooks
• Enforces ownership, auditability, and operational readiness within first 100 days and beyond.

Situation: In my first week as a Solutions Architect at a cloud services company, I inherited a stalled RFP for a mid-market retail client that needed a scalable inventory and analytics platform. Sales was two weeks from losing the deal.

Task: My goal was to regain client confidence, deliver a credible technical proposal, and move the deal to the next milestone within 90 days.

Action:

• Week 1: Met with sales lead, product manager, and client CTO to map requirements and risks; delivered a one-page architecture sketch and risk-mitigation list (quick win) within 5 days to re-establish credibility.
• Week 4–30: Built a modular reference design, cost estimates, and a demo pipeline with engineering and cloudops. Weekly checkpoints with sales and the client's technical team kept alignment.
• By Week 90: Led a joint architecture workshop, finalized implementation SOW, and handed off to delivery.

Result:

• Quick wins: one-page architecture and demo within first month restored momentum.
• Metrics: shortened sales cycle by 40% (deal moved from stalled to proposal accepted in 8 weeks vs. typical 13), increased win probability from 30% to 75%, and reduced estimated implementation risk score by 60%.
• Stakeholders: Sales lead, product manager, engineering, cloudops, client CTO and lead engineer.

What I changed in onboarding:

• Now onboards by scheduling stakeholder alignment and delivering a one-page architecture + risk list in week 1, plus a 30-day demo checkpoint—this reproducible pattern accelerated early trust and impact in subsequent roles.

Situation: On joining, I discover a backlog of technical debt (legacy integrations, brittle deployment scripts, missing monitoring, and one high-risk auth component) that—if unaddressed—will slow demos, increase deal cycles, and risk post-sale delivery.

Plan (first 60 days) — goals: align stakeholders, quantify risk/ROI, and propose a phased, low-disruption remediation plan.

Messaging (two versions):

• Executive (VP Product / CRO): “There’s a concentrated risk that will slow time-to-close and increase delivery cost on medium+ deals. Addressing three targeted items will reduce deal friction and expected delivery overruns by ~30% with a 6–9 month ROI.”
• Sales/AE (tactical): “We can keep current deals live while I secure quick mitigations that unblock demos and reduce escalation points. I’ll provide talking points and checklist items to reassure customers.”

Prioritized remediation list (by impact, effort, revenue risk):

1. Harden auth component (High impact, Medium effort) — prevents deal-killers for security-conscious customers.
2. Demo/staging reliability (High impact, Low effort) — flaky demos cost immediate revenue.
3. CI/CD rollback & automated smoke tests (Medium impact, Medium effort) — speeds delivery and reduces post-sale surprises.
4. Observability & alerting for critical flows (Medium impact, Medium effort) — reduces escalations.
5. Refactor legacy integrations (Low impact, High effort) — long-term modernization.

60-day phased work to protect deals:

• Days 0–14: Rapid assessment and risk scoring per active deal; produce a Deal Risk Register mapping debt items to specific open opportunities.
• Days 15–30: Execute two quick wins: stabilize demo/staging and add temporary mitigations (feature flags, runbooks) for auth to allow safe demos. Share scripted responses and collateral with sales.
• Days 31–45: Implement CI/CD smoke tests and one-step rollback for production-like environments; update solution docs and SOW language to reduce acceptance risk.
• Days 46–60: Begin auth hardening sprint and deploy basic observability for critical customer flows; present a prioritized roadmap and funding ask (time/cost vs. expected revenue protection).

How I’d get buy-in:

• Present quantified risks linked to specific deals and historical incident costs.
• Offer a small, time-boxed investment request (e.g., 2 sprints or $X) tied to measurable KPIs: demo uptime, mean time to recovery, reductions in estimated delivery variance.
• Provide Sales enablement: risk mitigations, customer-facing FAQ, and a “safe demo” checklist.

Outcome: This approach balances immediate sales needs with technical remediation—delivering visible short-term wins to protect revenue while establishing a funded roadmap to eliminate the remaining debt.

Situation: Joining as a Solutions Architect on a distributed team with multiple sites and recent hires, I needed to quickly understand norms and accelerate inclusion for remote/new architects so they could contribute to design decisions.

Task: In the first 60 days, my goal was to assess culture, surface collaboration gaps, and put in place practices that onboard remote architects into decision-making fast.

Action:

• Week 1–2: Listening tour — 30–45 minute 1:1s with PMs, engineers, sales reps, and new/remote architects to learn workflows, pain points, and existing rituals. Documented themes.
• Week 2–4: Team norms inventory — ran a short survey + mapped async vs. synchronous expectations (response times, decision authority, RFC process). Shared results in a cross-site working doc.
• Week 3–6: Build inclusion rituals — established a rotating “Design Spotlight” (30 min biweekly) where a remote/new architect presents a recent design and gets structured feedback; created an RFC template and defined SLAs for review.
• Week 4–8: Shadowing & pairing — arranged virtual pairing sessions between senior architects and new hires on active proposals; created a shared architecture board (Confluence/Diagrams) with clear ownership and comment threads.
• Ongoing: Improved visibility — published a decision log and “how decisions are made” playbook; set up weekly 15-min cross-site sync focused solely on blockers for remote contributors.

Result: Within 60 days the team reported clearer expectations, faster review cycles, and two new architects contributing to major proposals. The documented norms reduced repeated clarifying questions by ~30% and shortened RFC review timeframes.

This approach balances listening, low-friction rituals, and tooling to make remote architects visible and empowered in decisions.