An actual example of Dev-T (Developed Traffic) follows:
A warm wind came up and the heating system on the "MV APOLLO" was nolonger required to be on. A message was sent to the Engine Room to "turn off theheat".
The order was not complied with.
The order was repeated some time later to a steward to send a messenger to theEngine Room and tell them to "turn the heat off the fans". The messenger was notsent 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 theEngine Room and gave the order to "turn the heat off the fans" to the Engineer of theWatch.
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". Thistime 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.
The messenger accepted the ALMOST of turning down the heat. The order was toturn 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 oralmost done.
A communicator can often be tripped up by this form of Dev-T. It is most easilyspotted by insisting that the original order or orders be returned with the complianceso that any terminal on the line can tell at a glance what was ordered, and what wasdone.
Upon questioning it was found that the messenger had not fully understood whatwas required and passed this uncertainty on to the Engineer of the Watch.
The Engineer of the Watch, when told to "Turn the heat off the fans", gave themessenger 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 failedto inform the messenger of this, giving her only the irrelevant information that theyhad earlier turned it down.
This form of Dev-T can also take the form of forwarding to a senior largequantities 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 (seeP/L 27 Jan '69, Dev-T Summary point 6).
A staff member or executive can be "reasonable" and accept reasons whysomething cannot be done, accept incomplete cycles as complete, and fail to followthrough and get completions.
All of which results in further traffic. This form of Dev-T is best handled byknowing 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 GORIGHT.
The only tremendous error an organization makes, next to inspection before thefact, is failing to terminatedly handle situations rapidly. The fault of an organization'swoffle, woffle, woffle, Joe won't take responsibility for it, it's got to go someplaceelse, 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 tosomeone else. Complete the action now.
One of your most fruitful sources of Dev-T is your own double work.
You pick up a despatch or a piece of work, look it over and then put it aside todo 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 andnot after a while, if you always take the initiative and take action, not refer it, younever 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 waynot to work is to not handle things or to refer things. Everything you don't handlecomes back and bites. Everything you refer has to be done when it comes back to you.
Complete the action, do it now.
Failing to make an adequate record of an order given, losing or misplacing theorder 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 executivetime and money occurs straightening the matter out.
This is one of the most serious sources of Dev-T.
An executive giving an unclear order puts uncertainty and confusion on the lineright at the very beginning of the cycle of command.
The safe way on an important programme or action is to Target it.
Orders misunderstood by the recipient will not be properly complied with as theorder was misunderstood. The incorrect or no action following will require furthertraffic 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 mis-understood.
Communicators and messengers can create Dev-T and foul up actions by poorrelay of information.
Doing something that is already done or ordering something to be done alreadydone.
The same traffic repeated to the same executive is Dev-T. Often takes the form ofinformation or compliance reported by telex and then the same information being sentby despatch. There are times when a telex is followed by a more lengthy despatch orreport, but this should only occur when extra information is really needed.
A person on one post not doing that post but doing every other post createsendless Dev-T, all despatches and origins being off-origin and he covering the hole ofhis own post.
The person himself is the Dev-T.
Requests for authority to depart from the usual are dangerous when okayed asthey 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 ordersanyway.
The proper thing to do is order a checkout on the appropriate policy.
Apart from being a serious offense, taking comm particles off another's desk orout of their In Basket or off the comm lines causes Dev-T, and lost time in searchingfor the missing particles and can sabotage projects or actions, vital data being missing.
Despatches held up on lines cause other despatches to be originated about thesame subject, causing Dev-T to both sender and recipient.
The power of an organization is directly proportional to its speed of particle flow(letters, despatches, telexes, bodies).