Kurt Vonnegut quipped, “A step backward, after making a wrong turn, is a step in the right direction.”

That’s cold comfort a mile down the wrong road.

Taking a step backward is daunting once you have staked your reputation, the tranquility of your team, and a pile of public money on an initiative. “Software trouble,” or an overly complex technology deployment going over schedule and budget, exemplifies this situation.

But even if you were to ignore the advice in the first two parts of this series—elaborating a sprawling set of software requirements through poorly controlled brainstorming, then undertaking a major technology procurement without resisting the capitalistic forces involved—there still might not be much apparent damage.

The real trauma, measured in dollars and departed colleagues, begins after warning lights start to flash. That’s the point when you might “double down,” entrenching your existing commitment, instead of facing the pain of admitting failure.

A natural psychological reaction to the threat of losing face, doubling down is weaponized by the software business. The best protection against doubling down is similarly psychological. By centering efforts around goals that are higher than a specific software initiative and by tending to the psychological safety of your organization, it is possible to heed warning lights more gracefully and prevent untold grief and expense.

Weaponized Sunk Costs

In the middle of building any complex asset, four factors can be weighed. Looking back in time, you can account for what you’ve expended to date on the project, known as “sunk costs.” You can appraise the “net realizable value” of the partially constructed asset as it exists today. Looking forward, you can estimate the prospective costs needed to properly finish building the asset. Finally, you can estimate the prospective value of the asset once complete.

Of these four factors, sunk costs are water under the bridge and have no place in rational decision making. Yet sunk costs prove pivotal in real-world emotional decision making.

Called the sunk cost fallacy, humans often double down to experience victory against obstacles and to avoid the shame and reputational damage of admitting that the sunk costs were wasted. 

The sunk cost fallacy is nothing new. This wonderful article from 1987 dissects the psychology and sociology that make it so hard to pull the plug on struggling projects. Telling that local governments, businesses, and individuals are still struggle with this.

Collective experience since then suggests that enterprise software is unusually prone to the sunk cost fallacy. Software is exceptionally malleable and requires specialized expertise to inspect. In a physical construction project, you can bring common sense and a hard hat to a job site, eyeballing the net realizable value of the dirt and concrete taking shape on the site. Software projects don’t allow for this. Until an application launches, there may be nothing but PowerPoint slides and vague verbal assurances to show for your sunk costs.

The inherent difficulty of appraising a software initiative in progress is a huge risk for you and a huge profit opportunity for your vendors.

“Land and expand.” a canonical strategy in the software business, capitalizes on this difficulty. To land (you, as a customer) and later expand (the bill your residents are obliged to pay) does not necessarily connote bad faith. You could simply be thrilled with a vendor’s work and want more of it. But “land and expand” often involves misrepresentation in the sales process, followed by an uncomfortable situation where the easiest resolution is to double down and write another check, attempting a quiet end-run around undisclosed problems.

An acquaintance of mine implements a brand of complex Enterprise Resource Planning software for the US Government. Early in my independent career, he advised me, “Always leave a hook in your work. Something in there should not work quite right. If everything works perfectly, they’ll never call you back.” I hated that sabotage was a sound customer retention tactic in software. I hated it enough to steer my career away from writing code and toward high-touch process improvement.

Goal Orientation

When I’m called to help with software trouble, a named software vendor inevitably has become an internal political football. Stakeholders will have divided into promoters committed to a death march of doubling down and burned-out detractors resisting the death march.

By this point, it’s overdue to revisit the higher goals that motivated the software project in the first place.

Jessica Hoffman, assistant city manager of Wentzville, Missouri, ran into software trouble in her work but successfully resolved it by reframing the deployment in terms of higher goals. She said, “As long as we get the outcome that we need, it doesn’t matter how we get there. We don’t have to get there the way that we’ve always done it, we just need to make sure we get the outcome.”

An authentic articulation of institutional goals, often written down in your strategic plan, can start to heal the divisions that a struggling project caused. Wentzville was wrestling with a major software deployment including a resident-facing workflow that was not working out. Hoffman noted, “We have five critical success factors. One of those is customer service excellence.” Getting a consensus to edit the offending workflow out of the scope of the deployment “honestly wasn’t that scary. Because this isn’t going to provide customer service excellence” even as a legacy workflow could.

By staying true to the higher goal of customer service excellence, Hoffman was able to lead her team through a graceful step backward from software trouble, keeping her team intact and her city running.

Psychological Safety

In late-stage software trouble, heartbreaking callousness is often in plain view. Senior project promoters’ fear of shame, which animates their cycle of doubling down, spills out onto their teams as defensiveness. Power users of affected systems, often executive assistants or low-level managers of frontline operations, are often most impacted by broken workflows and most vocal when software is no good. These detractors often become scapegoats who eventually leave their positions. Their departures, in turn, can ruin a government by destabilizing core operations.

The opposite of this pattern is psychological safety, in which it feels safe to admit imperfection and raise problems. Such a healthy environment, among its many benefits, inoculates organizations against doubling down on software trouble.

It is hard to recover from a situation where psychological safety is lost. Steven Sawada, a senior manager of continuous improvement and change management at King County, Washington, has healed many troubled projects in his career. Sawada reflects,

“When the going gets tough, I might be working with somebody who’s very traumatized and afraid. And I have to be okay with that. I have to be very nonjudgmental about it. I have to help that person and the people around them succeed. You gotta have that resilience and that awareness to say, I’m dealing with somebody who’s had a tough time and I can’t give up on them anymore.”

This kind of healing is not easy. Far easier is to nurture psychological safety up front, before risky initiatives begin. You will be likely to enjoy the backing of psychologically safe colleagues if a software deployment disappoints you. They will be more forthcoming with the information you need to course-correct and more open to honestly taking a step backward from their own sunk costs in the project.

At bottom, providing psychological safety to your team is a deeply emotional task. It is the squishy domain of therapists. Yet it may be one of the most valuable ingredients in something as superficially unsquishy as enterprise software.

Graceful Failure

The goal of this series was to help prevent the cost and trauma of software trouble in all its stages. The first two parts argued for simpler software initiatives that minimizing the risk of falling into a spiral of sunk costs and doubling down. By winnowing the scope of a project as suggested in the first part, fewer people and functions are affected if a project fails. By biasing yourself to small tools with a single responsibility as suggested in the second part, you make vendors more interchangeable and maximize your alternatives to doubling down.

Even so, there will be projects you inherit, projects you don’t fully control, or simply projects you started before learning all this. Some of the most ethereal parts of good leadership, including a strategic orientation around higher goals and the psychological safety of your team, are deeply protective. Deploy them even on a struggling project, and there will be room to resist the urge to double down. You will gracefully admit failure, pick up the pieces, and live to serve another day. Next time, having earned some battle scars from software trouble, you will be better prepared to deliver a great government for the residents you serve.