Throughput is total, completed output counted over a fixed stretch of time. Not the speed of any one item — the actual, honest volume of what genuinely came out the other end.

Picture a car wash at the end of a busy street. One single lane, one crew, washing cars one at a time. On a quiet Tuesday morning, they might wash eight cars an hour. On a sunny Saturday, with the same crew working just as hard, they still only manage roughly the same eight cars an hour, because that is simply how many cars can move through that one lane, start to finish, in that stretch of time.

That number — eight cars an hour — is the car wash’s throughput. It does not describe how fast any single car gets washed. It describes how many complete washes actually come out the other end, counted over a fixed period of time. Speed up one car’s wash and you might bump the number up a little. Add a second lane, and you could genuinely double it. But the number itself is always about total output over time, not about any one individual car’s journey.

This exact idea — total output over a fixed stretch of time — shows up constantly across very different worlds: how much data actually flows across a network connection, how many packages a warehouse ships in a day, how many customer tickets a support team resolves in a week, how many tasks a software team finishes in a sprint. Different units, different contexts, but the very same underlying question every single time: how much real work got done, in this amount of time?

Keep that car wash and that cafeteria line in mind as you read on, because nearly every idea in this guide — from computer networks to project management boards — comes back to that same simple measurement: real, completed output, counted over real time.

What makes throughput such a valuable idea is how honestly it cuts through wishful thinking. It is tempting to describe a system as “fast” or a team as “productive” based on impressions and busy‑looking activity, but throughput refuses to accept vague descriptions — it insists on an actual number, counted over an actual stretch of time, that either holds up to scrutiny or does not.

Throughput did not start out in computing at all. It has roots in manufacturing and industrial engineering, then travelled through telephone lines, computer networks, and finally the dashboards of modern software teams.

The word “throughput” did not start out in computing at all — it has roots in manufacturing and industrial engineering, stretching back to the early twentieth century, when factories were racing to figure out how many finished goods a production line could actually turn out in a day. Early industrial engineers needed a clean, honest way to measure whether a factory floor was genuinely productive, separate from how busy individual machines or workers looked.

As telecommunications and computer networks developed through the mid‑twentieth century, engineers borrowed the same basic idea to describe something remarkably similar: how much actual data successfully travelled across a communication line in a given stretch of time. Early telephone and telegraph engineers cared enormously about this number, since it directly determined how many messages a line could realistically carry.

The rise of computer networking in the 1970s and 1980s brought throughput fully into the language of engineers building the earliest versions of what would become the internet. As networks grew more complex, with multiple devices sharing limited connections, understanding actual throughput — as opposed to a connection’s theoretical maximum capacity — became essential for diagnosing why a network sometimes felt slow even when nothing appeared to be technically broken.

More recently, the same underlying concept has been enthusiastically adopted by the world of knowledge work and software development, particularly through methodologies like Kanban, where teams track how many tasks or features they actually complete over a given stretch of time, using throughput as a grounded, honest measure of real progress rather than relying purely on estimates or plans.

It is worth appreciating just how consistently useful this one idea has proven across nearly a century of very different technologies. Whether the “thing” moving through a system is a physical part on an assembly line, an electrical signal down a copper wire, a packet of data across a fibre optic cable, or a completed task on a digital board, the underlying question engineers keep asking never really changes. That durability is a strong hint the concept captures something genuinely fundamental about how systems of any kind actually perform.

Throughput is always a rate — some amount of “stuff” divided by some amount of time. The single word that matters most in the definition is actually: it counts real, completed output, not theoretical potential.

Throughput is a measurement of how much work, data, or output a system actually produces or delivers within a specific period of time. It is always expressed as a rate — some amount of “stuff” divided by some amount of time — whether that is bits per second, cars per hour, or tasks completed per week.

The single word that matters most in that definition is actually. Throughput is not about theoretical maximum capacity, and it is not about how fast any one individual item moves. It is about real, completed, measured output — what genuinely came out the other end, counted honestly, over a real stretch of time.

It is worth being precise about what throughput is not. It is not the same as speed, which describes how quickly one single item moves. It is not the same as capacity, which describes the maximum a system could theoretically handle under ideal conditions. And it is not the same as efficiency, which describes how well resources are being used. Throughput sits quietly alongside all of these related ideas, answering its own specific question: how much actually got delivered, in this amount of time?

Two ideas are worth carrying with you through the rest of this guide, because they explain almost every decision engineers and teams make around throughput:

• Throughput measures reality, not potential. It counts what actually happened, which makes it an honest, grounded number rather than an optimistic estimate.
• The whole system matters, not just its fastest part. Throughput is shaped by whichever part of a system is slowest, not by how fast the quickest part could theoretically go.

There is a helpful way to picture throughput’s relationship to time: it is always a rate, never a raw count on its own. Saying “we finished 200 tasks” tells you very little without knowing the time period involved — 200 tasks in a day is a very different story from 200 tasks in a year. Throughput always comes paired with its time window, which is exactly what makes it comparable and genuinely meaningful from one measurement to the next.

In computer networking, throughput measures how much data successfully travels across a connection within a given period of time — usually expressed in bits per second, or larger units like megabits and gigabits.

In the world of computer networks, throughput specifically measures how much data successfully travels across a network connection within a given period of time, usually expressed in bits per second, or larger units like megabits or gigabits per second for busier connections.

Engineers often calculate this with a simple formula: divide the total amount of data transferred by the time it took to transfer it, then convert to bits if needed. Sending 10,000 bytes in 10 seconds, for example, works out to 8,000 bits per second, once the standard conversion of eight bits per byte is applied.

This number gets measured differently depending on context. For very short, fast‑moving systems, engineers often look at throughput over tiny slices of time — counting packets received per second, for instance — rather than waiting a full hour to get a meaningful reading, since network conditions can shift dramatically within just a few seconds.

It is worth knowing that throughput can be measured at several different points within the same network journey too. The throughput leaving a sender’s device might differ from the throughput arriving at a receiver’s device, particularly if something along the path — a congested router, a weak wireless signal, an overloaded server — is quietly limiting the flow somewhere in between. Skilled network engineers often measure throughput at multiple points specifically to isolate exactly where a slowdown is actually happening, rather than assuming the whole path behaves uniformly.

Bandwidth is the road’s theoretical maximum width. Throughput is how much traffic is actually driving on it right now. These two words get confused constantly, so it is worth drawing a clean line between them.

These two words get confused constantly, even by people who work with networks regularly, so it is worth drawing a clean, memorable line between them.

Bandwidth describes a connection’s theoretical maximum capacity — the widest the road could ever be, under perfect conditions. Throughput describes what is actually happening on that road right now — the real traffic genuinely flowing through it, which is almost always somewhat less than the road’s full theoretical width, due to congestion, overhead, and real‑world imperfections.

A useful comparison, borrowed from the world of air travel: bandwidth is like the maximum number of passengers an airport could theoretically process in an hour if every gate, security lane, and staff member operated at peak efficiency simultaneously. Throughput is the actual number of passengers who genuinely passed through during that hour, accounting for real queues, delays, and everyday friction.

This distinction matters enormously in everyday life, not just in technical documentation. Someone paying for an internet plan advertising a large maximum speed might still experience a frustratingly slow video call, precisely because that advertised number describes bandwidth — the theoretical ceiling — while their actual, lived experience depends on throughput, which can be dragged down by dozens of everyday factors the advertised number never accounted for.

Latency measures how long one thing takes; throughput measures how much gets done. A system can excel at one while being mediocre at the other — and confusing them leads to fixing the wrong problem.

Another frequent point of confusion involves latency, which measures something genuinely different, even though the two often get discussed side by side when people talk about a system “feeling slow.”

A system can have excellent throughput and poor latency at the same time, or the reverse. A cargo ship carrying an enormous number of containers across an ocean has fantastic throughput — huge volume delivered — but genuinely terrible latency, since any single container takes weeks to arrive. An overnight courier delivering one small envelope has wonderful latency — fast delivery for that one item — but comparatively modest throughput, since it cannot move nearly as much total volume.

Well‑designed systems usually pay attention to both numbers together, because a system that is excellent at one and poor at the other still leaves users unhappy in a very specific, predictable way.

Video calling offers a particularly relatable example of why both matter simultaneously. A video call needs decent throughput to carry a smooth, high‑quality video stream without pixelation, but it also desperately needs low latency, since a delay of even half a second between people speaking creates that familiar, awkward feeling of talking over each other. Neither number alone tells the whole story of why a call feels good or bad — both have to be reasonably healthy at the same time.

Several real‑world factors can push throughput up or drag it down. Recognising them is the first step toward improving a system’s actual performance rather than just its advertised specifications.

Several real‑world factors can push throughput up or drag it down, and recognising them is the first step toward improving a system’s actual performance rather than just its advertised specifications.

In networking specifically, intentional restrictions also play a real role — internet providers sometimes deliberately cap throughput on cheaper service plans, or organisations may prioritise certain types of traffic over others, reserving higher performance for the applications that need it most and accepting lower throughput elsewhere as a deliberate trade‑off.

The specific protocol a system uses to transmit data can shape throughput significantly too. Some protocols include careful mechanisms for managing data flow and avoiding congestion gracefully, sacrificing a little raw speed in exchange for steadier, more reliable delivery. Others are built for simplicity and speed at the cost of that careful management, trading some reliability for potentially higher raw throughput under ideal conditions. Neither approach is universally better — the right choice depends entirely on what a particular application actually needs.

The specific transmission medium matters too, and it is worth knowing at a basic level. A wired connection, like ethernet cable, tends to offer more consistent, predictable throughput than a wireless connection, which is more vulnerable to interference from walls, distance, and competing signals sharing the same airwaves. This is part of why a device plugged directly into a router often experiences noticeably steadier throughput than the same device connecting wirelessly from across the room.

Jitter — small, unpredictable variations in how quickly data arrives — also quietly erodes throughput, even when average conditions look fine on paper. A connection that delivers data in uneven bursts, with unpredictable gaps in between, ends up completing less real work over time than a connection delivering the same average amount steadily and predictably, since systems often have to wait out those gaps rather than making productive use of them.

Beyond networks and factories, throughput has become a central concept in modern project management — particularly within Kanban and other flow‑based approaches to organising work.

Beyond networks and factories, throughput has become a genuinely central concept in modern project management, particularly within Kanban and other flow‑based approaches to organising work.

In this context, throughput simply means the number of work items — tasks, stories, tickets, features, however a team defines them — genuinely finished within a chosen stretch of time. It is an exact count, not an estimate or an average, and it answers one very clear question: how many things did this team actually complete?

This measurement matters for reasons beyond simple bookkeeping. Throughput is one of several core “flow metrics” teams use to understand how smoothly work genuinely moves through their process, alongside related ideas like how many items are in progress at once and how long each one typically takes from start to finish. Together, these numbers paint a far more honest picture of a team’s real capacity than optimistic planning estimates alone ever could.

This grounded honesty is exactly why throughput has become such a trusted tool for forecasting. Rather than asking a team to guess how long a large batch of upcoming work might take — a notoriously unreliable exercise — a team can instead look at its own recent, real throughput and use it to build a statistically grounded estimate, sometimes running many simulated scenarios to produce a realistic range of likely completion dates rather than a single, falsely precise guess.

It is also worth noting that throughput data becomes more trustworthy the more consistently it is collected. A team measuring throughput sporadically, with gaps and inconsistent definitions, ends up with a noisy, unreliable picture. A team measuring it the same careful way, week after week, builds a genuinely useful historical record that gets more valuable the longer it is maintained.

Within agile and Kanban circles, throughput often gets compared — and sometimes confused — with a related but genuinely different measurement called velocity.

Within agile and Kanban circles specifically, throughput often gets compared — and sometimes confused — with a related but genuinely different measurement called velocity.

Velocity depends on story points — a team’s own internal, often inconsistent estimate of how much effort a task involves — which makes it notoriously difficult to compare fairly between different teams, or even to trust completely within one team over time, since estimation habits can quietly drift. Throughput sidesteps that whole problem by counting something concrete and unambiguous: how many items actually got finished, full stop.

It is worth understanding why this distinction actually matters in practice, not just in theory. A team’s velocity can rise simply because they have started estimating tasks more generously, even if their true output has not changed at all — a subtle, easy‑to‑miss distortion that can quietly mislead planning. Throughput does not have this vulnerability, since a finished task is a finished task, regardless of how anyone estimated its size beforehand.

None of this means velocity is worthless — it can still offer a useful internal signal for a single team tracking its own trends over time. The caution is mainly about comparing velocity across different teams, or treating it as an objective, universal measure of productivity, when it is really a somewhat subjective, team‑specific number shaped by that team’s own estimation habits.

This single idea quietly threads through an enormous range of everyday systems, far beyond the obvious cases of networks and software teams.

This single idea quietly threads through an enormous range of everyday systems, far beyond the obvious cases of networks and software teams.

Airports offer a particularly vivid, familiar example. A busy airport’s throughput might be measured in passengers processed through security per hour — a number shaped by staffing, equipment, and how smoothly the whole system coordinates, quite separate from how fast any single traveller personally moves through the line.

Hospitals track a version of this too, watching how many patients a particular department can genuinely treat and discharge within a day — a number with real consequences for care quality, especially during unusually busy periods when demand surges unpredictably.

Public transportation systems think about throughput constantly, even if they rarely use that exact word. A subway line’s real value is not just how fast one single train moves — it is how many passengers the whole system can genuinely move through a station during a busy morning rush, which depends on train frequency, platform design, and how smoothly boarding and alighting actually happen in practice.

Even something as ordinary as a coffee shop during a morning rush is a throughput story in miniature. A shop might brew coffee quickly for any single customer, but its real throughput — how many customers actually get served across a busy hour — depends just as much on how efficiently the whole line moves, how orders get taken, and how quickly payment happens, not merely on how fast the espresso machine itself runs.

It helps to see throughput playing out in systems people actually rely on, rather than staying purely theoretical.

It helps to see throughput playing out in systems people actually rely on, rather than staying purely theoretical.

Large streaming platforms obsess over throughput at a genuinely massive scale, since delivering smooth video to millions of simultaneous viewers depends entirely on sustaining enormous, steady throughput across a sprawling, globally distributed infrastructure. A brief dip in throughput during a hugely popular live event can mean millions of viewers simultaneously experiencing buffering, which is exactly why these platforms invest so heavily in monitoring and improving this one specific number.

E‑commerce platforms track transaction throughput especially closely around major sales events, when the number of purchases attempted per second can spike dramatically beyond an ordinary day. A payment system that cannot sustain enough throughput during that spike risks failed transactions at the exact moment a retailer most needs everything to work flawlessly.

Software teams practising Kanban lean on throughput data to make genuinely useful forecasts, using historical completion rates to answer questions like “roughly when might this batch of work realistically finish?” with actual statistical grounding, rather than relying purely on hopeful guesses made at the start of a project.

Ride‑sharing and delivery platforms depend on a particularly dynamic version of throughput thinking, since demand for rides or deliveries can swing dramatically within just a few minutes — a sudden rainstorm, a major event letting out, a holiday rush. These platforms constantly monitor real throughput against real demand, adjusting incentives and matching algorithms on the fly to keep the two as closely balanced as possible.

Manufacturing companies producing physical goods track throughput at nearly every stage of their production process, often displaying real‑time counts on factory floor screens. This is not just a curiosity — a sudden, unexplained dip in throughput on a production line is often the very first, earliest sign that something has gone subtly wrong with a machine, a material supply, or a process step, long before the problem becomes obvious in any other way.

Tracking throughput carefully pays off in ways that go well beyond simply having an interesting number to look at.

Tracking throughput carefully pays off in ways that go well beyond simply having an interesting number to look at.

That last point deserves real attention. Without a clear throughput number, conversations about performance or capacity tend to rely on gut feelings and impressions, which are notoriously unreliable. A concrete, consistently measured throughput figure turns vague impressions into an actual, shared fact everyone can reason about together.

There is a quieter benefit worth naming too: throughput data, tracked honestly over time, tends to build genuine trust between teams and the people relying on their output. A team that can point to a consistent, well‑understood throughput history has a far easier time having honest, grounded conversations about realistic timelines than a team relying purely on optimistic promises made under pressure.

Throughput is not a perfect, risk‑free metric, and treating it as the only thing that matters can lead a team or system astray.

Throughput is not a perfect, risk‑free metric, and treating it as the only thing that matters can lead a team or system astray.

This connects to a well‑known caution in measurement generally: once a number becomes a target people are judged against, there is a real risk people start optimising for the number itself rather than for the genuine value it was originally meant to represent. Throughput is a wonderful diagnostic tool precisely because it is honest — but that honesty can be undermined the moment it becomes a pressure tactic rather than a source of insight.

Variability is another subtle risk worth naming. Two systems can report the exact same average throughput while behaving completely differently underneath — one delivering a steady, predictable stream of output, the other lurching between bursts of activity and long stretches of nothing. An average alone cannot distinguish between these two very different realities, which is why experienced engineers and managers often look at the full spread of data, not just the single averaged number, before drawing conclusions.

Modern cloud infrastructure has made monitoring and improving throughput dramatically more accessible than it once was, with dashboards, alerts, and automated scaling tools built specifically around this one measurement.

Modern cloud infrastructure has made monitoring and improving throughput dramatically more accessible than it once was, with dashboards, alerts, and automated scaling tools built specifically around this one measurement.

Load balancers — the traffic directors sitting in front of many cloud applications — actively work to maximise throughput by spreading incoming requests evenly across multiple servers, preventing any single machine from becoming a bottleneck that drags the whole system’s numbers down. Auto‑scaling tools take this further, automatically adding more capacity the moment demand threatens to outpace current throughput, and quietly removing that extra capacity again once demand settles back down.

Techniques like compression and connection reuse also play a real role here, letting systems accomplish more genuine work within the same available capacity, effectively squeezing more real throughput out of an unchanged underlying connection.

Cloud monitoring tools have also made it far easier to spot throughput problems before they become genuine emergencies. Rather than waiting for customers to complain about a slow application, modern dashboards can alert an engineering team the moment throughput starts trending in the wrong direction, giving them a chance to investigate and respond while the problem is still small and manageable.

Improving throughput almost always involves some kind of trade‑off, and being honest about the costs involved leads to far smarter decisions than chasing bigger numbers blindly.

Improving throughput almost always involves some kind of trade‑off, and being honest about the costs involved leads to far smarter decisions than chasing bigger numbers blindly.

That last row deserves particular attention, since it is the trap many teams and systems fall into. Simply demanding higher throughput — pushing more data through a strained connection, or pressuring a team to finish more tasks without changing anything structural — rarely produces genuine, lasting improvement. Real throughput gains almost always come from addressing an actual limiting factor, not from wishing the number were higher.

It is worth being realistic about diminishing returns too. The first improvements to a genuinely constrained system often produce dramatic gains, since a badly bottlenecked system usually has an obvious, easy‑to‑fix constraint sitting right at the front. Later improvements tend to yield smaller and smaller gains, as the easy wins get used up and each further increase in throughput requires proportionally more investment to achieve — a pattern worth expecting rather than being surprised by.

A system’s overall throughput is always limited by its slowest, most constrained part — never by its fastest one. This idea, sometimes called the theory of constraints, explains why so many well‑intentioned improvements disappoint.

Perhaps the single most important idea connected to throughput is this: a system’s overall throughput is always limited by its slowest, most constrained part — never by its fastest one. This is sometimes called the theory of constraints, and it explains why throughput improvements so often disappoint when they target the wrong piece of a system.

Picture a three‑stage process where the first stage can handle 100 items an hour, the middle stage can only manage 20, and the final stage could handle 150. No matter how fast the first and last stages are, the entire system’s real throughput is stuck at 20 items an hour, because everything has to pass through that middle bottleneck. Speeding up the already‑fast stages accomplishes nothing for overall throughput; only fixing the bottleneck itself moves the needle.

This principle applies just as cleanly to a software team’s workflow as it does to a factory line or a computer network. A team that writes code quickly but has a slow, backed‑up review process is not limited by how fast anyone writes code — their real throughput is limited by how quickly reviews get done, no matter how impressively fast everything else moves.

There is a genuinely counterintuitive lesson buried in this idea, one worth sitting with: sometimes deliberately slowing down a non‑bottleneck part of a system can actually help overall throughput, by preventing unfinished work from piling up faster than the bottleneck can absorb it. A fast first stage that constantly overwhelms a slow middle stage with more half‑finished work than it can handle often creates more chaos and delay than it solves, even though every individual stage looks impressively busy.

Throughput is a genuinely powerful number, but it is not the only measurement that matters. Knowing when to lean on it — versus reaching for a different metric — makes a real difference.

Throughput is a genuinely powerful number, but it is not the only measurement that matters, and knowing when to lean on it — versus reaching for a different metric — makes a real difference.

Most healthy systems and teams end up tracking several complementary metrics side by side rather than fixating on just one, since each one illuminates a different part of the same underlying picture.

That guiding sentence captures the discipline worth holding onto: throughput is an excellent diagnostic tool for understanding how a system genuinely performs, but it works best alongside other measures of quality and outcome, not as a lone number pursued at any cost.

A useful habit for any team or engineer is to pair every throughput number with a quick, honest second question: “And is what we are producing actually good?” Asking both questions together, consistently, is what separates genuinely healthy performance measurement from a narrow obsession with volume alone.

Ideas like this are easiest to remember through a story, so imagine a small customer support team at a company called Harborline, handling incoming help tickets. Here is how throughput thinking might play out for them.

Notice what Harborline did not do: they did not simply ask everyone to “work faster” across the board, and they did not add headcount randomly. They measured their real throughput, found the actual constraint holding it back, and fixed that specific thing — exactly the disciplined approach that turns a vague sense of being overwhelmed into a targeted, effective fix.

It is worth imagining how differently this could have gone with a less disciplined approach. Harborline could easily have responded to the growing backlog by simply asking everyone to “work harder” or by hiring several new general support staff, without ever identifying that one specific approval step as the actual constraint. That kind of response often burns real money and goodwill while barely moving the needle, precisely because it never touches the thing actually holding throughput back.

A handful of specific mistakes come up again and again in throughput conversations. Each one is worth naming plainly, so it can be spotted early — ideally before it becomes a problem worth escalating.

Chasing the Number Instead of the Goal

Treating throughput as a target to hit, rather than a diagnostic to learn from, can quietly encourage shortcuts that boost the number while hurting genuine quality or value.

Optimising the Wrong Part of the System

Speeding up a stage that is not the actual bottleneck feels productive but changes nothing about overall throughput.

Measuring Over Too Short a Window

Looking at throughput over a single hour or a single day can produce noisy, misleading swings that do not reflect genuine underlying trends.

Comparing Incomparable Systems

Comparing raw throughput numbers between very different teams, networks, or systems, without accounting for their different contexts, often leads to unfair or misleading conclusions.

Forgetting to Define “Done” Clearly

In project settings especially, an unclear or inconsistent definition of when work truly counts as finished quietly undermines the reliability of any throughput number built on top of it.

Ignoring Variability Behind the Average

Reporting a single average throughput number, without looking at how much it actually swings week to week, can hide real instability that a steady‑looking average quietly papers over.

Good throughput practice tends to follow a consistent handful of habits, regardless of whether the context is networking, manufacturing, or project management.

Good throughput practice tends to follow a consistent handful of habits, regardless of whether the context is networking, manufacturing, or project management.

• Define terms clearly before measuring. Agree exactly what is being counted, and exactly when something counts as finished.
• Measure consistently over a sensible window. Avoid drawing conclusions from single, noisy snapshots of a much longer trend.
• Find the real bottleneck before optimising. Improving the wrong part of a system wastes effort without moving the actual number.
• Pair throughput with a quality check. Track a complementary measure of correctness or satisfaction alongside raw volume.
• Use it to inform, not to pressure. Treat throughput as a source of honest insight, not a stick used to demand more output.
• Revisit definitions as things evolve. What counted as “done” or “delivered” a year ago may deserve a fresh look today.
• Look at the full spread, not just the average. A single averaged number can hide meaningful swings worth understanding.
• Share throughput data openly. Transparent, consistently reported numbers build far more trust than numbers revealed only when convenient.

None of these habits require sophisticated tools or a large team — they mostly come down to treating throughput as a genuinely useful lens for understanding a system honestly, rather than a scorecard to be gamed or a number pursued without regard for what it actually represents.

A few questions about throughput come up again and again, in conversations ranging from casual curiosity to serious system design decisions. Here are short, honest answers to the ones that surface most often.

If you remember nothing else from this guide, remember the six ideas below — and the quiet habit of pairing every throughput number with an honest question about the value behind it.

At its heart, throughput is one of those quietly powerful ideas that shows up wherever real work happens — on factory floors, across fibre optic cables, inside team dashboards, and behind every well‑planned capacity decision. Systems and teams that respect it, measure it honestly, and pair it with an equally honest attention to the quality of what they produce tend to be the ones that stay predictable under growth, calm under pressure, and trustworthy in the eyes of the people depending on their output.