Divide and Conquer

Divide and conquer is a strategy: break a problem into smaller subproblems of the same kind, solve them (often recursively), then combine the solutions. In algorithms, merge sort is the textbook example — split the array, sort each half, merge. The same logic applies to organisations and decisions: split the work into pieces that can be handled independently, solve each piece, then integrate. The power is in the split. When the subproblems are genuinely smaller and the combine step is cheap, total cost drops. When the split is wrong — subproblems overlap heavily, or the combine step is expensive — divide and conquer doesn't help.

The key is independence. Ideal subproblems don't depend on each other; they can be solved in parallel or in any order. When they do depend (e.g. step B needs step A's output), you have a dependency graph, not pure divide and conquer — you still benefit from decomposition, but you must sequence or pipeline. In org design, "divide" means teams or owners; "conquer" means each solves their piece; "combine" is integration and alignment. The failure mode is dividing in a way that creates so much coordination cost that the combine step dominates. The strategic move is to find splits that minimise interdependence and to invest in clear interfaces so that the combined result is coherent.

In practice, divide and conquer shows up in product (break the roadmap into streams), in execution (break the project into workstreams with owners), and in analysis (break the market into segments). The discipline is to make the split explicit — what are the subproblems? who owns them? how do we combine? — and to check that the subproblems are actually smaller. Splitting a big problem into two big problems that share 80% of the work is not divide and conquer; it's fragmentation.