As a resigning employee. I have received quite a few requests to emphasize the company's current practice of scorecarding.
In a way, it's sad that it takes someone to leave for management to take notice of pain within the organization. I'm happy to do what I can to improve the conditions for my compatriots.
I've had a lot of requests from colleagues to make certain that I mention the current performance management policy.
I've talked about this before, but to summarize the policy: the individual contributors at my soon to be former company do an awful lot of work for the sake of performance management. Our senior director advised that we should spend approximately four hours a week working on performance management work, i.e., 1 on 1 with manager, team meetings, forecasting hours, time reporting, and updating our scorecards. With the exception of the meetings the performance management actions advance no cause other than to provide data points for the managers of those contributors to rank them.
Performance management work does little to make people more more performant. When contributors are aware of the criteria against which they are evaluated they make sure that they work to those points. It's an old game and it is universally played in systems where sets of data points are used to evaluate self aware people and organizations.
I liken performance management to mandatory testing in the public school systems. Because there is a test that evaluates the students, and the school, the teachers shape their content. Test standards and scorecards both narrowly define a success condition. In the case of public schools, curricula that does not advance students towards scoring well on the test are de-emphasized or eliminated.
In my company, all you need to do is make certain that you meet the goals on your scorecard. The goals are mostly time driven, or as Nate Schutta would say emphasizing dateility. You meet the date and have a project that doesn't linger in QA for too long you succeed. That's all that matters.
You could deliver an application that barely meets the customers' needs that is rock slow and painful to use and still get praised. Why? Well, the company has a scorecard of its own. The stock price, which is influenced in no small part on the company's 10Q. How does software play into this? Well, internal software development, under certain circumstances is a capitalizable. What does that mean? In my company it means that time that is spent working on a capitalized project is treated differently than other projects.
We are discouraged from working on non-capitalizable work and are rewarded for reporting time against capitalizable work.
I've been told that capitalization is the reason that IT departments are so interested in time tracking. I'm kind of surprised that someone hasn't figured out how to make all IT work capitalizable without wasting all sorts of time having the people who do the capitalizable work spend non-capitalizable time tracking time. I can see that trend coming down the road though.
But I digress, the company is held to a single number grade, stock price to evaluate success. I would cynically argue that work that advances the company towards a higher stock price through the financial reporting is prioritized over all other work. As the sludge flows downward we can see delegation of a narrowly defined set of success conditions assigned throughout the IT orgainzation. That is why I believe that our goals are so narrowly defined.
The question that nobody seems to have asked is whether working towards maximizing short term gains is in the best long term interest for an organization?
In any scenario where you have a metric that is a performance indicator, people should stop confusing the metric for the goal. Setting narrow goals or scorecarding aspects of a job is not a healthy practice. The participants who are most interested in making themselves look good will optimize their work to achieve those specific goals. Unless particular attention is paid to the goals when they are defined, the end result is going to be results that are optimized to achieve the narrowly defined goal. At least, the people who will be rewarded most are those who achieve the best scores on the narrowly defined goals.
Consider the following goal that I see in lots of organizations. The people who define the goals want their workforce to improve their forecasting abilities. They set the goal that those whose actual hours match their forecasted hours closest are the ones who are rewarded the most generously. People who are most interested in the reward will do whatever it takes to maximize their reward. In this case it's pretty easy for someone to overestimate the time and then drag their feet in the project to make the actuals match the estimate. Why wouldn't someone?
Software development, or any kind of work, is mostly a zero sum game. In software development, there's completeness, quality, and time. They are interdependent variables, if you change one of them the others will need to change.
Managing employees is exactly the same. If you emphasize one element of a person's job over the rest of the elements, the other elements will suffer.
What probably suffers the most is employees morale when they are told not to do what they know is right.
In a way, it's sad that it takes someone to leave for management to take notice of pain within the organization. I'm happy to do what I can to improve the conditions for my compatriots.
I've had a lot of requests from colleagues to make certain that I mention the current performance management policy.
I've talked about this before, but to summarize the policy: the individual contributors at my soon to be former company do an awful lot of work for the sake of performance management. Our senior director advised that we should spend approximately four hours a week working on performance management work, i.e., 1 on 1 with manager, team meetings, forecasting hours, time reporting, and updating our scorecards. With the exception of the meetings the performance management actions advance no cause other than to provide data points for the managers of those contributors to rank them.
Performance management work does little to make people more more performant. When contributors are aware of the criteria against which they are evaluated they make sure that they work to those points. It's an old game and it is universally played in systems where sets of data points are used to evaluate self aware people and organizations.
I liken performance management to mandatory testing in the public school systems. Because there is a test that evaluates the students, and the school, the teachers shape their content. Test standards and scorecards both narrowly define a success condition. In the case of public schools, curricula that does not advance students towards scoring well on the test are de-emphasized or eliminated.
In my company, all you need to do is make certain that you meet the goals on your scorecard. The goals are mostly time driven, or as Nate Schutta would say emphasizing dateility. You meet the date and have a project that doesn't linger in QA for too long you succeed. That's all that matters.
You could deliver an application that barely meets the customers' needs that is rock slow and painful to use and still get praised. Why? Well, the company has a scorecard of its own. The stock price, which is influenced in no small part on the company's 10Q. How does software play into this? Well, internal software development, under certain circumstances is a capitalizable. What does that mean? In my company it means that time that is spent working on a capitalized project is treated differently than other projects.
We are discouraged from working on non-capitalizable work and are rewarded for reporting time against capitalizable work.
I've been told that capitalization is the reason that IT departments are so interested in time tracking. I'm kind of surprised that someone hasn't figured out how to make all IT work capitalizable without wasting all sorts of time having the people who do the capitalizable work spend non-capitalizable time tracking time. I can see that trend coming down the road though.
But I digress, the company is held to a single number grade, stock price to evaluate success. I would cynically argue that work that advances the company towards a higher stock price through the financial reporting is prioritized over all other work. As the sludge flows downward we can see delegation of a narrowly defined set of success conditions assigned throughout the IT orgainzation. That is why I believe that our goals are so narrowly defined.
The question that nobody seems to have asked is whether working towards maximizing short term gains is in the best long term interest for an organization?
In any scenario where you have a metric that is a performance indicator, people should stop confusing the metric for the goal. Setting narrow goals or scorecarding aspects of a job is not a healthy practice. The participants who are most interested in making themselves look good will optimize their work to achieve those specific goals. Unless particular attention is paid to the goals when they are defined, the end result is going to be results that are optimized to achieve the narrowly defined goal. At least, the people who will be rewarded most are those who achieve the best scores on the narrowly defined goals.
Consider the following goal that I see in lots of organizations. The people who define the goals want their workforce to improve their forecasting abilities. They set the goal that those whose actual hours match their forecasted hours closest are the ones who are rewarded the most generously. People who are most interested in the reward will do whatever it takes to maximize their reward. In this case it's pretty easy for someone to overestimate the time and then drag their feet in the project to make the actuals match the estimate. Why wouldn't someone?
Software development, or any kind of work, is mostly a zero sum game. In software development, there's completeness, quality, and time. They are interdependent variables, if you change one of them the others will need to change.
Managing employees is exactly the same. If you emphasize one element of a person's job over the rest of the elements, the other elements will suffer.
What probably suffers the most is employees morale when they are told not to do what they know is right.
Posts
No comments:
Post a Comment