I’m continuing to dig into this article I shared previously, which does a lot to explain the value of vertical specialization: https://www.newyorker.com/magazine/2018/11/12/why-doctors-hate-their-computers
Many of the angriest complaints, however, were due to problems rooted in what Sumit Rana, a senior vice-president at Epic, called “the Revenge of the Ancillaries.” In building a given function—say, an order form for a brain MRI—the design choices were more political than technical: administrative staff and doctors had different views about what should be included. The doctors were used to having all the votes. But Epic had arranged meetings to try to adjudicate these differences. Now the staff had a say (and sometimes the doctors didn’t even show), and they added questions that made their jobs easier but other jobs more time-consuming. Questions that doctors had routinely skipped now stopped them short, with “field required” alerts. A simple request might now involve filling out a detailed form that took away precious minutes of time with patients.
As a total outsider to medicine, how would you know any of this stuff?
According to the article, Epic handles this with an optimization phase in the project, but isn’t this stuff that someone who had done some research or has some domain experience and empathy for their end users would know or figure out ahead of time?
Here’s another second-order consequence Atul Gawande discusses in the article:
Sadoughi told me that she has four patient slots per hour. If she’s seeing a new patient, or doing an annual physical, she’ll use two slots. Early on, she recognized that technology could contribute to streamlining care. She joined a committee overseeing updates of a home-built electronic-medical-record system we used to rely on, helping to customize it for the needs of her fellow primary-care physicians. When she got word of the new system, she was optimistic. Not any longer. She feels that it has made things worse for her and her patients. Before, Sadoughi almost never had to bring tasks home to finish. Now she routinely spends an hour or more on the computer after her children have gone to bed.
I’m pretty sure you can calculate the cost of these kind of consequences. The actual cost of having to bring work home is “squishy”, but the cost of burnout in a certain percentage of doctors, the cost of extended childcare, and stuff like that is less squishy and more readily estimated.
Understanding, managing, and–possibly–minimizing second-order consequences like this is part of the value a consultant brings to an organization.
More detail on that specific second-order consequence:
She gave me an example. Each patient has a “problem list” with his or her active medical issues, such as difficult-to-control diabetes, early signs of dementia, a chronic heart-valve problem. The list is intended to tell clinicians at a glance what they have to consider when seeing a patient. Sadoughi used to keep the list carefully updated—deleting problems that were no longer relevant, adding details about ones that were. But now everyone across the organization can modify the list, and, she said, “it has become utterly useless.” Three people will list the same diagnosis three different ways. Or an orthopedist will list the same generic symptom for every patient (“pain in leg”), which is sufficient for billing purposes but not useful to colleagues who need to know the specific diagnosis (e.g., “osteoarthritis in the right knee”). Or someone will add “anemia” to the problem list but not have the expertise to record the relevant details; Sadoughi needs to know that it’s “anemia due to iron deficiency, last colonoscopy 2017.” The problem lists have become a hoarder’s stash.
“They’re long, they’re deficient, they’re redundant,” she said. “Now I come to look at a patient, I pull up the problem list, and it means nothing. I have to go read through their past notes, especially if I’m doing urgent care,” where she’s usually meeting someone for the first time. And piecing together what’s important about the patient’s history is at times actually harder than when she had to leaf through a sheaf of paper records. Doctors’ handwritten notes were brief and to the point. With computers, however, the shortcut is to paste in whole blocks of information—an entire two-page imaging report, say—rather than selecting the relevant details. The next doctor must hunt through several pages to find what really matters. Multiply that by twenty-some patients a day, and you can see Sadoughi’s problem.
One more excerpt to illustrate second-order consequences:
As I observed more of my colleagues, I began to see the insidious ways that the software changed how people work together. They’d become more disconnected; less likely to see and help one another, and often less able to. Jessica Jacobs, a longtime office assistant in my practice—mid-forties, dedicated, with a smoker’s raspy voice—said that each new software system reduced her role and shifted more of her responsibilities onto the doctors. Previously, she sorted the patient records before clinic, drafted letters to patients, prepped routine prescriptions—all tasks that lightened the doctors’ load. None of this was possible anymore. The doctors had to do it all themselves. She called it “a ‘stay in your lane’ thing.” She couldn’t even help the doctors navigate and streamline their computer systems: office assistants have different screens and are not trained or authorized to use the ones doctors have.
“You can’t learn more from the system,” she said. “You can’t do more. You can’t take on extra responsibilities.” Even fixing minor matters is often not in her power. She’d recently noticed, for instance, that the system had the wrong mailing address for a referring doctor. But, she told me, “all I can do is go after the help desk thirteen times.”
Jacobs felt sad and sometimes bitter about this pattern of change: “It’s disempowering. It’s sort of like they want any cookie-cutter person to be able to walk in the door, plop down in a seat, and just do the job exactly as it is laid out.”
That’s a lot of excerpts, I know, but really you should read the whole article!
It’s quite good, and it illustrates how introducing complex software to a complex system produces predictable and unpredictable consequences.
Specializing vertically can help you predict, control, and minimize consequences like this. It doesn’t immunize your projects from having undesirable second-order consequences, but it puts you and your client in a more informed, prepared position with respect to those consequences.
And that adds value.