Jason Fried runs Basecamp on 6-week project cycles with no shared calendars, no status meetings, and a hard three-person-per-feature cap — and he argues that most of what makes work crazy is structural, not personal, and therefore fixable.
2
Work expands to fill available time: most organizations mistake busyness for productivity, but the real problem is that people's days are chopped into fragments too small for deep work, forcing them to work nights and weekends to finish what eight uninterrupted hours would have accomplished.
3
Every 'yes' is really a thousand 'no's — Fried's operating rule is that saying no is surgical and precise while saying yes is a shotgun blast that eliminates optionality for everything else you might want to do.
4
Phones are the new cigarettes: addictive by design, harmful in ways people don't yet fully appreciate, and the business model of engagement-driven apps depends on that addiction continuing — which is why individual behavior change requires deliberate structural choices, not just willpower.
Protocols
Concrete recipes — what, when, how much, and why
7 items
6-week project cycle with hard circuit-breaker
WhatCap every project or feature at a maximum of six weeks. At the six-week mark, evaluate honestly: if the work is not on track, pull the circuit-breaker and terminate the project regardless of sunk time. Start no project that cannot be scoped to fit within six weeks.
WhenApplies to every feature, product, or initiative. Scope must be defined before work begins so the six-week window is real, not aspirational.
DoseSix weeks maximum. Many features complete in two or three weeks. The hard cap is the mechanism; working under it is the discipline.
For whomFounders, product managers, and team leads who have experienced projects that 'just need one more month' for years on end, destroying morale and shipping nothing.
WhyProjects that run indefinitely build sunk-cost momentum that makes cutting losses organizationally impossible. The six-week cap converts every project into a bounded experiment with an acceptable worst-case outcome.
CaveatsRequires scope discipline before the cycle starts — you cannot just start with an undefined feature and hope it finishes in six weeks. The scope decision is the real work before work begins.
Fried's calendar feature example: a full-blown calendar with draggable cells and multi-day events is not buildable in six weeks. But 'show days that have something on them and what those things are' is buildable in six weeks and solves 80-90% of user needs. The discipline is to ship the six-week version, learn from it, and build the next version as a separate six-week cycle if needed. This also means never holding features until a big launch moment — ship each piece as it completes, preventing stale code and creating immediate feedback. The circuit-breaker is equally important: Fried explicitly says a terminated six-week cycle is not a failure. This cultural permission is what makes the time-box real rather than aspirational.
Mechanism
Hard time-boxing forces scope reduction to the true minimum viable version, preventing feature creep and sunk-cost entrapment. The circuit-breaker formalizes that stopping is acceptable.
At the very worst we have basically what we call circuit breaker which is after six weeks like if this isn't going anywhere if we're not where we need to be we can pull the circuit breaker and call it quits on that and like we lost six weeks but that's not the end of the world.
Also said
“We only work on things that take six weeks or less to do so every feature we build in the Basecamp there has to be a six week maximum version of that and many features are only two weeks or three weeks.”— States the rule precisely — six weeks is a ceiling, not a target; many features are shorter.
Three-person maximum per feature team
WhatHard cap every feature or project team at three people. Typical configuration: two programmers plus one designer, or one programmer plus one designer. Do not add a fourth person even when scope expands — instead reduce scope or add a separate parallel team working independently.
WhenAt team formation for any new feature or project. Applied before work begins, not reactively when a team grows unwieldy.
DosePermanent structural rule, not a per-project judgment call.
For whomFounders and team leads building flat, autonomous organizations. Especially relevant for knowledge-work teams where coordination overhead eats productive time.
WhyThree is the largest team size that is naturally self-governing: odd number prevents ties, small enough for informal coordination, no factions. Four or more people create management needs that break the flat structure.
CaveatsDoes not apply to teams with fundamentally different work than feature development (customer service, operations). The rule is for creative/analytical output teams.
Fried: 'Three is a wedge — it's odd so there's never any ties, it can be self-managed.' The three-person rule interacts with the six-week cycle: three people over six weeks is a definitionally scoped unit of work. Four or more people on a longer timeline requires a manager, status meetings, and coordination overhead — all of which fragment the productive time the six-week cycle is trying to protect. Basecamp currently runs four or five of these three-person teams simultaneously, each working on independent features that do not depend on each other's output.
It's a small team it's a wedge it's odd so there's never any ties it can be self-managed once you add a fourth person like something happens where like you can now have sides and someone has to kind of come in and mediate and it just becomes more complicated.
Protect 8 contiguous hours per person per day — ban shared calendar access
WhatRestructure scheduling so that no person can look at another person's calendar and book time without prior consent. Every individual gets a full uninterrupted block of working hours as the default; meetings and synchronous calls are exceptions requiring explicit agreement.
WhenApplied as a permanent structural rule at the team and organization level, not a personal opt-in.
DoseEight uninterrupted hours per person per day is the stated goal. Fried notes eight hours is genuinely a long time — comparable to a transatlantic flight — and most people never experience it at work.
For whomKnowledge workers, writers, programmers, designers — anyone whose value comes from sustained concentration rather than reactive availability.
WhyCreative work cannot be done in 15-minute windows between interruptions. The reason people work nights and weekends is not too much work — it is 45 minutes of uninterrupted time during the day, forcing off-hours completion.
CaveatsRequires structural change from the top; an individual contributor cannot unilaterally implement this if their manager books meetings in their calendar. Fried acknowledges it requires positional authority to implement.
Fried: 'You cannot allow people to look at each other's calendars and take time from each other. If you get to that place which is where we're at you can get a lot of work done in eight hours I mean a ton of work.' He notes the irony: people work 12+ hour days not because there is 12 hours of work but because the architecture of their day produces only 45 minutes of actual productive time. Attia acknowledges this is his own biggest health failure — he can optimize every other domain but has not fixed structural fragmentation of working hours. Fried's practical steps: no shared calendar visibility by default, all meeting requests require active acceptance, async written communication as the primary channel.
Mechanism
Contiguous time blocks allow flow states that fragmented schedules preclude. The productivity gain from one four-hour block is greater than the sum of eight fragmented 30-minute windows because each interruption incurs a re-entry cost.
We have to give people a full block of eight hours a day to themselves and you cannot allow people to look at each other's calendars and take time from each other if you get to that place which is where we're at you can get a lot of work done in eight hours.
Daily async written check-in — eliminate status meetings
WhatReplace all status meetings with a daily asynchronous written update. At Basecamp, software automatically prompts every team member 'what did you work on today?' at end of day. People write free-form responses visible to the whole team. Additionally, every week people write what they plan to work on. Every six weeks the team lead writes a cycle summary.
WhenEnd of each workday for the daily check-in; start of each week for the weekly plan; end of each six-week cycle for the summary.
DoseFive to fifteen minutes per person per day for the written update. Reviews are asynchronous — no meeting required.
For whomAny team currently running daily standups, weekly status calls, or sprint reviews that exist primarily to broadcast work state rather than make decisions.
WhyStatus meetings interrupt everyone's deep work to synchronize information that could be transmitted asynchronously. Written updates are scannable, searchable, and time-shifted — read when it fits the reader's work, not at a mandated time.
CaveatsRequires a writing culture to be effective. If writing quality is poor, the async updates are not useful. This is why Fried requires all Basecamp hires to be strong writers regardless of role — writing ability is the first filter in hiring.
Fried: 'In Basecamp the product there's a way with every at the end of every day Basecamp asks everybody automatically what you work on today people write up what they worked on today... so these things are self reporting and we're all paying attention to the work itself as it's going so there's no moments when there's a big presentations there's no presentations.' This model works because teams are fully autonomous — no cross-team dependencies means the daily written update is informational, not coordination-critical. Teams and managers stay aware of progress without requiring a meeting, and any concerns can be addressed asynchronously in writing.
In Basecamp the product there's a way with every at the end of every day Basecamp asks everybody automatically what you work on today people write up what they worked on today they also write up what they were what they plan on working on this week and then every six weeks the team lead writes kind of a summary.
Eliminate phone notifications — pull information, do not be pushed by it
WhatAudit every notification on your phone and remove all that are not operationally critical. Reconfigure your relationship with information from push (device tells you when to look) to pull (you choose when to look and what to seek). Treat the phone as a tool you control, not an attention-capture device that controls you.
WhenImmediately — treat it as a one-time structural setup that changes the default mode of attention from reactive to deliberate.
DoseFried's own practice: he checks information when curious, not when prompted. He deleted Instagram mid-podcast as a demonstration. He keeps only operationally necessary notifications active.
For whomEveryone with a smartphone — especially knowledge workers and anyone whose health goals require sustained focus, stable sleep, and low-grade stress reduction.
WhyPhone notifications are designed by engagement-optimized algorithms to interrupt attention at highest-conversion moments. The business model of most apps depends on maximizing time in-app; your attention is the product. Allowing notifications is allowing your attention to be directed by systems built to exploit it.
CaveatsFried notes the cigarette analogy is intentional: even after understanding the harm, the addictive pull remains. Structural solutions (deletion, blocking) work better than willpower because they change the default rather than requiring repeated acts of resistance.
Fried: 'I've eliminated pretty much all notifications on my phone except like things I need during the day... I don't like if I want to know something I'll go find it versus I don't wanna be pulled to anything.' He frames the business-model dynamic: engagement-driven apps 'are designed to addict to their services and prompt you the right amounts of time per day and reward you for engagement.' Attia's take: 'I think phones probably have a bigger AUC of suffering than cigarettes.' The specific harm Fried identifies in Instagram is the vanity-display behavior it enables in himself — buying a watch and wanting to show it off is psychologically corrosive in a way he only noticed after abstaining.
Personal experience
Fried deleted Instagram during the podcast recording when the conversation surfaced his ambivalence, observing: 'that made me feel weird for a second — that's them, that's them making me feel weird like I shouldn't let them make me feel weird that's just they shouldn't have control over me that way.'
I've eliminated pretty much all notifications on my phone except like things I need during the day the day I actually think phones are highly addictive I think they're basically cigarettes modern-day cigarettes and they might be at least as bad for you.
Book commitments in days or weeks — keep the future unscheduled
WhatDefault to booking professional and social commitments only a few days to a few weeks in advance. Decline requests to fill your calendar months ahead unless the value is certain and high. Apply the Warren Buffett reported practice: treat tomorrow as the planning horizon for most discretionary commitments.
WhenOngoing calendar management. Apply most aggressively to speaking engagements, travel, and social commitments where cost is time and logistics.
DoseFried's benchmark: he declines international speaking travel outright, applies the 'what do I want to be doing that specific day?' test by mentally zooming to the actual date rather than the moment of invitation.
For whomFounders, executives, and professionals who frequently feel resentful about obligations they agreed to months before.
WhyCommitting far in advance fills the future with past obligations, eliminating flexibility to respond to present priorities. The yes is easy at invitation time because no work is required; the cost arrives months later when the obligation competes with what you actually want.
CaveatsSome commitments (family events, medical appointments, key business obligations) should be planned in advance. The protocol is specifically about discretionary professional commitments where value is uncertain and cost is flexibility.
Fried: 'Yes is really easy to say yes requires no work like later like yeah I'll say yes to that trip to Germany because it takes no work to say yes... and then you get to like it's like I'd rather be somewhere else right now.' The mental fix: simulate the future date — 'it's not about do I want to do it now it's what do I think I want to do it then.' He also frames honest refusal as universally better-received than expected: 'everyone responds like I totally understand I appreciate that thanks for the consideration and you're just nice to people and they're nice to you back.' Attia acknowledges the same pattern: the times he musters the foresight to say no, the reception is far better than feared.
I often regret saying yes I've realized two things far out in the future one of the reasons why is because yes is really easy to say yes requires no work like later like yeah I'll say yes to that trip to Germany because it takes no work to say yes.
Also said
“When you say no you just say no to one thing and now you have more options available to you and that's how I've been thinking about no no is a very surgical very precise strike yes is a shotgun.”— The core asymmetry stated as an operating rule: no is precise, yes is diffuse. No preserves optionality; yes forecloses it.
Replace long proposals with appetite-based one-page pitches
WhatWhen preparing a proposal, project pitch, or business case, write only what the audience actually decides from: scope, cost, and time. Stop there. Match the length of your output to the real decision being made, not to an implicit expectation of comprehensiveness.
WhenAny time you are preparing a proposal to win work, get project approval, or pitch an initiative internally.
DoseFried compressed his own client proposals from 20 pages to 1-2 pages with no change in win rate. The experiment is self-validating.
For whomConsultants, freelancers, team leads asking for project approval, anyone seeking sign-off on new initiatives.
WhyProposal readers skip to time and cost. Everything else is noise. Producing 20 pages of noise costs enormous time and delivers no additional win probability. Internally: replace project estimates with 'appetites' — how much time are we willing to spend? — which makes scope the variable and time the constraint.
Fried's discovery: 'I was redoing my kitchen at my apartment and someone sent me their proposal and what did I do I turned to the last page and looked at how long is it gonna take and how much is gonna cost.' He started writing shorter and shorter proposals, found win rates unchanged, and got more sleep. The internal version at Basecamp is the 'appetite' concept from Shape Up: instead of estimating how long something will take, you decide how long you want to spend — which is a statement of priority, not a forecast. This shifts the conversation from 'how long will it take to build the right thing' to 'what is the best thing we can build in the time we want to spend.'
I realized like wait a second all this work I've been doing I don't need to do and that wasn't the first moment I realize I can kind of poke this expectation... when I was on the other side of that I just looked at the time in the price.
What's new
Personal practice updates, fresh positions, predictions
7 items
Six-week project cycles as a circuit-breaker against sunk-cost momentum
~2 h 15 min
Basecamp builds every feature with a hard six-week maximum window and a circuit-breaker: if the work isn't where it needs to be at the end of six weeks, they kill the project regardless of how much has been invested. This prevents the months-to-years of compounding sunk cost that destroy morale and wastes entire years.
Why this matters: Most software teams have no formal mechanism to stop a runaway project; they add one more month until the team is broken. The six-week cap is the structural forcing function that makes cutting losses organizationally possible.
Background
Before Basecamp adopted fixed cycles, they had built calendars that took six to eight months — and features that dragged on so long they had to launch them all together, creating dependencies and stale code.
Fried explains: 'Nothing is more demoralizing than working on something that you don't know when it's going to end.' When you work on something for six, twelve, twenty-four weeks and keep going, 'you have this huge momentum that makes it impossible for you to cut your losses.' The six-week hard limit converts every project into a bounded experiment with an acceptable worst-case outcome (six weeks lost). At Basecamp, a failed six-week project is explicitly called acceptable. The circuit-breaker rule also forces scoping discipline: the calendar feature that used to take eight months was re-scoped to 'show days that have something on them' — which is buildable in six weeks and solves 80-90% of use cases.
At the very worst we have basically what we call circuit breaker which is after six weeks like if this isn't going anywhere if we're not where we need to be we can pull the circuit breaker and call it quits on that and like we lost six weeks but that's not the end of the world.
Also said
“There's nothing more demoralizing than working on something that you don't know when it's going to end and that you don't like no matter what you're doing you're gonna work on some things you don't like to do at base camp the worst thing that could possibly happen is you have six weeks of something you don't want to work on certainly other bad things can happen but like when you begin you can see the end six weeks max.”— Frames the six-week rule as a morale mechanism, not just a delivery mechanism — the ability to see the end is itself motivating.
Three-person maximum per feature: why the fourth person breaks self-governance
~2 h 05 min
Basecamp limits every feature team to three people maximum — typically two programmers and one designer, or one programmer and one designer. At three people the team is self-managed; adding a fourth creates the conditions for factions, tie-breaking, and the need for a mediating manager.
Why this matters: Explains concretely why small teams feel qualitatively different from four-person teams, not just quantitatively different — it is the difference between self-governance and managed governance.
Background
Basecamp's flat structure depends on autonomous feature teams; once teams require management infrastructure, the flatness breaks.
Fried: 'Three is a wedge — it's odd so there's never any ties, it can be self-managed. Once you add a fourth person like something happens where like you can now have sides and someone has to kind of come in and mediate and it just becomes more complicated.' The three-person rule interacts with the six-week cycle: three people over six weeks is a definable, commitmentable scope. Four or more people on a long timeline is a project that needs project management. By keeping teams at three, Basecamp keeps every feature below the threshold where management infrastructure becomes necessary.
It's a small team it's a wedge it's odd so there's never any ties it can be self-managed once you add a fourth person like something happens where like you can now have sides and someone has to kind of come in and mediate and it just becomes more complicated.
Busyness is fragmented time, not too much work
~1 h 45 min
Fried's diagnosis of why people feel they need to work 12-hour days: their eight-hour workday has been chopped into fragments too small for deep creative work. The problem is not workload — it is structural fragmentation from meetings, shared calendars, and chat tools.
Why this matters: Reframes overwork not as insufficient effort or insufficient time but as a scheduling architecture failure — which means it is fixable by changing the architecture, not by working harder or sleeping less.
Background
Fried spent decades watching colleagues work increasingly long hours while output quality stayed constant or declined, and traced it to calendar colonization rather than actual work volume.
Fried: 'I don't feel like there's more work to do... people's days are pretty scrambled actually that's one of the reasons they feel busy.' The argument is that work quality and quantity are both higher when you give people contiguous blocks: 'eight hours is a long time — fly from here to Amsterdam and it's about an eight-hour flight, it's long.' If instead your day is forty-five minutes between a meeting and a call and a Slack ping, your effective working time is close to zero. This is also why remote work without async discipline is often worse than open-plan offices: you are always available, so you are always interrupted.
If you pay attention to what they're doing if you really ask them about why they're working so long and this is I think the deeper insight it's not that there's more work to do it's that there's less time to do good work because people's days are broken into smaller and smaller and smaller chunks of time.
Also said
“Most people don't have eight hours at work they have like 45 minutes to themselves and therefore they're working late nights and working on the weekends because there's no other time to get their work done that they're expected to do.”— Quantifies the gap between nominal work hours and actual productive time — 45 minutes per day explains why people have to work nights and weekends.
Chat tools are all-day meetings with an unknown agenda and no end time
~2 h 35 min
Fried argues that company-wide chat is structurally worse than email because it creates an expectation of immediate response, discourages long-form reasoning, and runs 24/7 with an unlimited and shifting participant set — effectively an open-plan office that never closes.
Why this matters: Makes the specific architectural case against synchronous chat rather than the vague 'too many meetings' complaint — and identifies the business model reason why chat tools will not self-correct.
Fried distinguishes the medium from the message: 'Organizations begin to think one line at a time — it discourages this writing thing... write and present and think something through and put it out there as a complete thought.' The structural problem with chat is that the medium makes half-formed thoughts the norm, then the expectation of immediate response locks everyone into reactive mode. He contrasts it with Basecamp's long-form async written update model: 'you write something in long form you get your whole idea together put it out there for people, people can read it on their own schedule and they can get back to you tomorrow.' He also predicts a correction: the open-floor-plan was celebrated, then widely abandoned; he expects chat will follow the same arc.
Chat rooms are basically all-day meetings with meetings with an unknown set of participants and many many different topics all at once and they're basically virtual open offices and they're running 24/7 and they're terrible but that's sort of the current trend.
Also said
“If you've ever tried to be in a chat room in a company you're sort of typing some idea out and someone else jumps in and takes it and like ask the question like wait let me just finish and it's like it's just a mess it's like this race to get your idea out because you're doing it one line at a time.”— Concretely shows how chat's real-time design actively degrades the thinking process, not just the time allocation.
Phones are the cigarettes of the 2020s — addictive by design, harmful in ways people have not yet accepted
~2 h 45 min
Fried draws the analogy to 1950s cigarettes: people knew something felt off but the cultural consensus had not caught up to the biology. He argues phones may have a larger aggregate burden of suffering than cigarettes — not from one catastrophic outcome but from diffuse chronic impairment of attention, sleep, relationships, and decision-making.
Why this matters: Attia explicitly agrees and notes that the engagement-driven business model of most phone apps means the harm is structural and intentional — not a side effect.
Background
Fried deleted Instagram mid-podcast during the recording after the conversation surfaced his own ambivalence — a live experiment in the same behavioral dynamic they were discussing.
Fried: 'I think they might be worse... like lung cancer is pretty damn bad right and cardiovascular... I actually think phones probably have a bigger AUC of suffering than cigarettes.' The mechanism is attention capture and reward-loop manipulation: 'these companies basically are designed to addict to their services and prompt you the right amounts of time per day and reward you for engagement.' Attia frames it through the business-model lens: the only fix is a business-model change, not individual corporate responsibility. The practical corollary both endorse: eliminate all non-essential notifications and do not allow the device to pull you — only push to it when you choose.
I think phones are highly addictive I think they're basically cigarettes modern-day cigarettes and they might be at least as bad for you I think they might be worse.
Also said
“I've eliminated pretty much all notifications on my phone except like things I need during the day... I don't want to be pulled to anything like I'll go look for it if I'm curious I think we've become slaves to phones telling us what to do.”— Fried's own practice: only pull the phone, never let it push you — the operational translation of the cigarette analogy.
Saying yes is a shotgun; saying no is a scalpel
~2 h 25 min
Fried argues the asymmetry between yes and no is almost always mis-priced: saying yes to one thing eliminates flexible optionality for hundreds of other things; saying no to one thing eliminates only that one thing while keeping all others alive.
Why this matters: Reframes saying no from a negative act to a positive allocation of flexibility — and provides a practical mental model for making calendar and commitment decisions.
Background
Fried developed this framework after tracking his own pattern of agreeing to future talks and then feeling angry at himself when the date arrived — diagnosing the root cause as FOMO plus the ease of yes versus the difficulty of no.
Fried: 'When you say yes to something you're basically saying no to a thousand other things cuz you can't.' He applies the same principle to Basecamp's independence from venture capital: taking VC money is a yes to one source of resources that forecloses flexibility to make decisions based on long-term judgment. The Warren Buffett scheduling anecdote encapsulates the principle: Buffett reportedly keeps his calendar almost entirely unbooked, accepting only same-day or next-day requests, so his schedule always reflects present priorities rather than past obligations.
When you say yes to something you're basically saying no to a thousand other things cuz you can't do I mean you go to Germany yeah you might meet someone interesting but look at all the things you can't do like at that same time you don't have the flexibility and the freedom to do things because you've already booked something far in advance.
Work habits compound — the 80-hour-week practitioner becomes unable to work any other way
~35 min
Fried's diagnosis of why founders who vow to 'grind now, coast later' never actually coast: they have practiced 80-hour weeks until that pace is the only work identity mode they know. The problem is not more work to be done later — it is that they never addressed what drove the compulsion in the first place.
Why this matters: Explains the mechanism behind the classic founder trap and suggests the real intervention is addressing the underlying driver of overwork, not adjusting the schedule.
Fried: 'Whatever you practice you get better at and sometimes you don't even realize you're practicing but if you're working 80-hour days you're gonna get really really good at working 80-hour weeks... and then at some point you're like that's the only way to do this right because that's what I've done.' He connects this to Parkinson's Law but adds a behavioral dimension: the expansion is not just about time availability, it is about identity formation. The person who has practiced overwork now identifies as someone who works that way, and pulling back feels existentially threatening.
If you're working 80-hour days you're gonna get really good at work or not even ADR weeks you're gonna get really really good at working 80-hour weeks that's just where you're gonna do a 12-hour days like that and then at some point you're like that's the only way to do this right because that's what I've done.
Disclosed sponsorships4speaker disclosed
It Doesn't Have to Be Crazy at Work by Jason Fried and David Heinemeier Hansson
Book Sponsored · disclosed
The philosophical manifesto for Basecamp's calm company model: no growth-at-all-costs, no 80-hour culture, protected deep work blocks, asynchronous communication, and profitability over scale.
DisclosureFried is co-author — this is the central book being discussed throughout the episode.
Fried describes it as 'the big picture, the framework' — covering the why of the calm company model rather than the operational how. He explicitly positions it as a book for people who are already struggling: 'The only time people are going to change is if there's actually a struggle.' Attia says work-life balance is his lowest-scoring area and frames this episode as a first step toward addressing it. The book grew out of Fried's realization that Basecamp's approach was not the natural evolution of a successful company but a deliberate choice to opt out of the startup escalation treadmill.
That's sort of more the big picture it's the framework dream work you know shape up is actually how we work day to day.
Shape Up by Ryan Singer (Basecamp) — free at basecamp.com/shapeup
Book Sponsored · disclosed
The detailed operational guide to how Basecamp actually works day-to-day: six-week cycles, appetite-based scoping, hill charts, the circuit-breaker rule, and how to pitch features without writing long specifications.
DisclosurePublished by Basecamp, available free on the web — Fried promotes it as the operational companion.
Fried: 'If you go to basecamp.com/shapeup it's a very very detailed... shape up is actually how we work day to day to build software.' He positions it as applicable beyond software: 'whatever you're building it has elements to it and if you can scope these things down into smaller elements I think you can work this way.' The book is free on the web and covers the appetite concept, the hill chart (visual progress tracking that shows whether work is in the problem-solving or execution phase), and the specific pitch format Basecamp uses instead of long specifications.
We just wrote another book actually called shape up which is a web-based book so if you go to base camp comm slash shape up it's a very very detailed like this book here doesn't be crazy work is more the big picture.
Rework by Jason Fried and David Heinemeier Hansson
Book Sponsored · disclosed
Earlier Basecamp book covering the fundamentals of building a sustainable software business without external funding: why you do not need a business plan, why you should not raise money, why small is a feature, and the danger of competitors and meetings.
DisclosureFried is co-author — referenced in the episode as an example of Basecamp's editing philosophy.
Fried uses Rework as an example of his own content-editing philosophy: 'Our contracts at 40,000 words and we handed in 20,000 and initially we had to argue with the publisher about it.' Rework was eventually padded with images to satisfy the publisher's thickness requirement — Fried's example of the gap between the book industry's proxy measure (word count) and the actual value (clarity per word). The book itself argues for working smarter, shipping earlier, and ignoring what competitors do.
So I had a picture of with each essay to thicken it up that was the compromise content was great but it wasn't thick enough to sell apparently which is so ridiculous.
The software that implements the async communication protocols discussed in the episode: daily automated check-in prompts, weekly planning posts, six-week cycle summaries, and structured progress visibility without status meetings.
DisclosureFried is co-founder of Basecamp — direct commercial interest.
Fried describes the daily check-in feature as central to eliminating status meetings: 'In Basecamp the product there's a way with every at the end of every day Basecamp asks everybody automatically what you work on today.' The check-in is a free-form prompt that every employee answers in writing, visible to the whole team asynchronously. The software also supports hill charts — visual progress tracking that show whether a piece of work is in the uphill problem-solving phase or downhill execution phase — letting teams see progress without a meeting. Basecamp is the product Attia and Fried both use for their respective organizations.
In Basecamp the product there's a way with every at the end of every day Basecamp asks everybody automatically what you work on today people write up what they worked on today.
Lines worth pulling out — contrarian, specific, or perfectly phrased
7 items
It's not that there's more work to do it's that there's less time to do good work because people's days are broken into smaller and smaller and smaller chunks of time.
The sharpest diagnosis in the episode — reframes every conversation about overwork from 'too much' to 'too fragmented', which implies a completely different set of solutions.
When you say yes to something you're basically saying no to a thousand other things cuz you can't do I mean you go to Germany yeah you might meet someone interesting but look at all the things you can't do.
Reframes declining as an affirmative choice to preserve optionality rather than a loss — the mental model that makes saying no feel positive rather than regretful.
I think phones are highly addictive I think they're basically cigarettes modern-day cigarettes and they might be at least as bad for you I think they might be worse.
Fried makes this claim and backs it with the structural argument — it is a specific claim about aggregate suffering and an engineered attention-capture business model, not a vague moral panic.
At the very worst we have basically what we call circuit breaker which is after six weeks like if this isn't going anywhere if we're not where we need to be we can pull the circuit breaker and call it quits on that and like we lost six weeks but that's not the end of the world.
Normalizes project termination as a designed outcome rather than a failure — the phrase 'we lost six weeks but that's not the end of the world' is the explicit cultural permission that most organizations lack.
Making money is a skill just like playing guitar as a skill just like anything is a skill and if you want to get good at it you have to practice it... if you keep borrowing money and keep having other people fund your operations you don't have to get in the black then when are you going to get good at this skill.
The core argument against venture-backed growth-at-all-costs: profitability is a learnable skill, and outsourcing it to investors means the skill never develops.
No is a very surgical very precise strike yes is a shotgun.
One of the most compact framings of the optionality argument — memorable as a standalone decision rule without needing the surrounding context.
We have to give people a full block of eight hours a day to themselves and you cannot allow people to look at each other's calendars and take time from each other if you get to that place which is where we're at you can get a lot of work done in eight hours.
States the calendar-sovereignty principle as a concrete structural rule, not a vague aspiration — 'you cannot allow people to look at each other's calendars' is an enforceable policy.
Sign in to share feedback
Tell us if this brief hit the mark or missed it — feedback feeds back into the next iteration of the prompt.
Reading is free for everyone. A free account adds the personal layer: save protocols, follow experts, and see how the other experts weigh in on this same topic.
Educational summary of the cited expert source — not medical advice. Open the source recording linked above and consult a qualified physician before acting on any protocol.