How To Do The Work

The Short Version of A Book That Should Have Been Shorter

How To Do The Work is essentially a guide about stopping the performance of productivity and actually doing the things that matter. Jason Fried and David Heinemeier Hansson wrote it to address the chronic overcomplication that has swallowed most modern knowledge work. The central argument is straightforward: most people and companies spend more time managing the appearance of work than doing the work itself. That observation alone is not novel, but the practical follow-through in the book is where it gets useful. The framework breaks down into four interlocking pieces. First, define what the actual work is. Not the meetings about the work, not the project management software tracking the work, not the status reports summarizing the work. The work itself. Second, protect time to do it. This means aggressively cutting everything that does not directly contribute to producing the work. Third, measure progress by output, not activity. If you spent eight hours in meetings but produced nothing tangible, you did not do the work. Fourth, accept that simplicity is harder than complexity and requires constant enforcement. People will drift back into busywork because it feels like progress even when it is not. I ran into this exact problem about two years ago when managing a product redesign. We had four project management tools, a shared dashboard, weekly standups, biweekly retrospectives, and a Kanban board that was always half-stale. The team felt like they were moving. They were not. We cut three of the four tools, eliminated the standups and retro, and moved to a single lightweight task list. In four weeks, shipping velocity roughly doubled because everyone actually had focused blocks of time instead of fragmented attention spans. It was the same number of people. Same skill set. Just less noise around the work.

Counter-Intuitive Things Beginners Miss

The first thing most people get wrong is assuming they need more structure to do the work. The book argues the opposite. Structure creates overhead. Each additional process step is a tax on actual production time. A team that starts with three mandatory reviews before any deliverable ships is paying a three-review tax on every piece of output. That tax compounds. A simple project with five deliverables now has fifteen review cycles sitting between completion and launch. By the time those reviews are scheduled, coordinated, and executed, momentum has dissipated and the context has shifted. The second miss is underestimating the social pressure to look busy. Even if you personally adopt a minimal-process approach, your organization will likely push back. Managers often interpret low meeting counts or sparse status updates as laziness rather than efficiency. You will need to learn to communicate results without padding the activity report. "Shipped the checkout flow in two weeks with zero blockers" carries less social weight than "Attended twelve meetings, updated eighty-three tickets, and created three documentation pages this sprint," even though the first statement is objectively more valuable. This is a real tension and the book acknowledges it but does not fully solve it. It is a cultural problem, not a process problem.

Where The Approach Breaks Down

The methodology works well for small to medium teams working on defined projects with clear deliverables. It breaks down in several scenarios. Highly regulated industries with mandatory audit trails and documentation requirements will find the simplicity constraints at odds with compliance obligations. Large organizations with multiple stakeholders who require visibility and sign-off at every stage cannot realistically eliminate the process without creating political risk. Research-heavy or exploratory work where the path is unknown and iteration cycles are long benefits from more structured checkpointing than the book recommends. In these cases, trying to force the minimal approach creates friction and resentment without gaining much efficiency. If you are in one of those environments, a hybrid model tends to work better. Keep the core production time protected and minimal, but layer on just enough process to satisfy compliance, stakeholder visibility, or coordination needs. The goal is not zero process. The goal is the minimum viable process that does not suffocate actual output. This distinction matters because the book sometimes reads as if simplicity is an absolute rather than a strategic choice dependent on context.

Practical Steps to Apply It

Start by auditing your current work week. Track everything you do in hour-long blocks for two weeks. Categorize each block as direct work, enabling work, or overhead. Direct work is writing code, designing interfaces, drafting copy, running experiments. Enabling work is meetings that unblock progress, reviews that prevent rework, coordination that synchronizes teammates. Overhead is everything else. Most people find overhead consumes forty to sixty percent of their week. That number is not a moral failing. It is a design problem. Once you have the data, identify the top three overhead categories and eliminate them first. If meetings are your biggest drain, negotiate a no-meeting Wednesday or cap all recurring meetings at twenty-five minutes. If status reporting is the problem, replace written updates with a single shared document that anyone can read asynchronously. The specific tactic matters less than the principle: remove the thing that generates the most busy signal with the least actual output. Then protect your direct work time. Block out two to four hour chunks on your calendar and treat them as non-negotiable. Turn off notifications. Communicate those blocks to your team so they stop interrupting. You will feel guilty at first. You will also produce more in those blocks than you have in most of your weeks. The guilt is a habit, not a signal that something is wrong.

Finally, measure and adjust monthly. Revisit your category breakdown. See if overhead crept back in. It always does. Process has a gravitational pull. Teams naturally add another check-in, another template, another approval step unless someone actively resists. Make that resistance part of your routine.

What To Actually Read

The book itself is short, roughly two hundred pages of fairly condensed advice. The downloadable companion material from the authors' site includes a simplified project canvas and a one-page workflow checklist that you can print and keep on your desk. Neither is essential, but the canvas is useful for defining the actual work before you start executing. Without that definition step, you tend to skip straight into activity and realize weeks later that you were solving the wrong problem efficiently. If you want a deeper technical follow-up on the project management side, the original Rework by the same authors covers similar territory with more examples. If you need something more process-oriented, The Phoenix Project by Gene Kim applies comparable philosophy to IT operations and DevOps workflows. Both are reasonable complements depending on your industry. The approach will not fix everything. It will not solve poor hiring, unclear strategy, or dysfunctional leadership. But for teams that are stuck in activity theater and want to actually ship things, it is about as practical as it gets. The hardest part is not understanding the framework. It is maintaining the discipline to keep cutting away the stuff that feels productive but is not.