Can a chosen definition be “wrong”? No. If you choose a definition, then you can define a sound or series of characters to mean whatever you want them to mean. For instance, if you wanted, you could declare that whenever you say “phloop,” you mean one of those little paper umbrellas that are sometimes found in Piña coladas. That would be weird, but it wouldn’t be “wrong.” But we suggest that there are at least seven ways a definition can be “lousy.” 

By understanding what makes a good definition and what makes a lousy one, you can better formulate your ideas, and you can better spot mistakes in other people’s arguments. For instance, you might be in a situation where you’re trying to define the essence of an idea you came up with or characterize the unique career role that you’ve designed for yourself. Alternatively, you might be struggling to understand a definition that someone else is using, and you want to diagnose why exactly you’re finding it confusing. The words we use are crucial to the success of the interactions we have, and it is very handy to be able to pinpoint when a particular word is making a conversation more confusing than it needs to be. So, here are the things that we think make for lousy definitions! 

1. Miscommunication

If you decide the word “dog” refers to cats, people are going to be very confused.

Similarly, if you’re talking to someone who uses the word “racism” to mean X (say, “an explicitly held and endorsed belief that some racial groups are inferior to others”), and you use it to mean Y (say, “any form of negative generalization or attitude to a racial group, whether it’s implicit or explicit”), your conversation is probably not going to go as well as you would like until you identify that difference in usage. For these reasons, good definitions shouldn’t reuse terms that people are already familiar with or have multiple meanings associated with them. A good way to avoid the latter is to clarify upfront what you mean when you’re using a particular definition if the other person might not know what you mean when using that word.

2. Irrelevance

If you define a “dooooog” to be a dog with more than five legs, you’re not going to find it to be useful for much of anything. Dogs like that probably do exist, but they are not something almost anyone ever needs to refer to. We want our definitions to aim toward the things we are likely to want to reference.

For instance, someone bothered to define the word “Rasceta” to mean the crease commonly found going across a person’s wrist. Presumably, there is some subculture where that is a useful word, but very few people will ever need to know that definition. 

3. Unnaturalness

If you define “dogephant” to include all dogs smaller than 10 pounds AND all elephants more than 8000 pounds, you have not “carved reality at the joints.” Because of mixing things that aren’t clearly alike, using this definition makes communicating more muddled than it needs to be.

Another instance of this phenomenon is our use of the word “selfish.” Sometimes people define the word “selfish” in such a way that it includes both “stealing money from someone” and “sacrificing your own life to save the life of ten others because you feel such a strong emotion of compassion for those people;” it’s about doing things that make you feel “good.” An alternate reading of “selfish” might be much more negative: it’s about taking actions which benefit you at the cost of other peoples’ wellbeing.

4. Opinionatedness

If you define “dogmor” to be “those dog-loving morons who somehow are convinced that dogs are better than cats,” then the definition imports both a debatable opinion and an emotional slant into its meaning, causing usage of this word to be infected with either or both of these things.

For example, the word “sissy” not only suggests that someone — usually a boy or man — embodies feminine qualities but carries with it a negative, insulting connotation. If your aim is to make certain people feel bad, then this might be a good strategy to take, though you might be being a jerk, and that approach doesn’t make for clear, unbiased communication.

5. Ambiguity

If by “dogdog” you mean anything that a dog can like, then your word is (1) hard to use and (2) hard to think about; dogs like a large range of things, and individual dogs also have distinct preferences!

The word “problematic” (when used without clarification) is another (problematic) example of a definition: the problem being referred to could be of many different types and could range from quite objective to just the idiosyncratic, subjective opinion of the writer.

6. Inefficiency 

If you define “doglegs” to be anything with the legs of a dog, and “dogface” to be anything with the face of a dog, etc., then you can talk about walking your dog by saying, “I just got back from walking a creature with doglegs, dogface, dogfur, dogheart, …” But this is a ridiculously inefficient way to talk about your dog! Some definitions make communication substantially more efficient since they compress lots of information you commonly want to express into a small package.

Consider a different instance of this: it is possible to talk about calculus without having a word that means “the derivative” (e.g., by always referring to “limits of functions”), but this is going to be a painful and inefficient way to think and communicate. The word derivative makes ideas in calculus much easier to talk about. 

7. Lack of precision

If you define “floofster” to be any animal with fur, then you will not be communicating very precisely when you say, “I pet my floofster this morning.” You may be saying something true (and rather adorable), but someone will not know if you were petting a dog, a cat, or something more exotic like a lizard wearing a fur coat! Ideally, we want our definitions to focus on just those items or concepts we are trying to communicate.

Similarly, if you say to your friend, “I’m feeling bad,” the ambiguity of the word “bad” makes it harder for them to understand what you’re going through. If you say, “I have a headache,” then it will be easier for your friend to help you. Even better, if true, would be to say, “I have a migraine.” 

So, no chosen definition can be “wrong,” but plenty of definitions are “lousy.” To prevent lousy definitions, you should choose definitions that:

(1) allow clear communication, 

(2) refer specifically to the things of interest, 

(3) carve reality at the joints, 

(4) don’t sneak in debatable opinions/slants, 

(5) are relatively unambiguous, 

(6) express more information in fewer words, and 

(7) allow us to be more exact and specific with our words. 

We hope you found this helpful!

This piece first appeared on the Clearer Thinking blog on March 2, 2021, and was published on this site on December 16, 2022.

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.