2.02: ‘Can you make it do…’
As this was my first foray into organizational change, I naively thought a good idea was all it took. I figured they stood up on their own. What I quickly learned was change costs calories, and human beings are genetically designed to collect them, not burn them. Good changes still require people to take a leap of faith that the new way will be better, and the calories spent learning a new process will have a good RoI. The entire industry of sales is built on helping people cross this chasm.
Now I didn’t learn this through a stroke of insight. Instead, I learned by flailing on my own for several months. Like all software, the system I was building needed test data, and I really needed customer feedback to make the user interface less horrible. But asking people to playtest your new system costs those critical calories they already don’t have. The result was I was stuck in limbo. The system wasn’t getting better, which means it also wasn’t getting adopted. Over my time in the Army, the response by most commands to this dilemma is to make it mandatory. ‘Apply command emphasis’. Except now you’re actually going to get the exact opposite of what you want, because people who hated your system because it was new also get to hate it for your horrible Ux.1 Passive resistance sets in, with pockets of active resistance. Revolution always begets more revolution.
About three months later I cracked the code when one of the majors in the basement caught a glimpse of what I was working on and asked me about it. He’d had another miserable day, getting his ass chewed because a JCET CONOP packet was late.2 It had been lost. Again. This major’s whole job in the unit was to process these packets, so his default setting was pretty miserable, but I guess the ass chewing hurt a little more that day. Maybe he was just out of ass.
It was how fast his mood turned around as I demoed what I was working on that caught my attention. He looked defeated when he sat down next to me, but in just a few minutes he clearly been bitten by the same bug that had gotten me weeks ago. It was seeing the spark of what we could do.
The major asked how hard it was to make a half-dozen changes, all of which were actually really simple, but hugely impactful on the flow of the process. Fewer clicks, less scrolling, clearer language. ‘How long do you need to make those changes?’ he asked. I told him we should have them done by the end of the week, which was clearly faster than he’d expected. The major jumped up from his seat, grabbed the rest of the future operations cell in the basement and brought them back to show his teammates. Suddenly I had three majors hovering over my desk, which in a normal day for a captain feels like being chum in a shark tank. But instead, they were excited, feeding off each other, with more tweaks and improvements.
Except they weren’t army majors in that moment. They were stakeholders. I’d designed the system with the detachment in mind, because that was where I had just come from. It was the lens most familiar to me. But prior to becoming the AS3, I hadn’t yet been on a staff in the Army. The lens of the those who created the documents was important, but so was the frame of the people who actually processed the files.
Too often the formats and the flow of a system are built around the last person in the chain. In the army this is the commander. The commander is often one of the oldest members of the unit. His experience helps him make decisions, but his age often makes him overly conservative when it comes to innovative ways to get to those decisions. Both the people making the data and the people processing it, which are 99% of the people in the chain, are all ignored to satisfy the wants of the last person in it.
Of late this has culminated in a ‘dashboard’ culture that markets fancy chart displays that are really just very basic PowerBI charts that the average person could knock up for themselves after a weekend of self-study. But when you just depict data in a chart, then you probably don’t need the commander anymore. Set a simple algorithm to take action X anytime metric Y turns red. If someone is trying to sell you on their new software or system and they lead with a ‘commander’s dashboard’, I can almost assure you it’s shit code. They aren’t leading with how you’re getting the data that makes the fancy chart, and if it’s a crap Ux, I can guarantee you’ll never get reliable data.3 But back to those majors.
They sat at the crossroads of all the training packets. These staff officers processed them all, and they all also took the ass chewings whenever something was wrong, out of date, or ‘goddamn it how’d that get lost again?!’ So, they were equal parts the ones who had the most to benefit from improving the system, and the ones feeling the most pain from the current process. Those are stakeholders, and they are often NOT the leaders in an organization. If they are, they are typically not the senior one. They are the first ones willing to spend calories to improve their day, because they are already feeling pain and want it to stop. They are also the ones who will see the largest return on those improvements, not just in pain cessation. In more accurate, timely, and simple data. Your innovation with give them what their boss won’t: more time.
We took another month tweaking and adjusting. In that time, the subordinate battalion operations majors all joined in the effort, even some of the ‘analog guy’ types. We iterated and fumbled through some blocks, but nothing that Google and some testing couldn’t solve. Finally, about six months after the project had started, we ran our first fully live test.4 A team submitted a JCET packet completely in the new system, starting from the MPG templates. The company, battalion, and group headquarters were each given five business days to staff it at each level before it was automatically moved up to the next level. Edits were made in line, on the spot, with track-changes to help audit the process and make sure the team knew what needed to be corrected.
A packet consisted of about 25 different files, but the rule was nothing would get kicked back unless it had a fundamental error, never for grammar, spelling, or cosmetics. Those would get fixed on the spot by whoever noticed them, and the document kept moving forward. This was probably one of the most revolutionary changes we made, and with it came some of the loudest gnashing of teeth from the people who didn’t want change. The old process would kick back a file at the first spelling error, which meant you’d repeat the process for the second, third, and so on. This single rule had the largest impact on the time cost to staff a packet.
Unlike paper printed folders, our inline system didn’t get lost in the lawyer’s stack of binders either. Instead, multiple sections could look at the packets simultaneously and annotate their issues or make their tweaks in stride. 15 days later, we brought our first 100% digitally staffed CONOP to the Group Operations Officer, the senior major in the unit, and showed him what we’d done. To his credit, having been brought in late to what we were working on, he was very receptive, and asked great questions that led to more tweaks to the system.
When he was satisfied it had still done the job to the standard of the old way, he accepted it with a simple, ‘Ok’. The other majors and I were stoked, and as we started to excitedly file out of his office the Group Ops stopped us with one final question, ‘What about when it has to go upstairs, when we need the commander to approve it? How long will it take to make that system?’
The majors all looked at each other, uncertain. ‘About a decade, sir’, I answered. Everyone looked shocked. In a little over six months, we’d built a system that ran from ODA through company and battalion to group. How could it possibly take ten years to get it up a single flight of stairs? ‘You need ten years for one of these guys to be in command up there. In the meantime, we’ll just print out a hand copy of the packet for the commander’.
Our commander wasn’t a bad guy per se, but he was solidly in the ‘not gonna learn this computer shit’ camp. At the time, as a young captain, I didn’t see this as much of a problem. Guys of his generation would age up out of the command jobs, and newer, more digitally native officers would become the next generation of group and brigade commanders.
Or so I thought. I missed two key factors that have contributed to today’s ossified leadership class who are still content, at times even arrogantly, to be illiterate both digitally and data. First, those commanders would progress to become the general officer class, the very people charged with driving change in the Army. They hadn’t needed to learn new skills to earn a star, so why learn it now? Being data illiterate had worked for them, it would work for the army. Second, and perhaps even worse, they served as the mentors and role models for the next generation of leaders. I left for grad school in 2012, slightly worried about what I’d miss while I stepped away from the Army for two years. My worries were misplaced, change wasn’t coming.
Joint Combined Exchange Training is a clunky name for when Special Forces go to foreign countries to train with foreign forces. CONOP is the Concept of an Operation. I’ll explain CONOPs more in 2.14.
That’s a digression for later. I’ll talk more about Ux in 4.2: Bad Ux = Bad Data.
To be clear, we did all this work in the gaps in an already busy day. Had this been our sole focus, it would have less than two weeks.