Process
Process is an emergent phenomenon, not a constructed one
Barcodes and Blood
Accountability of equipment is a big deal in the Army. Our equipment is provided by hardworking American taxpayers and we owe it to them to keep track of our stuff to make sure it doesn’t get lost or stolen. I won’t go through all of the nitty-gritty details of Army accountability procedures because they are extensive but let me give you some background. A regular infantry company of 120 soldiers has tens of millions of dollars of equipment like vehicles, radios, weapons, night vision, etc. Most of those pieces of equipment have serial numbers, and all of the equipment is on the unit’s property book. Every month, a unit must do 100% property book accountability checks. The responsibility for the accountability checks rotates between the officers in the unit. When I first came into the Army, the officer doing accountability would inventory everything by serial number. If you were inventorying the weapons, you would walk into the arms room with a few soldiers and they would read off the serial numbers, and you would check them off one by one. This process was extremely arduous.
A few years ago, my unit was required to put barcodes on all of our equipment and then use a barcode scanner to do the inventories. This new system was designed to be faster and more efficient than the old system. But there was a problem with this new system.
Because our equipment, specifically our weapons, were so heavily used in rough environments — rain, dust, snow, extreme heat, etc. — the barcodes would either fall off or get really scratched and couldn’t be scanned. The units got so fed up with having to replace bar codes that they eventually just reverted to the old system of reading off serial numbers. But the barcode scanning was mandatory. So, units would gather all of their barcode stickers, organize them neatly in a binder, do the regular inventory the old way, then take the scanner and scan everything in the binder, page by page. The old process for accountability re-emerged, even under strict constraints.
A top-down process that was designed to be faster and more efficient ended up as the old process with an additional step. This kind of top-down process implementation is, unfortunately, all too commonplace.
The barcodes have been improved so they are more durable, and some units are actually using them now. But a recent interaction with a brigade combat team revealed that not only were they not using the scanners, but they were also unaware that such a system even existed. It has been more than a decade since the Army began implementing this system and it still has yet to be adopted by the people it was designed to benefit.
As I dug into the technology of the scanners themselves, I discovered that there are also a whole host of ancillary challenges to using the system and keeping the software updated, ordering new bar codes, etc. The scanner is paired with a docking station. Because the docking station has to be plugged into an Army network, it has to constantly be updated with software. This requires additional internet lines to be run into supply rooms so that the supply sergeant’s computer and the scanner can both be plugged into the network. If the docking station is not plugged into the network for a certain amount of time, it gets kicked off the network and has to be re-added, which is not a fast or easy process.
Moreover, if a piece of equipment is missing a barcode, it still has to be inventoried and reconciled in the digital system. If a piece of equipment has a barcode which becomes unreadable, it takes several weeks to get the barcode replaced.
I recently listened to a subject matter expert on talking about the scanners and going through how they work and why they are important. He kept emphasizing that they will make inventories so much faster and more efficient. When people brought up issues or asked questions, the briefer kept saying, “If that happens all you have to do is XYZ.” But if all you have to do is 10 x XYZs, it isn’t obvious that the system is faster or more efficient in toto. Sure, the inventory itself might be faster, but if there are 10 other things that you have to do to enable that, then is it really easier? Inventories by hand are not fun, and a scanning system should work in theory, but it seems like this process could use a little more refinement.
Newly implemented processes are often resisted, subverted, or just outright fail. The strongest and most durable processes are not designed and implemented from the top down, like the bar codes, they emerge naturally from people working together to solve problems and survive in their environments.
For example, in the aviation world, there is a saying that every step in their multitudes of checklists and processes is “written in blood.” What they mean is that flying is an inherently dangerous activity, and there have been many accidents and deaths as a result of people not following best practices. Their myriad protocols emerged from contact with reality. This probably isn’t the case with all of their processes but, for the most part, these processes were not imagined by central planners and then implemented—they came as a result of intense investigations that nailed down why any particular accident happened. Once the investigators figured out the root cause of the problem, regulators (who are typically former pilots) put controls in place to ensure that specific problem is prevented in the future. In commercial and military pilot training, I am told, that the use of these checklists is drilled over and over and over again. And horror stories are told one after another about what happened to this or that pilot who skipped parts of the checklist.
You can have a highly regimented process, but it has to emerge from something. The cases where a process can be conceptualized and implemented in a vacuum are the exception, not the rule. We’ll touch on this more at the end.
Efficient v. Robust
A few weeks ago I talked a little bit about the warfighter exercise. To refresh your memory, it is a big exercise designed to train division and corps level staffs.
Our staff absolutely crushed Warfighter and we learned a lot along the way.
But Warfighter was not without its frustrations.
The most frustrating thing about the Warfighter exercise was the OC/Ts unhealthy obsession with “process.” The whole idea of “process” is an extraordinarily weird phenomenon. On paper, making a process seems so easy. A neat PowerPoint slide or whiteboard diagram quickly simplifies the complex and organizes the chaotic…on paper at least. What the OC/Ts wanted was for us to conceptualize certain processes, write them down, and then put them into action.
The problem is that clean and tidy diagrams of processes trick people into thinking that the best processes can be designed. But organizations are composed of people, and people are not machines. You cannot just write lines of code and then hand them to people to execute. This is especially true in highly dynamic environments with fluctuating time horizons and a highly intelligent enemy. In a complex environment, you need to act first, without too many preconceptions of how you think you want systems and processes to operate. You might have a vague idea, but it’s best to face uncertainty with an open mind and a willingness to quickly adjust. Then once you come into contact with reality, you watch the systems and processes emerge and you guide them and nurture them as they grow.
This is not the most efficient way to build processes, but it is much more robust. Efficient processes break down very easily under pressure, and the more efficient the process, the more danger there is of breakdown.
There is almost always a tradeoff between efficiency and robustness. This idea is hardly original to me — many people much smarter than me have pointed this out (Taleb and Dave Snowden come to mind). If you want a process that is highly efficient, it likely won’t be robust. If you want a process that is highly robust, it likely won't be efficient. The key is to find the sweet spot between efficiency and robustness. Finding that sweet spot is incredibly difficult. If your aim is to build a process for an organization and then implement it from the top down, it is unlikely to work at all. Even if you take draconian measures to implement a process, it is likely that a separate process will emerge in parallel, often hidden from the implementer. This was the case with the barcodes from the beginning of this essay.
So, how do you find processes that balance efficiency and robustness?
PPTO
When one is examining a team, a basic framework that one can use is PPTO — People, Process, Tools, and Organization.
People — are the right people in the right jobs doing the right work?
Process — What processes exist? Are they efficient? Do they get results?
Tools — What tools are being used to process work? Are they the right tools? Are they being used effectively? What tools are missing?
Organization — Are the right people working together? Are they matched with the right tools?
When we focus on processes, we are often tempted to think that they can be easily designed and implemented. But, as I said earlier, the best processes emerge. The question, then, is not how to design the best processes, but how to set the conditions for them to emerge naturally. In my essay Laziness Part 2, I told the story of a fictional battalion commander, LTC Folkus, who fixed his administrative problems by simply gathering the right people in a room (and, more importantly, excluding the wrong people), outlining the problems, and then allowing them to find their own solution. This may take a few iterations, but there is little doubt that this generic solution is effective in a wide variety of circumstances. The one thing that I failed to mention in that essay was the value of “tools,” but we’ll look at that next week.
If we follow the PPTO model, we can see that LTC Folkus is simply finding the right “People” and “Organizing” them to allow a process to emerge. If you find that a process is needed for something, don’t try to implement it yourself by coming up with some grand idea. Find the people closest to the problem and organize them to implement a solution. Equipping them with the right tools is definitely a plus, which is something I discovered during the Warfighter, and something I will examine in next week’s essay (for paid subscribers only).