Structured Problem Solving and Decomposition Questions

Direct answer

Split by one dimension only, the kind of deliverable each workstream produces, so every task has exactly one home. I would use six workstreams: discovery and planning, cloud foundation, workload migration, operations readiness, decommission and exit, and program and change management. Then order them by the critical path (the longest chain of dependent work, which sets the earliest finish date) and move the revenue-critical systems last, after the process has been proven on safer ones.

Structured elaboration

Why MECE matters here. MECE means mutually exclusive (no task in two workstreams) and collectively exhaustive (nothing falls between them). Overlap causes double work and blurred ownership; gaps are where a revenue-critical migration gets hurt late. Test it: take ten random tasks (set up VPN, train support staff, shut off the old database server) and confirm each lands in exactly one workstream. Then ask "where do security, cost and training live?" and make sure each has one named home plus an explicit boundary.

Terms used in the table: a wave is a group of applications migrated together, and the wave plan says which applications go in which wave and when. Identity means who can sign in and with what permissions. The security baseline is the minimum set of security settings every account must have. Tagging is attaching labels (team, cost center) to cloud resources so cost and owners can be traced. A region is a geographic location where the cloud provider runs data centers. Runbooks are step-by-step instructions for handling a known situation. Decommissioning is shutting down and removing the old systems. Rollback is returning an application to the old environment if the move fails.

Worked example

Illustrative nine-month order (months 1-9):

Operations readiness has a minimum version that must exist before the month-4 pilot: monitoring and alerts on the pilot app, a tested rollback runbook for the pilot app (its steps come from the workstream 3 rollback plan; operations readiness checks that on-call can actually run them) and a named on-call person. It is finished by the end of month 3; the rest (cost review routines, deployment pipelines for later waves) continues through month 5 alongside the early waves.

Waves: pilot (a low-risk internal app, month 4), wave 1 low risk (month 5), wave 2 (month 6), wave 3 medium risk (month 7), wave 4 revenue-critical systems (month 8), leaving month 9 as buffer and for finishing decommissioning. Order criteria: start long-lead items first (tasks with slow waiting time that cannot be compressed: network connectivity, compliance approvals meaning sign-offs that the new setup meets legal or regulatory rules, large data transfers), keep an easy rollback until each wave is stable, and avoid cutovers in business peak periods.

Trade-offs and pitfalls

• Splitting by team or by application type mixes dimensions and breaks MECE; a mixed split looks fine on a slide and fails at the first overlapping task.
• Moving the revenue-critical system last trades a later benefit for lower risk. If the cost of the old environment is the burning problem, you might move one revenue-critical but simple component earlier with a tested rollback.
• Big-bang cutover is the wrong turn for revenue-critical systems; migrate in waves with a rollback path.
• Operations readiness is the workstream most often forgotten, and the first production incident exposes it.
• What would flip the order: a hard external date (data center contract ending) moves decommission planning to the front and compresses waves.

Direct answer

First I turn the goal into a precisely defined number. Then I split it using a rule that guarantees the pieces do not overlap and cover everything, and I pick the splitting dimension that separates owners and actions. I stop splitting when each leaf is testable, owned, measurable and decision-relevant.

Worked decomposition: "onboarding completion dropped 30%" (illustrative numbers; the monolith goal is worked through with numbers after the table of other goals)

1. Define the metric. Completion = users who finish setup within 7 days of sign-up, divided by users who start. Check what "30%" means. A relative drop from 60% to 42% is 30% relative (18 percentage points); a drop of 30 points is a different problem.
2. First split: by funnel stage. Stages are sequential, so every user stops in exactly one place (mutually exclusive) and a user who finished passed them all (exhaustive). A simplified two-stage funnel:

Check: 0.75 x 0.80 = 0.60 and 0.75 x 0.56 = 0.42. Stage 2 fell from 0.80 to 0.56, which is 30% relative, so it holds the whole drop. A real funnel has more stages.
3. Second split inside stage 2: by what the user did. (a) never reached the connect screen, (b) reached it but never attempted, (c) attempted and failed. Each user is in exactly one state. The three states cover the stage-2 users who did not finish. Users who connected successfully are a fourth state, (d), kept in the split so it stays exhaustive and the sum test passes: with illustrative counts per 1,000 users who verified their email, before the drop 800 are in (d); after the drop 560 are in (d), and the 240 extra non-completers are spread across (a), (b) and (c). Each leaf has a metric from event logs, an owner (navigation team, product design, integrations engineering) and a test (count users in the state, before versus after). "Funnel" here means the ordered steps users pass through from sign-up to finished setup, and event logs are the recorded actions (screen viewed, button clicked) that let you count users at each step.

How I decide the split

I choose the dimension where (1) branches imply different actions, (2) branches map to different owners, (3) the data already exists, and (4) the split can be checked cheaply. A split by device or customer segment is useful too, but as a second-level cut, because it does not tell a team what to fix.

The stopping rule

A leaf is done when it is:

• Testable: one analysis or small experiment answers it in days, not weeks.
• Owned: one person or team can act on it.
• Measurable: it has a metric, a baseline and a target.
• Decision-relevant: a yes or no would change what we do.

Too shallow: a leaf needs a multi-week project or has two owners. Too deep: leaves nobody owns, or whose answer would not change the plan.

The same method on other goals

The monolith goal with numbers (illustrative)

Suppose the yearly bill is 1,200k and "cut cost 20%" means a saving of 240k a year, run cost only, with one-off migration cost reported separately. First split, by cost type, is run cost 1,200k plus one-off migration cost (tracked, not counted against the 20%). Second split, run cost by module: checkout 400k, search 300k, reports 200k, admin 100k, shared infrastructure 200k (400 + 300 + 200 + 100 + 200 = 1,200). Each module is a different team's code and bill, so each has an owner. Stopping check on the leaf "reports module, 200k": testable (move it behind an interface and compare its bill before and after, in weeks), owned (the reports team), measurable (baseline 200k, target for example 140k, a 60k saving, which is a quarter of the 240k goal), decision-relevant (if the saving is small, the next module is chosen instead). Shared infrastructure fails the check as a single leaf because no one team owns it, so it is split further by the module that consumes it.

Pitfalls

• Splitting by whatever is easiest to draw, which gives branches nobody can act on.
• Mixing two dimensions at one level (stage and device), which breaks mutual exclusivity.
• Splitting until the tree looks impressive instead of until leaves are testable.

Direct answer

Accuracy is correct predictions divided by labelled predictions. Both sides of that fraction come from only four places, which is why four branches can cover it. A prediction depends on the inputs and on the deployed model and pipeline; the label it is compared with depends on the real outcome and on how labels are produced. So the number is determined by four things: the inputs the model receives, the true relationship between inputs and the real outcome, the deployed model and pipeline that turns inputs into predictions, and the process that produces labels and the metric. A fall in accuracy requires a change in at least one of them, so those four are my top-level branches. I check soundness by replaying past incidents onto the tree and by testing every leaf for a single home.

The tree (example: a spam filter, where the two classes are spam and not spam)

Terms in the leaves: a threshold is the score cut-off above which the model says "spam". Upstream means earlier in the data flow. A schema is the agreed list of fields and their types. Retraining means fitting the model again on newer data. A preprocessing library is shared code that cleans and converts raw data before the model sees it. Drift means live data or the real-world pattern has moved away from what the model learned from. Data drift is the inputs changing (A1); concept drift is the link between inputs and the true outcome changing (B1).

Tie rule that keeps leaves exclusive: classify each cause by where in the chain it originates. A broken upstream job that feeds bad values is A2, even though it also looks like data drift. A shift in the spam share is A1, since it changes the inputs, not the rule linking them to labels. Two more overlaps to settle in advance. Skew versus a changed library: if a feature is computed differently online than in training and nothing was deployed this week it is A3; if a deployed code or library change made it differ it is C3 (the change event is the origin). Traffic mix versus labelled-sample mix: if real traffic changed it is A1; if traffic is unchanged but the emails chosen for labelling changed, it is D3.

How I check the structure is sound

1. One-home test: write five real past incidents (or imagine plausible ones) and place each. If one fits two leaves, sharpen the leaf definitions. If one fits none, there is a gap.
2. Exhaustiveness argument: could accuracy move while all four factors stay fixed? If I cannot construct such a case, the four branches cover the space. Where I cannot argue it, I add an explicit "unexplained" leaf that must shrink to zero before anyone calls the investigation finished.
3. So-what test: each leaf maps to a different owner or action (data team, ML team, labelling team, analytics).
4. Peer review: ask someone who did not draw the tree to find a cause with no home.

One incident traced through the one-home test (illustrative numbers)

Daily accuracy on 1,000 labelled emails falls from 95% (950 correct) to 89% (890 correct). Investigation shows a feature called sender reputation arrives empty for 12% of emails since a data-job change last Tuesday. Placement: the model and threshold are unchanged (not C), labelling volume and rules are unchanged (not D), spammer behaviour is the same on emails with a score (not B). The inputs are wrong, and they are wrong because an upstream job broke, so the single home is A2, not A1 and not B1. Fixing the job and re-scoring the affected emails should restore accuracy; if it recovers only part of the 6 points, the remainder still has to be placed on a leaf, and an unplaceable remainder goes to the "unexplained" leaf.

Trying to break the exhaustiveness argument: random noise on a small labelled sample can move accuracy with nothing real changing. That is a measurement cause, which is why D3 includes "too small".

Same discipline on three other systems (one split each, checked with the same one-home and exhaustiveness tests used on the classifier tree)

A feature store is a service holding precomputed model inputs (features) for training and live use. A Kafka topic is a named stream of events, durably stored (the Kafka documentation likens it to a folder of events), that producers write to and consumers read from. Here a broker is a server holding the log, a partition is one slice of a topic, a sink is where a consumer finally writes the data, retries are repeated send attempts after a failure, replication lag is the delay before copies of data catch up, and cache lifetime is how long a stored value is reused before being refreshed.

Pitfalls

• Mixing "what" and "where" in one level (for example "data drift" next to "upstream job failure").
• A catch-all "Other" holding most of the cases.
• Debugging before the tree is agreed, which anchors everyone on the first plausible story.

Direct answer

With 30 days and a small team you cannot make a legacy app secure; you can close the most likely and most damaging attack paths (an attack path is a chain of steps an attacker could follow, such as an exposed login page, a weak password, then customer data) and leave an honest list of what remains. Pick subprojects by risk removed per person-day, start with finding what is exposed, and write the deferrals down with a trigger for revisiting each. At day 30 claim "top attack paths closed", never "secured".

Structured elaboration

Order of thinking. First learn what you protect and who would attack it (customer data, payments, admin functions), because that decides what "highest value" means. Then list candidate subprojects and rank them by exposure, severity and effort.

Subprojects (highest value first)

1. Inventory and exposure. What is reachable from the internet (admin pages, old test servers), which components and versions run. Close anything that never needed to be public.
2. Known-vulnerable components. Scan dependencies and server software, patch or upgrade those with known public exploits (ready-made attack code anyone can download).
3. Authentication and secrets. Multi-factor authentication (MFA: a password plus a second proof such as a phone code) for admin access, remove shared or default credentials, rotate secrets found in code and config.
4. Compensating control in front. A web application firewall (a filter that blocks common attack patterns) is a compensating control, a safeguard that reduces risk when the flaw itself cannot be fixed yet, and it buys time for flaws you cannot fix in 30 days. (Formally, a compensating control stands in for a recommended control and is expected to give comparable protection; a firewall in front usually gives less, which is why it is recorded as temporary.)
5. Top application flaws. Fix the worst findings of a scan or review (injection, where attacker-supplied text gets run as a database command or code; broken access control, where users can reach data or actions they should not) on the most sensitive functions.
6. Detect and recover. Basic logging and alerts, plus a backup that you have actually restored once.

Explicitly deferred (with a reason and a trigger): rewrite or re-architecture (needs months; revisit after a residual-risk review, a check of the risk that remains after the fixes), low-severity findings (batch into normal sprints), single sign-on migration (one login shared across systems; large and not an attack-path closer), compliance certification (needs evidence over time), network micro-segmentation (splitting the network into small zones so one breach cannot spread; design work first).

Triggers to revisit each deferral: rewrite, the residual-risk review at day 30; low-severity findings, the first normal sprint planning after day 30; single sign-on migration, the residual-risk review showing shared credentials as the top remaining risk; compliance certification, an audit or customer contract that sets a date; network micro-segmentation, the inventory showing sensitive systems on the same network as exposed ones.

Worked example

Illustrative: 3 people x 20 working days = 60 person-days.

The total is 60. The deliverable for leadership: what was closed, evidence for each, and the deferred list, each item with a named owner, a reason and its revisit trigger.

Variation: building an insider-risk detection capability from scratch. Decompose into data sources (identity and access logs, file access, endpoint activity, HR events like departures), signals (such as unusual download volume against the person's own baseline, or access outside their role), privacy constraints, tuning and review. Sequence privacy and legal constraints first, because they gate which data sources are allowed; then start with a few high-precision signals (signals that are rarely wrong when they fire), tune against a baseline period (a stretch of normal activity used to set thresholds), and route alerts to a small trained review group rather than automatic action. One signal worked through (illustrative): an employee normally downloads about 20 files a day; the rule fires when a day exceeds 10 times their own 30-day average and is at least 100 files, so 400 files in one day on the week they hand in notice fires, while 60 files on a busy day does not. Review the alerts raised in the baseline period: if 3 of 10 were real concerns the precision is 30%, and you tighten the threshold before anyone is contacted.

Trade-offs and pitfalls

• Scanning everything and fixing in severity order ignores effort and exposure; a medium flaw on an internet-facing login can outrank a high one deep inside.
• A WAF is a bandage, not a fix. Record it as a compensating control.
• Overpromising "secure in 30 days" damages credibility when the first finding arrives.
• If the app handles regulated data, some deferred items may not be deferrable; confirm obligations before finalizing the list.
• What would flip priorities: evidence of active exploitation, which moves incident response ahead of everything else.

Direct answer

Put a boundary of your own between your feature and their API, build against that boundary, and learn about the real API early with a small spike (a short, throwaway experiment). Your team then progresses on everything that does not depend on the unstable part, the risky integration is tackled first in its smallest form, and drift is detected by an automated daily check instead of by users.

Structured elaboration

Decouple. Define an interface owned by your team that describes what your feature needs (for example: estimate shipping for a cart, returning minimum days, maximum days and price). Your business logic and screens depend on that interface only. An adapter (a thin translation layer) maps their API to your interface, so a change on their side breaks one file, not the feature.

Split the work

1. Spike on the real API. One or two days calling it for real: which fields exist, how errors look, how often it changes. Cheapest way to retire the biggest uncertainty.
2. Interface plus a fake. A fake implementation with recorded sample responses lets everyone build and test without waiting.
3. Own logic and UI. Fully independent of their stability.
4. Adapter to the real API. Small, isolated.
5. Drift detection. A scheduled contract check: a test, written by you, that asserts only the fields and behaviors you depend on, run daily against their test environment.
6. Resilience. Timeouts, retries with waiting between attempts, a circuit breaker (stop calling a failing service for a short time), and a fallback behavior when it is down.
7. Rollout behind a feature flag, so you can turn the feature off without a deploy.

Sequence the risky parts. Spike first, interface and fake second, so risk shrinks before the bulk of the work. Integration with the real API is scheduled early, not last, so surprises arrive while there is time.

Talk to the other team. Ask for a versioned contract, a channel for breaking-change notices and a stable test environment. Escalate with evidence (a log of unannounced changes) if the pattern continues.

Worked example

Feature: show a delivery estimate at checkout using the logistics team's estimate endpoint, which has twice renamed fields without notice.

• Day 1-2: spike shows the price field is sometimes a number and sometimes a string.
• Day 3: interface "estimate(cart)" and a fake with three recorded cases, including an error.
• Days 4-8: checkout UI and logic built against the fake; adapter written and tested with the recorded real responses.
• Day 9: daily contract check enabled; feature flag at 5% of traffic.
  When the field is renamed again, the contract check fails the next morning and one adapter line changes. The check runs daily, so the check can take up to a day to notice the rename, plus however long the one-line fix takes to ship, so the exposed window can be longer than a day; during it the resilience layer (timeouts and a fallback such as "usually 3 to 5 days") keeps checkout working and the flag lets you switch the estimate off. The check also runs against their test environment, so it only catches changes that reach that environment first; if production changes first, the adapter's own validation of each live response (log it and fall back when a field is missing or the wrong type) is what protects users.

Trade-offs and pitfalls

• Do not wait for the other team to stabilize; but do not silently absorb every change either, since your adapter can hide a problem they should fix.
• Fakes drift from reality; the contract check exists to catch exactly that.
• A fallback has a product cost (an estimate that says "usually 3 to 5 days" instead of an exact one), so agree it with product in advance.
• What would flip the plan: if they plan to deprecate the API, invest less in the adapter and ask whether a different source is available. If the API is truly unusable, consider keeping your own copy of the needed data.