Self Sabotage: Why Doing the Right Thing Results in Failure


In January 2010 improvised explosive device (IED) attacks against dismounted infantry squads in Afghanistan numbered in the single digits — with only two or three reported on a monthly basis. In the fall of 2010 however, the U.S. Army was blindsided by a surge in these attacks that by the end of November had reached over 900 per month — essentially rendering a $1.5 billion effort to protect vehicle mounted patrols out of sync with a growing need to provide more lightweight counter-IED equipment to dismounted patrols. Within days of recognizing the change on the battlefield, as the director of the U.S. Army Rapid Equipping Force I made countering these dismounted IED attacks our top priority and within months the Joint Improvised Explosive Device Defeat Organization would do the same.

Over the course of the next six months members of the Rapid Equipping Force became experts on the problem and the technologies available to solve it. With all the permission we needed to move fast and break things, we set out to produce an array of immediate responses to deliver to the battlefield while also prototyping more durable options. For a few months, things went well, then we found our delivery timelines slipping despite our expert knowledge of the problems we were working on and our intent to solve them with the first, best prototypes we could move into theater. Worse, we began to struggle to transition our minimum viable products into working prototypes that we could deploy.



I kept asking myself, “Why, if we are doing all the right things, are we still failing?” I would soon learn that in the attempt to do everything right, we had built what I have come to recognize as a “self-sabotaging system.”

Self-sabotaging processes and systems — all-too-common problems government agencies and large organizations face — are created when individuals blindly follow rules, process, and procedures without exercising even a minimum professional judgment that should tell them that they are doing damage to a program, service, or the country.

Government agencies have fallen into the trap of building self-sabotaging processes into their operations, requirements, acquisition and finance systems.

Large organizations looking to stay competitive grapple with this problem all the time. That’s because the very systems and guidelines that keep these organizations humming effectively — though unintentionally — strangle all other activities.

To protect the government from waste or misuse of funds and property, there are controls designed to prevent fiscal malfeasance. In the course of ensuring the assets of government organizations are spent for the purposes for which they were appropriated, officials have built a requirements and appropriations system full of barriers and disincentives to operating outside the norm. Unfortunately, these complex systems have a tendency to punish risk-takers and entrepreneurs for their failures. Over time, the people who operate the systems are no longer capable of reacting to changes in the environment the way (or at the speed) their organizations want them to, and despite all our efforts to do the right thing, we keep failing… as if the system is on autopilot and impervious to change.

This was the problem we discovered at the Rapid Equipping Force.

Fixing Systemic Self-Sabotage in the U.S. Army Rapid Equipping Force

Management in the middle of organizations is most often blamed for these failures. Some have gone so far as to inappropriately call them the “frozen middle,” describing them as bureaucrats who are unwilling to change. The reality is that it’s not the managers but the systems built around them that are at fault.

During my tenure at the Rapid Equipping Force, we struggled with delays in the transition of early-stage prototypes into working prototypes. I sat down with a program manager to better understand how his workflow mapped to getting our systems into production. The program manager explained to me how he ensured that contractors doing the work were accountable for meeting contractual requirements. As he talked, it became clear that he was holding up payments to some of these contractors – many of whom were non-traditional performers (startups and small companies we really needed to keep soldiers alive on the battlefield) for misspellings in reports or for confusing contract language and milestone requirements.

I was horrified at the interaction, yet, by holding the company to the terms of their contract, he was doing exactly what we expected of him in order to safeguard the government’s resources. Unfortunately, delayed payments are a crushing blow to small companies and startups. Without timely, consistent payments they are unable to hire (or keep) the people they need to do work and can’t buy materials to continue production. To many program managers, it’s not a significant matter to have an invoice payment delayed by 30 days while paperwork gets straightened out. To a startup, simply delaying a payment a few days has the potential to completely disrupt its payroll. To my dismay, I realized that our insistence on properly documenting work and holding companies strictly responsible for the execution of contractual terms was in fact the leading cause of delays in the delivery of the prototypes we needed.

These startups were cutting-edge companies that were generally opposed to doing government work because the government was too hard to work with. Here in my own organization, my folks were proving them right.

At the Rapid Equipping Force, rather than blame the program manager for the problems we were having working with nontraditional vendors, I dug deeper to find out why he was motivated to behave the way he did.

I eventually found the culprit: our program managers were just following the language in our standard contracts. The problem was that the standard contract language had been written for large prime contractors, not small business vendors. Our program managers were holding these small business vendors to the same standard of performance as our primes. Ultimately the outsized expectations baked into our contract language created adversarial relationships with the very teams we were desperate to convince to work with us. Our team’s incentives were in fact eliciting a behavior that while technically correct, was the opposite of what I wanted.

Digging further, I discovered a toxic mix of rules, regulations, policies, and lack of incentives and leadership throughout the Rapid Equipping Force. It was a place where common sense and compassion were overruled by disincentives and a fear of punishment. While it was possible to fix parts of it, the system we built was so complex that the rest remained locked into a predetermined behavioral pattern that was impervious to our efforts to change. Without a complete fix, we would just keep failing.

When I investigated the cases of frustration that bubbled up to me, I was surprised by just how many people were involved in my “innovation pipeline” that I did not know about. Other contractors who were integrators, contracting officers, and lawyers, for example, all had some official interaction with our non-traditional vendors. Their tendency to “stick with the system” also proved to be a detriment to our relationships with the small businesses we needed to deploy solutions to the battlefield. Left unengaged, these outliers defaulted to a risk-averse nature that was short-circuiting my mission to become more agile and deliver with speed and urgency.

It’s One Thing to Talk About a Problem, It’s Another to Actually Fix It

In the case of the program manager above, our solution was simple to articulate but took constant discussion to implement.

First, working with our acquisition team, we better defined our expectations for working with outside vendors to take on our toughest problems. We defined these as “partnerships” rather than contractual relationships. I made it a point to make sure our program managers were vested in ensuring the companies in their portfolio had what they needed to successfully work with us. Sometimes that meant late-night phone calls to make sure a team properly submitted invoices so they could be paid on time. Other times it meant helping them research the right way to document a technical issue they were facing. The bottom line is that we made it clear that we were trusted partners in the process and would do what was necessary to help partners be successful. Slowly we began to celebrate the hard-won successes our team had in conquering particularly tough problems rather than focusing on the things that didn’t work so well.

The answer to the problem of interference from people outside my organization was much more difficult. Here the solution was found in better understanding what motivated them to perform their jobs the way they did, then in crafting value propositions for working with us in a particular manner that met their needs within their organization but didn’t derail our efforts. The truly hard part of this process was establishing working relationships in each organization that allowed us to understand how they worked, then personal relationships with individual people that allowed us to encourage more tolerance for risk-taking. In short, we hunted for the entrepreneurial managers in each organization and made them part of a tightly connected, trusted network of middle managers who knew how to work together to get hard things done.

We had some hard discussions with people and not every relationship worked, but we learned what did work and we eventually melted the “frozen middle” one organization and relationship at a time.

How to Combat Systemic Self-Sabotage

The lessons we learned at the Rapid Equipping Force are applicable for other large organizations as well. Fixing systemic self-sabotage starts with having the right team and extends to developing new mindsets and incentives that encourage risk taking. It’s crucial to develop a cadre of “entrepreneurial managers” — leaders with the ability to manage entrepreneurial tasks alongside legacy enterprise tasks. This is a big lift, requiring time and experience, because the ability to accept and manage risk is at the heart of both.

At the same time, it’s important to map out the entire end-to-end innovation pipeline, look at the edges of it to identify who may be impacting (sabotaging) vendor relationships, and find ways to co-opt these outsiders.

A critical skill for an entrepreneurial manager is knowing everyone’s limitations and behaving like an ombudsman to smooth over conflict. This requires becoming an expert at understanding the pain points that working with you might create for other people, especially if you are asking them to accept more risk in the process.

Use what you learn from your internal and external discovery to create a language for innovation that is common across your organization and extends to those who touch it from the periphery.

Personally, see what’s being delivered by your group. When it’s not right, work your way backwards through the pipeline to find out why.

Reward risk-taking and clearly articulate what level of risk you are willing to tolerate and what levels you reserve for your own decisions. Keep your expectations simple and clearly communicate them — repetitively. Ask different people to tell you their interpretation of what you said and how they will reflect your expectations within their operations.

Finally, constantly examine your system for examples of what right and wrong look like. Teach, coach, and mentor your teams using those examples before you consider punishing someone. Keep in mind that any punishment delivered for a failure is observed by others who may or may not understand the reasons for it.

In any business, failing at innovation is expensive but failing to innovate is even more costly. In the military, failing to innovate is deadly. Unfortunately, despite their best intentions, large organizations and government agencies have created systems that are so rigorous and so complex that even seasoned managers struggle with finding ways to increase the speed of technology adoption to meet their changing missions. It doesn’t have to be this way, though. By seeking out the self-sabotaging systems within an organization and ultimately creating a new generation of entrepreneurial managers, it is possible to create systems where innovation and enterprise don’t merely co-exist but actually help organizations thrive in a rapidly changing world.



Peter A. Newell (@PeterANewell) is the CEO of BMNT Inc., a Silicon Valley–based innovation consultancy and early-stage tech accelerator. He is a retired U.S. Army colonel and the former director of the U.S. Army Rapid Equipping Force.

Image: U.S. Army (Photo by Spc. Joshua Edwards)