We can think about “productivity” in terms of how much value a team creates (according to any particular measure of value) on average each month.
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.
Comments