To make any decision or accomplish any creative work, break the time you have into two phases:

In the first phase, you gather information. Explore. The more paths, the better. Your aim is to widen the possibilities: add words to the draft, add code to the branch.

In the second phase, you use criteria - which can be a mix of objective and subjective - and processes to narrow down possibilities, make tradeoffs and smooth out inconsistencies until you've made a decision, shipped a diff, published a post.

Key Concepts

Divergence is playful, low pressure, fun: You usually won't have to schedule solo divergence unless the project really doesn't interest you. Brainstorming with a group can be fun, and there are hundreds of different exercises available to take a group through divergence.

But apply a few constraints anyway: Setting a few guardrails like max budget, tech stack family, word-count ceiling, etc prevents divergence from getting out of control breadth-wise and allows more time to go into depth on feasible choices.

The turn usually hurts: Convergence is hard work. If you're writing to relax, or writing because you like the idea of being a writer, your folder might be full of unpublished drafts. Mine sure is. Convergence almost always has to be calendared, and it usually requires a combination of discipline and some form of forcing function around it.

Timing: Often the phases are drawn with equal lengths, implying that the time you're diverging should roughly be equal to the time you're converging. This is almost never the case. Given a fixed due date, it's important to estimate the amount of time you'll need in the converge phase, pad it a bit depending on how many unknowns there are, and only allow yourself as much divergence as you can afford in the leftover time.

Overlapping Timeframes: In the simplest version, there is a single divergence phase and a single convergence phase. This is almost never the case. Often a project will combine timeframes, with divergence happening on an outer timeframe - let's say monthly - while smaller diverge-converge cycles happen within the higher timeframe phase.

An example of this: You want to build an app that display real time stock price changes along with AI-driven buy/sell advice. You've given yourself a two month deadline to ship an MVP that will allow to decide whether to keep going or scrap the idea, so you're taking the first two weeks to do meta-divergence and play with ideas. One of the subtasks of meta-divergence might be making a list of tech stacks to build in, and then choosing one. So on the project timeframe you're diverging, but for the tech stack selection subtask you run a one day divergence where you list out all the feasible stacks, and then take another day to narrow them down by spending an hour with each one doing a very light prototype to compare pros and cons until you've chosen one.

Gotchas

Running the whole process when there's an obvious choice: You see this as pedantic process following and you see this as CYA. If you already know you want to use library X, just pick library X and go. If someone if habitually making you feel like you have to exhaustively "document your decisions", it might be time to run a more personal sort of diverge/converge process.

No time pressure: This might seem like a blessing, but it's not. It's saccharine, a short term reprieve from pressure that will in the long run have poor results. Deadlines are a tool to ship. Teams that don't ship are usually among the first to get cut in a layoff.

Resisting or even failing to converge: Divergence is more fun. There's always a new thing to learn about.

Applying To Tech Projects

• Make drivership official. It's usually clear, but is it? Sometimes exploration involves multiple parties, sometimes convergence was multiple workstreams, that's all ok. The driver doesn't have to do all the work. They're the one responsible for the work being done.
• Ask for or assign a due date. The best due date is the one the driver comes up with themselves.
• Assign an approver. This is a person who gets to say the plan is approved. Usually a member of the management or leadership hierarchies. Often it might be you if you're in a management role.
• Diverge as a group. Generally speaking, the more people you can include in the divergence phase, the better. Let people know that not every idea will be chosen.
• Converge as a much tighter group. Be transparent as you can with how you discarded possibilities, and thank people for their contributions. Remind members of the broader group who didn't get to choose that they will have their chance too, either on another project and/or later in their careers as they gain wisdom and seniority.

A simple one week example

• Monday plan & describe high level goals
• Tuesday open ended exploration and prototyping. End the day with an idea of what an end-to-end draft might look like. (If you can't conceive of it or it seems impossible, come back to that thought in the morning and be prepared to ask for more time if you still feel that way)
• Wednesday morning make the turn, spend the day going end to end on a draft, painting with a broad brush & leaving behind todos.
• Thursday start with a peer review of the end to end solution, then as long as it's sound you can spend the day filling in the details and the gaps. (If unsound or need a start over, repeat Wednesday and communicate out that you'll be a day late)
• Friday apply the finishing touches, ship