The commonest cause of OFFLINE despatches is:

A staff member writes a despatch to himself but routes it to somebody else.

Example: Registrar writes a despatch to the Org Sec asking how to meet a quota of interviews. This is Dev-T because it is offline. Why is it offline? The staff member responsible for increasing interviews is the Registrar, not the Org Sec. Therefore the despatch should be routed to the Registrar and routing it to anyone else is misrouting. Informing the Org Sec, "I am doing so and so to increase the number of interviews" is quite in order, but it's a despatch containing a report, requiring no answer. The correct routing of a query about increasing interviews would be to the Registrar. Thus, the above example's routing would be the Registrar to the Registrar.

When a staff member generates a lot of despatches about his post, these are usually misrouted if they go to anyone else but himself. Since who else should wear that hat? Not the Org Sec or Assn Sec. Not the HCO Sec. Only the staff member himself or herself.

In orgs a goodly number of people think staff members senior to them also wear their hats. This is definitely not true. The Assn Sec or Org Sec does not wear every other hat in the org. If he does, he is a pretty poor organizer. And if he lets staff force him to, then he isn't much of a leader.

You can detect people who fear responsibility or consequences of their most ordinary actions by the number of despatches they send others which should only have gone to the staff member himself or herself.

It's the figures on the weekly report sheet, the volume of work accomplished, the resume of results that inform others about a hat and the activities and effectiveness of the person wearing it. An Org/Assn Sec only needs to look at these reports, not his in-basket, to know if posts are being held. It may make one feel grand and responsible when others must come to one for help on their jobs but it sure doesn't make a strong org to have "what-do-I-dos" flying up to the head of the org day and night. People exist who do their jobs without a lot of Dev-T about how to do them, what to decide, how to think. And people exist who do their jobs without getting everyone else in trouble.

There is another type of Dev-T which one encounters. And that is the origination of comm that should have been originated by someone else.

This has several guises. You see it in a usual form in Academies where some student is always asking questions "so that the others will understand". The student himself or herself understood the instructor but asks a question so "the others will understand also". This is, of course, a student trying to wear the instructor's hat or another student's student hat. I can usually detect this one and break it right there with "Are you asking because you don't get it or because you think the others haven't?" Such a student can lengthen study hours horribly without helping anyone a bit.

A staff member occasionally tries to originate for another hat than his or her own. It is easily detected. The despatch has to do with the Academy but is from the HGC, etc.

Such a despatch is usually misrouted also. It is sent to a department head or the HCO Sec or somewhere. Trying to handle it gets pretty deadly as it's a double snarl.

The originator shouldn't have originated it and also should have sent it elsewhere if he or she did originate it. If the HGC thinks it has to wear the Academy hat then the despatch should go to the Academy and nowhere else. At least send it to the hat it most concerns.

This gets even more snarled when it jumps an org — to wit, an HGC staff member originates a despatch for the Academy and sends it to, let us say, the National Central Org. In the other org, unfamiliarity with the org board of the originating org can cause action to be taken. It isn't noticed that the HGC is talking for the Academy.

When action is taken other than returning the off-origin despatch to its sender, a great many evils can result. The least of them is that it gets the sender in trouble when acted upon.

Example: A staff auditor proposes to the Assn Sec that students be trained better in 8c because of a recent HGC flub. The Assn Sec jumps on the D of T. The D of T privately pounds the staff auditor into the ground.

Ill feeling in orgs usually stems from these off-origin despatches.

In the above example, the staff auditor should have taken it up emphatically on the basis of a flub in the HGC with the D of P who then would take it up with the D of T still on the basis of an HGC flub. Then it has a chance of straightening out. You see, lacking data, the person originating an off-origin despatch usually assigns wrong cause. In the above example it may have been certification at fault, not the Academy at all. One can drown in a sea of errors on these off-origin despatches. Basically what ails governments is their dependence on spy reports, police reports, etc. The reporting person does not wear the hat which should have originated.

When a staff member does not himself originate when he or she should, it will show up in the OIC reports and in emergencies. It is handled by putting on the person's hat, auditing or personnel transfers, not by off-origin despatches.

Did you know you can let an entheta despatch drop right there and create less entheta by doing so? Try it sometime.

Not all off-origin despatches are entheta, of course.

Part of this type of despatch is of course off-zone. Perth originating for Sydney. Or Los Angeles originating for New York. Or Assoc Sec London (as once happened years ago) doing business only in Australia. Or LA getting pcs only from Nevada. Here one sees somebody operating for the wrong zone or for only part of their whole zone. On a smaller look, a staff member doing only part of his job produces a similar result. And somebody doing another staff member's job is another version of it.

Off-origin despatches or work can make an awful lot of Dev-T — not always pleasant.

An out of date Org Board can cause Dev-T.

A staff that doesn't have a well done Org Board cannot help but make Dev-T.

An Org Board is what we use instead of Appointment lists inside orgs. If it isn't posted on the Org Board, it hasn't been appointed. Why? Because an appointment is effective only if its work will be routed to it. If nobody knows about an appointment, then how can anything but Dev-T occur?

Thus prime preventers of Dev-T are:

1. A well done Org Board.

2. A complete Org Board containing all appointments.

3. A staff checked out on the Org Board.

4. All new staff checked out on the Org Board.

5. No appointments existing that don't appear on the Org Board.

A lot of Dev-T occurs because some people are insufficiently aware of the existence of an org. They think "we're all here together working". They don't realize everybody in the org does a different job than the rest.

There is no one so eager to reorganize everything as a new staff member who has yet to discover the org board and its purposes.

And there is a flood of Dev-T from anyone who:

1. Doesn't know the org board well and who

2. Hasn't got his own hat on.

Obviously, to reduce Dev-T and keep one's In-Basket within reason, one must:

1. Have a complete and well-done Org Board up to date and known, and

2. Get individual hats on.

Otherwise people will misroute continuously — sending their own bits to others and flooding wrong others with despatches.

Given a good Org Board with the purpose of each post stated and the whole thing well known to staff, lengthy and complex hats become less important.

Hats, complete ones, are important and of value.

But did you know that a staff member will do best if he has to evolve his own hat before he reads up on it or afterwards?

The way to do this is on a Clay Table.

Take a very fundamental statement of the staff member's job — a complete, simple statement. Then, have the staff member:

(a) Work out the org in relation to the field and public in clay;

(b) Work out his job in clay in relation to the rest of the org;

(c) Work out his job in clay in relation to his job and himself.

After a staff member has done that (labelling every bit of everything he makes), and then done (a), (b) and (c) again, most of those misapprehensions and not-knows that cause Dev-T will be gone.

And it pays off in the time spent by increased effective volume and decreased Dev-T.

Very little Dev-T is caused by viciousness or mean intent. It's just the accumulations of (1) Not-knowns and (2) Afraid to dos.

Cure them.