Orders, Suggestions, and Good Ideas

Since its formation, the Army has operated under as an organization of order.  The Constitution directs that the President of the United States will also serve as its Commander in Chief.  He exercises his authority over the Army’s various formations through his subordinate commanders (AR 600-20).

While orders can be sent and received by a number of means, written is generally the preferred way.  A written order leaves a permanent record of what that order is.  This can be important in the case of a complex order because it allows everyone to go back and review what the actual order was.  If the order concerns a number of people or organizations, a written order also ensures that everyone is tracking the same thing.

At the brigade level, orders normally come in two forms, an operations order which is generally produced for major events and a Daily Tasking Order (DTO).  While these orders are normally produced by the unit’s S3, they are all signed and executed under the Commander’s authority.

So why is this important to us as a warrant officer?  Because as a Net Tech, Server Tech or pretty much any other kind of “tech” we are going to need/want the units that we support to do something.  Far too often, I see not only warrants but even the Brigade S6 tell a subordinate battalion S6 to do something, and then act surprised when it doesn’t happen.  So why doesn’t it happen?  Because even though we all have general military authority by virtue of our rank, we have absolutely 100% no command authority which makes pretty much everything we tell our units rate as a suggestion or good idea (and you know how we all love good ideas).

Orders Process

So does that mean that we have no way to get units to do what we want/need?  No of course not.  First, the easiest way to get someone to do something for you is for them to want to.  That all goes back to building strong relationships with key people like your battalion S6s and signal company commander/1SG so that when you ask them for something, they are more than willing to help you out because it’s you asking.  However, we don’t always have good relationships and even when we do, just because the S6 wants to support you doesn’t mean his commander is willing to.  That is when it becomes vital to get involved in the orders process.

When the Brigade staff is working on producing an operations order for something major (operation, event, whatever) we have a part of that.  The S6 produces the annex H for that order, but we as the Net Tech should be producing supporting appendixes for the annex.  This should include things like network diagrams, equipment moves, detailed instructions on how the network will operate or be maintained, and things like that.

One thing to remember is that just because it is included in the annex H doesn’t mean that it will actually be read.  Generally only signal people (and sometimes not even them) will read the annex H which means that super important things that may affect the way a battalion operates should be placed in the base order under “tasks to subordinate units” where everyone pays attention (especially the battalion commanders and S3s).  I often see a unit get tasked to pull security for a brigade retrans, but that tasking is in the annex H instead of the base order and then we are surprised when the security team never shows up and the retrans team gets killed.  My general rule is that if it involves the movement of personnel or equipment, it needs to be included in the base order with additional details included in annex H.

While an operations order may only be produced once for each operation, a DTO or fragmentary order (FRAGO) is produced a lot more often (sometimes daily) to help refine things and update orders.  The DTO/FRAGO is where we will often place a lot of information as our plans change or progress.  Again, anytime we are moving people or equipment, it has to be included in the DTO/FRAGO.

Technical Service Order

While written orders are essential to informing the force of what we are doing, they normally lack the technical details that spell out how we are going to do it; this is where the Technical Service Order (TSO) comes into play.  The TSO is a document which generally stays internal to S6s and supported nodes and lays out in exact detail how the network is configured.

The TSO should include such things as frequencies for a HCLOS link or router configuration snippets.  This ensures that not only is the network configured in a way that we have planned, but also that we have a written record of changes to help maintain change control.  I have included an example format for TSOs that I used when deployed.

Example TSO