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.

Here are 24 different methods you could use to better understand the way humans work. In each case, I use “trying to figure out new things about post-traumatic stress disorder (PTSD)” as an example. What techniques am I leaving out here?

1. Papers: Reading academic studies (e.g., from social psychology, consumer psychology, cognitive psychology, neuroscience, etc.)

Example: reading the newest academic papers on treatments for PTSD.

2. Products: Carefully examining products and apps that have been successful (as well as, potentially, those that have failed) to understand what human needs they were or weren’t satisfying and why they succeeded or failed.

Example: looking at what mental health apps related to PTSD are popular in the app stores.

3. Outliers: Investigating extreme case studies of real-life events (e.g., case studies of people with extreme psychological conditions who may have been reported about in the news or true stories about what actually happened when people were placed into really extreme conditions).

Example: reading about cases of extreme cults and whether or not each cult produced PTSD-like symptoms in its members.

4. Society: Examining the large-scale trends and organization of societies, including potentially human cultures around the world (American culture, traditional cultures, etc.) and how they are similar or different, and which societal structures tend to be created and what the effects of these structures are, etc.

Example: investigating which sort of societies PTSD appears to be much more prevalent in.

5. Conversations: Talking to smart and insightful people about what they think is true of human psychology. You can also show them the models or theories you have so far to get their criticism and suggestions for improving them.

Example: asking really smart (non-experts) who had PTSD what their current theories about PTSD are.

6. Reading: Reading books, blog posts, media articles, etc., containing information from smart or insightful people about psychology (including potentially writing from life coaches, relationship experts, marketers, thoughtful bloggers, user experience designers, game makers, etc.)

Example: seeing what theories bloggers have proposed regarding PTSD that many academics may not have considered.

7. Experts: Reaching out to experts and talking to them to understand their models of psychology (e.g., psychologists, psychiatrists, game developers, etc.). You can also show them the models and theories you have so far to get their criticism and suggestions for improving them.

Example: talking to world-class experts in PTSD.

8. Textbooks: Reading academic textbooks about psychology, cognitive science, etc.

Example: Linehan’s textbook on DBT and thinking about possible applications of DBT in PTSD treatment.

9. Models: Looking at what models or frameworks of psychology others have created (e.g., in social psychology, theoretical cognitive neuroscience, gamification research, persuasion research, etc).

Example: looking at the model of PTSD that is used in Cognitive Behavioral Therapy treatment.

10. Intuition: Our own intuition for what’s true about humans (presumably based on our first-hand experience interacting with others, as well as our first-hand, ingrained experience of just being a human).

Example: We may have the intuition that after experiencing a traumatic event, people will tend to start having frequent disruptive thoughts about that event, even when doing unrelated things.

11. Interviews: talking to individuals or groups about their thought processes, feelings, behaviors, etc., to understand their individual psychology and then attempting to extrapolate that knowledge to humans more generally.

Example: interviewing 20 people with PTSD about what their experience of it is like and what does or does not seem to help them.

12. Application: attempting to put into practice a psychological theory (e.g., by coaching individuals using a psychological technique or by trying to build an app that implements it) and paying attention to the ways it seems to work or not work.

Example: creating a tool for people with PTSD and making it publicly available, then monitoring how people respond to it.

13. Anecdotes: psychologically surprising or interesting anecdotes that we’re confident actually happened (e.g., because they happened to us or were reported on by a trustworthy source) that may have a bearing on human psychology.

Example: a story a friend told you about how they (believe) they fully cured their own extreme PTSD in a matter of days.

14. Self-observation: careful (and honest) observation of our own thoughts/beliefs/behavior/emotions and internal processes.

Example: observing the mental processes in your own mind that seem to occur after a very upsetting event has happened.

15. Self-experimentation: simply trying techniques and paying close attention to what effects they appear to have and what it feels like to apply them.

Example: try the technique of writing down for a week every upsetting thought that you notice yourself having, as well as writing down everything you observe or learn about the experience of doing this.

16. Deduction: combining propositions we already believe to produce new propositions we didn’t realize before that may be true.

Example: knowing that women with PTSD are much more likely to have associated depression than men with PTSD, and knowing that depression is a strong risk factor for attempting suicide, we might predict that women with PTSD are more likely to attempt suicide than men with PTSD (even though they may not be more likely than men to actually commit suicide).

17. Experiments: Conduct your own online randomized controlled trials, surveys, longitudinal studies, or fMRI studies, etc.

Example: looking at which variables that don’t seem obviously PTSD related are, in fact, strong predictors of whether someone has PTSD.

18. Statistics: looking up known statistics about a phenomenon.

Example: looking up whether younger people or older people are known to be more likely to get PTSD in any given 12-month period.

19. Data: finding existing data sets (e.g., large longitudinal surveys or government data sets) and running your own statistical analyses to test hypotheses.

Example: measuring whether it is true that after someone gets a pet, they are more likely to recover from PTSD than similar people who do not get a pet. Running studies can also be a good way to search for new hypotheses. For instance, examining which of many variables in the data are most associated with a rapid recovery from PTSD.

20. Literature: looking at portrayals of psychology in literature, art, myths, stories, philosophical writings, etc.

Example: What hypotheses do Kafka’s novels give us about the nature of trauma?

21. Crowdsourcing: Request suggestions for hypotheses on a social media platform like Facebook or X or on a question-answer site like Quora.

Example: posting to Facebook asking people to suggest theories for why PTSD sometimes does and sometimes doesn’t happen after extreme trauma.

22. Social experiments: bringing a group of people together under a new set of chosen social rules or guidelines and observing what happens.

Example: getting a small group of people together with the idea that it will be a time to discuss traumas that members of the group have experienced.

23. Evolution: considering what possible evolutionary function different psychological phenomena might have.

Example: consider ways that aspects of PTSD responses might be evolutionarily adaptive.

24. Practitioners: examine how people “in the field” who benefit from being able to understand this aspect of psychology do their work.

For example, at veterans hospitals where rates of PTSD are high, investigate what techniques and approaches the therapists have developed to work successfully with their patients.

This piece was first written on November 16, 2017, and first appeared on my website on July 22, 2025.