The math that proves you're doing too much work
Little's law is a simple concept of operations that demonstrates you need to limit the work arrival or the work in progress to improve a system. Read: "Everything Starts Out Looking Like a Toy" #262
Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.
This week’s toy: the NFL is introducing robotic measurement of the first down line in preseason games. I’m not sure whether to think this is great or worry that a bunch of line judges are going to lose their jobs. There’s not a whole lot of suspense in wondering whether a robot observer is going to judge that play a first down.
Edition 262 of this newsletter is here - it’s August 4, 2025.
Thanks for reading! Let me know if there’s a topic you’d like me to cover.
The Big Idea
A short long-form essay about data things
⚙️ The math that proves you're doing too much work
You know that feeling when your team is drowning in work? When every task feels urgent, every request seems important, and you're constantly starting new things but never finishing anything?
I learned the hard way that this isn't a productivity problem—it's a math problem. And the solution isn't working harder. It's doing less.
The problem everyone knows
Here's what happens in every organization I've worked with: Teams get overwhelmed with "interesting" work that all takes similar time. A 2-hour task feels as important as a 2-day task when you're drowning in work. Context switching makes everything feel urgent. And before you know it, you're spreading your effort across everything instead of focusing on anything.
Sound familiar? You're not alone.
The real issue isn't that teams aren't working hard enough. It's that they're working on too many things at once. And there's a mathematical law that proves this.
The hidden math behind your backlog
Little's Law is a deceptively simple formula that explains why most operational problems aren't about speed—they're about having too much work in progress:
L = λ × W
Where:
L = Work in Progress (your backlog)
λ = Arrival Rate (new work coming in)
W = Cycle Time (how long work takes)
The counterintuitive truth? Most teams try to optimize W (speed) when they should be optimizing L (work in progress). You literally cannot work faster than your arrival rate allows.
Here's what this means in practice: If you have 100 items in your backlog, and new work arrives at 10 items per week, and each item takes 2 weeks to complete, you're doomed. Your backlog will grow by 80 items per week (10 arrivals × 8 weeks = 80 items added while you complete 5).
The solution isn't to work faster. It's to stop starting new work.
Why every piece of work feels important
The real challenge isn't the math, it's the psychology of seeing all of that work in one place. When you're overwhelmed, every piece of work starts to look equally valuable because:
Similar cycle times create false equivalence. A 2-hour task feels as important as a 2-day task when you're drowning in work.
Context switching makes everything feel urgent. The task you're currently working on always seems most important.
Parkinson's Law takes over. Work expands to fill available time, so teams spread their effort across everything instead of focusing.
I've seen this pattern in every industry. Software teams with sprint backlogs that grow faster than completion rates. Customer service teams with queues that never shrink. Manufacturing lines clogged with too many products in process.
The teams that break this cycle don't work harder. They work less, but focus more.
What happens when you limit work?
Here's what I've seen when teams embrace this truth:
Software Development Example: A team I worked with had 20 features in their sprint backlog but only completed 5 per sprint. They were starting new work faster than they could finish it. The solution? Limit sprint capacity to 80% of theoretical maximum and create explicit "not doing" lists. Within three sprints, their completion rate doubled.
Customer Service Example: A support team had a growing queue because new tickets arrived faster than they could resolve them. The solution? Stop accepting new work until the backlog cleared to a manageable level. Customer satisfaction actually improved because issues got resolved faster.
Manufacturing Example: A production line was clogged with too many products in process. The solution? Implement Kanban limits on work in progress. Throughput increased because products moved through the system faster.
The fear of missing out
The biggest resistance comes from the fear of missing something valuable. "But it's all important work!" "We can't just ignore these requests!" "What if we miss something valuable?"
Here's the reality: When you're overwhelmed, most work has similar value. The difference between a "high-value" task and a "medium-value" task becomes meaningless when neither gets completed.
Completion creates more value than starting. A completed medium-value task is worth more than an abandoned high-value task.
Measuring and controlling work in progress
Step 1: Measure Your Current State
Count your work in progress (L)
Calculate your arrival rate (λ)
Measure your cycle time (W)
Step 2: Set Aggressive Limits
Limit WIP to 50% of current levels
Create explicit "not doing" lists
Establish clear completion criteria
Step 3: Enforce the Limits
Say "no" to new work until capacity opens
Batch similar work to reduce switching costs
Celebrate completion, not starting
Taking the bigger picture into account
This isn't just about efficiency—it's about effectiveness. Teams that limit work in progress:
Complete more high-value work
Reduce stress and burnout
Create space for innovation
Build momentum through wins
The most successful teams I've worked with aren't the ones that work the hardest. They're the ones that work the most focused.
Why this matters
The timing couldn't be better for this message. Teams are overwhelmed with "interesting" work that all takes similar time. AI tools are making it easier to generate work than complete it. Companies are struggling with execution despite having good ideas.
Little's Law isn't just a mathematical curiosity—it's the key to operational sanity. The teams that embrace this truth will be the ones that actually get important work done, while others drown in their own good intentions.
Your expertise isn't making you blind to opportunities. It's making you blind to the simple math that proves you're doing too much work.
The solution? Do less. But do it better.
What’s the takeaway? Little’s law is an axiom and not really a physical law. But it reminds us that there are few ways to lower the backlog besides limiting the arrival rate of new work and limiting the work in progress. You may not be able to control how long it takes to do current work, and you can be cautious about accepting new work (until the other work is done).
Links for Reading and Sharing
These are links that caught my 👀
1/ Smartphones cheat at being cameras - This piece compares the iPhone camera to a typical point and shoot digital camera, and you’ll notice some … odd things about the way the iPhone camera (and post-processing) have a way of changing the results. It’s a good reminder that subtle manipulation of images is happening all around us, and we don’t notice without a reference set.
2/ The everyday sport - in a weird and interesting twist, YouTube is becoming a magnet for sub-professional sports. “The YouTube golfer” is more accessible than the PGA tour and also, more relatable. I’ve seen a similar trend in visiting minor league baseball stadiums and finding it more charming than the bigs.
3/ The odds of venture - if you’ve ever wondered about the the conditions that create a winning outcome for VCs, this is a good read about how often that happens. (Spoiler: it’s often a single company that makes the return for an entire fund.)
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon