Staff Engineering Manager Interview Preparation Guide - FAANG Standards

6‑Month Onboarding & Coaching Plan (Engineering Manager perspective)

Goals (0–6 weeks)

• Ramp on team, tech, roadmap, stakeholders.
• Build trust via weekly 1:1s, attend all team ceremonies.
• Key skills: active listening, feedback loops, priority-setting, basic hiring and performance processes.

Month 2–3 (Skill building + early wins)

• Teach: delegation, coaching conversations, stakeholder communication, sprint planning and risk management.
• Assign early win: own a small cross-team deliverable (release or hiring panel) with measurable target (on-time delivery, candidate interview score ≥4/5).
• Mentorship: pair with senior EM for weekly shadowing; peer support via biweekly EM peer group.
• Checkpoint at 3 months: 1) 1:1s established (90% cadence), 2) delivery of early win, 3) team pulse score improved or stable. Evaluate via direct feedback, OKRs, and stakeholder survey.

Month 4–6 (Scaling leadership)

• Teach: developmental performance reviews, career ladders, conflict resolution, metrics-driven planning.
• Gradually shift ownership of technical reviews to ICs; focus on strategy and team health.
• Continue mentorship; add quarterly skip-levels.

6‑month evaluation

• Success metrics: retention/engagement change, on-time delivery rate, quality (bugs/post-release), hiring pipeline health, 360 feedback showing clear improvement in people management.
• If gaps remain: targeted coaching plan (role-play feedback, formal management training, stretch assignments).

Direct answer

Horizontal scaling means running more copies of a service side by side (more instances behind a load balancer) so the same work is split across a wider set of machines. Vertical scaling means making one existing machine bigger (more CPU, memory, or disk on the same box). As a technical product manager, the question I'd push engineering on isn't "which is better" in the abstract; it's "which one fits this specific service's constraints right now," because the two options carry very different cost, risk, and speed-to-ship trade-offs.

Structured elaboration

Definitions, concretely:

• Horizontal scaling: going from 1 app instance to 5 instances, each handling a fifth of the traffic, coordinated by a load balancer.
• Vertical scaling: taking that same single instance and moving it to a larger machine, for example doubling its CPU and memory.

Scenario favoring horizontal: a multi-tenant API serving many short, independent requests.

• Cost: higher baseline (more machines running), but better cost efficiency per request once traffic is high and steady.
• Downtime risk: lower; instances can be replaced one at a time without taking the whole service down.
• Operational complexity: higher upfront; needs load balancing and service discovery in place, which is infrastructure work, not a business decision by itself.
• Observability: needs request-level and fleet-level visibility (how is load distributed across instances), not just one machine's health.
• Developer experience: scaling is "add another instance," which is fast to execute once the infrastructure exists, but the service has to be stateless first (see below).

Scenario favoring vertical: a legacy or stateful component that can't easily be split, such as a single-process cache or an analytics-ingest service holding state in memory that isn't designed to be split across machines.

• Cost: a bigger machine has worse cost-per-unit-capacity at the high end, but it's often the fastest way to buy headroom without an engineering rewrite.
• Downtime risk: higher; resizing frequently requires a restart, and there's a single point of failure the whole time.
• Operational complexity: lower day-to-day (one machine to watch), but scaling further is capped by the largest machine available and harder to automate safely.
• Observability: narrower, focused on that one machine's CPU, memory, and health.
• Developer experience: no code changes required, which is attractive under deadline pressure, but it's a deferral of the real fix, not a substitute for it.

Signals that should trigger a move from vertical to horizontal, even if the team's instinct is to keep resizing:

1. You're already near the largest machine size available, or the next size up costs disproportionately more for a shrinking capacity gain, so vertical simply runs out of room as a lever.
2. A resize requires downtime, and that downtime window is now colliding with real user traffic instead of fitting inside a quiet maintenance period, meaning the "safe" vertical option has stopped being safe.
3. Growth has become spiky rather than steady. A single bigger machine can absorb a slow, predictable climb, but it can't add capacity fast enough for short-lived spikes the way a set of instances that scale out and back in can.

User-visible impact during the transition. Moving from one big machine to several smaller ones is not free for users if the service was holding state in memory (a logged-in session, an in-progress upload). Unless that state is externalized to a shared store first, users can be logged out or lose in-progress work mid-cutover. There is also typically a short window of uneven response times while new instances warm up behind the load balancer, before their health checks stabilize.

How I'd influence engineering's choice:

• Translate the business need into concrete decision criteria: expected request volume, response-time targets, cost ceiling, and how soon this needs to ship.
• Ask directly whether the service is stateless (safe to run many identical copies) or stateful (holds data on one machine that would need to move first); this single question usually decides which path is realistic, more than a general cost debate does.
• Propose starting with the cheapest safe option (often vertical, if there's headroom left) while scoping the refactor that horizontal scaling requires, rather than treating it as an all-or-nothing choice.
• Get explicit agreement on a timeline: at what point does the team commit to the horizontal path even if vertical is still technically an option, so the decision doesn't get re-litigated every time a resize buys another few months.

Worked example

A concrete story: a developer-platform API starts on a single, reasonably large instance. Over several months, traffic grows steadily and the team resizes the instance twice, each time buying a few months of headroom with a short maintenance-window restart. On the third approaching resize, the team discovers they're already near the largest instance size the cloud provider offers for that machine family, and the next tier up costs far more for a proportionally smaller capacity increase. That's the vertical-headroom-exhausted signal firing. At the same time, product has just launched a feature that drives short, unpredictable traffic spikes around specific events rather than steady growth, which is the spiky-growth signal. Together, these push the team to invest in making the service stateless (moving session data out of the process and into a shared store) so it can run behind a load balancer as multiple instances, even though that refactor takes real engineering time the earlier vertical resizes didn't.

Trade-offs & pitfalls

• Horizontal scaling isn't free just because it's more "modern." It requires the service to be stateless first; skipping that step and scaling horizontally anyway produces inconsistent behavior (a user's session data only living on one of several instances) that is worse than staying vertical until the refactor is actually done.
• A string of "just one more vertical resize" decisions can quietly become the expensive path, if nobody is tracking how close the team is to the largest available machine size.
• The transition itself has a user-visible cost that's easy to leave out of the plan. Budgeting the refactor without budgeting for the state-externalization work, or without warning users about a rockier-than-usual cutover window, turns a well-reasoned architecture decision into a rough surprise for customers.
• The right metrics for validating this decision are the same ones that should have driven it: response-time percentiles (the response time under which a given percentage of requests complete), utilization per instance, cost per request, and how often scaling events happen; a decision that isn't being watched with these after the fact is a guess, not a validated choice.

Direct answer

Decide whether to add a cache by measuring the actual read pattern (how often the same value is requested, how expensive it is to produce, and how much staleness is tolerable), not by defaulting to caching every endpoint; a cache with a low repeat-read rate or zero staleness tolerance is a cost with no real benefit.

Structured elaboration

• Signals to collect: request rate for the same key/query (does the same data actually get read repeatedly, or is nearly every read unique), the cost of producing the value (a fast, cheap lookup gains little from caching even if repeated), and the data's staleness tolerance (how quickly must a change be visible).
• Tests to run: a load test comparing latency and backend load with and without a proposed cache, and a profile of the actual query/computation to confirm it is genuinely a meaningful cost worth caching against.
• Criteria for choosing a cache tier: an in-process cache fits data that is cheap to duplicate per instance and does not need cross-instance consistency; a shared cache (Redis) fits data that benefits from being consistent across instances or too large to duplicate per instance; a content delivery network (CDN) fits public, non-personalized content that benefits from being close to users geographically.
• Cost: weigh the infrastructure and operational cost of adding a caching layer (a new dependency to monitor, secure, and keep available) against the actual load/latency benefit measured above; a marginal benefit may not justify the added complexity.
• Operational complexity: caching adds invalidation logic, a new failure mode (cache unavailable), and another thing to monitor; these costs are real even when the caching decision is otherwise sound, and should be weighed explicitly.
• Correctness: if the data's staleness tolerance is effectively zero (a value that must always reflect the absolute latest state, with no acceptable delay), caching adds risk without benefit, since any caching mechanism introduces at least a small window of potential staleness.

Worked example

An endpoint returning a real-time stock quote, requested uniquely per symbol per user with essentially no repeat reads within any meaningful window, and requiring zero staleness tolerance: this fails on both the "does the same value get read repeatedly" test and the "can staleness be tolerated" test, making it a poor caching candidate regardless of how expensive the underlying computation is. Contrast with a product description, read thousands of times per hour by different users for the same handful of popular items, changing rarely: this passes both tests clearly.

Trade-offs and pitfalls

Caching by default, without measuring the actual read-repetition rate, either wastes cache capacity on data that gets no benefit or, worse, introduces a staleness risk on data that could not tolerate it; always start from measurement, not habit. The decision is not binary per endpoint; the same service can have some data that benefits enormously from caching and other data (even on the same page) that should never be cached, and treating the whole endpoint uniformly misses that nuance.

Overview (90-day, prioritized experiments)

Goal: reduce time-to-meaningful-contribution from 3–4 months → 6–8 weeks. Measure: Time-to-first-merged-PR, Time-to-ownership (first small feature), New Hire NPS (onboarding), Mentor touchpoints, First 90-day retention.

Phase 0 (Week 0–2) — Quick wins

1. Structured Day-1 + 2-week checklist

• Hypothesis: Clear, role-specific checklist cuts administrative friction so hires start coding sooner.
• Owner: Eng Manager (you) + HR
• Expected improvement: -20% time-to-first-PR
• Acceptance: 90% hires complete checklist by day 2; median time-to-first-PR ≤ 14 days

Phase 1 (Week 1–6) — Ramp experiments (priority)
2) Starter-project + automated infra sandbox

• Hypothesis: A runnable microtask and pre-built sandbox accelerates meaningful learning.
• Owner: Senior Eng + DevOps
• Expected: -30% time-to-first-merged-PR
• Acceptance: 75% complete starter project within 10 days; sandbox uptime 99%

3. Mentor-backed 2-week pairing sprints

• Hypothesis: Focused pairing with assigned mentor reduces context ramp.
• Owner: Team Lead / Mentor coordinator
• Expected: -25% time-to-ownership
• Acceptance: 3 paired sessions/week; mentee rates pairing as “helpful” (NPS ≥ 8)

Phase 2 (Week 4–12) — Process and culture
4) Role-specific learning path + tracked milestones

• Hypothesis: Learning path with measurable milestones accelerates autonomy.
• Owner: Tech Lead + L&D
• Expected: -20% time-to-ownership; +15 pts onboarding NPS
• Acceptance: 80% hit milestone 1 & 2 by week 6

5. Codebase walkthroughs + live architecture session

• Hypothesis: Shared mental model reduces PR review cycles and rework.
• Owner: Principal Engineer
• Expected: -15% PR review time; -10% early bug rate
• Acceptance: Sessions held biweekly; avg PR review time ≤ 48hrs

6. Hiring & role-fit feedback loop

• Hypothesis: Better role descriptions and hiring calibration reduces mismatch.
• Owner: Eng Manager + Recruiting
• Expected: +10% retention at 90 days
• Acceptance: Drop in “role mismatch” feedback by 50%

Roadmap notes:

• Run experiments concurrently where low effort (checklist, sandbox).
• Track weekly dashboard: median time-to-first-PR, time-to-ownership, onboarding NPS, mentor hours.
• Stop/scale decision at 30/60/90 days based on acceptance criteria.

Direct answer
Speaking up when you notice leadership or business behavior running against a stated principle, or discovering a values-violating practice yourself, is a career-risk-aware judgment call. The strongest answers show that you assessed the risk of speaking up honestly, chose a channel and framing proportionate to the issue, and can describe a concrete outcome, even a partial or mixed one.

Structured elaboration

• Assessing: what made you decide this was worth raising rather than letting go, whether it was a one-off or a pattern, and how material the impact was.
• Channel: who you raised it with first, and why (a direct manager rather than jumping straight to a skip-level or a formal channel, unless the severity warranted it).
• Framing: leading with concrete impact or evidence rather than an accusation, which is what makes an objection hearable rather than confrontational.
• Outcome: what actually changed, or didn't. An honest "it partially worked" or "nothing changed and here is what I did next" is a legitimate and often more credible answer than a perfectly clean resolution.
• The self-discovered variant: if you found the issue yourself, in your own work rather than someone else's, the same shape applies, but the story should show you didn't just quietly fix it and move on. Escalating a self-discovered gap through the proper channel, rather than silently patching it, is the part that demonstrates the competency.

Worked example
While reviewing a data-handling process they had built, a candidate noticed it retained a category of information longer than the stated retention policy required. Rather than quietly deleting the excess and saying nothing, they flagged the specific gap to their manager and the relevant policy owner along with a proposed fix, since a silent fix would have hidden that the gap had existed and might recur elsewhere. The fix was implemented, and the review also surfaced one other process with the same gap that would not have been found otherwise.

Trade-offs and pitfalls
Escalating everything regardless of materiality can read as poor judgment rather than integrity; the strongest answers show calibration about what is worth raising. An outcome of "nothing changed" is realistic and acceptable, but the answer should still show a proportionate attempt, not that you gave up after one try or escalated aggressively without cause. Framing a self-discovered gap as "I caught someone doing something wrong" when the honest version is closer to "I found a gap in a process I owned" overstates the story; the self-discovered version is common and doesn't need to be dressed up as catching someone else.

Direct answer
Choose synchronous calls when the caller genuinely needs the result before it can proceed and can tolerate the callee's latency and availability becoming part of its own; choose asynchronous messaging when the caller can proceed without waiting for the result, or when decoupling the caller's availability from the callee's is more important than getting an immediate answer.

Structured elaboration
Latency: synchronous calls put the callee's latency directly on the critical path of the caller's response time, and a chain of several synchronous calls compounds that (each hop adds its own latency, and the caller waits for the slowest one). Asynchronous messaging removes the callee's latency from the caller's response time entirely, since the caller doesn't wait for the message to be processed. Coupling: synchronous calls create a direct availability dependency (if the callee is down, the caller's request fails or blocks); asynchronous messaging decouples availability, since a message can sit in a queue until the consumer is back up, at the cost of the consumer's effect on the world happening later, not immediately. Error handling: a synchronous call gives the caller an immediate, explicit success-or-failure signal it can act on right away (retry, show an error, fall back); an asynchronous message's failure needs a different mechanism entirely (a dead-letter queue, a retry policy on the consumer side, and some way for the ORIGINAL caller to eventually learn the outcome if it needs to, since it already moved on). Operational implications: synchronous chains make on-call debugging comparatively straightforward (a single request trace shows the whole call chain and where it failed) but make service-level objectives (SLOs, the reliability/latency targets a service commits to) harder to hit as the chain gets longer, since the end-to-end latency and availability are the product of every hop's; asynchronous flows make individual components easier to keep within their own SLOs independently, but debugging "why didn't this eventually happen" requires tracing through queues and consumers rather than a single linear request.

Worked example
A checkout flow illustrates both: charging a customer's card needs a synchronous call to the payment processor, because the checkout page genuinely can't tell the customer "success" until the charge is confirmed, and the caller needs an explicit success-or-failure signal to act on immediately. Sending the order-confirmation email, by contrast, is a good fit for asynchronous messaging: the checkout flow doesn't need to wait for the email to send before showing the customer a success page, and decoupling it means an email-service outage doesn't block checkout at all, only delays the email itself.

Trade-offs and pitfalls
The most common mistake is defaulting to synchronous calls for everything because it's simpler to reason about in the moment, which quietly makes every downstream service's availability and latency a dependency of the caller's SLO, even for work that didn't need an immediate answer. The opposite mistake is making something asynchronous that the caller actually needed an immediate answer for (like the payment charge above), which either forces an awkward polling loop on the caller's side or produces a confusing user experience where the system says "success" before it actually knows whether the operation succeeded.

Escalation indicators, made explicit. I look for a combination of: the decision crosses into a domain I don't have standing authority over, such as legal or compliance; the blast radius or reversibility exceeds what I'm personally authorized to accept, for example real regulatory exposure or user-trust risk above a threshold; a peer and I have genuinely examined the same evidence and still disagree, which signals the ambiguity won't resolve with more of my own analysis; and the cost of being publicly wrong, legally, reputationally, or safety-wise, meaningfully exceeds the cost of the delay that escalating causes. Any one of these alone might not be enough; the combination is what triggers escalation rather than deciding it myself.

A worked example. I was designing the 'connect your bank account' flow for a budgeting feature that used a third-party aggregator to pull transaction data. The product spec said 'make it as frictionless as possible,' but it was genuinely ambiguous whether the consent screen needed to explicitly name which data fields (transaction history, account balance, account holder name) would be shared, versus a generic 'connect your bank' button. This sat in financial data-sharing territory with real regulatory exposure, and the downside of guessing wrong, a dark-pattern-consent complaint or a media story, was high and hard to walk back once shipped. That combination, regulatory ambiguity plus a high, hard-to-reverse downside, outside my design authority to accept alone, is what triggered escalation rather than my own judgment.

Whom I involved. Legal and privacy counsel, the security lead, and the PM as the ultimate decision owner.

How I packaged the evidence and impact. Rather than asking an open-ended 'is this okay,' I brought two annotated flow mockups side by side (frictionless versus explicit field-level disclosure) with the actual copy, a measured data point from a prior A/B test on a comparable disclosure step (adding a data-disclosure interstitial had cost a 6-point drop in completion in that earlier test), and the specific regulatory question spelled out in writing: does the applicable law require itemized, field-level disclosure for aggregator-based bank linking, or is general consent sufficient.

Synthesizing differing opinions. Legal's first instinct was maximal, itemized disclosure. Security cared more that the user clearly understood a named third party was involved than about itemizing every field. Design wanted to hold the flow to one screen. I ran a short working session where each side named their actual must-have versus their nice-to-have: legal's must-have was naming the aggregator and the purpose of sharing; security's must-have was making the third party visible, not itemizing every field; design's must-have was a single screen. The overlap fit entirely on one well-designed consent screen naming the aggregator (a hypothetical vendor here) and three data categories, without a multi-step legal itemization, and that became the shipped design.

Outcome. The one-screen consent step shipped naming the aggregator and the three data categories. Completion dropped 3 points (91% to 88%) versus the frictionless mockup's projected number, a cost leadership judged acceptable for compliance certainty, and the pattern became the reused template for two later integrations, avoiding a repeat of the same escalation.

What separates a strong answer from a mediocre one. A mediocre answer here is 'I just asked my manager,' with no named indicator for why this specific ambiguity needed outside input, no evidence brought into the room, and no method for reconciling disagreement beyond 'we talked it through.' It reads as deferring judgment rather than exercising it. The strong version names the specific trigger, brings concrete artifacts and a specific written question rather than a vague ask, and has an explicit method (must-have versus nice-to-have) for resolving disagreement rather than hoping consensus emerges.

A second, shorter example. A monthly revenue dashboard showed an unexplained 15% spike right as it was being cited in an active board-deck draft. The time-sensitivity and the cost of a wrong number in front of the board meant full root-causing wouldn't finish before the deck deadline. I escalated with a one-page summary: the anomaly, three ranked candidate causes from a quick 30-minute check on each, and a recommended interim number excluding the most likely affected segment, clearly footnoted. The finance lead and deck owner reviewed it, the deck shipped with the footnoted interim number, and the actual cause (a duplicated row double-counting one product line) was confirmed two days later, matching the flagged hypothesis exactly.

Direct answer

I distinguish by pattern, not just output level. Burnout or disengagement usually shows up as a broad decline across previously strong areas, paired with a real change in energy or affect (a person's visible mood and emotional expression). A skill gap is usually narrower, tied to a specific type of task, and doesn't come with that affect change. Once burnout is suspected, the shift is from output-focused coaching to a wellbeing-first conversation and workload adjustment.

Distinguishing signals

The diagnostic move

Because the same output pattern (missed deadlines, lower-quality work) can come from either cause, guessing from behavior alone risks the wrong intervention. More skill-focused coaching aimed at someone who's actually burned out just adds pressure. The reliable move is to ask directly and non-accusatorially rather than only inferring, since it's the fastest way to tell the two apart.

What to do differently once suspected

Shift the conversation from task correction to workload and wellbeing. Reduce scope or redistribute urgent items in the short term rather than expecting normal output immediately. Check in more on process and how they're doing than on deliverables for a while. Point toward available support resources where they exist. Avoid escalating straight to a formal performance conversation while this is unresolved, but also avoid treating it as an indefinite excuse, set an actual review point to reassess rather than letting it run open-ended.

Worked example

A mentee whose work had been consistently strong started slipping across several unrelated tasks, not just one. The decline was recent and came with noticeably less participation in discussions, which pointed away from a narrow skill gap. A direct, private conversation surfaced an unsustainable workload building up over recent weeks. The short-term adjustment was reprioritizing their task list and explicitly deprioritizing anything non-urgent, with a check-in scheduled two weeks out to see whether things had actually improved rather than assuming they had.

Trade-offs and pitfalls

A common mistake is treating every dip in output as a skill or effort problem and escalating straight to a formal process. The stronger approach separates "can't" (skill), "won't" (motivation or disengagement), and "can't sustain right now" (burnout), because they call for different responses, while staying alert that a genuine performance issue can coexist with real burnout, one doesn't automatically rule out the other. It's also a pitfall to assume burnout excuses declining output indefinitely: there still needs to be a check-in cadence, and if it doesn't resolve, it may need to go beyond what a mentor alone can fix, involving a manager or people-ops rather than absorbing an open-ended situation solo.

For a regulated financial customer, the three approaches trade off differently on exactly the dimensions that regulation cares most about: auditability, revocation speed, and operational maturity required to run them safely.

The three approaches

A, a centralized Vault with dynamic credentials. HashiCorp Vault (or an equivalent) issues short-lived, scoped credentials on demand rather than storing static secrets; every issuance is logged centrally, and a compromised credential expires on its own within minutes even if nobody notices the compromise. Operational complexity is the highest of the three: running Vault itself well (unsealing, high availability, backend storage) is a real operational commitment, and every pipeline needs a supported authentication method into it (OIDC (OpenID Connect), AppRole, or similar). Developer experience has the highest upfront cost of the three: a team has to integrate its pipeline with Vault's auth method before it can fetch a single secret, but once that integration exists, day-to-day use is transparent (a developer never sees or handles the actual credential value at all).

B, platform-native sealed secrets or cluster secret stores. Secrets are encrypted at rest and only decryptable by the specific cluster or platform they're deployed to (Kubernetes sealed-secrets, or a cloud-native equivalent). Operational complexity is lower than running Vault, since the platform already exists and this uses its native mechanism, but rotation is typically a manual or semi-automated process rather than the always-short-lived credentials of approach A, and auditability depends heavily on the platform's own audit logging maturity. Developer experience is generally the easiest of the three to adopt, since it reuses tooling (kubectl, the platform's own CLI) developers already use for everything else, at the cost of the weaker rotation story above.

C, encrypted variables stored in the CI system itself. The lowest operational complexity of the three (no additional infrastructure to run), but the weakest security guarantees: the CI system itself becomes a single point of both storage and access control, credentials are typically long-lived, and audit trail quality varies widely by CI provider. Developer experience is the simplest of all three to set up (paste a value into the CI system's own secrets UI, reference it by name), which is exactly why teams default to it even though it's the weakest option on every other dimension.

Recommendation for a regulated financial customer

Approach A. Dynamic, short-lived credentials directly satisfy the kind of access-review and least-privilege requirements a financial regulator will ask about (every credential issuance is individually logged and every credential expires whether or not it's ever explicitly revoked), and the centralized audit trail is exactly the evidence an auditor wants to see. The higher operational cost, including the steeper initial developer-experience cost of integrating every pipeline with Vault's auth method, is the honest trade-off: this customer needs the operational maturity to run Vault (or accept a managed Vault offering) reliably, including its own high-availability and disaster-recovery story, since an outage in the secrets layer becomes an outage in every pipeline that depends on it.

What would change the recommendation

For a smaller, less-regulated customer with a single small platform team, approach B or even C might be the right call precisely because the operational cost of running Vault well, and the developer-experience cost of onboarding every pipeline to it, would exceed the actual risk reduction it buys; the recommendation is a function of the customer's regulatory obligations and operational maturity, not a universal ranking of the three options.

I would frame the discussion around user impact, risk, and reversibility. A workaround is a temporary fix that reduces pain now, while the root issue is the underlying cause we still need to solve. I would ask: how many users are affected, how severe is the problem, and how risky is the workaround itself?

If the workaround is low risk and reversible, I would lean toward shipping it now and scheduling the root fix immediately after. For example, if users are blocked by a broken validation rule and we can safely relax it, I would ship the workaround, monitor errors, and commit to the deeper fix in the next cycle. If the workaround could corrupt data or create a bigger support burden, I would slow down and fix the root issue first.

I would make the decision explicit, document the trade-off, and assign an owner for the follow-up fix. That way the team is not pretending the workaround is the final answer, and users get relief as soon as it is safe to do so.