More tickets, more tools, and more completed tasks do not automatically mean more productivity. Sometimes, the real improvement starts by removing work and reviewing tasks.
If you work in software development, you probably know the routine. You file tickets, update the board, push commits, review pull requests, answer messages, and attend meetings. By the end of the day, there is plenty of activity to show for your time.
Your sprint board has moved. Tickets have changed status. The activity logs are full.
But is the project actually moving forward?
I've been thinking about the difference between doing work and making progress. The two often overlap, but they are not the same thing. A lot of what we do during the day is necessary to get the job done, yet the volume of that activity doesn't tell us how much useful progress we've made.
And that's where measuring productivity gets complicated.
Activity is easy to measure. Productivity is harder.
We have tools for practically everything. Project management systems track tickets. Git platforms record commits and pull requests. Communication platforms measure responsiveness. Dashboards summarize activity and turn it into charts.
These metrics are useful. They help us understand workload, coordinate teams, and identify bottlenecks. The problem comes when we start treating them as direct evidence of productivity.
A developer who closes twenty small tickets may appear more productive than someone who spends a day investigating a difficult architectural problem. But what if that investigation prevents weeks of rework? What if the twenty tickets were minor maintenance tasks, while the architectural decision determined whether the product could scale?
Counting completed tickets doesn't tell us the difference.
The same applies to commits, lines of code, meetings, and hours worked. They describe activity or output, but they don't automatically establish the value created.
This distinction is notable because being busy tells us that we're using time, not necessarily that we're using it well.
What should we measure instead?
At its simplest, productivity is about the relationship between output and the resources required to produce it. In many settings, that means examining output relative to time.
For knowledge work, however, the definition of output deserves some attention.
A developer's output isn't necessarily the number of lines written. Sometimes, a small change removes a major source of complexity. Sometimes, a few hours of debugging resolve a recurring production issue. Sometimes, the best contribution is discovering that a proposed feature isn't worth building.
The visible output may be small, while the impact is substantial.
The same principle applies outside development. A technical lead who clarifies an architectural decision might save several developers from implementing incompatible solutions. A manager who removes an unnecessary approval step could shorten delivery time across an entire team. Neither contribution is adequately represented by counting completed tasks.
This doesn't mean every discussion, investigation, or management activity is productive. It means we need to look beyond the activity itself.
- What did the work produce?
- What changed as a result?
- Did it improve reliability, reduce uncertainty, remove a constraint, or help someone else make progress?
Those questions are more useful than simply asking how much work was completed.
Your tools can create work of their own
Here's another trap: once we have a tool, we tend to build processes around it.
We introduce a project management platform to improve coordination. Then we create additional fields, require more status updates, build dashboards, and schedule meetings to review the information. Eventually, maintaining the system becomes another part of the job.
Some of that overhead is justified. We need enough structure to make work understandable and to coordinate dependencies. But a tool can become an additional source of work without producing a corresponding improvement in results.
The fact that a tool is available doesn't mean we need to use every feature. And the fact that a process is automated doesn't mean the process needs to exist.
Automating a report nobody reads simply makes unnecessary reporting faster. Tracking a metric that doesn't inform a decision adds information without necessarily improving anything.
The same applies to our daily routines. We can spend considerable time organizing work, updating work, and reporting on work while leaving less time to perform the work that matters.
Tools should support the work, not become the work.
Full utilization isn't the same as fast delivery
There is a related problem with keeping everyone fully occupied.
In development, work rarely flows without interruption. A pull request waits for review. A feature depends on an API change. A production issue takes priority over planned work. A technical decision blocks three other tickets.
If everyone's schedule is already full, dealing with an unexpected dependency means postponing something else. Work accumulates, context gets switched, and tasks spend more time waiting.
This is the utilization paradox: keeping every person busy can make the overall system slower.
A team needs some capacity to handle variability, review work, resolve blockers, and respond to unexpected problems. That capacity may look unused on an individual schedule, but it can help work move through the system more quickly.
This is also why maximizing the number of active tickets is a poor objective. Ten tasks in progress aren't necessarily better than three tasks moving steadily toward completion. More work in progress often means more context switching and more unfinished work to manage.
The goal isn't to keep everyone occupied at every moment. It's to help valuable work reach completion reliably.
Try subtraction before optimization
When productivity feels low, the instinct is often to add something: another tool, another dashboard, another meeting, another process, or a new way to track performance.
Sometimes that is exactly what's needed. But before adding anything, it is worth asking what can be removed.
- Can a recurring meeting become an asynchronous update?
- Can a report use data already available in the project system?
- Can an approval step be eliminated without introducing unacceptable risk?
- Can a team stop maintaining a metric that never influences a decision?
The same approach works at the task level.
- Can a feature be simplified?
- Can an unnecessary dependency be removed?
- Can a decision be made once instead of repeatedly reopened?
- Can the team stop working on something that no longer justifies its cost?
Subtraction often improves several things at once. Removing an unnecessary handoff can reduce waiting, communication overhead, and the risk of misunderstanding. Simplifying a process can free capacity without asking anyone to work faster.
Of course, removing work indiscriminately isn't the answer. Reviews, tests, documentation, and controls can prevent expensive failures. The point is to distinguish necessary work from work that persists simply because it has become part of the routine.
Make progress the objective
None of this means we should stop tracking tickets, measuring delivery, or using productivity tools. We need operational metrics to understand how a system behaves. We just need to be careful about what conclusions we draw from them.
A busy board tells us that many tasks are being handled. It doesn't tell us whether the right tasks are being handled, whether they are producing useful outcomes, or whether the process could achieve better results with less effort.
The next time a team looks productive on paper but struggles to deliver, look beyond individual activity. Examine unfinished work, dependencies, repeated coordination, and the processes that consume time without changing the result.
The improvement might not come from asking developers to complete more tickets. It might come from removing a bottleneck, simplifying a decision, or stopping work that shouldn't have been started.
This is the central idea behind the MXI Studio editorial Busy Is Not Productive: productivity is not the amount of activity a system can generate. It is the useful progress that system produces relative to the time, effort, and resources it consumes.
And before adding another tool to improve productivity, there is one question worth asking:
What could we stop doing and still achieve a better result?
Dive Deeper: Read the full, unabridged analysis on Busy Is Not Productive.
Top comments (0)