If you are short on time, here’s the tl;dr: most good processes emerge, they aren’t designed and implemented from the top-down. Set conditions for good processes to emerge by equipping your team with good tools and training them on how to use them.
Tools
As I’ve mentioned in previous newsletters, I appointed myself the deputy Knowledge Mangement Officer for the division and started introducing myself that way as though it meant something. If you say anything enough times people eventually just take it at face value. This is rather hilarious considering that my actual job is to be a maneuver planner—I draw lines on maps and write orders telling units to go certain places and do certain things.1 In addition to doing my actual job, my made-up title of Deputy KMO has ended up coming with actual responsibility.
When I first arrived on the staff, our knowledge management system consisted of multiple horrendously disorganized Shared Drives. This meant that the entire division staff was operating off of nothing more sophisticated than file folders. And those file folders were a complete mess. There were shortcuts and duplicates all over the place. There was no standard convention for naming files (well, there was..in the TACSOP which no one read or used…see my essay “Standard”). It was a disaster. No one could find anything, and sharing files with others was incredibly difficult.
I went to the Knowledge Management Officer and said, “hey, we have to fix the shared drive.” She was so busy running another system that she didn’t even know how bad the shared drive was or how big of an impact it was having on the staff. So, I told her, “Let’s talk to the G6 (that’s Army speak for IT department) and have them take down the shared drive in the middle of the night for a few hours so we can go in and organize it.” She agreed.
Before we took it offline, we went to the whiteboard and I mapped out how I thought the shared drive should be organized and where different types of files should go. We consulted a few other people on the staff for feedback and they gave some excellent input. That night, we worked for four hours reorganizing the entire thing. In the morning people woke up to find that their files were neatly organized.
We were both a little unsure about how the changes would be received by the staff, but the feedback was almost overwhelmingly positive. We had brought order to chaos and people were appreciative.
Fast forward 6 months to the next big field exercise. The KMO told me that instead of using the shared drive as our primary platform, we could create a special SharePoint site on our classified network. The problem was that she didn’t have time to really build it. She made her best attempt to build one given her enormous time constraints, but it wasn’t really usable. She also couldn’t really ask me to do it since my job was, you know, totally made up. But I saw the value in creating a central website on the tactical network for the division staff, so I decided to drill down and make it.
All my formal training in web design, user-experience, and knowledge management was helpful in creating…[checks notes]
…oh…
…That’s right. I have zero formal training and didn’t know what the hell I was doing. But I knew a few rules of thumb that helped me to build what eventually became a freaking awesome SharePoint site: aesthetics are important and things shouldn’t be more than three clicks away.
Using these two basic rules I ended up building what several senior leaders said was the best SharePoint site they had ever seen.
But I didn’t build the SharePoint in a vacuum. I went to different staff sections, showed them what I was working on, and asked them how they could use it. For example, I went to the current operations cell and asked them if I could build them a tool that would help them track requests for information. They showed me what they wanted, and I built it for them. Then I went to other staff sections, explained what I was building and asked them how they might use the SharePoint site. With their combined feedback, I was able to build a pretty darn good site.
Processes Emerge
As I mentioned last week, the best processes aren’t designed and implemented from the top-down, they emerge from groups of people working together to solve problems that they encounter. Unfortunately, not all groups are equally skilled or motivated to solve problems. When an observer watches a team fail, they often mistakenly attribute their failures to bad processes, rather than poor individual performances, poor organization, or under-utilization of tools. They just jump right to process. This is something I’ll write more about next week.
But if the best processes emerge, and you want to make better processes, then the key is to set the conditions to allow processes to emerge, rather than try to design and impose processes. One of the best way to get processes to emerge on their own is to find really good tools and just make them available to people.
For example, the SharePoint was an under-utilized tool that we had available to us. No one had had the time or motivation to put a lot of effort into making the SharePoint site work, so the tool simply went unused. When I made the tool work, processes ended up emerging around it. For example, the intelligence analysts typed up great reports every day, including an excellent battle damage assessment, but they had not found a good way to distribute it. When I saw their report, I was shocked that I had never seen it. So, I offered to build a button on the homepage of the site that linked directly to their daily report. In order to make sure the link stayed updated, they had to follow some steps, which I laid out for them. They were happy to do it. I then had to spread the good word, so I posted a banner on the homepage of the SharePoint that said, “HEY! Check out the intelligence report button!” A lot of people love the intelligence reports and started incorporating them into their working groups and planning efforts.
We didn’t need to design a better process for intel reports, we just needed to be creative and play around with our available tools.
This same kind of thing happened through several exercises and warfighter. People would come to me and ask if I could help them build something on the SharePoint. The SharePoint became the digital home for the division and processes evolved out of the simple fact of it just existing.
This same type of thing happened with another piece of software that we recently acquired called VJOC. We didn’t mastermind top-down solutions for VJOC, we just trained people how to use it and it became crucial to our operations. Processes evolved from and around it.
Of course, some tools will require some level of training people to use them, otherwise the tool will be underutilized. Last week
wrote this in a great essay called “White Space.”In aggregate, I’ve spent the equivalent of many weeks learning to use enterprise software the hard way. Most soldiers can’t shoot to the mechanical accuracy of their rifles, and most staff officers can’t use their digital tools at a level that approaches their full potential. Yet it seems like there is never enough time to work on either problem.
I couldn’t agree more. Officers spend hours on their computers every day and I am still finding officers who haven’t even set up OneDrive on their computers. I met a captain the other day who didn’t know how to sum a column in Excel. I’ve met other officers who think it is black magic to use the “align center/left/right/middle” buttons in PowerPoint. So many people don’t know how to use the basic functionality of their tools, and yet we harp on and on about process!
If you want to set conditions for better processes to emerge, you could do worse than to equip your team with really good tools and then train them on how to use the tools to their maximum potential.
On a somewhat related note, I am currently reading an excellent book called Flesh and Steel During the Great War: The Transformation of the French Army and the Invention of Modern Warfare, and it is WILD to read how the French military intelligentsia were arguing about the future of warfare prior to WWI. They were trying to figure out how big of a deal machine guns were, and how to use trucks, and if cavalry was still relevant. They were trying to figure out how to use their tools, and they were changing their doctrine as a result.
I am sure I will publish a much longer essay once I finish the book, but let me leave you with these little nuggets from the conclusion of the book that supports my hypothesis:
“…in order to win, it [the French Army] was obliged to carry out the deepest and fastest transformation in its history…This transformation was not the achievement of an ‘enlightened’ high command working in the calm surroundings of staff officers…the men and units who were actually in contact with the front were the main instigators of tactical innovations.”
The author, Michel Goya, points out that it was the technological innovations, the tools, around which new tactics would evolve.
So, when we look at warfare (or anything really) we cannot underestimate the power of tools to drive processes. If you want better processes, you might just need better tools.
To be clear, the Commanding General and his deputies make the decisions about what will happen, I am just one of the staff that gives recommendations and then codifies their decisions in orders.
Okay, I see one area where I am a "Fat Eddy." I've worked as sole, or sometimes one of two, IT of small, usually tech companies since getting out of the USAF in the mid 80's. I've done everything you talk about here, with earlier tools, including the training, websites (made ALL the aesthetic mistakes, from too many fonts to blinking crap), databases, both flatfile and relational. Jill of all trades, even server admin. All completely out of date now, of course. So I have, or had, "street smarts" on that stuff, once upon a time.
¡Si es Goya, tiene que ser buen!