A Real Life Example
In a prior article, I described the Obvious context and shared with you a story from early in my career where I worked in the mailroom for a major law firm. This article continues that story and introduces the Complicated context.
As I mentioned, there were computers in the mailroom - one for processing FedEx and one for processing UPS. The computers were nearly identical save the software running on them and the printer attached. The software and printers were provided by the carrier. The computers were property of the law firm.
Now and then, the printer would jam or the computer would fail to perform its assigned duty. I was a computer hobbyist as a teen and was comfortable around computers. I had limited experience with the inner-workings of a computer, but had no qualms about hooking up serial devices, toggling interrupt switches, or fiddling with peripherals in general. This was sufficient to elevate me to the mailroom's technical support position. If the printer jammed or the software needed an update, I was your man. If cycling the power didn't fix a glitch, I was informed right away.
One day, the FedEx computer died. I think it was a bad power supply, but back then I just knew it was "busted". Computers were expensive, in short supply, and priority went to the secretaries of partners and senior associates. We weren't going to get a new computer for weeks, if at all. So, I went about figuring out how to get both programs and printers working on a single computer. A couple of hours reading the manual and fumbling around and I had both printers working. Another hour and I had both pieces of software installed on the machine. I additionally installed the firm's standard menu system and wrote up some brief instructions on how to exit one program and launch the other. Not too long thereafter, I found myself working full time in the computer room as a junior PC technician.
This role was new to the firm. All of our word processing was done on a WANG mainframe system through dumb terminals. In the prior months, we'd started buying PCs as replacements for terminals. The PCs were cheaper and we could get them in days rather than weeks.
We'd purchase maybe one computer per week to replace a broken terminal or to outfit a new secretary. As each PC came in, we'd open the case and install a WANG Local Office Connection Card (WLOC Card). We'd configure switches on the motherboard to allow for the WLOC Card. We'd configure some additional switches on the card, assigning each a unique address. We'd then test the connection and install the computer at the user's desk, connecting it to the mainframe through the same coax cables the dumb terminals used. This should have been a simple repeatable process, but the firm bought these machines one at a time from the lowest cost provider they could find. That meant that one week we were preparing an IBM machine, the next week was Hyundai (yes, that Hyundai), and the week after that was some unknown local brand that was out of business the week after. Nearly every machine was unique in some way. The switches on the motherboard were in different locations and indicated different things. This was often true between machines from the same provider, received in the same shipment. Every install required us to analyze the machine's internals, figure out the configuration, and decide on a course of action.
About six months in, some of us in the computer room started messing around with a local area network (LAN). It allowed us to connect machines together without the mainframe and it allowed us to share files and communicate with each other from different machines. With this new capability, computers became all the rage within the firm. We hired contractors to re-wire the entire building with 10baseT wiring and we settled on a single vendor for all new computers. We replaced WLOC Cards with Network Interface Controller Cards (NIC Cards) and installed an emulator. We switched from a terminal-based word processor to WordPerfect. Computers replaced every dumb terminal in the company. Suddenly attorneys needed computers too as our internal library could not keep up with the growing demand for computer time to search the LexisNexis system and legal bulletin boards (this was before the World Wide Web).
Before long, we were running a full PC support desk. Employees would call the hotline and we'd try to walk them through their issues. In many cases, we were helping folks with tricky features in WordPerfect or walking them through adding a new software option to their menu system. In other cases, the PCs were physically broken.
Sense, Analyse, Respond
A physically broken PC was collected and returned to the support desk. There, we'd review any notes that came with the PC, analyze the machine, narrow our list of possible issues, and decide on a course of action. In the beginning, our standard course of action was to verify an issue, fill out a service sheet and set the machine aside to go out to a professional repair shop. Some days, there'd be as many as a dozen machines sitting in a stack for repair.
Bored while on a break and sitting on a chair in front of the repair stack, it occurred to me that we could reduce turn-around if we could actually fix the machines ourselves. We already had the tools to take them apart. We knew how to add and remove peripherals. We knew how to run some basic diagnostics. We should be able to do this.
I started by consolidating issues. I wasn't really fixing the problems, but I was reducing the number of people affected. Say several PCs were waiting for repair. If one had a bad video card and one had a bad hard drive, I'd swap the video cards. Now we had one working machine and one with both a bad card and bad hard drive.
A common problem with bad hard drives was the controller card. The drive itself was fine, but the logic board that controlled it was bad. I kept a few good controller cards on the desk. If a "bad hard drive" came in, I'd swap the controller card to see if that worked. If it did, I'd swap the bad card for a good one in a different machine already going out for repair and update the service note to indicate this one also had a bad disk controller.
Workers become experts
I rapidly got better at analyzing the problems in more detail. I could figure out if a bad drive was the controller, a head crash, or another of a dozen possibilities. I could remove and solder common chips, bringing motherboards back to life. And I could often order replacement parts and install them myself for less than the cost of the professional repair shop.
To be good at this job, you had to be able to make observations, investigate several options, and choose a course of action. It required more experience and specific knowledge. The more you learned about the domain, the better you got at the analysis and the better your decisions about how to proceed.
Good Practices rather than Best Practices
This is the nature of complicated work. The analysis is required, not just categorization. You need to be able to choose from a number of options. And there are often equally correct paths to the solution. So while there are good practices, there are not necessarily best practices. Workers need to be able to solve problems on their own. Management in a complicated context is about collaboration. While a manager can set procedures for how to execute the discrete parts, a manager must rely on the knowledge of the worker to analyze the situation. It is valuable here for workers to understand as much about the system as they can. Managers provide advice and mentoring. They participate in discussions and help to make decisions, but must resist the temptation to be the authoritative decision maker. Authoritarianism results in subordination of team members, reinforcing the need for the leader to make decisions, thereby creating a potentially disastrous bottleneck.
A complicated context is stable with clear cause and effect relationships, but the cause and effect are not easily discerned by most people. There are often multiple equally good paths to a solution. The notion of best practice does not apply as well to this context. Instead, we have good practices.
Management needs to be more collaborative than in the simple domain. Hierarchy is less beneficial here and improperly implemented can be overly restrictive. Workers spend their time sensing, analyzing, and responding. Deep knowledge and experience are beneficial as they improve the worker's analysis skills. Creativity and problem solving are valuable activities in this context, but are not paramount. One can learn the skills necessary without being particularly creative.
The key risks here are over-analysis and entrenched thinking. Over-analysis is the result of a desire to make the "right" choice among a few viable options. Taken to an extreme, over-analysis leads to "analysis paralysis" wherein an individual or group are unable to make a decision out of concern of disagreement. This is where hierarchy still has value. The manager can either make the call or coach the individual or, better yet, facilitate a team discussion. While entrenched thinking is also a risk in the complicated context, the risk moves from management to the members of the team. Doing things they way we've always done them and ignoring new information, tools, and techniques can lead to lost opportunities.