“The Linkway attached to the STT for the JNN is has a high BER from the RHN because the PVCs weren’t built correctly.” How many times have we (or one of our Soldiers or Officers) said something like this to the Commander or XO, only to watch their eyes glaze over, get pissed off, and walk away mumbling something about “FIX IT”? Signal folks (much like intel and a few other very specialized war fighting functions) have a language of their own that few people outside of their own group are able to speak or understand. We understand the language of “geek”. We were taught it in AIT many years ago, speak it at “home” (the company) with our brothers and sisters (Soldiers, NCOs, and Officers) but when we walk outside and talk to the people around us, they don’t understand it because they only speak “grunt” and so they don’t understand us, and then we get pissed off because they ignore us even though we are actually in their city. It’s like taking a trip to Russia and then getting pissed off that the locals don’t understand our English.
Translating geek to grunt is a critical task that all senior NCOs, and officers (including us warrants) have to be able to master when we face the likely event of working in a tactical unit vs some other unit full of signal folks. When we are in tanker (or infantry) land, we have to speak their language (grunt) vs what we grew up with and are comfortable with (geek). So how do we do this?
Geek to Grunt Dictionary
Just a couple of weeks, I mentioned ADRP 1-02 when we talked about the subject of shapes for network diagrams. While there is a noticeable lack of symbols used to represent objects that we need to (JNN, CPN, etc.), there is not a lack of terms by any means. In addition to being the official guide for Army symbols, ADRP 1-02 is also the official “dictionary” of Army terms and even acronyms. These are terms that grunts understand. They are taught them in school over their career, they plan, write, and execute orders based on the definitions of these words but as signal folks, we absolutely suck at using them and on the occasion that we do use them, we’re generally using them incorrectly trying to say something that they don’t mean by doctrine. And then we wonder why our commander just tells us to shut up and sit down.
When we live in the land of grunt, we must be able to speak to the locals in their native language or suffer the consequences. That means that it is incumbent on us (not them) to learn how to speak their language and use it correctly when we are talking about how our concept of mission command (aka the commo plan) will support their scheme of maneuver (what everyone else is going to be doing).
Knowing How They Fight
Despite the fact that the Army’s move to modularity years ago was supposed to make units of a particular type interchangeable, we all know that no two units operate and fight in the same way. Armor units fight significantly different than light units who fight different than Stryker units. 2/1 AR fights different than 2/1 ID even though they are both armor brigades. The reason for this is because they have different experiences in the unit’s collective history, different staffs, and different commanders. Understanding how our particular unit fights is critical to ensuring that we know how make our plan.
Knowing Their Plan Before You Make Your Plan
Units don’t fight the signal plan; Signal fights the unit’s plan. We all say this, but I don’t think that nearly as many of us actually truly acknowledge this or understand the impact that that simple statement has. We as staff officers (and yes, as a Brigade Net Tech, you are absolutely a staff officer in addition to being a technician) have the responsibility to develop our particular plan in order to support the Brigade’s plan. When that plan is initially being developed and refined, we are responsible for providing input (abilities, constraints, etc.) but once the boss decides what plan they will execute it often means that we must go back and at least refine if not radically change what the signal plan is.
In order for us to develop a signal plan that fully supports the operation, we need to know what the hell is going on in the operation. That means ensuring that the S6 has representation during MDMP, actually reading the products and orders that are produced during MDMP and orders production, and then making sure that the plan that we develop actually supports the operation.
During a recent rotation here, there was a decision point for the commander that was clearly identified during MDMP that basically said that the commander was going to have to decide if the unit was going to fight to the north or to the south based on a number of things. The preferred decision by most involved was to the north. When the S6 developed the FM retrans plan, they came up with a pretty good plan to support comms to the north. The problem occurred when the commander actually reached that decision point and decided to go south. At that point, the S6 hadn’t even considered a plan to support the south and communications quickly failed.
While we must plan for contingencies, it is obviously impossible to plan for every one of them. However, when the plan clearly identifies that one of two things may happen when we reach a decision point, we have the responsibility to plan for both A and B and to be able to execute once that decision is made. The only way we can know about those critical decision points is to be part of the planning.
Does our Plan Support Their Plan?
Once we know their plan, we need to make sure that our plan supports it even if we’re not crazy about it. Again, our plan has to support theirs, not the other way around. This means that we have to acknowledge the constraints that their plan puts on us. Another classic example that I see routinely is again with retrans. Our plan calls for us to emplace a retrans team on a hill that is forward of the Forward Line of Troops (FLOT). While it is possible to do, it is rarely a good idea. Instead of trying to put a retrans team forward, we need to figure out a way to support the unit from slightly behind and then once the terrain feature that we ultimately want is secure, bound the retrans team forward.
In another example with WIN-T that I see frequently concerns the Brigade Sustainment Area (BSA). With the move from FOB based fights to decisive action, the BSA has taken up a much higher level of importance. In many cases the BSA is the largest concentration of assets and people for the entire brigade. This means that there are a large number of different types of people and units that require communications support. Under the MTOE, the BSB (which generally runs the BSA even though it is by no means the only element actually there) only has a CPN. That CPN can very easily run out of resources to support all of those users. That is one reason why I am personally an advocate of putting the TAC’s JNN at the BSA.
Teach Our Leaders
As much as we dread doing it, we have to take the time to teach our leaders and other primary staff just what signal can and can’t do. This has a few important objectives. First, it provides expectation management so that when things operate slow, or they enter a communications blackout area, etc., they know this going into the operation instead of discovering it during the operation. Additionally, it helps provide us with some extra leverage on getting what we need into the plan to support their plan if they understand why we need it.
Another reason for this education piece is to open up general communication between the S6 and the rest of the staff. We can do a lot to support the staff but if they don’t know what to ask for, we can’t offer it up to them. Additionally, they can do a lot for us but if we don’t talk to them, we’ll never get it.