Leaving a battalion and catapulting to a three-star command was always going to be a jarring experience. But the hardest transition was going so far back in time digitally. I left Oki in the summer of 2022 and landed in Fayetteville, North Carolina in what felt like 1997. Our headquarters had effectively no data plan, and hadn’t even managed to adopt Microsoft Outlook calendars, opting instead for a text email every morning from the vice chief of staff — followed half the time by another text email twenty minutes later changing half of what had been sent out earlier. What made this particularly frustrating to me was the headquarters had over a dozen KM contractors just down the hall on the same floor as the command suite.1
As I’ve mentioned before, I’ve had a long-contested relationship with KM.2 Some of this is certainly because I had unrealistic expectations of KMOs.3 After all, KMs aren’t even required to know how to code.
When I started working with SharePoint, we didn’t have a KM, but we did have a Dan. Dan’s job was in Lessons Learned, and in keeping with that office’s remit, he happily gave me rights to the portal to help me learn. So, it was a bit of a surprise when I returned to work after graduate school a couple years later and the new unit KM contractor refused to give me rights to edit the SharePoint portal. The only reason we were able to build out the systems we did in the battalion was because I got the group XO to intervene on my behalf. I still had to battle with the KM contractor, who had a habit of breaking the links to our site because we weren’t adhering to the style guide set by our three-star command headquarters, the very one I’d just been assigned to post-battalion command. I was stunned to discover a decade later the three-star command which so strictly applied its style guide, had effectively no data systems.
Some of this was probably because of the vanishingly tiny data caps users were still given. In my new job, I started off by trying to get a data repository started. Our commander’s CAG team took detailed notes on all his engagements, which in turn were disseminated out to the subordinate commands to help flatten information.4 But this was all via email, and so an early first step was getting a digital library of the notes going. We also needed to build messaging products and information handouts for the CGs engagements, all of which needed a home where everyone could access and update them. It didn’t take a month for me to bump up against the 1gb cap for our site.5
I reached out to KM to get more storage space and got the always baffling question back. ‘What do you need it for?’. ‘More data’, did not seem to be most productive answer, but I couldn’t understand why I needed to justify the need for more than a single 1gb of data. For context, my Steam Deck has a 512gb microSD card in it that’s smaller than my thumb nail that cost me less than $50. I walked down the hall to the KM shop and explained the data repository we were hanging on the site and managed to get my data cap bumped up to 10gb — less than 2% of that thumbnail sized card in my Deck.
While I was there, I brought up the site permissions, which garnered the usual rebuttal: ‘What do you need design privileges for?’ To be clear, this was not to get full control over the entire SharePoint for the command, just the CAG subsite. We had new team members coming on board and I didn’t want to have to send a request to KM every time I needed someone added to the site. After a back and forth with KM they finally relented, though they were adamant I do not give anyone else on my team design privileges.
When I asked why not, I got the familiar, ‘Because they might delete the site’. In my 14 years of working with SharePoint this has happened exactly never times. And if it did, you just pull the site out of the recycling bin, which is where it ends up if someone accidentally deletes something.6 But to get them to give me design rights, I told KM I wouldn’t give them to the rest of my team —and then did exactly that as soon as I got back to my office.
While they are stingy with data caps and permissions, I’ve found KMs are very generous in one place: Lean-Six-Sigma training.
Full disclosure, I don’t know anything about Lean-Six-Sigma that I haven’t read on the internet. Ostensibly, I should be all about it, given the focus on process and efficiency. I’ve just never once seen anyone with one of those Lean-Six-Sigma certificates on their wall do anything. Every week KM would report they’d trained another batch of ‘green belts’ in Lean-Six-Sigma, but our headquarters still had no processes and was a masterclass in inefficiency. At least my daughter had to prove she could break a board to get her green belt in karate. KM was all about doing Lean-Six-Sigma training, reporting their new trainee metrics in each weekly SITREP. But they never reported one time someone leaned or sixed or sigmaed a process we had.
Our KM was equally committed to bad Ux, when it wasn’t endlessly ‘migrating the SharePoint’. I’ll talk more about bad Ux in 4.3, but for now just picture too much scrolling, too many buttons, and too many clicks without a clear way to find what you were actually looking for. Making things worse, our SharePoint was out of date in a lot of places, which the commander discovered while interviewing new CSM candidates.7 Seems one of the candidates had diligently read the CG’s philosophy on the portal, only to find out it was the last CG’s version still hanging up there.
What baffled me was KM’s commitment to defending bad Ux. Beyond the portal, we convened a working group to try and address the miserable Ux that SOFReady had. As someone who’d previously tried to help fix the system back when it was DefenseReady, I was brought into the working group to try again, and I was eager to do so. Except whenever we brought up the systems failings, the KM team kept telling us we didn’t know what we were talking about. When we highlighted the clunky Ux, to the KM rep, they pushed back. According to KM, the system was perfect and the reason we were getting bad data was ‘a lack of command emphasis’. Back when I was taking my first Ux forays with InfoPath on SharePoint, it had never occurred to me to just say the user is wrong.
The problem wasn’t with KM. It was with my expectations of KM. KM wanted to ration data, safeguard permissions, and be left alone to run their Lean-Six-Sigma training while they endlessly ‘migrate the SharePoint’ in peace and quiet. The fewer customers, the better. What I wanted was the team that invented Slack.
I’ll briefly summarize here, but it’s worth reading one of the longer accounts like Tech Crunch’s chronicle of pivot and rise of Slack. While the overall company was trying to build a massive multiplayer online game, the engineers at Tiny Spec were struggling to coordinate a team spread geographically across North America — back before COVID this was remarkable. They saw a need for improved communications tools, so they built out their own tools sua sponte.8 When the game they were making ultimately crashed and burned, it was this team internal tool that had been scratched together to help the team overall that was salvaged and turned into a billion-dollar company.
In her book Scaling People, Claire Hughes Johnson describes similar work done by the internal coding team at Stripe. The team is always on the hunt for friction points. They sit in meetings and listen for signs of inefficiency, opportunities for improved processes, and then they start generating solutions. All without waiting to be told to.
The process isn’t without its own frictions, and needs beta testing and coordinated rollouts, but it's better than doing nothing. It has to have a better RoI than just paying a team to migrate the old commander’s old philosophy to the new SharePoint. The KM team could have been building our headquarters a digital equivalent of a high-end sports car if they wanted. Of course, that would require someone who knew how to drive one.
Knowledge Management. According to the army, ‘KM is the process of identifying, organizing, storing, and disseminating information within an organization’. In my experience, it’s the contractor(s) who won’t give you rights to edit the SharePoint until ordered to, and who will report in every weekly update they are ‘migrating the SharePoint’ while taking zero proactive steps to improve how your organization identifies, organizes, stores, and disseminates data.
Knowledge Management Officer. Technically there’s a slew of different KM titles, but everyone just calls them KM, which I’ll keep doing throughout this post.
Commander’s Action Group. Also called a (CIG) Commander’s Initiative Group. Ostensibly a mini staff for general officers that works prep and projects for the CG. IMO? Stolen manpower from the staff.
Gigabyte, or 1,024 megabytes. Roughly the file size of one episode of a Netflix sitcom in HD.
If the person that deleted the site didn’t do it on accident, SharePoint permissions are the least of your problems.
Command Sergeants Major are the senior NCO in a unit.
Famously the motto of the US Army Rangers. Latin for ‘of one’s own accord’, it reflects the Ranger ethos of mission command and doing the thing that needs to be done because you recognize it, not because you were told to be. It is the antithesis of KM.
That's good advice for working on anything in the service.