Consultative Discovery and Requirements Gathering Questions

Direct answer

"Zero downtime in two weeks" is two demands that may conflict. Here the migration means moving a live payment service to new infrastructure, and the cutover is the moment traffic switches from the old system to the new one. Availability is the share of time the service works for users. I would first find out what zero downtime has to protect (which users, which functions, how long an interruption is tolerable), then what two weeks is tied to, then lay out the options with their risk and cost. I would take it back as a choice, not a refusal: "Here is what is achievable by that date and what it costs to go further."

Exploring what it has to mean

• "Which services and users must stay up? Is read-only access during cutover acceptable?"
• "What is the longest interruption nobody would notice or complain about?"
• "What happens at 2 a.m. versus at peak? Are there blackout periods (times when changes are forbidden, such as month-end)?"
• "Why two weeks? A contract, an event, a licence expiry, a cost?"
• "What is the rollback requirement (the ability to switch back to the old system) if something fails?"

Feasibility, with the arithmetic

Availability numbers translate into allowed downtime. For a 30-day month (43,200 minutes):

A 99.999% payment cutover across clouds leaves about 26 seconds in a month. 99.9% is often called "three nines" and 99.999% "five nines". A single failed deployment can use that up, so the plan needs a staged cutover (moving traffic in steps rather than all at once), rollback rehearsed, and real-time monitoring.

Dependencies cap the target. A migration adds dependencies: the new cloud's services, a network link, a partner API. Suppose a client expects 99.99% overall but a dependency fails in 5% of hours (an exaggerated, illustrative figure chosen so the effect is easy to see). If every request needs that dependency, the parts are "in series": the whole works only when every part works, so availabilities multiply. 0.9999 x 0.95 = 0.949905, about 94.99%, so the dependency alone caps the system near 95%. Two independent copies reduce the failure to 5% x 5% = 0.25%, giving 99.75% (this assumes the failures are independent). So the answer is design change (redundancy, fallback, retries), not a promise.

Options I would bring back

1. Phased migration in cohorts (separate groups of users moved in turn; for 100,000 users: first 1,000, then the next 10,000, then the next 50,000, then the remaining 39,000), with the ability to roll back each cohort.
2. Read-only window (a few minutes when users can view but not change data), announced in advance.
3. Full dual-running (old and new systems both live and kept in sync, so traffic can move with no gap), which needs more time and budget.

My recommendation, for the stated two weeks: option 1 or 2 with a fixed agreed maximum interruption, and option 3 only if the VP funds more time. What would change my call: a hard legal or contractual reason for no interruption at all.

Capacity or growth uncertainty

If traffic may grow suddenly (viral growth), a capacity shortfall during the cutover is downtime too. Ask for plausible bounds, not one number. Illustrative: today 200 requests per second, low case 300, expected case 600, high case 2,000. Then agree what degrades first if the high one occurs, for example new signups are queued before payments slow down.

Taking it back to the VP

Use a one-page summary: what "zero downtime" is interpreted as, three options with date, risk and cost, my recommendation, and the decision needed by a given day. Lead with what we can deliver, then what each extra increment costs.

Trade-offs and pitfalls

• Saying "impossible", which ends the conversation.
• Promising the number without a rollback plan.
• Forgetting that dependencies set the ceiling.
• Different people reading "downtime" differently: always agree the measurement point.

Direct answer

"Move faster" is rarely about speed in general. It usually points at a specific event, promise or pressure. I would do homework first, then ask about outcomes and events (not "why are you rushing?"), reflect back what I heard, and offer options that trade scope, date and risk. The aim is to turn "faster" into a concrete constraint such as a date, an audience and a minimum deliverable.

Step 1: do homework before the conversation

Check calendars and planning documents for dates the initiative may be tied to: board meetings, budget cycles, partner announcements, customer commitments, a regulatory deadline. Ask a peer or the executive's chief of staff what has changed lately.

Step 2: ask about events and consequences

• "What prompted this now?"
• "What happens if we hit the date, and what happens if we miss it?"
• "Who is waiting on this, and what did they expect?"
• "If we could only deliver one piece by then, which piece?"
• "What, outside our team, is this date anchored to?"

These are open questions about events (each one asks for a story, a name or a date, not a yes or no), so the executive can share a constraint without feeling interrogated. Repeated "why" questions to a senior person tend to sound like pushback.

Step 3: pin down what "faster" means

Ask "faster than what?" and "by when, for whom?" Then reflect back: "So the real need is a working demo for three partner use cases by week six. Is that right?"

Step 4: offer options with trade-offs

Worked example (illustrative)

The executive says "move faster" on a partner integration planned for ten weeks. My questions reveal a partner announcement in six weeks, and the executive told the partner the integration would be live. The real constraint is a demonstrable integration for three use cases at week six, not a ten-week build in six. I propose a demo-grade version (good enough to show a partner, not yet safe for real customers) of those three flows by week six, with hardening afterwards, and name the risk of shipping something not production-ready.

Pitfalls

• Answering with a capacity speech before understanding the pressure.
• Assuming politics or guessing the motive.
• Promising speed without a changed scope or a named trade-off.

Direct answer

Before touching the code, I would find out what the module does for the business, who depends on it, and what has gone wrong before. I talk to the original author if they are reachable, the people on call, the downstream users, and the business owner. I write down behaviours, dependencies, owners and risks, and I pin current behaviour with tests, so any later change is measurable.

Who I talk to, in order

1. The business or product owner: what it is for, what breaks if it fails, how often, how badly.
2. The original author or earlier maintainers, even if they left (the version history shows who touched it, and when).
3. The people on call or in support: past incidents, the workarounds, what pages them at night.
4. Downstream consumers: teams, scripts or reports that read its output or call it.
5. Finance, compliance or operations, if it touches money or regulated data.

What I ask

• "What does it do, in one sentence, and what must never go wrong?"
• "What did it look like when it last broke? What fixed it?"
• "What is odd in it that looks like a bug but is deliberate?"
• "Who calls it, and what do they assume about its output?"
• "What runs on a schedule, and what happens at month-end or peak times?"
• "What would you not change without a long conversation?"

What I write down

A living note: purpose, owners, inputs and outputs, dependencies (including scheduled jobs and configuration), known incidents, the odd-but-intentional behaviours, and open questions. I also record what I observed (logs, the live behaviour) separately from what people told me.

Before changing anything

Capture current behaviour with characterization tests (tests that record what the code does today, correct or not), check monitoring exists, and agree a way to roll back.

Worked example (illustrative)

A billing module rounds amounts per line instead of per invoice. The author's note says nothing. A support engineer says finance reconciles to the penny and complained once. The rounding is intentional. I record it as "behaviour: per-line rounding, owner: finance, evidence: ticket and support recollection", add a test that fixes it, and avoid "cleaning it up".

Trade-offs and pitfalls

• Reading code alone misses the business meaning.
• Relying on one person's memory. Cross-check with logs and a second source.
• Treating odd behaviour as a bug before asking.
• Starting a refactor without tests or a rollback path.