Structured Problem Solving and Decomposition Questions

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

Separate two orders that are often confused: the order things must be built in (set by dependencies) and the order you learn in (set by uncertainty). Build order follows the critical path; learning order starts the riskiest unknowns early with cheap spikes (short, time-boxed experiments that answer one question and are thrown away, not production code), even if the full build comes later. Anything with no dependency between them runs in parallel.

Structured elaboration

Assumed dependencies (state them, then confirm with the team)

• Auth (who the user is) feeds payments, because a payment belongs to an identity.
• Payments produces the transactions that fraud detection scores.
• Analytics events are inputs to fraud features, and analytics can start with instrumentation early.
• Client validation (checking input in the app before sending it) depends on nothing but helps payments forms.

Critical path is the longest chain of dependent work: auth, then payments, then fraud detection. Everything off that chain has slack (time it can slip without delaying the end).

Worked example

Illustrative durations in weeks: auth 2, payments 3, fraud detection 4, analytics 2, client validation 1.

• Critical path: 2 + 3 + 4 = 9 weeks.
• Schedule on the critical path: auth weeks 1-2, payments weeks 3-5, fraud detection weeks 6-9.
• Analytics must be finished by the end of week 5, when fraud starts. It takes 2 weeks, so its latest start is week 4; starting in week 1 instead gives 4 - 1 = 3 weeks of slack.
• Client validation must be finished by the end of week 5, when payments goes live. It takes 1 week, so its latest start is week 5; starting in week 1 gives 5 - 1 = 4 weeks of slack.
• So weeks 1-2 run auth, analytics and (if capacity allows) validation in parallel.

Fastest learning. Fraud detection is last to build but the most uncertain: is there signal, how are labels obtained? Run a shallow offline analysis on historical data and a payments-provider sandbox spike in week 1, while building in dependency order.

The same method on two other problems

• Five ML workstreams, four weeks, one engineer. One engineer means no parallelism, so cut each to a thin slice and sequence by what unblocks and teaches most. For example (data pipeline, labeling, training, serving, monitoring): week 1 data plus a minimal labeled set and a baseline, week 2 a first model with offline evaluation, week 3 serving, week 4 hardening with monitoring reduced to logging inputs and predictions, full alerting deferred.
• Model quality versus a 100 ms latency budget. Latency is the time from request to response; budget it per stage, illustratively 20 for network and orchestration (the code that coordinates calls between services), 30 for feature fetch (looking up the input values the model needs), 35 for inference (the model computing its prediction), 15 for post-processing (total 100). Levers: architecture (a smaller model, or a distilled one trained to imitate a larger one), features (precompute expensive ones), caching (reuse answers for repeated inputs, at the cost of staleness), batching (grouping several requests into one model call: higher throughput, meaning more requests handled per second, but waiting to fill a batch eats budget). Measure the quality lost per millisecond saved (illustratively, a distilled model that cuts inference from 35 to 20 ms, 15 ms saved, while accuracy falls from 91% to 90%, costs about 0.07 points per ms; caching that saves 10 ms at no accuracy cost should be taken first) and judge at the 99th percentile, the slowest 1% of requests, not the average.

Trade-offs and pitfalls

• Dependency order can hide the riskiest item at the end; spikes fix that without changing build order.
• Parallel work needs people; with fewer people than branches, the critical path still goes first.
• A mocked upstream lets parallel work start, but integration surprises move to the end unless you schedule an early integration.
• What would flip the order: if fraud signal turns out to be weak in the spike, you reconsider the whole workstream before payments is built.

Direct answer

MECE (pronounced "me-see") stands for mutually exclusive, collectively exhaustive. Mutually exclusive means no item belongs to two branches. Collectively exhaustive means every item belongs to at least one branch. Together: each item has exactly one home. A split is only useful if it is MECE and its branches lead to different actions.

Example: monthly retention fell (illustrative numbers)

Retention is the share of customers at the start of the month who are still customers at the end. Say 1,000 customers started the month; retention fell from 80% (800 kept, 200 lost) to 72% (720 kept, 280 lost), so 80 extra customers left.

A split that looks reasonable but is not MECE

Cut the 1,000 customers into: new users (300), mobile users (500), enterprise customers (150), European customers (200).

• Overlap: Priya joined 10 days ago, uses mobile, is on an enterprise plan and lives in Germany. She sits in all four branches. The counts add to 300 + 500 + 150 + 200 = 1,150, more than the 1,000 customers, which is the quick tell.
• Gap: a two-year-old desktop customer on a small-business plan in the US fits none of the four branches.

The fix: one dimension, one rule

Split by tenure at the start of the month: under 30 days (300), 30 to 179 days (400), 180 days or more (300). Each customer has exactly one start date, so exactly one bucket (exclusive), and 300 + 400 + 300 = 1,000 (exhaustive). Other dimensions such as mobile versus desktop then become a second-level split inside each tenure bucket, never mixed in at the same level.

Tests for any split

1. Sum test: do the branch counts add to the total?
2. One-home test: pick five real items and place each. Two homes means overlap, none means a gap.
3. So-what test: does each branch imply a different action? If not, the split is correct but useless.

How I pick the most useful cut

Four families of splitting dimension:

I choose the dimension where (a) branches differ most in outcome, (b) data exists, (c) branches map to owners, and (d) I can check it quickly. For a retention decline I would start with tenure, because "new-user problem or long-time-user problem" decides which team owns it.

Continuing the example (illustrative, same tenure mix last month): last month 60, 80 and 60 customers were lost in the three tenure buckets (200 in total). This month the losses are 140, 80 and 60 (280 in total). The extra 80 sit entirely in the under-30-days bucket, whose loss rate went from 60/300 = 20% to 140/300 = about 47%, while the other two stayed at 20%. That is the so-what: the problem is onboarding, not long-time customers, so the next split goes inside that bucket.

More partitions

• Signup conversion: never started, started and abandoned, submitted but unverified, completed.
• Onboarding non-completers, with a hypothesis per bucket: (1) never started: the prompt is not being seen; (2) started and stalled: one step is too hard or long; (3) completed but not recorded: a tracking gap undercounts completion; (4) ineligible, such as test or internal accounts: the denominator is polluted. Tie rule: eligibility is checked first, so a stalled internal account lands in bucket 4 only.

Pitfalls

• Mixing dimensions at one level (the 1,150 trap).
• An "Other" bucket that quietly holds half the data.
• Treating MECE as a pass mark: a MECE split nobody can act on is still a bad split.

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

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.