We stopped working one thing at a time

Julio, this has raised my productivity at least 3x. That's from a retro at Riqra, when we evaluated introducing worktrees into the workflow. Not my claim — the engineer's.

Worktrees are parallel copies of the workspace. Several agents work on different features at the same time without stepping on each other, and one engineer orchestrates all of it. You stop working on one thing at a time.

Why this chapter comes late in the series

Here's what the productivity posts don't tell you: parallelism multiplies whatever system you already have. Run five agents on a repo with no written context, no review bar and no clear owner, and you get five times the mess — faster.

Parallel work doesn't create capacity. It multiplies the system you already have.

It only worked for us because everything before it was in place. The context lives in the repo, so every agent starts oriented. Review has a score and a rule, so five parallel branches don't pile up behind one reviewer. And the engineer who ships is on call, so speed never outruns ownership.

It's not magic, and it's not free: you need to understand your architecture, how services and resources are shared, and what each parallel copy needs to run. The setup takes real engineering judgment.

What it feels like

The engineer stops being a person doing tasks in sequence and becomes someone directing work in parallel — reviewing one feature while two others build, unblocking a third. Same person, several streams. This is the multiplication the whole series was pointing at.

Founder question: if every engineer on your team could run three work streams tomorrow, would your system survive it — or does it barely survive one?