Middle

What? Divergent and convergent thinking are two distinct cognitive production modes (Guilford, 1950s): divergent production fans out into many valid answers; convergent production funnels toward the single correct or best one. Mature problem-solving is a deliberate sequence of these phases, not a blur of both. How? You structure your work — and your team's — into explicit diverge-then-converge cycles. You set quantity targets to force breadth, fix decision criteria before options to keep convergence honest, and you timebox both so neither phase runs away.

1. Guilford's distinction, precisely¶

J.P. Guilford introduced divergent production and convergent production in his work on the structure of intellect in the 1950s. The distinction is operational, not just metaphor:

• Convergent production: there is one best answer and the task is to home in on it. "What is the time complexity of this loop?" "Which index makes this query fast?"
• Divergent production: there are many acceptable answers and the task is to generate as many as possible. "List the ways this service could fail." "Enumerate the API shapes we could expose."

Guilford measured divergent ability along axes that remain a useful checklist for whether you actually diverged:

Flexibility is the one engineers most often fail. Listing "Redis cache, in-memory cache, CDN cache, query cache" feels like five ideas but it's one idea (cache it) wearing five hats. True divergence crosses categories: cache it / precompute it / denormalize it / change the access pattern / push work to write-time / drop the requirement.

2. The Double Diamond¶

The British Design Council's Double Diamond (2004) is the cleanest model for sequencing the modes. The key insight most people miss: you diverge and converge twice — once on the problem, then again on the solution.

The first diamond is where seniority shows. Juniors get a ticket and jump straight to "Develop solutions." Engineers who diverge on the problem first ("is the real issue slowness, or that the user doesn't trust the number they see?") often dissolve the problem instead of solving it.

3. Forcing divergence¶

Left alone, individuals and groups converge far too early — the first plausible idea anchors everyone. You have to force breadth with structure.

Quantity targets¶

"Give me ten ways" produces better final answers than "give me a good way," because the requirement to reach ten defeats the instinct to stop at the first workable one. The early ideas are obvious; the later ones are where flexibility and originality live.

SCAMPER (Bob Eberle)¶

A checklist that generates variations by prompting different operations on an existing design:

SCAMPER is a divergence engine when you're stuck staring at one design and can't see alternatives.

Worst-possible-idea¶

List deliberately bad solutions. It bypasses self-censorship and the inversions are often instructive — this is a gateway to inversion thinking.

Osborn's brainstorming rules¶

Alex Osborn's original rules (1953) are really just rules for protecting the divergent phase: defer judgment, encourage wild ideas, go for quantity, build on others' ideas. Every rule exists to stop convergence from leaking in early.

4. Forcing convergence honestly¶

Divergence without disciplined convergence is just a long meeting. Convergence has its own failure mode: rationalizing the choice you already wanted.

Criteria before options¶

This is the single most important convergence discipline. Write down what "best" means before you look at the candidates. Otherwise you'll weight whichever criterion the winning option happens to satisfy. If latency, operational simplicity, and time-to-ship are the axes, name them and (roughly) weight them first. This is the bridge into evaluating trade-offs objectively.

BAD:  look at options → "I like the event-sourcing one" → invent reasons
GOOD: criteria = {ship in 2 weeks: high, ops burden: high, future flex: low}
      → score each option → event-sourcing loses on the first two → cut it

Dot-voting and narrowing¶

In a group, dot-voting (each person spends N votes across the options) is a fast convergence tool — but only after divergence is fully done. Vote too early and you're voting on a thin field.

The cost of deciding¶

Convergence isn't free. Every option you seriously evaluate costs time, and the decision itself has a deadline value: a good-enough decision today often beats a perfect one next sprint. Treat "we will decide by Thursday" as a real constraint and let it cap the divergence.

5. A worked example: rate-limiting design¶

You're asked to add rate limiting to an API.

Diverge on the problem (Discover): Why? Abuse? Cost control? Fairness between tenants? Protecting a fragile downstream? These imply different solutions. Suppose it's "one tenant's batch job starves everyone else."

Converge on the problem (Define): "Prevent any single tenant from consuming more than its fair share of capacity, measured per-minute." Now it's decidable.

Diverge on solutions (Develop): token bucket per tenant / leaky bucket / fixed window / sliding window log / concurrency cap instead of rate / queue + fair scheduler / quota with overage billing. Eight, across genuinely different categories.

Converge on a solution (Deliver): Criteria fixed first — {accuracy of fairness, memory cost at 50k tenants, implementation time}. Sliding-window-log is most accurate but costs too much memory at scale; token bucket per tenant wins on the weighted score. Ship it.

Skip the first diamond and you might have built a global fixed-window limiter that doesn't solve the per-tenant fairness problem at all.

6. Where mid-level engineers slip¶

7. The maturity curve¶

Juniors converge too fast — first idea that works, ship it. Mid-level engineers learn to hold the design space open longer and to diverge on the problem, not just the solution. The risk you now carry is the opposite one: enjoying divergence and under-investing in the convergence that actually ships a decision. Watch for it.

See the section overview for how the sibling techniques — inversion, analogical thinking, constraint-driven creativity — plug into the divergent phase, and the problem-solving track for the surrounding method. The roadmap root places this within engineering thinking as a whole.

Takeaway: Sequence the modes — diverge then converge, twice. Measure your divergence by flexibility, not just count, and keep convergence honest by fixing the criteria before you ever see the options.