Русская версия

Search document title:
Content search 2 (exact):
ENGLISH DOCS FOR THIS DATE- Dev-T Summary List Additions (DEVT) - P690130-2 | Сравнить

RUSSIAN DOCS FOR THIS DATE- Добавления к Перечню Видов Дев-ти (ИСР) (ц) - И690130-2R80 | Сравнить
- Дополнение к Перечню ИСР (ИСР) (2) - И690130-2 | Сравнить
- Дополнение к Перечню ИСР (ИСР) - И690130-2 | Сравнить
- Дополнение к Перечню Искуственно Созданных Работ - И690130-2R80 | Сравнить
- Дополнения к Перечню Видов ИСР (ИСР) - И690130-2R80 | Сравнить
- Дополнения к Перечню Искуственно Созданных Работ - И690130-2R80 | Сравнить
- Оргсхема Отделений по Работе с Публикой (ц) - И690130 | Сравнить

SCANS FOR THIS DATE- 690130 - Board Policy Letter - Dev-T Summary List Additions [BPL03-056]
- 690130 - HCO Policy Letter - Public Divisions Org Board [PL014-020]
- 690130 Issue 2 - HCO Policy Letter - Dev-T Summary List Additions [PL014-019]
- 690130 Issue 2R - Board Policy Letter - Public Divisions Org Board [BPL07-037]
- 690130 Issue 2R - HCO Policy Letter - Dev-T Summary List Additions [PL038-027]
CONTENTS DEV-T SUMMARY LIST ADDITIONS 36. ACCEPTING AN ALMOST 37. FAILURE TO GET AN ORDER CLARIFIED 38. IRRELEVANT INFORMATION 39. REASONABLENESS 40. FAILURE TO TERMINATEDLY HANDLE, REFERRAL 41. FAILURE TO COMPLETE A CYCLE OF ACTION and REFERRAL 42. FAILURE TO RECORD AN ORDER 43. UNCLEAR ORDERS 44. MISUNDERSTOOD ORDERS 45. RELAYING AN ORDER IN A CONFUSING MANNER 46. CLEANING CLEANS 47. REPEATED TRAFFIC 48. FAILURE TO WEAR YOUR HAT 49. UNUSUAL SOLUTIONS 50. REMOVING PARTICLES OFF THE LINE 51. SLOW COMM LINES Cохранить документ себе Скачать
HUBBARD COMMUNICATIONS OFFICE
Saint Hill Manor, East Grinstead, Sussex
HCO POLICY LETTER OF 30 JANUARY 1969
Issue II
Remimeo

DEV-T SUMMARY LIST ADDITIONS

Adds to HCO P/L 27 Jan '69
(add to Dev-T Policies)

An actual example of Dcv-T (Developed Traffic) follows:

A warm wind came up and the heating system on the "MV APOLLO" was no longer required to be on. A message was sent to the Engine Room to “turn off the heat”.

The order was not complied with.

The order was repeated some time later to a steward to send a messenger to the Engine Room and tell them to “turn the heat off the fans”. The messenger was not sent by the steward, but the steward instead told the I & R (Inspections and Reports) of the Engine Room who was making his inspection rounds, to turn down the heat.

Again the order had to be repeated this time to a messenger who went to the F.nginc Room and gave the order to “turn the heat off the fans” to the Engineer of the Watch.

He replied, “We turned it down a short while ago!”

The messenger accepted this ALMOST and reported back to the senior executive, who again had to send the messenger to repeat the order to “turn off the heat”. This time the messenger returned with the compliance that the heat had been turned off.

FOUR TIMES the message had to be repeated before compliance was reported.

Developed Traffic.


From the above some new forms of Dev-T can be isolated.

36. ACCEPTING AN ALMOST

The messenger accepted the ALMOST of turning down the heat. The order was to turn it off.

An executive or communicator or messenger who accepts and forwards an “almost” is permitting Dev-T.

Orders given are to be executed and reported DONE, not to be nearly done or almost done.

A communicator can often be tripped up by this form of Dev-T. It is most easily spotted by insisting that the original order or orders be returned with the compliance so that any terminal on the line can tell at a glance what was ordered, and what was done.

37. FAILURE TO GET AN ORDER CLARIFIED

Upon questioning it was found that the messenger had not fully understood what was required and passed this uncertainty on to the Engineer of the Watch.

38. IRRELEVANT INFORMATION

The Engineer of the Watch, when told to “Turn the heat off the fans”, gave the messenger the irrelevant information “we turned it down a short while ago”.

A later check revealed that he did indeed comply and turn the heat off but failed to inform the messenger of this, giving her only the irrelevant information that they had earlier turned it down.

This form of Dev-T can also take the form of forwarding to a senior large quantities of irrelevant information, jamming his lines, and reducing his productiveness. The opposite of this, of course is failure to inform one’s seniors of relevant data (see P/L 27 Jan '69 Dev T Summary point 6.)

39. REASONABLENESS

A staff member or executive can be “reasonable” and accept reasons why something cannot be done, accept incomplete cycles as complete, and fail to follow through and get completions.

All of which results in further traffic. This form of Dev-T is best handled by knowing and applying HCOB 19 August ’67 “The Supreme Test”.*[Volume 7, page 362].

THE SUPREME TEST OF A THETAN IS HIS ABILITY TO MAKE THINGS GO RIGHT.

40. FAILURE TO TERMINATEDLY HANDLE, REFERRAL

The only tremendous error an organisation makes, next to inspection before the fact is failing to terminatedly handle situations rapidly. The fault of an organisation’s woffle, woffle, woffle, Joe won’t take responsibility for it, it’s got to go someplace else, and all that sort of thing, is that it continues a situation.

What you should specialize in is terminating the end of a situation, not refer it to someone else. Complete the action now.

41. FAILURE TO COMPLETE A CYCLE OF ACTION and REFERRAL

One of your most fruitful sources of Dev-T is your own double work.

You pick up a dispatch or a piece of work, look it over and then put it aside to do later, then later you pick it up and read it again and only then do you do it.

This of course doubles your traffic just like that.

If you do every piece of work that comes your way WHEN it comes your way and not after a while, if you always take the initiative and take action, not refer it, you never get any traffic back unless you’ve got a psycho on the other end.

You can keep a comm line in endless ferment by pretending that the easiest way not to work is to not handle things or to refer things. Everything you don’t handle comes back and bites. Everything you refer has to be done when it comes back to you.

Complete the action, do it now.

42. FAILURE TO RECORD AN ORDER

Failing to make an adequate record of an order given, losing or misplacing the order can result in endless Dev-T.

The original orders being lost or not recorded at all, wrong items are purchased, incorrect actions are taken, cross orders are given, and a tremendous waste of executive time and money occurs straightening the matter out.

This is one of the most serious sources of Dev-T.

43. UNCLEAR ORDERS

An executive giving an unclear order puts uncertainty and confusion on the line right at the very beginning of the cycle of command.

The safe way on an important programme or action is to Target it.

44. MISUNDERSTOOD ORDERS

Orders misunderstood by the recipient will not be properly complied with as the order was misunderstood. The incorrect or no action following will require further traffic to correct.

As an executive originate clear precise instructions and orders.

As a junior, duplicate the order, and never fail to clarify if you have misunderstood.

45. RELAYING AN ORDER IN A CONFUSING MANNER

Communicators and messengers can create Dev-T and foul up actions by poor relay of information.

46. CLEANING CLEANS

Doing something that is already done or ordering something to be done already done.

47. REPEATED TRAFFIC

The same traffic repeated to the same executive is Dev-T. Often takes the form of information or compliance reported by telex and then the same information being sent by despatch. There are times when a telex is followed by a more lengthy despatch or report, but this should only occur when extra information is really needed.

48. FAILURE TO WEAR YOUR HAT

A person on one post not doing that post but doing every other post creates endless Dev-T, all despatches and origins being off-origin and he covering the hole of his own post.

The person himself is the Dev-T.

49. UNUSUAL SOLUTIONS

Requests for authority to depart from the usual are dangerous when okayed as they then set up areas of difference and cause policy to wander and misfit at the joints.

Juniors who propose unusual solutions generally don’t know the policy or orders anyway.

The proper thing to do is order a checkout on the appropriate policy.

50. REMOVING PARTICLES OFF THE LINE

Apart from being a serious offense, taking comm particles off another’s desk or out of their In Basket or off the comm lines causes Dev-T, and lost time in searching for the missing particles and can sabotage projects or actions, vital data being missing.

51. SLOW COMM LINES

Despatches held up on lines cause other despatches to be originated about the same subject, causing Dev-T to both sender and recipient.

The power of an organisation is directly proportional to its speed of particle flow (letters, despatches, telexes, bodies).

Ken Delderfield
LRH Comm Aide CS-7
for
L. RON HUBBARD
Founder
LRH:KD:ldm.ei.rd