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.
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.
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.
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.)
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”.
THE SUPREME TEST OF A THETAN IS HIS ABILITY TO MAKE THINGS GO RIGHT.
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.
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.
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.
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.
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.
Communicators and messengers can create Dev-T and foul up actions by poor relay of information.
Doing something that is already done or ordering something to be done already done.
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.
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.
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.
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.
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).