Senior Solutions Architect Interview Preparation Guide - FAANG Standards

Summary recommendation: Buy the managed SaaS unless you require heavy custom analytics, proprietary IP capture, or strict data residency/compliance — SaaS delivers ~3x lower 3-year TCO, much faster time-to-value, and lower operational risk.

3-year TCO (high-level)

Assumptions used:

• 3 engineers @ $150k/yr; 1 SRE @ $175k/yr
• Infra (build) $10k/month for 2 years
• SaaS license $12k/month
• 3 months integration effort (engineers)

Build (in-house)

• Engineers (3) over 3 yrs: 3 * $150k * 3 = $1,350,000
• SRE over 3 yrs: $175k * 3 = $525,000
• Infra: $10k/mo * 24 months + conservative $5k/mo in year 3 = $240,000 + $60,000 = $300,000
• Overhead (security, monitoring, backup tools, training, 10% of labor): ≈ $187,500
  Total (3 yrs) ≈ $2,362,500

Buy (SaaS)

• SaaS license: $12k/mo * 36 = $432,000
• Integration effort: 3 engineers * ($150k/12) * 3 months = $112,500 (one-time)
• SRE/ops (vendor integration, runbooks, 25% FTE): 0.25 * $175k * 3 = $131,250
• Contract/legal/vendor mgmt & contingency (~10%): ≈ $67,725
  Total (3 yrs) ≈ $743,475

Net difference: Build ≈ $2.36M vs Buy ≈ $0.74M → ~ $1.62M savings favoring SaaS over 3 years.

Hidden costs to include before final decision

• Build: ongoing feature roadmap dev, long-term maintenance, technical debt, security/compliance tooling, backups and DR testing, hiring/replacement risk, performance scaling, SLA obligations, monitoring/alert noise, audit costs.
• Buy: data egress and integration costs, limited customization, vendor lock-in and exit/migration costs, per-feature or per-seat add-ons, SLA limitations and support escalation, compliance/gov risks, shadow IT if teams bypass integration.
• Both: training, change management, analytics governance, data lineage, and observability costs.

Recommendation & rationale

• Default: Choose SaaS now if your needs match standard analytics, you prioritize speed-to-value, and want to avoid recruiting/ops burden. It’s materially cheaper and reduces operational risk.
• Build only if: you require unique/custom analytics pipelines that are core IP, have predictable scale where marginal cost favors in-house, or strict regulatory constraints prevent SaaS usage.
  Next steps if buying: run a 3-month pilot, negotiate SLAs and exit terms, validate data portability and egress costs, define runbook and observability requirements, and include a 12–18 month review to reassess cost/performance.

Direct answer

Persuading someone senior to fund or change something means leading with the decision you want, naming the cost of the status quo explicitly, pre-empting the single most likely objection before it's raised, and sizing the ask (a phased or capped version) so agreeing feels lower-risk than it would if you asked for everything up front.

Structured elaboration

Anatomy of an executive ask:

1. Lead with the decision, not the narrative. State the ask early; don't make the sponsor wait for the punchline.
2. Name the cost of inaction explicitly, not just the benefit of acting.
3. Pre-empt the most likely objection (revenue impact, cost, risk) before someone else raises it in the room.
4. Size the ask to reduce perceived risk: a phased rollout, a pilot, or a capped budget is an easier yes than the full commitment.
5. Know your sponsor and your skeptic beforehand, and align the skeptic privately when possible.

Same competency, different scale. This shows up from small asks to board-level ones:

Worked example

Situation. At a mid-size company, an engineering manager proposed a platform consolidation project in a leadership review. A senior VP publicly dismissed it in the room as "solving a problem nobody has," undermining the pitch in front of the same audience needed for approval.

Stakes. Losing credibility with that VP risked not just this proposal but every future ask; meanwhile the underlying problem (duplicated infrastructure, rising support cost) was real and getting worse.

The influence moves.

• Didn't re-litigate in the room; took the public pushback as a signal to gather sharper evidence, not an invitation to argue live.
• Went back to the VP one-on-one, not to reopen the room's discussion but to ask directly what would change their mind, and learned the real objection was a past project's failed ROI, not this one's merits.
• Rebuilt the case to address that exact objection: capped the initial ask to a bounded pilot instead of the full six-month rewrite, with a defined stop-loss checkpoint.
• Brought the VP back in as a named reviewer of the revised plan, rather than resurfacing it as a surprise.

Resolution. The VP co-sponsored the revised, phased version at the next review. The earlier public criticism ended up making the final plan tighter and more credible, not dead.

What a senior candidate does differently. Doesn't treat public pushback as the end of the story or take it personally; treats it as the clearest possible signal of the real objection and goes to address it directly with the person who raised it, rather than only preparing a better slide for the same room.

Trade-offs and pitfalls

• Sequencing matters. Leading with the ask before the sponsor is aligned invites exactly this kind of public pushback; senior candidates often pre-wire the most skeptical stakeholder before the room, not after.
• Sizing matters. Asking for the full multi-month or multi-million commitment up front is a harder yes than a capped pilot with a defined checkpoint; the same case is more persuasive staged.
• "Strategic value" still needs a quantified comparison. Even initiatives without near-term revenue need some measured comparison (opportunity cost, cost of inaction), or the ask reads as a hunch.

Direct Answer

A saga coordinates a business transaction that spans multiple services by breaking it into a sequence of local transactions. Each service commits its own step immediately with no cross-service lock held, and if a later step fails, the saga undoes the steps that already succeeded by running a compensating action for each one, in reverse order. This trades strict, all-or-nothing atomicity for eventual, recoverable consistency and loose coupling between services.

Choreography vs. Orchestration

• Orchestration: a central coordinator issues each step as a command to the relevant service and decides, based on that service's response, what to do next, including which compensations to trigger if something fails. The whole workflow lives in one place, which makes it easier to see, test, and reason about end to end.
• Choreography: there is no central coordinator; each service publishes an event when it finishes its local step, and whichever service is subscribed to that event reacts by doing its own step and publishing its own event in turn. This avoids coupling every service to a central coordinator's command contract, but it scatters the workflow logic across services, so understanding or changing the whole sequence means tracing through several services' event subscriptions instead of reading one place.

Worked Trace: Order Fulfillment When Shipment Fails (Orchestration Style)

Order O123, three steps: reserve inventory, charge payment, schedule shipment.

1. Orchestrator sends ReserveInventory(O123, sku=42, qty=1) to Inventory. Inventory reserves the unit and replies Reserved.
2. Orchestrator sends ChargePayment(O123, $50) to Payment. Payment captures the charge and replies Charged.
3. Orchestrator sends ScheduleShipment(O123) to Shipping. Shipping tries to allocate a carrier slot and replies Failed: no carrier capacity.
4. The orchestrator now runs compensations in reverse order. It sends RefundPayment(O123, $50) to Payment, undoing step 2. Payment replies Refunded.
5. It sends ReleaseReservation(O123, sku=42, qty=1) to Inventory, undoing step 1. Inventory replies Released.
6. The orchestrator marks order O123 as Failed and notifies the customer.

The same sequence in choreography looks like this instead: Inventory reserves and emits InventoryReserved(O123). Payment, subscribed to that event, charges and emits PaymentCharged(O123). Shipping, subscribed to PaymentCharged, tries to schedule and, on failure, emits ShipmentFailed(O123). Both Payment and Inventory are subscribed to ShipmentFailed: Payment independently issues its own refund and emits PaymentRefunded(O123), and Inventory independently releases its reservation and emits ReservationReleased(O123). No single component ever holds the full picture of the workflow; each service only knows what to do when it sees an event it's subscribed to.

Trade-offs and Pitfalls

• Every forward step and every compensating action has to tolerate being retried, since at-least-once delivery means ChargePayment could be delivered twice; this is a system-property requirement on the saga's steps, a separate concern from how an external API exposes idempotency to its own callers.
• The saga's state, meaning which steps have completed and which compensations are pending, needs to be durably persisted, whether by a central orchestrator or by each participant in a choreography, so that a crash and restart can resume the saga correctly instead of leaving it stuck partway.
• Not every action has a true inverse. Compensating a shipment step after the package has physically left the warehouse can't undo the physical fact, only correct the system's record and possibly trigger a real-world return process; a senior design puts the hardest-to-compensate steps as late as possible in the sequence.
• Choose a saga when the steps naturally live in separate services or databases and each one can be given a real, working compensating action. Reach for a real distributed transaction only when an intermediate, partially-applied state genuinely cannot be tolerated and you can afford a synchronous locking protocol across every participant, which a saga specifically avoids.

Approach (practical, repeatable):

1. Clarify scope & requirements — collect statutes (GDPR, CCPA, HIPAA), affected data flows, jurisdictions, and relevant contracts.
2. Map requirements to control objectives — translate legal obligations into measurable technical/procedural controls (e.g., GDPR Article 32 → encryption at rest/in transit, access control, logging).
3. Create artifacts:

• Compliance matrix: rows = legal requirements; columns = control owner, implemented control, evidence, status, residual risk.
• Gap analysis & remediation roadmap: prioritized gaps, effort, timelines, dependencies.
• Data flow diagrams & DPIAs/RIAs for high-risk processing.
• Test evidence pack: config screenshots, SOC reports, policy docs, audit logs.

4. Assign stakeholders & RACI:

• Legal/Privacy: interpret requirements, DPIAs.
• InfoSec/Security: technical controls, verification.
• Engineering/Platform: implement fixes.
• Product/PM: feature trade-offs and timelines.
• Compliance/Internal Audit: validation and evidence.
• Ops/SRE: monitoring, incident response.
• Sales/Account teams: customer contract impacts.

5. Validation & testing: run tabletop exercises, automated control checks, periodic internal audits.

Cadence & triggers:

• Quarterly operational reviews for controls and evidence.
• Annual full regulatory re-mapping and risk reassessment.
• Immediate review on triggers: new law/clarification, major product change, breach, or significant customer contract.
  Metrics & governance:
• Track open gaps, mean time to remediate, control test pass rate. Review results in a governance board (monthly) with owners accountable for fixes.

Why this works: it turns high-level legal text into actionable, owned controls with evidence and a repeatable review cadence — balancing legal nuance, engineering feasibility, and business timelines.

Situation: Three days before submission a client adds a country-specific data-residency requirement.

Immediate steps (first 24 hours)

• Triage: confirm exact requirement scope (which data, retention, processing vs. storage) with account lead/PM and client.
• Risk/feasibility quick audit: check current architecture, cloud region availability, legal/compliance, and any existing in-country partners.
• Convene a rapid cross-functional huddle: Sales (AE), Legal/Compliance, Cloud/Infra engineering, Security, Delivery lead, and Procurement.

Assess & design

• Map affected data flows and components; identify what must be hosted in-country vs. can be pseudonymized/aggregated.
• Propose 2–3 options: (A) native regional deployment (new cloud region/account), (B) hybrid (local storage + central processing with encrypted transfer), (C) partner/local datacenter or managed hosting.
• For each option list constraints, security controls (encryption at rest/in transit, key management), and migration approach.

Estimate cost & timeline

• Provide ballpark estimates: infra provisioning, licensing, engineering effort, legal reviews, and SLA impacts. Break into fixed vs. recurring costs and estimate timeline for MVP vs. full compliance (e.g., 1–4 weeks infra + 2–8 weeks validation, depending on option).

What to present to Sales

• A concise decision memo with: clarified requirement, proposed options (with pros/cons), cost/time ranges, risk level, dependencies, recommended option, and ask (e.g., budget/time extension or acceptance of mitigations).
• Include impact on contract terms and a suggested change request text.

Documentation to produce

• Updated architecture diagram highlighting in-country components and data flows.
• Short compliance checklist and assumptions.
• Migration/implementation runbook outline and roll-back plan.
• Risk register and residual risk mitigation.
• Estimated BOM and timeline Gantt.

Follow-up

• Agree next steps, sign-offs and a communication plan with client and Sales; capture approval for chosen option before updating the formal proposal.

At 100M to 1B events/day with hundreds to thousands of concurrent BI/ad-hoc users, the design has to separate three concerns that are often conflated: where raw data lands, what serves fast interactive queries, and how you keep cost proportional to actual usage rather than peak capacity.

Architecture

flowchart LR
    A[Event sources] --> B[Ingestion: Kafka/Kinesis]
    B --> C[Raw storage: object storage, partitioned by date]
    C --> D[Transform: dbt/Spark]
    D --> E[Curated warehouse/lakehouse tables]
    E --> F[Materialized aggregates + cache]
    F --> G[BI / ad-hoc query layer]
    E --> H[Ad-hoc query engine: Presto/Trino]
    I[Orchestrator] -.-> B
    I -.-> D
    J[Monitoring + catalog] -.-> C
    J -.-> E

Storage layer: a lakehouse (open table format like Apache Iceberg or Delta Lake over object storage) is the right default at this scale, because it gives you cheap raw retention alongside ACID-safe (atomicity, consistency, isolation, durability) curated tables without maintaining two separate copies of the data for BI versus ad-hoc/ML use.
Compute/query engine: split by workload. Scheduled transformation and large ad-hoc scans go through Spark or Presto/Trino; the bulk of BI dashboard traffic should hit pre-aggregated, materialized tables rather than scanning raw fact tables live, since hundreds of concurrent dashboard refreshes against raw data will not hold predictable latency.
Caching and materialization: build daily or hourly materialized aggregates for the metrics that dashboards actually chart repeatedly (this is the single highest-leverage latency and cost lever at this scale), and put a query-result cache in front of the BI layer for identical repeated queries.
Workload isolation: give ad-hoc/exploratory queries a separate compute pool (a separate warehouse, or a separate Presto/Trino cluster) from the scheduled BI dashboard refreshes, so one analyst's expensive ad-hoc query cannot degrade dashboard latency for everyone else.
Cost controls: partition and cluster raw and curated tables on the columns dashboards actually filter on (date, region, product), enforce query timeouts and byte-scanned quotas on the ad-hoc pool, and autoscale compute down aggressively outside business hours.

Multi-region extension

If the platform must serve low-latency dashboards across regions, replicate the curated (not raw) layer to a read replica or regional cache near each user population, route BI queries to the nearest region, and keep a single source-of-truth region for raw ingestion and transformation to avoid multi-writer consistency problems. Accept eventual consistency between regions (typically a few minutes of replication lag) rather than trying to build synchronous cross-region writes, which would tank both latency and availability for a marginal freshness benefit.

Worked example

If a single dashboard metric (say, daily revenue by region) is queried 5,000 times a day by different analysts but the underlying data only changes once a day after the nightly ETL (extract, transform, load) run, materializing that one aggregate turns 5,000 potentially-expensive raw scans into 5,000 cheap reads of a small precomputed table, which is the difference between a system that needs constant capacity tuning and one that comfortably serves thousands of users on modest compute.

Trade-offs and pitfalls

The most common failure at this scale is letting BI dashboards query raw or lightly-aggregated fact tables directly "because it's simpler," which works in a demo with ten users and falls over once real concurrency and real data volume both show up. The second is over-isolating workloads into so many separate compute pools that operational overhead (monitoring, cost allocation, capacity tuning per pool) exceeds the benefit; two or three pools (ETL, BI, ad-hoc) is usually enough.

Summary: Two viable patterns — CDN edge caching (public CDN like Cloudflare/Akamai/CloudFront) vs in-service cache (service-fronted cache such as regional Redis/ELB-level caching or application-layer cache). Below I compare key dimensions and give a recommendation for a global user base.

Alternatives:

1. CDN edge caching

• Cache invalidation complexity: Medium — supports TTLs, cache-control and soft/purge APIs. Invalidation at scale requires purge API orchestration or versioned URLs (cache-busting) to avoid mass purges.
• Consistency guarantees: Eventual. Edges may serve stale objects until TTL expires or explicit purge propagates; purges are fast but not instantaneous globally.
• Geographic performance: Excellent — single-digit to low-double-digit ms globally from nearest PoP.
• Estimated cost / 1M requests: $0.50–$5 (request + egress; depends on CDN and region); bandwidth dominates if assets are large.
• Operational complexity: Low — managed service, simple integration, fewer infra responsibilities.

2. In-service cache (regional Redis/edge application caches or nearest-AZ caches)

• Cache invalidation complexity: High — need coordinated invalidation across regions, or central invalidation service; more logic in app.
• Consistency guarantees: Stronger possible — can implement near-real-time invalidation (pub/sub), read-through/write-through patterns to keep caches coherent.
• Geographic performance: Moderate — faster within region/availability zone; global users may see higher latency unless you deploy many regional caches.
• Estimated cost / 1M requests: $5–$30 (compute + managed cache nodes + network egress if regional replication used).
• Operational complexity: High — provisioning, scaling, replication, failover, and operational runbook for cache coherence.

Recommendation:
Use CDN edge caching as primary delivery mechanism for static user profile assets, combined with cache-control headers and versioned asset URLs for deterministic invalidation. For assets requiring immediate consistency (e.g., profile photo changed and must be visible instantly to owner), add a short cache TTL + origin purge on update and a user-scoped cache-bypass query param for critical paths, or implement a fast synchronous invalidation flow (invalidate CDN by versioned URL). Optionally deploy regional in-service caches only for write-heavy metadata workflows needing strong consistency; keep origin storage (S3/object store) and small TTLs to minimize stale windows.

Justification:
Global performance and cost favor CDN edges — lowest latency worldwide and lowest per-request cost. CDN reduces operational burden while offering pragmatic invalidation tools. Combine conservative TTLs and versioned URLs to balance eventual consistency with user expectations; reserve in-service caches where strict, low-latency consistency is required and you can absorb operational overhead.

Direct answer

Triage by urgency and impact first, protect your own deliverables with an explicit, communicated time-box, and convert repeat-pattern questions into reusable artifacts so future requests don't all cost you 1:1 time. Prioritization alone doesn't scale past a certain number of mentees; reusable resources are what let personalized-feeling mentoring keep up as the queue grows.

Triage and scaling approach

Triage each request on three axes. Is it blocking (them or someone downstream) versus a growth request with slack. How long would it actually take to unblock: a quick answer versus a real session. Is this a shape of question you've answered before, which is a signal to build something reusable rather than repeat yourself.

Route, don't just prioritize. Not everything needs to be you specifically. A growth-oriented question might be better answered by a peer with more direct expertise, freeing your time for things only you can unblock.

Time-box and communicate the SLA out loud. "I can give you twenty minutes now on the blocking piece; let's put the design question on tomorrow's slot" sets expectations honestly instead of leaving people guessing whether they've been deprioritized.

Build reusable async artifacts for repeat patterns. When you notice you've answered a variant of the same question more than once, that's the signal to invest in a recorded walkthrough, a short playbook, or an FAQ instead of repeating the synchronous session a third and fourth time. This is a genuinely different lever from prioritization: it lets you scale personalized-feeling help without your 1:1 time growing linearly with the number of people asking.

Maintain the artifacts deliberately. A playbook or recording that goes stale is worse than not having one, because people trust it and get misled. Whoever owns it, you or a rotating owner, needs a cadence to revisit and refresh it, not a one-time write-and-forget.

Worked example

You're juggling your own deliverable alongside three mentees asking for time at once: one is genuinely blocked, one has a growth-oriented design question with no real time pressure, and one is asking a version of a question you've now answered several times before. You give the blocked person a focused twenty minutes to unblock them. You schedule the design question for a defined slot the next day rather than squeezing it in now. And instead of walking the third person through it live again, you point them to an existing recorded walkthrough, or if one doesn't exist yet, you record a short one this time specifically because you can already tell it'll come up again.

Trade-offs and pitfalls

Treating every request as equally urgent burns you out and, worse, under-serves the person with the actually urgent need, because everyone gets a diluted amount of attention instead of the right amount going to the right place.

Over-investing in artifacts nobody maintains creates a different failure: a stale playbook actively misleads people and erodes trust faster than simply not having documentation and telling people to ask.

Prioritizing strictly by who's loudest or most urgent can systematically starve quieter mentees who don't escalate assertively. It's worth periodically checking who you haven't heard from, not just responding to who's asking.

If you find yourself using "I'll make you a doc" as a polite way to avoid ever giving someone real synchronous time, that's usually a sign the mentee queue has outgrown what one person can reasonably carry, and it's a resourcing conversation to raise with your own manager, not something to keep absorbing indefinitely.

High-level approach: translate the business priority ("reduce fraud false positives") into measurable goals, decompose into data/model/runtime workstreams, define acceptance criteria tied to business KPIs, assess risks, and estimate effort so engineering and stakeholders can prioritize.

Goal / success metric:

• Reduce false positive rate (FPR) by X% (e.g., from 4% to 2%) while keeping detection rate (TPR) within ±1% of current.
• Business constraint: no >5% increase in investigation latency; cost budget delta <= $Y/month.

Example breakdown

1. Data (Owner: Data Engineering) — Task: Improve feature quality & label hygiene

• Subtasks:
  • Audit current labeled dataset for label noise and sampling bias; produce report.
  • Add new feature pipelines (behavioral sessionization, device fingerprint enrichments).
  • Implement automated data validation (tests + monitoring).
• Acceptance criteria:
  • Label noise reduced to <2% in sampled audit; new features available in training and prod ETL.
  • Data validation alerts trigger on schema drift.
• Risks: Poor label availability; privacy/compliance constraints.
• Estimate: Medium (3-4 wks)

2. Model (Owner: ML Engineering) — Task: Retrain & calibrate model with cost-sensitive objective

• Subtasks:
  • Train candidate models incorporating new features and class-weighted loss or focal loss.
  • Implement probabilistic calibration and threshold optimization by expected cost (FP vs FN).
  • Run A/B offline evaluation vs baseline, with business-cost simulation.
• Acceptance criteria:
  • Offline: FPR reduced by target X% at equal or better TPR; expected cost metric improves.
  • Calibration Brier score improved by Y%.
• Risks: Overfitting, distribution shift, longer training time.
• Estimate: Medium-High (4-6 wks)

3. Runtime / Production (Owner: SRE/Platform) — Task: Safer inference & human-in-loop routing

• Subtasks:
  • Add model explainability scores and confidence band; route low-confidence positives to manual review.
  • Implement canary rollout, metric dashboards (FPR/TPR, latency, reviewer load), and rollback playbook.
  • Add throttling or delayed-accept for uncertain decisions.
• Acceptance criteria:
  • Canary shows no regression on TPR, FPR meets target in canary population, latency within SLA.
  • Dashboards populated and alerting configured.
• Risks: Increased manual review load, latency spikes.
• Estimate: Medium (3-5 wks)

Cross-cutting items

• Monitoring & Alerts: Define SLOs, build dashboards, alert on FPR, TPR, inference latency, reviewer queue depth. (Small, 1-2 wks)
• Compliance & Privacy Review: Ensure new features meet data-use policies. (Small, 1 wk)

Risk assessment summary

• Data risk: high impact if labels/features bad — mitigate via audits and fallbacks.
• Model risk: medium — mitigate with conservative thresholds, canary, and AB tests.
• Production risk: medium-high — mitigate with manual-review routing, throttles, and rollback playbooks.
• Business risk: low if we enforce guardrails (latency, cost caps).

Prioritization & next steps

• Immediate: Data audit + monitoring + compliance check (uncovers blockers).
• Parallel: Model experiments; plan canary deployment once candidate passes offline cost metric.
• Deliverables in 8–12 weeks for a controlled rollout, with incremental checkpoints for stakeholder sign-off.

1. Proposal-to-win conversion rate (Lag)

• Why: Measures effectiveness of solutions in closing deals.
• How to measure: (# of opportunities where I authored/owned solution that closed) / (total opportunities I supported). Data from CRM (Salesforce) + internal opportunity logs.
• Cadence: Monthly (trend and root-cause analysis).

2. Time-to-deliver first solution draft (Lead)

• Why: Speed of response impacts sales momentum.
• How: Avg hours/days from opportunity assignment to first complete architecture doc. Source: ticketing system (Jira), versioned docs in Confluence or Git.
• Cadence: Weekly (identify bottlenecks).

3. Technical objections per opportunity (Lead)

• Why: Frequency of unresolved technical risks shows design gaps or misalignment.
• How: Count of unique technical objections logged in sales calls / opportunity. Sources: CRM call notes, objection-tracking spreadsheet.
• Cadence: Weekly (address recurring objections).

4. Architecture rework rate (Lead/Lag)

• Why: High rework means requirements misunderstanding or poor solution fit.
• How: % of solutions requiring >1 major revision post-PE review. Source: doc version history + review comments in Confluence/PRs.
• Cadence: Weekly for immediate pipeline; monthly for trend.

5. Customer satisfaction / technical NPS (Lag)

• Why: Measures perceived value and credibility post-engagement.
• How: Short post-delivery survey (1–2 Qs) and tNPS aggregated by engagement. Source: Survey tool (Typeform) + CS feedback.
• Cadence: Monthly.

6. Implementation readiness score (Lead)

• Why: Ensures solutions are actionable for engineering and reduce handoff friction.
• How: Checklist-based score (requirements completeness, runbook, infra cost estimate, security review). Tracked in Confluence/Jira.
• Cadence: Weekly for active deals; monthly aggregated.

7. Revenue-at-risk reduced / technical risk mitigation rate (Lag)

• Why: Quantifies impact on protecting pipeline value.
• How: Sum of pipeline $ where technical risks were identified and mitigated by my actions / total pipeline $ supported. Source: CRM risk fields + mitigation logs.
• Cadence: Monthly.

Prioritization: Weekly reviews focus on lead indicators that unblock current opportunities (time-to-draft, objections, readiness, rework). Monthly reviews focus on lag indicators and trends (conversion, tNPS, revenue-at-risk) to show strategic impact.