Measuring Productivity: More Difficult for Managers

Jack has an intriguing post, The fun of productivity measures. He ponders how to measure knowledge workers.

For software project teams, it's easy: the number of running, tested features over time. The features have to be complete. No partial credit for partially done features.

But what about for managers? That's a little trickier. I like to start with these things:

  • How many obstacles did I remove?
  • Did I make decisions that stuck? How many? How many had to be remade? (Remaking decisions can mean the time spent on the first one was waste. Maybe.)
  • How much strategic thinking and action did I take? (A little each week and you make progress. None each week and you fall behind.)
  • Did I prevent any crises?
  • Did I cancel any meetings?
  • Did I have to change the project portfolio between portfolio evaluation meetings? (This makes waste for everyone)

Do you have any measures you like for managers?

15 Replies to “Measuring Productivity: More Difficult for Managers”

  1. How many people in my team consider me as a good manager. Or better how many of them consider me as the best manager they worked with?

    How many times I was happy and proud with results achieved by the team?

    How often people were able to convince me to their point of view (if never there’s somthing seriously wrong with me)

  2. A trend change in “The number of running, tested features over time” after the manager has been exchanged.
    How the manager achieved this change (to the better or to the worse) is, IMHO, not properly measurable because too many soft-fuzzy-factors are involved.

  3. I have two quotes which I always share with people who ask me how I measure productivity.

    “In my consulting, I frequently talk to managers who seem obsessed with cutting the cost of software, or reducing the development time, but I seldom find a manager obsessed with improving quality.” Gerald M. Weinberg, “Quality Software Management – Volume I: Systems Thinking”

    “Measures of productivity do not lead to improvement in productivity. Concentrate on quality and productivity will take care of itself.” W. Edwards Deming

    The point of these two quotes is obvious to me. Concentrate on quality. Trying to measure productivity is a waste of time and effort. I don’t agree with measuring implemented features (what constitutes a feature?). Do I increase productivity by implementing the features that are easy and delaying those that are more difficult, even if they have more value to the customer. It’s too easy to game the system, and optimize the wrong variables. Remember, what you measure is what you get. It is like measuring function points, some people swear by this but I never understood the point.

  4. Possible measures for managers:

    (1) the rate of drinking and drug problems among employees.

    (2) the rate of health issues among employees

    (3) the rate of divorce among employees

    One problem with these is that the manager needs to be in place long enough to attribute these measures to the manager and not to the previous manager.

  5. “Did I cancel any meetings?”

    Why is that good? I had to cancel three one-on-one meetings last week. That’s more than the week before. Am I making progress? 🙂

    We shouldn’t measure the processes, we should measure results. That also applies to number of meetings.

    I would suggest maintaining a manager’s backlog of things-to-do. And employees should be accepting or rejecting the results.

  6. In reading your original posts and the comments, I think my take on it stands – don’t measure productivity. However, one chooses to measure it with knowledge workers, especially managers, can be extremely invalid. We can all be very productive doing the wrong things. This seems a clear case of local optimization at the expense of the whole. Measure results – at a much higher level than individual managers.

  7. “For software project teams, it’s easy: the number of running, tested features over time. The features have to be complete. No partial credit for partially done features.”

    This might not be enough. Features are not linear when put side-by-side. Some are ‘easier’ to complete than others. Furthermore, the quality of an implemented feature should matter.

    1. We’re not discussing the quality of the team; we’re discussing the productivity. The only way to measure productivity is to look at output over time.

  8. We may be talking past each other here, saying the same thing in different ways. I’ll stand by my original observation from the Deming quote: “Measures of productivity do not yield productivity.” As Goldratt pointed out in his writings, local optimums, e.g., productivity of individuals or teams, can often lead to inappropriate behavior when considered from the viewpoint of the enterprise as a whole.

  9. I support the comments of Jim Ward.

    High productivity of the wrong features, should it score high or low on “productivity”?
    How about, high productivity of implementing approved requirements that were approved because nobody actually reviewed seriously. Should it score high or low?
    A manager removing 10 obstacles, should be score high or low on productivity?
    How do we measure the number of obstacles he encountered? How do we measure how “heavy” an obstacle is? How about obstacles that cannot be removed due to other circumstances (e.g. a senior manager not willing to authorize time and money for removing the obstacle)?

    What happens if you score high? What happens if you score low?
    Low scores demotivate. High score may demotivate others if it does not feel “right”.

    And finally, where do the measurement engineers get the wisdom from to decide what scale of measurement is correct? Are they so overly talented that they can decide better than the managers who are being measured about what is more productive behavior and what is less? If they are, why are they measurement engineers and not managers themselves?

  10. Measuring productivity is always a problem, but no matter where I go, I’m always asked for metrics.

    Yes measuring productivity is bad, but if you have to do it how would you do it?

    So far, the way I like to think of it is not measuring productivity, but controlling your process.

    You know that your team’s velocity is say 11 points, so you probably want to understand when it goes below that, right?

    As for manager’s productivity, I’m still trying to figure it out 🙂

    This is my current project as a manager and would love to hear comments you might have on this.

    I’m blogging my experiences at



Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.