Parallel processing is doing multiple units of work at the same time instead of one after the other. In computing, it means executing instructions or tasks concurrently across multiple cores, machines, or processes so that total throughput increases and wall-clock time decreases. The same idea applies to organisations and operations: run independent streams of work in parallel so that overall output scales and latency drops. The limit is dependency — when one task must wait on another, parallelism doesn't help until that dependency is broken or the critical path is shortened.
In systems, parallelism is constrained by Amdahl's law: speedup is bounded by the fraction of work that is serial. If 10% of a job must run sequentially, maximum speedup is 10x no matter how many processors you add. The leverage is in parallelising the remaining 90% and in reducing the serial fraction. In organisations, the analogue is the critical path: the longest chain of dependent tasks determines the minimum time to completion. Parallel work that isn't on the critical path doesn't shorten the project; it just uses slack. So the disciplines are: identify the critical path, parallelise what can be, and reduce serial bottlenecks (dependencies, single points of coordination).
In building and scaling, parallel processing appears in team structure (squads that own independent streams), in product (multiple features or experiments in parallel), and in infrastructure (distributed systems, async pipelines). The mistake is adding more parallel work without fixing the bottleneck — you get more activity but not more outcome. The win is to increase the fraction of work that can run in parallel and to shrink the serial section.
Gustafson's law is the optimistic counterpart to Amdahl's: when problem size grows with the number of processors (e.g. bigger dataset, more users), the serial fraction can become negligible in practice and speedup can scale almost linearly. So scaling the problem can make parallelism pay off even when Amdahl would cap a fixed-size problem. The lesson: for fixed work, fix the serial bottleneck; for growing work, add parallel capacity and keep the serial part from growing as fast.
Section 2
How to See It
Look for contexts where total time or throughput is limited by doing things one after another. When you can split work into independent streams and run them concurrently, or when adding more workers or cores doesn't proportionally increase output, parallel processing (and its limits) is in play.
Business
You're seeing Parallel Processing when a company runs multiple squads or teams on different product areas or experiments at the same time. Output scales with the number of independent streams — until a shared dependency (e.g. design, platform, approval) becomes the bottleneck.
Technology
You're seeing Parallel Processing when a pipeline runs map-reduce jobs, microservices, or async workers in parallel. Throughput scales with the number of workers until the serial parts (e.g. single DB, single coordinator) cap speedup.
Investing
You're seeing Parallel Processing when a fund has multiple partners sourcing and evaluating deals concurrently. Deal flow scales with parallel effort — but if every deal needs one person's sign-off, that person is the serial bottleneck and limits how much parallelism helps.
Markets
You're seeing Parallel Processing when a launch plan runs regional rollouts or channel tests in parallel instead of sequentially. Time to full launch drops because independent streams complete concurrently; the constraint is any step that must be done once for all (e.g. central compliance, global creative).
Section 3
How to Use It
Decision filter
"When you need more throughput or shorter cycle time, find what can run in parallel and what must run in sequence. Parallelise the independent work; then attack the serial bottleneck (the critical path or the single point of coordination). Adding parallel capacity only helps if the bottleneck is in the parallel part."
As a founder
Structure teams and roadmaps so that independent work streams run in parallel — different features, segments, or experiments. Identify the serial bottleneck: the decision, resource, or dependency that everything waits on. Fix or duplicate that before adding more parallel teams, or you'll add cost without proportional gain.
As an investor
Portfolio construction and deal flow benefit from parallelism: multiple partners, multiple themes, multiple stages. The limit is the serial step — e.g. partnership approval, allocation committee. Scale the parallel layer; don't let a single serial step cap the whole system.
As a decision-maker
When planning a complex initiative, map the dependency graph. Run in parallel all work that doesn't depend on other work. Shorten the critical path by breaking dependencies or adding capacity at the bottleneck. Measure progress by critical-path completion, not by total activity.
Common misapplication: Equating parallel work with faster outcome. Parallel work only reduces time if it's on the critical path or if it increases throughput at the bottleneck. Otherwise you get more concurrent activity but the same (or worse) delivery time because coordination cost can increase.
Second misapplication: Ignoring Amdahl's law. There's always a serial fraction — coordination, integration, approval. Throwing more people or cores at the problem has a ceiling. The leverage is in reducing the serial fraction and in making the parallel part as large as possible.
Grove ran Intel with parallel business units and clear accountability. He emphasised that the bottleneck to scaling was often the number of people who could make decisions — a serial constraint. His "output-oriented" management was about maximising throughput by parallelising execution while keeping decision rights and information flow aligned so the serial layer didn't cap growth.
Netflix's "context not control" and distributed decision-making are designed to increase the parallel fraction: teams can act without waiting for central approval. The mechanism reduces the serial bottleneck (top-down decisions) so that more work runs in parallel. The goal is to scale output by scaling the number of independent decision points.
Section 6
Visual Explanation
Parallel Processing — Serial (one after another) vs parallel (concurrent). Throughput scales with parallel streams until the serial bottleneck (shared step) limits speedup. Amdahl's law: speedup ≤ 1 / (serial fraction).
Section 7
Connected Models
Parallel processing sits with bottlenecks, throughput, and scaling. The models below either reinforce it (division of labour, throughput), create tension (bottlenecks, theory of constraints), or extend to structure (scale, modularity).
Reinforces
[Division](/mental-models/division) of Labour
Division of labour splits work among specialists; parallel processing runs that split work concurrently. The reinforcement: you divide labour to specialise, and you run the divided streams in parallel to scale. Both are needed — division defines the streams; parallelism runs them at the same time.
Reinforces
Throughput
Throughput is output per unit time. Parallelism increases throughput by doing more units of work in the same time. The reinforcement: when throughput is the goal, parallelise up to the limit imposed by the bottleneck. Throughput is the metric; parallelism is the lever.
Tension
Bottlenecks
Bottlenecks are the limiting step. In a parallel system, the bottleneck is often the serial part — the one step every stream depends on. The tension: adding parallel capacity helps only until the bottleneck is saturated. Then the bottleneck must be fixed or replicated for parallelism to yield more.
Tension
Theory of Constraints
Theory of constraints says improve the constraint first. The constraint in a parallel system is the serial step or the critical path. The tension: parallelism is wasted if the constraint isn't addressed. Use theory of constraints to find the serial bottleneck; use parallelism to scale the rest.
Section 8
One Key Quote
"The speedup of a program using multiple processors in parallel computing is limited by the sequential fraction of the program. If 5% of the program is serial, maximum speedup is 20x regardless of how many processors are used."
— Gene Amdahl (1967)
The quote states Amdahl's law. The practical lesson: adding parallel capacity (people, cores, teams) has a ceiling set by the serial fraction. To scale further, reduce the serial part — break dependencies, duplicate the bottleneck, or redesign so more work is independent.
Section 9
Analyst's Take
Faster Than Normal — Editorial View
Find the serial bottleneck first. Before adding parallel capacity, map where work waits. The bottleneck is the step or resource that limits throughput. Fix or shard that step; then add parallel streams. Otherwise you add cost and complexity without proportional gain.
Critical path drives delivery time. In projects, the critical path is the longest chain of dependencies. Only work on the critical path shortens the project. Parallel work off the path uses slack but doesn't reduce time. Focus parallel effort on the path or on shortening the path by breaking dependencies.
Coordination is often the serial step. In organisations, the "serial" part is often the meeting, the approval, or the single decision-maker. Decentralise decisions and approvals where possible so that more work can run in parallel without waiting. Grove and Hastings both focused on this: scale the number of decision points.
Measure throughput, not activity. Parallel work can look busy without increasing output if the bottleneck is elsewhere. Measure end-to-end throughput (e.g. features shipped, deals closed) and tie it to the critical path and bottleneck. Optimise for that.
Section 10
Test Yourself
Is this mental model at work here?
Scenario 1
A company doubles its engineering team but delivery speed doesn't improve. Every feature still needs the same single design review and the same VP sign-off.
Scenario 2
A data pipeline is parallelised from 1 to 10 workers. Throughput increases 8x, not 10x.
Scenario 3
A company runs 5 product squads in parallel. Ship dates don't improve; they add a release train that every squad must sync to.
Scenario 4
A team completes a project by running design, build, and test in overlapping phases instead of strictly one after the other.
Section 11
Summary & Further Reading
Summary: Parallel processing is doing multiple units of work concurrently to increase throughput and reduce time. In systems, Amdahl's law caps speedup by the serial fraction. In organisations, the critical path and serial bottlenecks (single approver, shared resource) limit the benefit of adding parallel capacity. Use it when building and scaling: parallelise independent work, identify and fix the serial bottleneck, and measure throughput rather than activity. Connected to bottlenecks, theory of constraints, division of labour, and scale.
Decentralisation and parallel decision-making in organisations. Reduces serial bottlenecks by distributing authority.
Leads-to
Scale
Scale is growing output without proportional growth in cost or time. Parallelism is a primary scaling lever: more parallel streams, more throughput. The connection: scaling often means adding parallel capacity (people, servers, teams) while keeping the serial fraction small so that scale actually converts to output.
Leads-to
[Modularity](/mental-models/modularity)
Modularity is decomposing a system into independent parts. Independent parts can run in parallel; coupled parts cannot. The connection: good modularity increases the parallelisable fraction and reduces dependencies, making parallelism more effective. Design for modularity to enable parallelism.
