Individual vs. Team Productivity

Many people define "productivity" as how much you can accomplish in a given unit of time. Using this definition as the basis for higher productivity can sometimes be counter-productive.

Consider the following examples:

1. As a product manager, you can start writing up many new product features for your development team. But, if you do not have enough resources, all you have done is create a huge backlog of work.
2. As a tester, you can find many more bugs per hour than the average tester. But, this has just created more work for the project manager and the developers.
3. As a developer, you complete and check in more features than expected. Now the build is delayed because there is more work for regression and integration testing.

The above examples all relate to problems caused a team setting by a highly productive member of the team.

In a team, every person's work is the trigger for another person to start their work. There is a flow in the system. For example, we may have a simple flow like:

Customer -> Business Analyst -> Developer -> Tester -> Customer

There may be backward flows, where a tester reports bugs back and creates work for the developer, or the business analyst requests more information from the customer. The point I want to make is that when each person in a team produces something, they create work for other persons or teams. This is usually good. If there is a reasonable backlog for every person, they can continue working towards producing the end result.

However, if you are a person in the chain and you exhibit very high productivity, you have just created a bunch of problems. First, a huge backlog overwhelms the downstream employee. You or they must now spend time prioritizing the list of items in the backlog. In the absence of prioritization, the downstream employee will work on the wrong things, causing delays for everyone else too.

For example, let us consider a developer suddenly faced with a tester finding several bugs a day, albeit many obscure and minor ones. Since the bug count looks very nasty, he will be tempted to reduce it by knocking off the easier, less time-consuming bugs and delay work on new features. If the tester continues this mode of operation, very soon, you will have a project go totally off the rails.

This issue is, of course, one of the more important concepts in lean thinking. In a manufacturing setting, a highly productive team (or machine) can create huge inventories that consume space and money. In the above example, it may actually be more useful at this point to have the tester report only critical bugs (and sit idle, if need be) while the developer catches up. It may even be more profitable because the product can be shipped sooner and more sales gained.

Let us reverse the situation. Say, a developer produces more than a tester can test within a period of time. This is the case with projects in many smaller companies, where the tester-to-developer ratio is low and the pressure to ship is high. Here, the higher productivity results in a lower quality being shipped. The tester practically doesn't have time to test everything and makes effort allocation choices that may sometimes be wrong.

It is necessary to establish the right rhythm of work within a team. In this way, each person produces just enough to keep the next person busy and no more. This may mean idle time for some people at times. Thus, individual productivity may go down. But the overall team will be more efficient in meeting the objectives of the project in terms of timely delivery and quality.

So what can you personally do? I think you can look at the work you do in terms of the people you affect and start asking yourself questions like:

• If you are doing a task (like writing an email or a document), is it going to create more work for others?
• And if so, is it filling a vacuum or is it adding to an already long list of tasks?
• What effect will your work have on their existing tasks? Beware: if you are the boss, your new request, however silly, will immediate rise to the top, de-prioritizing important tasks.

If you are highly efficient, you cannot help producing more. What you can do is produce only the necessary work product within a shorter time. And then, instead of working on the same thing, you should move onto tasks that do not affect others. For example, a developer or tester can spend time learning new skills while they are idle and waiting for others.

---

Technorati tags: productivity