“The truth is like poetry. And most people f***ing hate poetry.”
— Jared Vennett, character from The Big Short

‍

A common digital transformation statistic is that 70% of efforts fail; in McKinsey-speak, “less than 30% succeed.” But who’s defining “success”? After all, McKinsey surveys global executives at the highest levels of a company, who are charged with increasing topline revenue (and eliminating costs).

‍

In a 2018 New Yorker article, “Why Doctors Hate Their Computers,” Atul Gawande chronicled the thicket of conflicting definers of success as he witnessed the digitization of healthcare. The hospital administrators were keen on the ability to collect and analyze data; the software implementers insisted it was “patient-centric.”

‍

But the clinicians—the people on the front lines—were buried by and burning out from admin. Worse, the patients found themselves speaking with doctors whose eyes were glued anxiously to computer screens. “Success” for hospital administrators was emphatically at odds with “success” for the users (clinicians) and, critically, for the patient experience.

‍

Sometime in the 1980s and 1990s, the software industry took a hard turn into Taylorism, applying assembly-line techniques to building software. Enter business process re-engineering. Waterfall methodologies. And a decidedly cold shoulder to the purpose of software, which was to serve as a backbone to the organization, in all its organic and chaotic human-factor glory, to help it work smarter, faster, and more flexibly.

‍

It didn’t have to be this way. Socio-technical system design, with its roots in the 1950s, is a concept that recognizes success as a function of human, social, and organizational factors alongside technical factors. Baxter and Sommerville (2011) noted:

‍

“Simply put, the failure of large complex systems to meet their deadlines, costs, and stakeholder expectations are not, by and large, failures of technology. Rather, these projects fail because they do not recognise the social and organisational complexity of the environment in which the systems are deployed. The consequences of this are unstable requirements, poor system design and user interfaces that are inefficient and ineffective. All of these generate change during development, which leads to delays in the delivery of the system, and to a delivered system that does not reflect the ways that different stakeholders work.”

‍

In Board-speak, that’s the quarterly RAG status going from green to amber, amber, amber, and finally, red and brown bread.

‍

Modernization projects that meet their technical requirements often end up failing because they don’t support the real work in the organization. The unlock is to find out what the real work is: we’ll explore in the next newsletter.

‍

News and Views

Discuss: if a modernization project perpetuates technical debt, is it really a “modernization” project at all? The Pragmatic Engineer (aka Gergely Orosz) invites Lou Franco to discuss how to pay down technical debt.

‍

More evidence that the old is new again. In The Economist’s latest Technology Quarterly is an exploration of analogue computing (subscription required). Bin the 0s and 1s, let’s go back to the brain.

‍

Human factors, anyone? Might explain why Delta’s experience from the CrowdStrike outage was so much more disastrous than any other company’s—and why the lawsuits are flying faster than fries in a food fight.

‍

From the Orchard

We conducted research on the state of mind of technology leaders when it comes to legacy modernization and sat down with Paul Gaffney to discuss the findings in a special episode of our On a Limb podcast. Watch our podcast here or listen on Apple, Spotify, or wherever you find your podcasts.

‍

Thank you to Gergely Orosz for a shout-out at his Craft Conference 2024 keynote in May. Yes, feedback loops are indeed getting longer.

‍

Teams implementing legacy modernization projects often remark that it feels like they’re “holding our breaths for 3-5 years.” Kent Beck discusses why they can exhale and breathe freely throughout our modernization process, while Edward Hieatt posits a world in which legacy modernization can be free of fear.

‍

Curious to learn more? Say hello@mechanical-orchard.com.

‍

——————

Issue first published on September 25th, 2024.

‍