Critical Path Newsletter

The T Word

At Macadamian, we’ve always known that trust is a vital component of the outsourcing relationship. In this Critical Path and the next one, we will talk about a couple different aspects of the “T” word. First, a little story about why trust in the outsourcing relationship is so important. Sadly, the story is unhappy—and true.

Next month, we’ll talk about how you know when you can trust your outsourcing partner.

An exciting project
Recently, we got a valuable reminder of why trust is so important.

We got the chance to work on an exciting product. Most of our projects are exciting, but you can probably understand that it’s extra fulfilling to work on something that can save people’s lives.

The idea behind the product was brilliant. It was a low cost system that would be useful to every hospital in the developed world. It would free up resources and save lives.

But then the project started to go sour.

“You don’t need access to the hardware—just use an emulator.”
A one-product start-up company with a disruptive idea has a huge stake in protecting its intellectual property. A lot rides on that one product being the first of its class. Our client couldn’t afford their secrets leaking out. They wanted to protect their intellectual property.

Unfortunately, the client also felt the need to protect their intellectual property from us. We asked for the hardware that the product was going to run on. The client was unwilling to give us access.

Not sharing the full details of the hardware left us in the dark when it came to developing software for the device. Going on incomplete information and the provided emulator, we got to work.

Maybe you think it’s presumptuous for an outsourcing company to think they need access to company secrets and to expect to be trusted with them.

When you sign a contract with a development partner on a Fixed Price basis (where the contract specifies a flat rate for development, instead of the partner being paid by the hour), you’re downloading some of the risk of the project onto the partner. There are probably a lot of unknown factors at the time of the signing—chances are that features aren’t entirely scoped out, that changes will be required, or even just that things will go wrong at some point.

The partner and the client have worked together to negotiate a price, but as long as there are these unknowns, the partner takes on risk. The more unknowns, the more risk. So keeping secrets from your partner increases their risk. That might not concern you too much—after all, the partner did sign the contract—but development partners base their estimates on man-hours. When risks become reality, those man-hours go up, and your product gets delayed.

“You don’t need to do end-to-end testing. We’ll do it and give you the results.”
Development using the emulator did not go well, to put it bluntly. Lots of problems. And a few tenacious bugs. Really tenacious bugs. They seemed to be happening in the communication between the hardware and the software, which was not a big surprise.

Of course the client wasn’t happy we couldn’t get the application to work reliably. We weren’t happy either—over half our business comes from repeat clients. We want our clients’ projects to succeed almost as much as they do. It means they’ll come back to us for the next one.

To fix the problem, we needed to do end-to-end testing in a real environment. There was no substitute.

We approached the client to let them know… and they told us no. They said they would do the testing and give us the results. They didn’t want us to see the company secrets, so they isolated our access to the system.

It didn’t work. No matter how hard the client testers and the Macadamian dev team tried, without access to the system, we couldn’t get the info we needed to solve the problem.

I said earlier that a one product company can’t afford to leak secrets. Even more disastrous than the secrets getting out would be the product not living up to expectations. If a secret gets out to your competition, then you’ll have more powerful competition in the game. However, if your product doesn’t live up to expectations, then you aren’t even in the game.

An unhappy ending
After months of frustration, we figured out the technology they’d chosen for the device just wouldn’t work for the planned functionality. No amount of great software development would have fixed the problem. And all the hardware had already been purchased.

The product never passed the approval tests from the regulatory body. The project was eventually cancelled. So, this amazing, low-cost, life-saving device won’t ever reach the market.

It was an unhappy ending for everyone involved.

When not to outsource
There’s a lesson to be learned here. It’s simple. When you’re considering outsourcing, you need be prepared to trust your partner. If nothing in the world would convince you to give your partner full access to the product, then perhaps developing in house is a better option for you.

In the next Critical Path, we’ll talk more about the flip side—how you know when your development partner is trustworthy.