If someone “wastes” $100, someone else now has $100 extra to spend. Even burning bills deflates the currency, making other bills more valuable.

But people’s time genuinely can be wasted. The tragedy of someone spending hundreds of millions of dollars building a yacht is not the dollars spent but the enormous quantity of people’s time and all of those resources that could have gone towards much more societally valuable pursuits.

If you don’t believe this, just consider what happens after the yacht has been built – those dollars spent are now in the hands of the shipbuilders, ship captain, crew, boat insurance provider, etc., who can spend it themselves. So the money is not lost – not even a single dollar of it disappears; it just goes to other people to use! But all of those people’s time and most of the materials used in building the yacht are lost forever.

What do I mean by “lost” here? Well, time and resources can be spent creating lots of what conscious beings intrinsically value (e.g., happiness, positive relationships, freedom, justice, etc.), or they can be spent producing little to no value. Time and resources are “lost” when they produce little to no value in the process of using them up.

Someone buying an expensive yacht gets some genuine value out of it: some pleasure for them and their friends, social status, etc. But that amount of value is really tiny compared to the hundreds of millions of dollars of labor and resources permanently used up in the process (that could have been used to produce far more value). That vast sum of labor and resources could have produced large amounts of value for many people, but instead produced a small amount of value for one person.

This line of thinking has a surprising consequence: frivolous spending on things that are expensive due to labor and resource usage is much worse societally than frivolous spending on things that are expensive only due to taste preferences. It is much worse for society if someone builds a yacht for hundreds of millions of dollars than if that person spends the same amount on a lost Leonardo da Vinci painting that someone recently found in their attic. The latter scenario mostly just involves money moving around (which causes no harm), whereas the former scenario not only moves money around but ALSO uses up a ton of labor and resources.

There is a libertarian counterargument that may seem to refute what I’m saying. It goes like this: if people enter into transactions willingly and with full knowledge of what they’re giving and getting, then they are better off because of those transactions, so all transactions are good, even ones involving buying frivolous yachts for hundreds of millions of dollars.

To take this to an extreme, let’s suppose a billionaire goes around paying people to undergo torture (let’s assume that, like most people, these people hate torture). The billionaire offers enough money that these people are willing to accept the offer even though it is absolutely awful for them. Now by standard libertarian logic, the world is still better off since the billionaire chose to pay them, and the participants being tortured were willing to do it.

On the other hand, compare how much worse off the world is in that case compared to if the billionaire instead paid people to make beautiful things, or to run non-profits that seek to make the world better, or used that money to fund new startups, or just gave the money directly to those same people instead of requiring that they be tortured for it. In fact, the world would be better off if the billionaire did “nothing” with the money – leaving it in the bank so others can borrow it rather than using it to pay for torture.

The issue is not that the world is strictly worse off if a billionaire pays people to undergo torture (you could imagine a world where both the billionaire and the torture sufferers are slightly better off post-transaction – this only requires that the torture sufferers accept the deal with complete knowledge of the consequences and that they really do value the payments enough to make the torture worthwhile according to their values).

The issue is that there is a tremendous loss of value if a billionaire pays people to undergo torture relative to what could have been if the billionaire used the money for almost anything else. Paying people to be tortured does not destroy money (the money merely exchanges hands), but it does unnecessarily destroy value (people’s time is spent being tortured, which is horribly dis-valuable, instead of doing things with that time that are valuable). In this hypothetical example, the billionaire’s huge sum of money could have been spent on numerous things that would have produced value, and yet, they found one of the very least valuable ways to spend via voluntary exchange (by purchasing people’s suffering).

Buying a yacht is far less extreme than paying people to be tortured, but the torture example helps illustrate the point: using money never destroys that money; money always just moves hands, and some uses of money produce a lot of value in the world, and some don’t (and some even destroy value). Another way to put it is: buying a multi-hundred-million-dollar yacht creates VERY little value relative to the resources and amount of labor it consumes. A ten-million-dollar yacht, as a point of comparison, might make the billionaire slightly less happy, but it would produce a lot more value per unit of labor used. And a one-million-dollar boat is even better still on this ratio.

Since people’s time and physical resources are finite, when they are used on one thing, they are necessarily not used on another. To take it to extremes in order to illustrate the point, a society that spends most of its resources and work hours on making luxury goods that produce just a modest benefit for only a small number of people (as with yachts) is far worse at supporting human values than one where labor, time, and resources produce widespread benefit, with a higher “unit of what humans value” produced per hour of labor. A society that spends its time and resources building public parks and quality roads is a better one for flourishing than one which focuses instead on building pyramids to bury kings (even if the laborers are paid the same amount in each case).

I’m not saying it’s unethical to spend money on things you enjoy (I don’t think it is unethical so long as you don’t harm others). But it’s interesting to consider that, for very large expenditures for enjoyment (like multi-hundred-million-dollar yacht purchases), the amount of labor and resources they consume relative to the value they create may be bad societally relative to other equally frivolous-seeming purchases.

Note: as some commenters pointed out, there is substantial value in buying a yacht in terms of redistribution of wealth – it’s usually better for the world that the wealth moves from the billionaire to the yacht crew, etc. That’s absolutely true, but it would also be true for most usages of the money spent by billionaires, and the points I’m getting at here (about usage of labor and resources) are separate and independent from redistribution effects.

This piece was first written on February 24, 2023, and first appeared on this site on April 30, 2023.

Here is a list of “feeling-based” strategies that may help you get started on what you have trouble getting yourself to do:

If you are feeling:

1. unsure of where to start-> think of three really small, simple, actionable steps that would constitute a small amount of progress, but those steps in their most natural order, then start on the first of those steps

2. a lack of motivation -> make a list of all the reasons you care about this project and why it is meaningful or worth working on (if you can’t think of good reasons, maybe you should just drop the project), read this list back to yourself, and then get started.

3. too tired, during daytime -> try my “cool reboot” method (see: http://bit.ly/2Ehhy7N – just do whichever parts of the method that you are able to do wherever you are) then start working on the project immediately after.

4. too tired, during late evening -> go to sleep and set the alarm to wake up early, add another alarm on your phone to remind you to start the project shortly after you wake up.

5. overwhelmed by the magnitude of the project -> on paper, break the project down into large (at least mostly) independent pieces, then take the first of those pieces (the one that it would make sense to start working on next) and break that piece down into smaller (at least mostly) independent pieces, and so on, until you can start to see how you might actually accomplish the different small pieces since none of them seems impossibly large.

6. ambiguity about what the project actually is -> write down a first draft description of the project, making the description as concrete as you can manage (but don’t worry about filling in every detail), send this description to any collaborators you have for their feedback (if you have any collaborators), then get started working on any part of your concrete description that feels actionable.

7. overwhelmed by how many different things you need to do for the project -> pick the three easiest things to do that would still count as progress on the project, then start working on whichever of the three you think has the highest priority.

8. anxious when you think about starting -> make a list of the reasons that you think you are anxious about the project and write a short challenge in response to each reason (that points out any exaggeration or irrationality or distortion you can find in the fear), then do something that really helps you feel calm (e.g., take 20 extremely slow, extremely deep breaths), and when you’re done, immediately start on the project.

9. too distracted by your current environment to work effectively -> go to another room or a coffee shop or a corner (where there is nothing in your immediate field of view – try to face a wall) and put on headphones to listen to your preferred customized white noise (http://bit.ly/2nQIZuN) or instrumental music, then get started.

10. there isn’t enough time at this moment to make meaningful progress -> even a minor forward step is worthwhile, so if there is at least some small amount of progress you can make in the next ten minutes, do that; otherwise, schedule a few hours of free, uninterrupted time on your calendar to work on the project (picking a time during which you’re unlikely to be distracted by other things) and work on it then.

11. that you’re going to fail at the project -> make a list of the reasons you think you will fail, for write down one thing you can do to reduce the chance that you fail in that way, then make a list of all the evidence you can think of that implies you can succeed at the project, then get started on it.

12. it’s going to be unpleasant to work on it -> select for yourself an enjoyable reward activity that you’re going to allow yourself to do after you work on the project for an hour, then pick out whatever you think the easiest part of the project is, then go work on that easiest part for an hour to earn your reward.

With that definition in mind, there are many reasons a work team may have low productivity. To make a team more productive, I suggest first trying to pinpoint the predominant causes of inefficiency, since different failure points typically have different solutions. The key is to identify and then focus on just the 1-3 of these causes that seem to be the biggest recurring blockers of team productivity.

Once these biggest blockers are identified, an analysis needs to be made of why they are occurring (e.g., using a method like the “5 whys”, where you try to uncover the root cause of the issue). Then, strategies need to be developed to try to resolve the blockers, and one or two strategies that have sufficient team buy-in need to be selected for implementation. Finally, re-evaluation needs to occur to make sure the problems are actually improved by those strategies.

Below is a list of these potential failure points or blockers.

There are four main facets of team productivity (Planning, Effectiveness, Resources, and Communication), which break down further into specific reasons for low productivity. You can use this list by considering each potential reason and scoring the degree to which you think it’s a problematic factor on your team (or having all team members anonymously score each potential reason for how big a problem it is, and then aggregating the responses to find the few most important seeming issues).

—

Reasons For Low Team Productivity:

—

(A) Planning

(1) Wrong Goal – the work is focused on achieving a goal that is not actually particularly valuable.

      e.g., the team is building a new feature that customers don’t want

(2) Poor prioritization – rather than focusing on the very most important things, the team focuses on things of secondary importance.

      e.g., the team lead keeps pushing team members to make tiny improvements to existing features, even though there are really major features where implementation hasn’t even begun.

(3) Slow Path – the planned route for achieving the team’s goal is not as efficient as other routes to achieving the same goal.

      e.g., the team could use a well-tested plugin to help them solve their problem, but the team lead insists they build their own alternative to this plugin.

(4) Incompletion – there is no pressure to finish projects, or team members work on far too many projects at once, so work doesn’t get completed, or takes much longer than it should.

      e.g., when a crisis comes up, the projects already in progress are abandoned, and rarely are they picked up again.

(5) Feature Creep – the project takes a really long time to be released because its scope or feature set keeps unnecessarily increasing, repeatedly delaying the launch.

      e.g., the client keeps making more and more requests about what to include in the next version.

(6) Missing Buy-in – team members don’t actually care about achieving the team’s goals (i.e., they don’t view the goal as valuable, and don’t feel like a genuine team, such that they care about the team’s success).

      e.g., Bill doesn’t think the product they are building is worthwhile, Sally doesn’t feel invested in the success of her team members or the team overall.

(7) Incentive Misalignment – some team members have incentives that cut against the project going well, or are focused on optimizing for personal goals at the expense of project goals.

      e.g., team members know that if they succeed at the goal, then someone else will take all the credit, and if they fail at it, there will be no negative consequences, and Bob actually wants the project to fail because then he’ll get to move on to a different project he likes more.

(8) Missing Skills – certain skills are needed to accomplish the goals, but no one on the team has these skills, and there are no external consultants that can be called on.

      e.g., no one on the team has a good eye for design, so the interface you’re building has the right features but looks bad.

(9) Reactivity – the team is constantly reacting to crises or imminent deadlines, which means there isn’t time to focus on achieving the long-term goals.

      e.g., every month or two, there is a major system failure, followed by weeks of scrambling simply to get things back to normal.

(10) Groupthink – team members do not feel comfortable sharing their unique ideas, or challenging the team lead, or getting their ideas heard above the most vocal person, or contradicting the group consensus, so the best ideas don’t filter to the top.

      e.g., the first proposed solution to a problem was accepted because no one wanted to challenge the person who proposed it, and since no one spoke up, everyone assumed the other group members must be in consensus.

(11) Guessing – the team doesn’t have enough data or information to solve the problems they are working on, but rather than gathering this data or information, they guess at solutions that aren’t very likely to work.

      e.g., the team has the goal of reducing customer churn, but they haven’t conducted customer interviews or carefully analyzed the churn data, so they are merely guessing at why churn is occurring and developing inadequate solutions based on those guesses.

—

(B) Effectiveness

(12) Insufficient Time – people not working enough hours.

      e.g., a culture of showing up at 10 am and leaving at 4 pm.

(13) Waste – spending time engaged in unnecessary processes or pointless meetings.

      e.g., a culture of constant meetings where you have little time to get your actual work done, or a requirement to tediously document all your work.

(14) Distraction – people may not be able to get “in the zone” on their work because of frequent distractions, or an environment where it is hard to focus.

      e.g., a noisy office environment where colleagues continuously interrupt you to ask you questions.

(15) Burnout – people may feel stressed, depressed, disinterested, bored, or exhausted, and find it is psychologically difficult to get their work done.

      e.g., a culture where bosses regularly yell at, blame, and fire employees for things that are not their fault.

(16) Bad Foundations – the work may be building on other work that was not well made, slowing down additional progress.

      e.g., programmers inherit a massive, buggy, and poorly written spaghetti codebase (i.e., high levels of technical debt).

(17) Disempowerment – team members are not allowed to do certain things (or make certain decisions) that would move the project forward, or they are required to follow a bureaucratic or standardized process that is not an efficient or effective process.

      e.g., a user experience researcher is not allowed to pay customers for doing interviews, but customers won’t do the interviews for free.

(18) Intrinsic Difficulty – the work may genuinely be intrinsically difficult, with progress speed inherently limited.

      e.g., work involving proving new theorems that others have failed to prove.

—

(C) Resources

(19) Slow Platforms – the systems or platforms on which the work is performed make progress more difficult, slower, or more complex than it needs to be.

      e.g., teams are forced to work on Windows 98 and experience regular computer crashes, or teams are forced to work using old and out-of-date software.

(20) Lacking Tools – the team members don’t have the best tools to do their work.

      e.g., a construction team is forced to use a saw that is inappropriate for the job because they don’t have access to the right kind of saw.

(21) No Training – there is a lot of relevant information about how to do the job well that team members are not told, and have to laboriously figure out on their own, or struggle to get by without.

      e.g., programmers are expected to figure out how the undocumented API works on their own via trial and error.

(22) Insufficient Assistance – when team members are stuck, they have no one knowledgeable they can go to (or that they feel comfortable going to) for help.

      e.g., a machine learning researcher can’t get her neural network model training properly and has no one she can ask for advice.

(23) Insufficient Skill – team members are not sufficiently skilled at the tasks they are trying to do.

      e.g., the team members responsible for writing documentation are not skilled at clear communication.

—

(D) Communication

(24) Blocking – team members are waiting on each other to do things before they can get their own work done.

      e.g., Sam needs approval from Sally to move forward, but Sally requires approval from Samantha in order to give Sam permission.

(25) Conflict – team members dislike each other, don’t trust each other, or have clashing personalities.

      e.g., Bill refuses to work with Sam, Jill thinks that Jenny is trying to undermine her, Tim and Tammy get into heated arguments.

(26) Discordant Goals – different team members are working towards different long-term goals, because they are not on the same page about what the purpose, mission, or primary goal of the team is.

      e.g., the product manager is trying to add features, whereas the engineering team is trying to do a feature freeze so they can focus on stability and efficiency.

(27) Ambiguity – the goals are not clear enough, leading to confusion, false starts, and stops, or circling around problems without directly solving them.

      e.g., there is agreement that the user interface needs to be “easier to use,” but little clarity on what that means.

(28) Duplication – team members end up repeating work that has already been done (or that is in the process of being done) by others, either because they don’t know that other work exists or because they don’t trust the quality of it.

      e.g., the new lead engineer doesn’t trust the code developed by the prior lead engineer and so decides to rewrite it from scratch.

(29) Unassigned work – it is not clear who is supposed to tackle certain work (e.g., it is not in any particular person’s job description or current assignments), so some important work just doesn’t get done by anybody.

      e.g., nobody has been assigned the responsibility of bug testing, so bug testing simply doesn’t get done, and therefore, the product is highly buggy.

(30) Siloed Information – team members need information from each other to do their work well, but this information is not transmitted reliably.

      e.g., the team member doing customer interviews isn’t reliably communicating what they learn to the team member planning UX changes.

A big shoutout goes to Eddie Liu, who helped develop this framework.

This piece was first written on July 3, 2019, and first appeared on my website on January 22, 2026.

Note: there is, of course, such a thing as taking a mental break. If you find PW useful as a mental break and recovery between bouts of meaningful work, I’m all for it. Just keep in mind that you are taking a break from the real stuff. Furthermore, note that work comes on a continuum from pseudo work to real work. Here, I’m mainly talking about tasks that have very little or no value. Many of these points apply (but certainly to a lesser extent) to work that’s a bit more useful but still not significantly so.

A related problem occurs with what I’ll call PFPW (pseudo fun pseudo work). PFPW is fun and useful for work goals but not well optimized for either one. Usually, we’re better off dividing our time into real work time, where we try to accomplish our work goals efficiently, and fun time where we genuinely relax or aim to enjoy ourselves. Of course, some jobs incentivized PFPW, for instance, by making you stay at the office when you don’t have much real work to do. Since you can’t have real fun there and don’t have work to do, you do PFPW instead. Unfortunately, this is frequent in some industries and is an effective way to make employees unhappy.

PW is a real problem for individuals, but for startups and small companies, it can be deadly. What makes startup pseudo work (SPW) so bad is that startups are almost always on the verge of death and must drive relentlessly towards their goals to live. SPW, therefore, can be a fatal distraction. Imagine a person standing on a bridge on fire, but who happens to notice he is thirsty. He leisurely drinks from his water bottle to quench his thirst until the bridge collapses into the river. Yes, he was thirsty, but he wasn’t THAT thirsty. There are endless things to do at a startup that feel like work, but that don’t move you strongly in the direction of survival. Don’t quench thirst; run to the other side of the burning bridge.

What pseudo work do you do regularly that you should reduce?

Here is a list of common forms of “pseudo work” and “pseudo fun pseudo work” that I’ve seen (or done):

• giving long responses to work emails when much shorter responses would suffice
• conducting unnecessarily long meetings or meetings with lots of unnecessary chit chat
• agreeing to meet with people (or initiating meetings with people) just because they work in one’s industry, even though it’s doubtful that either party will benefit from the meeting.
• reading the news or reading trade publications (except when one is in the relatively rare sort of work where reading the news is actually important to one’s job). If you like reading the news for some non-work-related reason, then there’s nothing wrong with that, but it doesn’t mean it’s necessarily “work” that counts.
• agreeing to give talks in cases when we have mainly non-work-related motivations (e.g., we like the idea of it), but we pretend it’s because it actually moves our work goals forward. It may be worth giving a talk for those non-work motivations, but it’s useful to know why we’re actually doing it and not count it as work if it isn’t.
• double or triple checking things when minor errors wouldn’t matter
• excessive time spent chatting with teams on slack or sending emails to check in on things when not really necessary

Here is a list of common forms of pseudo work I’ve seen founders at startups fall into especially (and in some significant cases have fallen into myself):

• doing work yourself that could easily be delegated to someone you manage when you have more mission-critical work you should be focused on
• doing work that is not related to the core of your business that could easily and cheaply be outsourced to a 3rd party vendor
• networking with other startup founders too much (e.g., going to lots of startup events without a clear important goal)
• spending too much time and energy worrying about record-keeping over-focus on critical operations
• spending too much time on high-level discussions of the business, market, or future when the product you’re building is not actually good yet
• obsessively checking performance metrics way more often than is useful
• focusing too much credibility or brand when the product is not yet released
• delaying too long on releasing the product or pushing out new features due to perfectionistic optimization
• spending too much time in meetings and not enough time building and problem-solving
• spending too much time on paperwork or formal processes that are not actually improving your business
• spending too much time planning when in the same amount of time one could have already executed a reasonable solution
• micromanaging employees rather than letting them figure out their own solutions