The situation one often finds in an org, after one has, to some degree, conquered dev-t, is that PEOPLE REQUIRE ORDERS.
For years I wondered why this was so. Well, I found it.
WHEN PEOPLE DO NOT CLEARLY KNOW WHAT THEIR PRODUCTS ARE THEY REQUIRE CONSTANT ORDERS.
To the Establishment Officer, this reflects most visibly in trying to get program targets DONE.
Some people have to be ordered and ordered and ordered and threatened and howled at. Then, in a bewildered way, they do a target, sometimes half, sometimes nearly all.
Behind this apparent blankness lies an omitted datum. When they’re like that they don’t know what their product is or what it adds up to. Or they think it’s something else or should be.
That blankness can invite overts.
It is very seldom that malice or resentment or refusal to work lies behind the inaction. People are seldom that way.
They usually just don’t understand what’s wanted or why.
Because they don’t know what a PRODUCT is!
A whole Ad Council of a downstat org was unable even to define the word.
They had required orders, orders, orders and even then didn’t carry them out.
A staff member who requires orders may also think that any order is a policy and lasts forever. If you look into hats you will even find casual “close the door” type of orders, given on one occasion to fit one circumstance are converted over into STANDING (continual) ORDERS that forever keep a certain door closed.
An Esto surveying the hats of a unit may very well find all manner of such oddities.
It is a standard Esto action to survey hats.
In hats you will find despatches giving specific orders or quoted remarks preserved instead of notes on what one has to know to produce a product.
In auditors’ hats, directions for 1 specific pc in 1960, never published and from no tape or correct source, held onto like death like it was to be applied to every pc in the world!
A dishwashing hat may have orders in it but not how to wash dishes rapidly and well.
This is all a symptom of a unit or activity that does not know what its products are.
Where you find lots of orders kicking around, you will also find disestablishment by bypass, command channels not held and staff members like to take their orders from anyone but those in authority — any passerby could give them orders.
This is rampant where an executive has not been well on post.
By counting such orders up and seeing who they are from one can determine the unhattedness of staff, their org bd weaknesses and principally their lack of knowledge of their products.
If an Esto is to hat so as to get the staff member to get his product out, then the Esto has to know how to clear up “products.”
Now an Esto is an Establishment Officer? There are Product Officers. The product of an Esto is the establishment. Then what is he doing with products?
Well, if he doesn’t hat so staff members get out products then the org will be a turmoil, unhappy and downstat.
Production is the basis of morale.
Hattedness is a basic of 3rd dynamic sanity.
But if you don’t HAT SO AS TO GET THE STAFF MEMBER YOU ARE HATTING PRODUCING YOU WILL HAT AND HAT AND IT WILL ALL BE IN VAIN. The person won’t stay hatted unless he is hatted so as to be able to produce.
The Product Officer should be working to get the products out.
So if you don’t hat for the product then the staff member will be torn between two sets of orders, the Esto’s and the Product Officer’s.
Only when you hat to get product will you get agreement with Product Officers.
If you are in disagreement with Product Officers, then the Esto is not hatting to get production.
There is a right direction to hat. All others are incorrect.
1. CLEAR UP WHAT THE PRODUCT IS FOR THE POST AND HAT FROM THERE.
2. HAT FROM THE TOP OF THE DIVISION (OR ORG) DOWN.
These are the two right directions.
All other directions are wrong.
These two data are so important that the failure of an Esto can often be traced to violation of them.
You can have a senior exec going almost livid, resisting being hatted unless you hat by first establishing what the product is. If PRODUCT is first addressed and cleaned up then you can also hat from the top down.
If this is not done, the staff will not know where they are going or why and you will get silly unusual situations like, “All right. So you’re the Establishment Officer. Well, I give up. The division can have 2Vi hours a day establishment time and then get the hell out of here so some work can be done! . . .” “Man, you got these people all tied up, stats are down! Can’t you understand. . . .”
Well, if you don’t do one and two above you’ll run into the most unusual messes and “solutions” you ever heard of, go sailing off policy and as an Esto wind up at your desk doing admin instead of getting your job done in the division. And an Esto who is not on his feet working in the division is worth very little to anyone.
So see where the basic errors lead and
Hat on product before doing anything else and
Hat from the top down.
This is a general rundown of the sequence by which product is cleared and recleared and recleared again.
This can be checklisted for any exec or staff member and should be with name and date and kept in the person’s “Esto file folder” for eventual handing to his new Esto when the person is transferred out of the division or in personnel files if he goes elsewhere.
NOW he really can be hatted.
Quickie handling is a very very bad fault. “Quickie” means a brush-off “lick and a promise” like wiping the windshield on the driver’s side when really one would have to work at it to get a whole clean car.
So don’t “quickie” product. If this is poorly done on them there goes the old balloon. Hatting won’t be possible.
Orders will have to be poured in on this terminal. Dev-t will generate. Overt products will occur, not good ones. And it won’t be worthwhile.
There can be a lot of disagreement amongst Product Officers and Estos on what products are to be hammered out.
In such a case, or in any case, one can get a Disagreements Check done in Dept of Personnel Enhancement (who should look up how to do one).
This is a somewhat extreme way to settle an argument and should only be a “when all else fails.”
It is best to take the whole product pattern of the org apart with the person, STARTING FROM THE BIGGEST PRODUCT OF THE ORG AND WORKING BACK TO THE PERSON’S PRODUCT.
Almost always there will be an outpoint in reasoning.
An exec who only wants GI can be a trial as he is violating EXCHANGE. As an org is paid usually before it delivers, it is easy to get the org in trouble by backlogs or bad repute for nondelivery. An org that has credit payments due it that aren’t paid maybe didn’t deliver. But Div III may soften up collections for some reason like that and then where would the org be?
Vol 0 of the OEC Course gives an excellent background of how a basic org works. As one goes to higher orgs, lower orgs are depended upon to continue to flow upward to them. (See HCO PL 9 Mar 72 Issue I Finance Series No. 11 “Income Flows and Pools.”)
A study of Vol 0 OEC and a full understanding of its basic flows and adapting these to higher orgs will unsnarl a lot of odd ideas about product.
The Esto has to be very clear on these points or he could mis-hat a person.
Usually however this is very obvious.
Heads of orgs and divisions have had to organize so long they get stuck in it.
They will try to order the Esto.
This comes about because they do not know their products or the Esto is not following 1 and 2 above and does not know his own product.
The Product Officer may try to treat the Esto as a sort of “organizing officer” or a “program officer” if
So it comes back to the 1 and 2 first mentioned.You can look over it now and see that if one is not doing these two things, dev-t, nonviability and orders will occur.
So where you have dev-t, down stats and orders flying around you know one thing that will resolve it:
SOMETHING WILL HAVE TO BE IRONED OUT ABOUT PRODUCT.
When it all looks impossible, go to this point and get to work on 1 and 2.