Z.05: Your Most Casualty Producing Weapon
Part of the reason data literacy keeps getting relegated to ‘just a CTO / CDO task’ is because people tend to conflate it with digital literacy. This is in part because the digital transformation has had an unmatched impact to both the amount and speed of data. The progress started out slowly and much further back in time than many think, because today its rate of change has been logarithmic.
As I mentioned a couple posts ago, there’s been a place for data literacy in combat for over 160 years. Yet, a decade before Florence Nightingale was doing data analysis on the Crimean War, Ada Lovelace was writing the first computer program. While it’s not clear when data and digital literacy first met up, few would dispute that Alan Turing’s contribution to defeating the Nazi’s in World War 2 firmly established the idea that data and digital literacy were going to change warfighting.
While I concede a person can be digitally fluent and not be data literate — see cryptobros and their NFTs — I do firmly believe that digital matters to data. It’s why the first part of my definition of data literacy is ‘Digitize information into data structures’. Unfortunately, a lot of military commanders see data in the same lens as they view digital: someone else’s job.
Commanders can’t know everything. They have to be judicious about where they spend their time studying the craft of war. Which subjects will they know intimately? Which can they get by on a cursory level, relying on their staff to be their subject matter experts? How does one know the difference?
One rule introduced to me early on in my career was ‘Always know the capabilities of your most casualty producing weapon’. That’s why I know a M240C 7.62mm machine gun has a maximum fire rate of 950 rounds-per-minute, the maximum effective range of a M224 60mm mortar is just under 3.5 kilometers, and you can run an M1A2 Abrams tank for about 10 hours before it needs gas. At early points in my career these were key things to know, impacting my daily life, and on occasion, preventing an early death.
Now I could easily spend the rest of this post writing about how later in my career what was my most casualty producing weapon changed. I could write about how as you progress in rank you need to learn new capabilities. All of that is true.
But no commander gets a pass for not knowing some things, regardless of their grade plate. So, instead I’m going to share a time when a young SF Captain under my command, the youngest grade we give commands in the army, didn’t know the capabilities of his most casualty producing weapon: a digital radio. Every commander, of every grade, needs to know about the capabilities of their digital systems.
Our battalion TOC had just jumped to an island and set up the myriads of satellites and computers we needed to keep the headquarters running.1 We’d opted to leave the headquarters and build our TOC on a nearby island because nothing helps validate your packing lists like having to catch a ferry back to the office because you forgot to pack dry erase markers. Moving our TOC had immediate and noticeable impacts to the way we communicated inside the headquarters.
Just like when I was the group S3, our staff leveraged OneNote to share information flat and fast. When I showed up to the island, the staff’s first issue they raised with me was their notebooks were struggling to synch. The OneNote notebooks we typically relied on were stored on hard drives back in the building with us when we were on Torii Station. Now that we’d jumped forward to Ie Shima, those hard drives went from roughly 100 meters away to just under 40 kilometers. Except not really, because we weren’t firing data back and forth via microwave, but instead relying on SATCOM.2
SATCOM data moves at the speed of light, so we often seem to expect it to be very fast. But SATCOM means your traffic needs to go to space. And space is very, very far.
Just how far? Well for planning purposes, geo-synchronous orbits are just over 35,000 kilometers away from the surface of the earth.3 If you ran a 5k every day, that would take you a week to get to. And that’s just one way. Whatever message you send to the satellite has to come back to earth. Hope you like running. I don’t.
If our data was going from our TOC on Ie Shima to the box back on Torii, that round trip ticket to space would take just under half-a-second at light speed. Except, it wouldn’t be doing that, because that’s not how military networks work.
Instead traffic moves between different nodes that are scattered across the globe. When one staff officer updated their OneNote, the changes weren’t going down the red ethernet cable to the switch in the next room and back up to the laptop next to them. Instead, those updates were taking trips all around the globe, and at least two round trips to space and back. Just to move data half a meter to the right.
Those transmission times don’t take into account actual processing either. The data may move at the speed of light, but there’s a lot of processing that has to be done, breaking the data down, reassembling the data on the other end, and resending lost packets. Transmission can often be the fastest part of the whole process. Every time you make an update multiple computers have a lot of computation to get done. Multiply that times 50 for all the people working in the JOC and the bandwidth challenges quickly become insurmountable.
The first thing we did was switch to OneNotes on our SharePoint portal. While those were hosted all the way back in Hawaii, the data’s trip was noticeably shorter than the circuitous route it was trying to take to our base 40km away. Thankfully, once you have data in a OneNote, moving and copying it is actually pretty simple.
Educating the staff on all this allowed our comms shop and my battalion Sigo to focus instead on the already full-time challenge of keeping the networks and their 200-odd points of failure up and running.4 That was until an SF detachment commander in the Philippines tried to get a CONOP approved.
We’d setup a call time and were waiting on the CONOP to come over. But after 20 mins without a download, it was clear something was wrong. Everyone looked at the Sigo, who bolted out of the room to go recheck those 200 points of failure. But the video feed was up, and while a bit pixelated, it was working. Interested in helping where I could, I asked the team leader what he was sending us.
‘It’s a PowerPoint file,’ the young captain ventured. My operations officer caught my sideways glare, and so he reminded me the young captain hadn’t been in the battalion long before he had deployed. Maybe it wasn’t the captain's fault he didn’t get the memo.
‘How are you trying to send it?’ I asked him.
‘Email,’ he replied.
‘Ok, well lets try Jabber instead’.5 No joy.
‘How big is the file?’ I asked.
‘I don’t know,’ came the reply. The captain just sat there in another country, looking sheepishly at the camera.
‘Why don’t you check?’ I replied, my patience wearing.
‘How do I do that?’
And there we had diagnosed the problem.
After explaining to the young captain how to find the size of the file, we discovered the PowerPoint was over 30mb, which our networks were blocking from being pushed via email.6 I took the opportunity to help him figure out why his CONOP file was larger than it needed to be, and how to fix it. I also got to ask him and his team sergeant why, faced with the comms challenges, they just kept trying to send it harder. When I asked why the whole thing couldn’t have just been a KMZ file it was clear the idea hadn’t even occurred to them. I still needed to put more work in to wean the battalion off the habit of PowerPoint.
I’m confident that young green beret could recite to me the max range of a 60mm mortar without a thought. But he didn’t know the bandwidth limitations of his network, nor did he know tricks like the one above to hang data in places that help it move faster. Because even on an ODA, he had a commo sergeant to worry about that. Radios weren’t his job. But then neither was the machine gun. But he damn well needed to know how far one could shoot.
As a platoon leader I had, depending on the day, up to four Bradley Fighting Vehicles with two squads of dismounts, two Abrams Tanks, a USMC ANGLICO team, a squad of Engineers, and a Civil Affairs Team in tow. Even as a young platoon leader, I had done what I could to learn what I needed to know to use those forces. That much combat power can dominate roughly one city block or about two square kilometers of open desert.
As a battalion commander, I had eighteen detachments like that one in the Philippines. Each with its own captain to command it. The day I left command those teams were in six different countries. I was their commander and they were my most casualty producing weapons, capable of sewing destruction across entire time zones. Knowing the fastest way to communicate with them, and knowing how much bandwidth I had to work was not my Sigo’s job. It was mine.
As the army seeks to pivot to network-centric warfare, knowing about bandwidth, much like data literacy, is no longer just a staff officer’s responsibility. It’s a commander’s.
Commanders don’t need to know how to crimp ethernet cables, but they need to know what their digital platforms can and can’t do. They need to know how to cut every digital corner that’s slowing down their data. They need to be able to dream up new ways to connect digital repositories of data, and how to leverage that data to fight. They need to know what the EW signature of their systems looks like.7 They need to know just how small they can get, and how that impacts the information requirements they leverage on their subordinates.
The days of ‘I’m not a computer guy’ should have been gone a decade ago. On today’s battlefield that attitude will get you and everyone under your command killed.
Tactical Operations Center. A room full of computers, displays, and occasionally actual soldiers who are monitoring the current fight.
Satellite communications. Not sure if this one needs a footnote these days, but for those who knew of a world before Starlink, the military relies on satellites in geosynchronous orbit to relay communications.
Geo-synchronous means the object will, generally, stay in the same place over the earth. I say generally because there’s about a hundred variables to include apogee, perigee, and eccentricity. If you’re looking for a post steeped in the finer details of orbital mechanics, you probably shouldn’t be asking someone who has never successfully deorbited a kurbal.
Signal officer. The S6 can mean the officer in charge as well as the entire comms shop. But there’s only one person who gets to own the title ‘Sigo’. Often the least happy staff officer in the unit, because much like a placekicker, no one seems to talk to you unless something’s gone wrong.
Cisco’s jabber uses a different file transfer protocol than email. Email’s protocol was not designed to send large files.
Megabyte or 1,024 kilobytes. Roughly the file size of one decent photograph on your phone.
Electronic Warfare. The competition across the electromagnetic spectrum which is subject to interference like jamming and spoofing.