# Slow Productivity: Why Looking Busy Is Costing You Real Output
> Cal Newport's Slow Productivity argues that visible busyness is a poor proxy for real output. Ten quotes from the book, and what its three principles mean for software developers and engineering leaders.

*21 August 2026* · Jamie Taylor


This post is part of an ongoing series on the books that I have read as part of my continual professional development (CPD). All of my CPD posts are available at the following link: [Continual Professional Development](/tags/continual-professional-development/)


There is a particular kind of day that every knowledge worker recognises. Your status dot stays green from nine until six. Your inbox is tidy. You moved between four meetings, replied to every message within minutes, and closed a respectable number of small tickets. By every visible measure you were productive. And yet the one piece of work that actually mattered, the design you needed to think through or the gnarly bug sitting at the heart of the release, is exactly where it was when you sat down. You were busy all day. You accomplished almost nothing.

Cal Newport's "[Slow Productivity: The Lost Art of Accomplishment Without Burnout](https://app.thestorygraph.com/books/c4037cdf-1b2d-4980-ba6a-4317b786242f)" is a book about why that day keeps happening, and what to do about it. Newport is worth listening to here because he is not a productivity guru selling a morning routine. He is a computer science professor at Georgetown, an academic who has to produce original research while teaching and writing books, and he is the author of Deep Work, the book that put the phrase into common circulation. He has spent his career studying how people do cognitively demanding work, and Slow Productivity is his attempt to define what the word "productivity" should even mean for those of us who think for a living.

His argument rests on three principles: do fewer things, work at a natural pace, and obsess over quality. Before any of those land, it helps to clear away the objection that a busy decision maker raises straight away, which is that this all sounds like a polite excuse to do less. It isn't. As Newport puts it, "Slowing down isn't about protesting work. It's instead about finding a better way to do it." The book is, underneath everything, a more honest account of how good work actually gets made. It is also a short book, barely 224 pages, which is itself a quiet argument for its own thesis.

This is the third book in this column to circle the same ground from a different side. [Jake Knapp and John Zeratsky's Make Time](/blog/continual-professional-development/make-time-why-focus-is-an-energy-problem-not-a-discipline-problem/) is about designing your day so your attention has somewhere to go. [Alex Soojung-Kim Pang's Rest](/blog/continual-professional-development/rest-why-stepping-away-from-the-screen-is-part-of-the-work/) is about treating recovery as part of the work rather than the absence of it. Slow Productivity asks the question sitting underneath both of those: what if the sheer volume of work, and the way we have learned to measure it, is the thing that is broken? Where the other two fix the day and the recovery, this one questions the workload itself.

What follows are the ten passages I found most useful, and what each one means for software developers and the people who lead them.

## When Activity Became the Proxy for Value


> It was from this uncertainty that a simple alternative emerged: using visible activity as a crude proxy for actual productivity. If you can see me in my office–or, if I'm remote, see my email replies and chat messages arriving regularly–then, at the very least, you know I'm doing something. The more activity you see, the more you can assume that I'm contributing to the organization's bottom line.
>
> — Cal Newport, [Slow Productivity](https://app.thestorygraph.com/books/c4037cdf-1b2d-4980-ba6a-4317b786242f)


Newport gives this phenomenon a name, pseudo-productivity, and the diagnosis is the foundation everything else in the book is built on. When work was physical, productivity was easy to see and count: cars off the line, bushels in the barn. When work moved into our heads, that easy measure vanished, and rather than invent a better one, we reached for the nearest visible substitute. Are you at your desk? Are the messages flowing? Then you must be working. The activity became the evidence.

A developer feels this in their bones. The green presence dot, the speed at which you answer Slack, the commit streak on your profile, the lines of code in the pull request, the simple fact of being online late: none of these measures whether valuable software got built, yet all of them still function as proof that you are doing your job. The afternoon I described at the top of this piece is pseudo-productivity in miniature. Every visible signal said "productive". The thing that mattered did not move. The two have almost nothing to do with each other, and most of us have spent years optimising for the wrong one because the wrong one is the one people can see.

This is exactly the trap that serious engineering measurement tries to climb out of, and it is the failure mode I keep meeting in the teams I work with. I have written before about [how DORA metrics get misread and what they actually measure](/blog/when-agile-isnt-agile-how-dora-metrics-reveal-whats-really-broken/), and about [building engineering dashboards that boards can actually understand](/blog/from-trust-us-to-look-at-this-building-engineering-dashboards-that-boards-actually-understand/). Pseudo-productivity is what rushes in to fill the vacuum when you have no honest measure of outcome. You count motion, because motion is easy to count. The hidden cost is steep: you train an entire team to perform busyness for the metrics, and performing busyness is itself exhausting, time-consuming work that crowds out the deep, quiet, unglamorous effort that actually ships the product.

## Fewer Things Is the More Productive Choice


> The first principle of slow productivity provides what is ostensibly professional advice. Working on fewer things can paradoxically produce more value in the long term: overload generates an untenable quantity of nonproductive overhead.
>
> — Cal Newport, [Slow Productivity](https://app.thestorygraph.com/books/c4037cdf-1b2d-4980-ba6a-4317b786242f)


This is the first principle, and it is the one that sounds wrong to business ears. Newport even acknowledges the resistance elsewhere in the book, noting how knowledge-work culture is so thoroughly built around juggling more and more that the idea of doing fewer things, however logical in the abstract, feels impossible in practice. If fewer things produced more value, surely someone would have noticed by now. The word doing the heavy lifting in the quote is "overhead". Every active project carries a tax that has nothing to do with the work itself: the status updates, the check-in meetings, the context you have to reload every time you switch back to it, the messages from people who want to know how it is going. Run five projects at once and you can spend most of your week servicing the overhead and almost none of it doing the actual work.

For a developer this is the difference between a focused fortnight and a fractured one. Five tickets in progress does not mean five tickets moving. It means five mental models you are paying rent on, five threads you are half-holding, five things you feel guilty about whenever you are touching any one of them. Pick up two instead and finish them, and you have not only shipped more, you have spent far less of your energy on the overhead of merely keeping track. The arithmetic feels counterintuitive until you have lived both versions, and then it feels obvious.

For an engineering leader, this is one of the most useful ideas in the book, because the overload is usually something you are causing without meaning to. A backlog stuffed with forty "priorities" is not ambition, it is overhead generation at scale. Every item you assign or leave hanging over someone is a small ongoing cost paid in attention, whether or not anyone is actively working on it. The leadership move is to have the discipline to decide what the small number of things that matter this quarter actually are, and to protect the team from the rest long enough for the real work to get done, instead of pushing them to juggle the forty faster.

## The Task Is Never the Whole Cost


> Most people focus on the difficulty of a project, or the total amount of time it might require. But once you understand the havoc wreaked by an overstuffed to-do list, it makes sense that the task footprint of a project should be taken just as seriously.
>
> — Cal Newport, [Slow Productivity](https://app.thestorygraph.com/books/c4037cdf-1b2d-4980-ba6a-4317b786242f)


Newport's idea of a "task footprint" is the practical follow-on from the first principle, and it is one of those concepts you cannot unsee once you have it. When we size up a piece of work we ask how hard it is and how long it will take. We almost never ask how much administrative surface area it will create: the emails it will spawn, the people it will require us to coordinate with, the recurring meetings it will add to the calendar, the small ongoing supervision it will demand for weeks. A task can be quick to do and still have an enormous footprint, and the footprint is what quietly eats your days.

Developers know this even if they have never had the word for it. Take a small feature that touches three teams. The coding might be a day. The footprint is a fortnight of Slack threads, design sign-offs, a recurring sync, two rounds of review across time zones, and a deployment you have to babysit. Meanwhile a genuinely hard refactor that you can do alone, head down, has almost no footprint at all. If you plan your week by difficulty or by hours-of-typing, you will keep mis-estimating, because the thing draining your week was never the typing. It was everything orbiting the task.

For leaders, the task footprint is the missing variable in most planning conversations, and accounting for it changes which work you say yes to. Two features may look equally valuable on a roadmap, but if one carries triple the coordination overhead, they are not equal at all, and the cheaper-looking one may be the expensive one. The same lens applies to how you protect your people. Heaping a developer with five low-effort but high-footprint tasks can wreck their fortnight more thoroughly than one genuinely difficult problem ever would, and the damage is invisible if all you are tracking is how "small" each task looked when you handed it over.

## A Little Friction Slows the Flood


> It's common, for example, for a boss to shoot off an idea to an employee on a whim. When this request gets formalized, however, and the boss sees that they need to provide you with more information, and they're confronted with the reality of your current workload, they might simply respond, "On second thought, let's put a pin in this for now." Sometimes a little friction is all it takes to slow down a torrent of incoming work.
>
> — Cal Newport, [Slow Productivity](https://app.thestorygraph.com/books/c4037cdf-1b2d-4980-ba6a-4317b786242f)


If the first principle is "do fewer things", the obvious question is how, given that the work keeps arriving whether you want it to or not. Part of Newport's answer is wonderfully low-tech: add a small amount of friction to the intake. Most overload does not arrive as a considered decision. It arrives as a casual "could you just" tossed off in passing, costless to the person tossing it and expensive to the person catching it. Make the request take slightly more effort to make, and a surprising amount of it evaporates before it ever reaches you, because it was never that important to begin with.

In practice this is the real power of a simple intake process. When a request has to be written down in a shared form, with a line for why it matters and a line for the desired outcome, two things happen at once. The genuinely important work gets captured properly, and the whims die on contact with the small effort of articulating them. You are not refusing anything. You are simply asking the request to prove it is real, and a lot of it cannot.

Newport is careful to note elsewhere that there is a myth around how hard it is to say no, when in truth saying no is not so bad once you have solid evidence that it is the only reasonable answer. Friction is how you surface that evidence without ever having to be the difficult one. For an engineering leader this is gold, because you are usually both the source of the casual requests and the person responsible for protecting the team from them. Routing work through a visible queue, rather than letting it land as a tap on the shoulder or a quiet DM, gives the team a way to work on fewer things without anyone having to fight about it. Done well, it protects focus instead of adding red tape.

## Unrelenting Intensity Is a Performance, Not a Pace


> Working with unceasing intensity is artificial and unsustainable. In the moment, it might exude a false sense of usefulness, but when continued over time, it estranges us from our fundamental nature, generates misery, and, from a strictly economic perspective, almost certainly holds us back from reaching our full capabilities. A more natural, slower, varied pace to work is the foundation of true productivity in the long term.
>
> — Cal Newport, [Slow Productivity](https://app.thestorygraph.com/books/c4037cdf-1b2d-4980-ba6a-4317b786242f)


This is the second principle, work at a natural pace, and the phrase I keep coming back to is "from a strictly economic perspective". Newport is not making a wellbeing argument here, or at least not only one. He is saying that flat-out, every-day intensity is bad economics. It feels useful because it looks useful, and it produces worse work over any horizon longer than a sprint. The varied, slower pace is the more productive way to work, and it happens to be the kinder one as well.

The software industry has actually known this for a long time and then spent twenty years ignoring it. The original Agile Manifesto principles explicitly called for a sustainable pace, the idea that a team should be able to maintain its rhythm indefinitely. Somewhere along the way "sustainable pace" got redefined as "maximum pace, forever", which is a contradiction nobody bothered to resolve. Anyone who has been through a death march knows how it ends: the code written in the exhausted final weeks is the code you spend the next year apologising for, and the velocity you bought was borrowed at a punishing rate of interest.

This connects directly to the case I made drawing on [Alex Soojung-Kim Pang's Rest](/blog/continual-professional-development/rest-why-stepping-away-from-the-screen-is-part-of-the-work/), that stepping away from the screen is part of the work rather than time stolen from it. Newport is approaching the same truth from the workload side: not "rest more after the intensity", but "stop treating relentless intensity as the natural state in the first place". For a leader, the practical question is whether your team's normal operating mode is a pace they could genuinely hold for years, or a sprint they are privately hoping to survive. If it is the latter, you do not have a high-performing team. You have a team running down a battery you will eventually have to pay to replace.

## You Are Guessing How Long It Takes


> A reality of personal productivity is that humans are not great at estimating the time required for cognitive endeavors. We're wired to understand the demands of tangible efforts, like crafting a hand ax, or gathering edible plants. When it comes to planning pursuits for which we lack physical intuition, however, we're guessing more than we realize, leading us to gravitate toward best-case scenarios for how long things might take. We seem to seek the thrill that comes from imagining a wildly ambitious timeline during our planning: "Wow, if I could finish four chapters this fall, I'd really be ahead of schedule!" It feels good in the moment but sets us up for scrambling and disappointment in the days that follow.
>
> — Cal Newport, [Slow Productivity](https://app.thestorygraph.com/books/c4037cdf-1b2d-4980-ba6a-4317b786242f)


There is no group on earth this lands harder for than software developers. We are professionally, almost comically, bad at estimating cognitive work, and Newport explains why with real generosity: we evolved an intuition for physical tasks, and we simply do not have the equivalent instinct for thinking-shaped work. So we guess, and because the optimistic guess is the pleasant one, we reliably guess low. The thrill of "I could have this done by Friday" is genuine, and it is the same thrill every time, regardless of how many previous Fridays have come and gone with the thing unfinished.

Every story-point debate, every "it's basically done" that precedes another week of work, every roadmap built on best-case timelines stacked end to end, is this exact human flaw wearing a process costume. The flaw does not go away because you adopted a planning framework. It just gets laundered through one and given a number.

The honest response is to build the optimism bias into how you plan, rather than to estimate harder as though more rigour applied to a guess could turn it into a fact. That means you deliberately pad, halve the ambition, leave genuine slack, and treat a confident estimate with more suspicion than a hesitant one. For a leader, this reframes a conversation you are probably having in the wrong terms. When a team consistently overruns, the instinct is to read it as a discipline or competence problem and to push for tighter estimates. Newport's framing says it is a species-level limitation, predictable and universal, and that planning which assumes the best case is not optimistic, it is simply wrong on a schedule. Plan for how cognitive work actually behaves and the scrambling and disappointment he describes largely stop being your team's default emotional weather.

## A Drop in the Bucket, Every Day


> If you collect modest drops of meaningful effort for 365 days, McPhee reminds us, you'll end the year with a bucket that's pretty damn full. This is what ultimately matters: where you end up, not the speed at which you get there, or the number of people you impress with your jittery busyness along the way.
>
> — Cal Newport, [Slow Productivity](https://app.thestorygraph.com/books/c4037cdf-1b2d-4980-ba6a-4317b786242f)


The image comes from the writer John McPhee, and it is the gentle, long-range counterweight to the whole culture of frantic urgency. A drop a day looks like nothing on any given afternoon. Compounded across a year, it fills the bucket. The work that lasts is almost never produced in a heroic, sleepless burst; it accumulates, quietly, from modest amounts of real effort applied consistently over a length of time that resists being rushed. Newport's own phrasing elsewhere is blunter and worth keeping somewhere you can see it: the path is long, so pace yourself.

For developers, this is permission to stop measuring a day by its drama. The afternoon where you carefully untangled one genuinely hard problem and committed forty good lines can be worth more than the frantic day of context-switching across nine threads, even though the frantic day felt far more productive while you were inside it. The serious things we build, real expertise, a system that holds up under load, a reputation for code people trust, are bucket-filling projects. They do not respond to sprints. They respond to showing up and adding a real drop, most days, for a long time.

For leaders, the bucket is a reminder to celebrate the right thing. It is tempting to reward visible intensity, the developer who is always online and always firefighting, because the intensity is easy to see and feels like commitment. But "jittery busyness", in Newport's lovely phrase, is precisely what pseudo-productivity rewards and precisely what fills no bucket. The people steadily filling theirs, the quiet ones doing consistent, careful work without performing the effort, are often the ones your activity metrics overlook entirely. Where the team ends up at the end of the year is the only measure that survives contact with reality. The speed and the theatre along the way are not.

## Quality Is the Slow Worker's Secret Weapon


> Obsessing over quality isn't just about being better at your job. It's instead a secret weapon of sorts for those interested in a slower approach to productivity.
>
> — Cal Newport, [Slow Productivity](https://app.thestorygraph.com/books/c4037cdf-1b2d-4980-ba6a-4317b786242f)


The third principle, obsess over quality, is what stops slow productivity from collapsing into simply doing less. This is the line that holds the whole argument together. You do not get to do fewer things and work at a humane pace by default, by opting out while everyone else sprints. You earn it. Quality is the currency you earn it with, which is why Newport calls it a secret weapon rather than just a virtue. It is the mechanism, not the moral.

For a developer, this should be reassuring, because it points at the part of the job most of us actually care about. The craft is not a luxury you indulge once the "real" delivery pressure eases. It is the thing that, over time, buys you the standing to push back on the delivery pressure in the first place. The developer whose work is consistently excellent, whose changes are clean and whose systems quietly keep working, accrues a kind of trust that slowly rewrites the terms they get to work under.

For a leader, the warning runs the other way. A culture that worships activity over quality is busily dismantling its own foundation, because it removes the only honest basis on which anyone could ever be trusted to slow down and do less. If the work is measured by motion, then more motion is always the answer, and the team is locked on the hamster wheel by design. Make quality the thing you genuinely prize and you create the conditions in which a calmer, more deliberate, ultimately more productive way of working becomes not just possible but rational.

## Quality Buys You Freedom


> Obsess over the quality of what you produce, even if this means missing opportunities in the short term. Leverage the value of these results to gain more and more freedom in your efforts over the long term.
>
> — Cal Newport, [Slow Productivity](https://app.thestorygraph.com/books/c4037cdf-1b2d-4980-ba6a-4317b786242f)


This is the secret weapon spelled out as a strategy, and the second sentence is the one that matters. Quality is not the destination; it is the means of exchange. You produce excellent work, and you spend the standing it earns to buy autonomy: more control over what you take on, more room to set your own pace, more freedom from the casual demands that pull lesser-regarded work in every direction. The freedom is the prize. The quality is how you pay for it.

Developers live a version of this whether they have named it or not. The engineer trusted to disappear for two weeks and return with something genuinely solid has bought that latitude with a track record. Nobody hands it out as a perk; it is earned, change by careful change, until the trust is deep enough that the leash comes off. This is why I keep arguing the unglamorous case for investing in craft, including the [mechanical sympathy that comes from giving engineers time to actually optimise](/blog/mechanical-sympathy-the-case-for-giving-engineers-time-to-optimise/) rather than just ship and move on. That time is how the team accumulates the quality that, in turn, accumulates freedom.

For a leader, the chain runs in a specific direction, and getting the order wrong is a common and expensive mistake. Freedom follows quality; it does not precede it, and it cannot be granted as a substitute for it. But the corollary is the part most organisations miss: if you never give your people the space to do excellent work, because every hour is spoken for by the next urgent thing, they can never build the track record that would have earned them, and you, a calmer and more autonomous way of operating. You are not just costing them their freedom. You are trapping yourself in the supervision and firefighting that low-quality, high-activity cultures make permanently necessary.

## The Knowledge Worker Must Direct Themself


> Companies might standardize on the software that their employees use, but systems for assigning, managing, organizing, collaborating on, and ultimately executing tasks are typically left up to each individual. "The knowledge worker cannot be supervised closely or in detail," argued Peter Drucker in his influential 1967 book, The Effective Executive, "He can only be helped. But he must direct himself."
>
> — Cal Newport, [Slow Productivity](https://app.thestorygraph.com/books/c4037cdf-1b2d-4980-ba6a-4317b786242f)


Newport reaches back nearly sixty years to Peter Drucker for this, and the age of the observation is part of its force. We have understood that knowledge workers must direct themselves since 1967, and we have spent much of the time since building tools and cultures that pretend otherwise. The organisation can standardise the editor and the ticketing system, but it cannot meaningfully supervise the actual work, the thinking, the design, the judgement, because that work happens somewhere a manager cannot watch. The worker has to steer it. There is no other option that produces good results.

For developers, Drucker's line is a quiet statement of professional dignity, and also of responsibility. The good ones already know that nobody can manage the inside of a hard problem for them. The corollary is that how you organise your own work, how you protect your focus, choose what to ignore, and set your own pace, is not a personal indulgence around the edges of the job. It is the job. Self-direction is the skill, and the principles in this book are, in the end, tools for exercising it deliberately rather than by accident.

For leaders, this is the idea that closes the loop back to where we started. Pseudo-productivity is, at root, a failure to believe Drucker. It is what you fall back on when you do not trust your people to direct themselves, so you measure the one thing you can see, which is their visible activity, and in doing so you actively prevent the self-direction that produces the work you actually want. You cannot demand both surveillance and autonomy. The leader's real job is the one Drucker named: not to supervise the work, which is impossible, but to help. Set the direction, remove the obstacles, protect the conditions, and then trust people to fill their own buckets. Everything else in Slow Productivity depends on a leader willing to do that.

## The Argument in One Sentence


Slow Productivity is a short book making a single, well-defended claim, and it is worth reducing to one sentence you can actually act on: do fewer things, at a pace you could sustain for years, and care enough about quality that it earns you the freedom to keep working that way.

The diagnosis underneath it all is pseudo-productivity, the quiet swap of visible activity for real value that we never quite decided to make and have never quite undone. Almost everything that exhausts a modern software team grows out of that one substitution. We measure motion, so we generate motion. We reward busyness, so we perform busyness. We mistake intensity for productivity, and then wonder why the actual output is so thin and the people producing it so tired.

For a developer, the practical version is smaller than it sounds and entirely within reach. Carry fewer things at once and finish them. Account for the footprint of a task, not just its difficulty. Distrust your own optimistic estimates, because they are wrong in a predictable direction. Add a real drop to the bucket most days, and let the occasional dramatic day be the exception rather than the standard you measure yourself against. None of it requires you to care less. It requires you to aim your care at the work instead of at the appearance of work.

For a leader, the stakes are larger, because you are not arranging one person's week, you are setting the conditions an entire team works inside, and those conditions decide whether real productivity is even possible. Whether the backlog generates overhead faster than the team can clear it. Whether the pace is one people could genuinely hold for years. Whether quality is prized enough to be worth pursuing, and trust extended far enough to let people direct themselves. Getting that right is some of the most consequential work an engineering leader does, and it is the kind of work I do regularly with the leaders I support.

---

If your team is busier than ever and somehow shipping less of what matters, that gap is usually pseudo-productivity rather than a lack of effort, and it is a conversation I have often with engineering leaders. [Let's talk](/schedule-consultation/).