(1) Looks good overall. Nice, long list of points of evaluation that would take a lot of time to reinvent and test.

(2) Looks like it is designed for an employee with a lot of both responsibility and discretion and long-term, continuing work.

However, typically a significant fraction of employees are there to do essentially just what they are told to do, project by project, one at a time. In that case, I’d expect that the more appropriate appraisal would be about a completed project just after the project was completed.

(3) In a lot of organizations, anyone other than the CEO who does any of the following, from the appraisal, even worse if they ever did them all, would be out the door or well on the way:

a. Identifies problems

b. Takes responsibility for problem solving

c. Identifies solutions

d. Decisiveness

e. Action

f. Initiative

IMHO, a darned small fraction of middle managers want any subordinate doing any such things!

=== War Story Example 1

E.g., at times in computing, it’s important to have a large supply of really good random numbers — here I omit the usual long, torturous discussion of just what good random numbers are!

A random number generator that gives, say, only a few hundred thousand random numbers and where each sequence of three consecutive numbers are closely related, as was long common, is not “good”!

One of the more important users of random numbers was, right, Oak Ridge National Laboratory. If you have to ask just why, then I don’t want to tell you!

But some Oak Ridge mathematicians published some tests of the quality of random number generators and some specific recipes that did well on the tests, e.g., as in

R. R. Coveyou, R. D. MacPherson, “Fourier Analysis of Uniform Random Number Generators”, Journal of the ACM, Volume 14, Issue 1, Jan. 1967, Pages 100-119.

One of the recipes, also in one of D. Knuth’s volumes in The Art of Computer Programming, is, for X(0) = 0 and n = 1, 2, …

X(n + 1) = A * X(n) + B mod C

where

A = 5^15

B = 1

C = 2^47

Then for a random number n apparently uniformly distributed on the interval [0,1), take

X(n + 1) / 2^47

Yup, didn’t have to look up this recipe!

In case you want to check your own code, from some quick and dirty coding I just wrote, with X(1) = 0, some of the initial output is apparently:

n X(n)

———- ————-

1 0.000,000,000

2 0.000,216,840

3 0.900,641,062

4 0.086,043,575

5 0.357,810,994

6 0.344,300,077

7 0.552,901,194

8 0.088,387,418

9 0.370,361,679

10 0.050,934,082

11 0.551,504,976

12 0.039,947,104

13 0.041,395,887

14 0.209,097,032

15 0.182,443,859

16 0.674,647,504

17 0.534,733,248

18 0.146,229,796

19 0.418,737,891

20 0.713,940,508

But the long precision needed in the arithmetic there is usually a bit much for most high level programming languages so needs more access to the actual machine arithmetic via assembler language. But writing in assembler is a pain.

So, once I was in a group that needed a lot of good random numbers. At one point, so did I in the work I was doing. So, I got out the documentation on the assembler language for the computer we were using and wrote the code for a generator for the recipe above. Actually, the code was more general than just that recipe because it permitted passing the A, B, C, and X(n) as parameters — that’s like being object oriented if anyone would care!

So, I got my generator running and used it — right, to estimate how many US SSBNs would survive in a special scenario of global nuclear war limited to sea, less exciting than what Oak Ridge was doing but not really trivial. The Navy wanted the results in two weeks, so that was fast work!

Then in our group, the other users of random numbers wanted to use my generator and did. Fine with me.

Tilt! Alarm! Falling rocks! Land mines! Bombs! Incoming! Presto, bingo, I was in deep trouble!

My new, very high quality generator gave significantly different results on some old work using an old, low quality generator.

By several important people I was deeply resented and no longer wanted around.

=== War Story Example 2

Once at FedEx, the BoD wanted some revenue projections. I was working on fleet scheduling and some tricky ways to save money on the cost of fuel (a huge biggie for anyone flying jets) and didn’t want to get involved, but no one had anything beyond hopes, dreams, intentions, etc.

So, I asked, what do we know? Okay, we know the current revenue. And from our fleet planning, we know our capacity. So, the revenue projections have to be essentially an interpolation between those two numbers.

Next, what causes the growth? Sure, happy customers communicating with intended customers, e.g., by sending them a package via FedEx. So, that was viral growth.

So, the rate of growth is directly proportional to both (1) the number of happy customer communicating with (2) the number of intended customers.

So, if we denote time in days by t, the number of customers at day t by y(t), the current number of customers by y(0), the number of customers at our maximum capacity by b, and, from freshman calculus, the rate of growth in y(t) by its calculus first derivative y'(t), then we have that for some constant of proportionality k

y'(t) = k y(t) ( b – y(t) )

where, again, we know y(0).

So that is about as simple as a linear, ordinary differential equation initial value problem gets. Indeed, need only freshman calculus to get an exact solution as a simple algebraic expression.

So, I did that.

With the SVP responsible for the projections, we picked a constant k and submitted a graph something like the attached graph.

That was a Friday. The next day in my office I got a call from FedEx executive Roger Frock who asked about the projections and had me come to the BoD meeting to explain.

I reproduced several points on the curve, and the BoD was happy. FedEx was saved — it had come within minutes of dying.

But, when the dust settled, again, for doing good work, I was resented.

=== Lessons

Net, “No good deed goes unpunished” is not always wrong. There can be a lot of jealousy.

A good CEO or middle manager, if they want good work, needs at least to protect, maybe reward, employees who deliver good work.

(1) Looks good overall. Nice, long list of points of evaluation that would take a lot of time to reinvent and test.

(2) Looks like it is designed for an employee with a lot of both responsibility and discretion and long-term, continuing work.

However, typically a significant fraction of employees are there to do essentially just what they are told to do, project by project, one at a time. In that case, I’d expect that the more appropriate appraisal would be about a completed project just after the project was completed.

(3) In a lot of organizations, anyone other than the CEO who does any of the following, from the appraisal, even worse if they ever did them all, would be out the door or well on the way:

a. Identifies problems

b. Takes responsibility for problem solving

c. Identifies solutions

d. Decisiveness

e. Action

f. Initiative

IMHO, a darned small fraction of middle managers want any subordinate doing any such things!

=== War Story Example 1

E.g., at times in computing, it’s important to have a large supply of really good random numbers — here I omit the usual long, torturous discussion of just what good random numbers are!

A random number generator that gives, say, only a few hundred thousand random numbers and where each sequence of three consecutive numbers are closely related, as was long common, is not “good”!

One of the more important users of random numbers was, right, Oak Ridge National Laboratory. If you have to ask just why, then I don’t want to tell you!

But some Oak Ridge mathematicians published some tests of the quality of random number generators and some specific recipes that did well on the tests, e.g., as in

R. R. Coveyou, R. D. MacPherson, “Fourier Analysis of Uniform Random Number Generators”, Journal of the ACM, Volume 14, Issue 1, Jan. 1967, Pages 100-119.

One of the recipes, also in one of D. Knuth’s volumes in The Art of Computer Programming, is, for X(0) = 0 and n = 1, 2, …

X(n + 1) = A * X(n) + B mod C

where

A = 5^15

B = 1

C = 2^47

Then for a random number n apparently uniformly distributed on the interval [0,1), take

X(n + 1) / 2^47

Yup, didn’t have to look up this recipe!

In case you want to check your own code, from some quick and dirty coding I just wrote, with X(1) = 0, some of the initial output is apparently:

n X(n)

———- ————-

1 0.000,000,000

2 0.000,216,840

3 0.900,641,062

4 0.086,043,575

5 0.357,810,994

6 0.344,300,077

7 0.552,901,194

8 0.088,387,418

9 0.370,361,679

10 0.050,934,082

11 0.551,504,976

12 0.039,947,104

13 0.041,395,887

14 0.209,097,032

15 0.182,443,859

16 0.674,647,504

17 0.534,733,248

18 0.146,229,796

19 0.418,737,891

20 0.713,940,508

But the long precision needed in the arithmetic there is usually a bit much for most high level programming languages so needs more access to the actual machine arithmetic via assembler language. But writing in assembler is a pain.

So, once I was in a group that needed a lot of good random numbers. At one point, so did I in the work I was doing. So, I got out the documentation on the assembler language for the computer we were using and wrote the code for a generator for the recipe above. Actually, the code was more general than just that recipe because it permitted passing the A, B, C, and X(n) as parameters — that’s like being object oriented if anyone would care!

So, I got my generator running and used it — right, to estimate how many US SSBNs would survive in a special scenario of global nuclear war limited to sea, less exciting than what Oak Ridge was doing but not really trivial. The Navy wanted the results in two weeks, so that was fast work!

Then in our group, the other users of random numbers wanted to use my generator and did. Fine with me.

Tilt! Alarm! Falling rocks! Land mines! Bombs! Incoming! Presto, bingo, I was in deep trouble!

My new, very high quality generator, gave significantly different results on some old work using an old, low quality generator.

I was deeply resented and by several people no longer wanted around.

=== War Story Example 2

Once at FedEx, the BoD wanted some revenue projections. I was working on fleet scheduling and some tricky ways to save money on the cost of fuel (a huge biggie for anyone flying jets) and didn’t want to get involved, but no one had anything beyond hopes, dreams, intentions, etc.

So, I asked, what do we know? Okay, we know the current revenue. And from our fleet planning, we know our capacity. So, the revenue projections have to be essentially an interpolation between those two numbers.

Next, what causes the growth? Sure, happy customers communicating with intended customers, e.g., by sending them a package via FedEx. So, that was viral growth.

So, the rate of growth is directly proportional to both (1) the number of happy customer communicating with (2) the number of intended customers.

So, if we denote time in days by t, the number of customers at day t by y(t), the current number of customers by y(0), the number of customers at our maximum capacity by b, and, from freshman calculus, the rate of growth in y(t) by its calculus first derivative y'(t), then we have that for some constant of proportionality k

y'(t) = k y(t) ( b – y(t) )

where, again, we know y(0).

So that is about as simple as a linear, ordinary differential equation initial value problem gets. Indeed, need only freshman calculus to get an exact solution as a simple algebraic expression.

So, I did that.

With the SVP responsible for the projections, we picked a constant k and submitted a graph something like the attached graph.

That was a Friday. The next day in my office I got a call from FedEx executive Roger Frock who asked about the projections and had me come to the BoD meeting to explain.

I reproduced several points on the curve, and the BoD was happy. FedEx was saved — it had come within minutes of dying.

But, when the dust settled, again, for doing good work, I was resented.

=== Lessons

Net, “No good deed goes unpunished” is not always wrong. There can be a lot of jealousy.

A good CEO or middle manager, if they want good work, needs at least to protect, maybe reward, employees who deliver good work.

http://themusingsofthebigredcar.com/power-monkey-see-monkey-ceos/

BRC
http://www.themusingsofthebigredcar.com