ADVERTISEMENT

Why Pay More?

Making Not-invented-here worth something, and keeping that MBA busy, too!

By Chris Espinosa, Apple Computer, Inc., MacTech Magazine Regular Contributing Author

Many of us have let life pass us by without experiencing the reward and gratification that comes from possessing an MBA degree. Fortunately, people like this are fairly easy to come by, and if you’re in an organization of reasonable size, it’s likely that there’s someone on the payroll who will confess to it.

There’s nothing inherently wrong with advanced secondary education, nor does an MBA degree disqualify someone from working in a technical field. But sometimes engineers or technology managers feel like they’re talking a different language when an MBA offers opinions about how to proceed with product development.

A big gap in communication can come when discussing the “make versus buy” decision. This happens when most everybody agrees that a certain feature, function, or technology needs to be added to a product line, and the engineers are trying to figure out how to do it and how long it will take.

At this point, the MBA might ask whether someone else might already have created the necessary technology, whether you might go looking for such people and simply buy a lump of source code and build it into your product, and whether that will make the product better, more compatible, and quicker to market than designing, building, and testing it yourself.

Different engineers react in different ways to this. Some take great offense at the suggestion, or react with something resembling total denial that it could ever work. Others consider it and are willing to investigate and make a rational decision. Still others will politely ask the MBA-type-person to leave the room (or building, or company).

Oddly enough, it’s sometimes the people who have the most experience with the make-versus-buy decision who take the third option. In companies with an ingrained engineering culture and a mature product or technology, the job of licensing and integrating a foreign technology can be very difficult and time consuming, and more expensive in the long run than simply doing it yourself. Why pay more for somebody else’s technology when you can have better integrated, more maintainable, more “pure” code done by your own people?

The pitfalls of buying are many. First, you should do a diligent evaluation of the state of the code you’re buying. Make sure that the implementation language, development environment, and coding style are acceptable to your engineers (or whoever’s going to be maintaining that code down the road). You don’t want this to become a read-only, never-edit lump of code in your source tree. Make sure that the structure and flow of the code is clear, and preferably documented. In general it’s OK to have higher standards for purchased code than you have for your own engineers, because your organization may have some unspoken stylistic or architectural rules that are taken for granted in your own code, but will not be obeyed in code you license.

Then make sure that the project to integrate the code into your product will be well-managed. Throwing code over the wall increases the odds that it won’t work well. And believing that you should be able to make little or no changes to your existing code is also short-sighted. If you should buy, the make-versus-buy analysis should be so obviously tilted towards “buy” that you can afford to make a good number of changes to what you have and still come out ahead - you will need to make changes. Make sure that you have access to technical support or the original design team during implementation, but don’t expect them to do all the work: if you aren’t willing to make some sacrifices for the mutual success of the partnership, it may not be a good idea to get into it.

Finally, don’t be stingy with royalties or payments to your source, and be open-minded about their form of compensation. If you make this functionality a critical part of your product, and your customers like it, you’ll be dependent on it; if the unit royalty is too large, or your rights too limited, you may have problems a few years down the road when you need to lower prices or expand distribution, but are constrained by the license of a crucial technology. Check to see if you have something the other company wants: technology in exchange, or the right to make accessory products to yours, or even co-marketing. Money isn’t everything. A good deal can be made with a code swap and some press releases, if you both are committed to it and your customers benefit from it.

The warnings above might scare people off from even considering a make versus buy. It’s wise to be wary, but you should also be honest about your own abilities. Could your engineers spend more time on really valuable stuff instead of reinventing common technology? Must you be compatible with some industry standard or file format you have no experience with? Could minor problems hold you up? Will your engineers really write all that code from scratch in the time they claim? Will it be good enough to be worth it to your customers?

A good make versus buy decision is not a business school exercise, and it shouldn’t be done with dollar calculations on a spreadsheet. It takes the analysis and expertise of the people you trust most, and when you make the right decision, it ought to feel good, as well as add up. Don’t throw the MBA out of the room until you really think it through, and if you decide to make the purchase, give the MBA a position of respect and trust: make him or her manage the contract, rather than flit off to make another decision!