How do you measure your teams productivity?
The way you measure productivity directly impacts the improvement processes that are implemented. Traditional management science focuses us on metrics such as worker utilization i.e. how hard are workers working and then subsequent improvement processes are geared toward keeping workers working as hard as is possible. Companies reward people who put in tons of time and classify them as star employees. The fundamental problem with this approach (at least in knowledge work) is that it is dependent on individual productivity on the team being exactly the same. This is rarely (if ever) the case. If I am on team of 4 people, and we all put in a 40 hour week, because we don’t all generate the same output in 40 hours, it is most likely that some output is not being processed. Now let’s assume that I’m the most productive individual on the team and I put in a 60 hour week but my teammates only put in 40 hours, my extra 20 hours becomes a larger problem because the deficit of work that needs to be processed is increased. Everyone’s utilization (hence productivity) needs to increase significantly to balance out the system. A teammate may need to work 80 hours just to catch up! In an interesting way, my extra effort causes my teammates to become bottlenecks when it was supposed to increase our collective throughput. Sort of counterintuitive wouldn’t you say. We see this a lot when developers deliver too much software for testing, such that the testers can’t keep up. Operating at full capacity (or overloaded in the case of 60 and 80 hours) eventually causes the system to breakdown leading to unhappy people and systemic poor quality.
Maybe there is another starting point for measuring productivity. Let’s see, how about if we measured how long it takes to deliver what we’ve promised in the form of cycle time? By focusing on the product (and not the people) we (hopefully) begin to direct our efforts to shortening the cycle time by addressing those things that are impacting it in the first place. We begin looking at the bottlenecks in our flow and try to address them. Maybe we’re taking on too much work in the first place. Maybe our estimates are completely unrealistic. Maybe we are understaffed. We identify better ways to actually get the most out of the team by (for example) developing in a set based manner or increasing feedback loops with our end users. We end up with a more efficient and effective way of delivering value (and it just might be that people want to work harder out of their own volition).
This is part of what lean thinking is about. It might be worth taking a look at.