Probably the basic reason for the expansion of bureaucracies is Dev-T.

When Admin staff in one of our orgs begins to exceed Tech staff then it is obvious that a lot of Dev-T is on the lines. Proof of this is the continual finding that an increase in Admin staff does not lead to an increase in income but on the contrary often heralds an era of decreased gross income.

Within reason, you must not increase Admin staff numbers until you have thoroughly hunted down all Dev-T and taken adequate remedies for it.

When a government sees a lot of despatches it thinks it needs a lot of people.These, making more Dev-T, then seem to need many more people, etc. The cure for a lot of despatches without a lot of new income showing up is a brisk analysis of the org's comm lines.

This is simply done.

1. Look around for constantly full and not emptied In baskets. When you find one in which the traffic does not move, look the post over carefully and decide which one of the following to do on the basis of what you find on that post (a) educate or (b) replace. If, when (a) is done, the basket again remains as before, do (b).

2. Look into people's baskets for despatch and letter dates. If you find a basket where these are quite old, find out why and make up your mind what to do about it on the basis of what you find.

3. Look into drawers for cached despatches, letters, etc. If you find a drawer full, realize somebody is staying clean on the boards by hiding what should be visible. Find out why this violation is occurring and act accordingly.

4. Look over the traffic flow of the principals of the Org (Assn/Org Sec, HCO Sec) and analyze their traffic on the basis of the number of offline, offpolicy, off-origin despatches. Note what staff members are doing these and act accordingly.

5. Make the principals of the org keep logs of offline, offpolicy, off-origin despatches and also bodies brought with despatches. After one week, take these logs and, as they spot the Dev-T artists in the org, act accordingly.

The main thing to know is never get reasonable about Dev-T. If it doesn't cure by education or other means, then you have no choice but to act. The sooner you act, the better for everyone.

The Anglo-Saxon race has a crazy spot on the subject of work. The whole ambition is to not work.

This is quite at variance with several other races and normal thetan behaviour.Easily the greatest source of Dev-T is non-compliance or no-comm.

You can say all you want about despatches and analyze them thoroughly and with benefit to all. But the most deadly conditions, the things most likely to produce the greatest floods of traffic in the long run are non-compliance and no-comm.

One or the other of these is the basis of any emergency.

So in analyzing traffic to increase income and efficiency, be very alert to the points of non-compliance and no-comm.

In our ordinary despatch system these are not easily spotted as we seldom keep copies of our despatches.

The way to locate these spots is by questioning the principals of the org and getting a list of:

1. Emergencies of the past 3 months and what departments and personnel were most closely connected to them.

2. Present time problems of the principals with the org and the names of the staff members most closely connected with these.

Compare lists 1 and 2. You will find that there are names common to both these lists.

Query what despatches remain unanswered by these persons or what orders have not been complied with. This selects out one or two people.

You now have the basic sources of Dev-T in the org which causes more visible Dev-T to build up.

Act accordingly. And don't get "reasonable".

Principals seldom realize that their softness on bad Dev-T offenders works great hardship on other staff members. The real overt is against other staff members by not acting effectively to locate and reduce Dev-T.

As an example, I know of an instance where two staff members' non-compliance and neglect of orders cost an org 120,000 cash in one year alone and brought the org to a point where only heroic action saved it. Only two out of 50 were responsible. The other 48 were working their heads off trying to make a go of things. These two, by non-compliance with despatches, with no-comm, sabotaged all promotion and the entire PO system and nobody could tell how it was happening. When they departed, not only the losses vanished but org income doubled.

So don't ever get soft where you see non-compliance or unanswered despatches. You're looking at trouble and future emergencies that may wipe out the org.

You can pretty well size up a whole org just by watching its despatch lines and baskets.

If you were very skilled at this, you really wouldn't need to move out of the communicator's chair to spot every bad and good point in the org.

Without analysis by Dev-T, an org is carried on the backs of a few desperate staff members.

Why do it the hard way? Watch and handle Dev-T sources and you'll be able to breathe again.