The Rescue Mission

“Trust doesn’t come with a refill. Once it’s gone, you probably won’t get it back.”

• Unknown

A couple years ago, a start-up that was in the middle stage of its MVP development came crashing through the doors at Creative Chaos, all out of breath and claiming to be in hostage situation. After an initial calming conversation to let the drama dissipate, we came to understand the company had indeed descended to the place where third-party development contracts all-too-commonly go: a fixed-bid dispute. After a series of “he said, she said” conversations, the start-up’s development contactor was holding the code-base for ransom, and had effectively locked them out of their own Intellectual Property.

This is a story of faith, where Creative Chaos found itself challenged to transport a client from a deep state of trust deficiency to the shores of belief and confidence.

Tactful Approach

As a first step, Creative Chaos agreed to diagnose and attempt to resolve this cloudy situation, knowing full well our accountability was under the strongest microscope it had ever been under.

To add to the urgency, the start-up was at the point where it needed a mobile-ready UI just to get itself to market, and it wanted it fast since so much time had already dissolved away in a state of limbo. Our team was granted access to a single server where the original solution had been deployed. After a thorough discovery session, we discerned that developing a front-end app would be possible for our team. However, we could also see that many changes would be required within the already-built back-end in order for the application to function as desired upon release. It was still possible to build on the existing back-end, but far preferable to start over entirely.

This discovery alone brought a series of additional challenges to the surface:

a) Given the client’s history and baggage, it was not going to be prudent or productive to tell them outright, “Your baby is ugly and needs to be thrown away.”

b) From a purely fiscal standpoint, nobody can ever be tactfully convinced to walk away from $2 Million in sunk costs, which is exactly the precipice on which this circumstance stood.

Rather than forcing the client to digest a conversation about re-building from scratch, our team made a strategic decision that turned out to be the best one we could have made. We decided to tell the client we would continue to develop for the existing platform, while our team conducted a sprint in parallel to re-build the back-end, at our own financial risk. Once the re-build was complete, we would be able to seamlessly transition the front-end work over to the new back-end without any interruption, delay, or additional cost to the client.

A Slow Build Toward Trust

It was relatively easy to see the root of this client’s distress came from its former development partner’s lack of bandwidth to turn hopes and expectations into reality. But we also knew full well this client could not be asked to throw more investment dollars at the problem.

By taking the project on in the way we did, we moved the client from skeptic to believer. The challenge we set up for ourselves was to solve $2 million worth of pain without requiring the client to make significant new investments.

Lessons in Practice

Because we are so practiced in delivering against value and timelines, as opposed to hours spent or bandwidth used, taking on these kinds of risks does not present a barrier for Creative Chaos. We know what we can realistically achieve, and we set a higher bar for ourselves as a result.

Just as market success for a given innovation must begin from a place of empathy with prospective users, so, too, must successful developer/client relationships start with empathy. It is only by understanding the journey an innovator has taken, and the sacrifices they’ve made, that a true symbiotic relationship can be forged. Such was the lesson learned during this rescue mission. If we had acted upon our initial instinct to call out the faulty back-end build for what it was, it would only have fanned the flames of failure and, most likely, derailed all hope for long-term success.

But most importantly, this experience highlights that skirting plans for transition of knowledge and assets back to the internal team can come back to haunt both innovator and development partner. If both sides are not planning for this transition from Day Zero of the build phase, it only opens the door for issues and mis-understandings to become outright barriers.

In short, this experience serves as a blueprint for why ‘outsourcing’ can never be considered a reasonable approach to the Innovation Delivery challenge. The term implies a ceding of institutional knowledge, ownership and control over the development process, and ultimately places IP at risk. Innovation cannot be considered truly delivered until final transfer of resources and assets, and internal teams trained to assume full control.

This rescue is not an isolated incident, and it is why you hear the Creative Chaos team speak so fervently about the Build=>Operate=>Transfer delivery model. Every project we take on begins with a plan to flow it back to you.