You can have it all: 3 business imperative

Most high-tech businesses have three business imperatives.  One is continued leveraging of global resources in order to have access to the best people world-wide and to save costs.  Another is continued outsourcing in areas where we are not the best in the world.  We need to have access to the best technology at the lowest cost in order to remain competitive and to be able to grow the company, our stock price, and opportunities for our people.  A third imperative is that we need to develop ever deeper competencies in areas critical to our business.  I think about this as trying to bring the company into ever sharper focus, understanding what we need to do, who can do it best, and where to do it.  The sharper our edges, the more competitive we will be.

Outsourcing is clearly part of this equation, but I have struggled for years with the following problem in the industrial equipment business.  I know (1) that our outsource vendors are often better at some specialties that we are, after all it is their whole business while it is peripheral to ours; (2) that most cost and quality issues are built into a design from its earliest stages, which puts a premium on early cooperation with the world’s experts while the design is still in flux or else they cannot help much; (3) I know that if we design-in a vendor early on in the design they will likely rape us with respect to price; and (4) I know that we generally have low volumes so multi-vendor solutions for any given product in production is generally impractical or costly.  Items (2) and (3) seem to be irreconcilable conflicting given (4).  On top of that, our outsource suppliers are sharpening what they are good at too, so it is even more important to partner early so that you hit the sweat spot where they are really good.

Foundation principle: you can have it all.  Let’s look at a few cases.  The easiest one to understand is when you compete two possible vendors, working closely with both from the beginning.  This is resource intensive since you generally either need two internal groups, each trying to help a specific vendor, or one group that can work with two vendors.  (Obviously you need to be careful of the vendor’s IP and be able to prove that you were careful.)     A big key is keeping both vendors believing that the other is a serious competitor.  Part of the challenge here is being sufficiently disciplined about information flow.  In a case I was involved in (let me call the vendors ExCo and WhyCo), since we were working closely with both companies, they had the opportunity to develop coaches in our organization so that they could keep track of the head-to-head.     In this case, there were genuine advocates for each position and there was also a senior executive (me) that had the credibility of being willing to make a decision to switch, having switched before. Having the reputation of being a madman is often useful in negotiations.  I have often been on the other side of such situations where, even though we are convinced we have won the technical contest and the user loves us, we have to contend with a senior executive capable of overruling the engineers on “capricious or emotional issues,” such as price.  I got to play this role this time, which was a lot more fun.  Also our engineers were able to hook up the competing vendors’ products to our systems, a fact that both vendors learned to their distress.  It was ExCo’s business to lose, which they did.  Unfortunately ExCo then went out of business, leaving WhyCo in too powerful a position for the future.  So for the next round we had to create a new competitor.  In this case it was an internally generated solution.  An internally generated solution is very scary to an external vendor because it is extremely difficult to compete with, for obvious reasons.  It is, of course, also expensive to do.  In this case we also saw another common phenomenon.  A competitor introduced just to make a powerful vendor think that they have competition, emerged as the eventual winner. Another thing we did was define standard interfaces and test suites so as to commoditize the vendor’s products to the greatest extent possible.  A lot of business competition can be thought of as the Darwinian attempt of various industries to commoditize the other. In another dual-vendor case, a new company was introduced to the procurement just to drive down incumbent’s price, but as we went through the motions of pretending to seriously look at the new company, we suddenly found ourselves intrigued by the offering and you know how the story ended—we are now running with the new guy.  You can bet we got great prices from both vendors.

But such situations are uncommon in the industrial equipment business because only for the most expensive subsystems can we afford to put in so much effort to work closely with multiple vendors.  There are also cases where doing this teaches our vendors a lot about our business and they end up selling to our competitors also.  WhyCo lost the last round of vendor selection we just discussed and now they are selling to our competition instead.  We think we have a better solution, but we still helped the bad guys.

A second technique is to utilize the fact that a vendor has multiple engagements with us to reward or punish behavior in a particular procurement. Companies with strong procurement departments do this all the time.  This is one of the many reasons procurement groups put such emphasis on lowering the number of suppliers to the company.  With fewer vendors with more engagements for each, the purchasing department has more power.  This is actually a great technique.  First we qualify at least a couple of vendors and then we pick one to work with where that vendor has their eyes on future business, perhaps with other divisions.  If we feel that they screw us on the present engagement, then we punish them later.  Conversely we can reward good behavior with more business.    The beauty of this is that we can engage very early and therefore exploit the vendor’s full expertise to get the lowest cost, highest performance solution.  But it needs to be set up carefully.  For instance you want to make sure that you are not locked in in perpetuity.  The program manager must also stay close with Procurement so that he or she fully understands the evolving multidimensional relationship with the vendor.  But the opportunities here are huge.   Sometimes I think that some divisions avoid this technique because each group feels that they need to be independent.  In fact, while there are disadvantages to working in a large company, this is one of the advantages.  Since we are sure to suffer through the disadvantages, we must be sure to enjoy each advantage of being part of a larger whole.

A third technique is actual co-dependence with the supplier.  In this case the vendor is locked in but only wins if their customer wins.  Carl Zeiss is this kind of vendor to ASML. In this case the vendor will get very good gross margins but it is ok if they enable their customer to win.  Zeiss lifted ASML from nowhere to become the largest and most profitable lithography equipment producer in the world.  I was at a Stanford short course a few years ago and got to ask our guest speaker, Michael Dell, how he managed Intel.  He laughed and exclaimed that one doesn’t manage Intel, one stays aligned.  The results are not always intuitive.  For instance, when I was running business, we had a pair of customers, one of whom was extremely difficult to deal with, extracting big discounts, always placing PO’s (or not) the last day of the quarter, not paying their accounts receivable without time-consuming escalations, demanding warranty extensions for the slightest excuse, etc.  We had a second customer with whom we had a harmonious relationship.  They never (well, almost never) played games with us.  They were nowhere near as tough in negotiations.  One day I did a set of customer P&L’s (I don’t know why people don’t this a general course of business.) and, lo and behold, the “good” customer actually paid less, taking everything into account, even though everyone on the division assumed that they paid more because they were so “nice.”  Unconsciously, we invested extensively in the relationship with our “friends.”  Obviously, it is uncomfortable to be in the position where the only reason that a vendor will control costs is because they want to help you gain market share, but it is real.  If one depends on such a vendor, it is even more critical that you get them intimately involved early in the development process because the only way your costs are going to go down is if they help you find “win-win” modifications to the design that lowers their costs.  You are not going to be able to transfer bottom line profit from them to you.  When I was talking with a procurement officer about this, he explained to me that this is called “expanding the pie.”  Then he looked seriously at me and said, “but it is still a pie,” meaning he still wanted the bigger slice.

The last option we talked about was a famous case at Harley Davidson.  Harley was on the verge of going out of business.  In desperation they worked with competing vendors in the same room to figure out how to drive out costs and improve quality.  HD attributes part of their recovery to this experience.   You can imagine the sort of trust, planning, and execution that this requires.

Of course, as with all possible big gains, there are cautions.   Outsourcing requires tight management (can’t just throw it over the wall), and the influence and behavioral skills necessary to technically manage outsourced providers can be different from managing in-sourced efforts.    An emerging possible cautionary example is Boeing.   They increased their outsourcing, which of course does lessen control in order to gain other benefits.   It is a difficult enough challenge for them that they are making the news.  It is common to throw too much over the wall to vendors.  One of the big challenges is not assuming too much of the suppliers.  Yes, we selected them because they are supposed to be the expert and we are paying them good money to do what they said they would do and we have a well-written contract, but you cannot assume.  A typical failure mode is to assume that the vendor can actually do the job.  A few ink blotches on a piece of paper called a contract will not save you.  Even with a world-class companies, not all engineering groups are created equal.  For instance, we had an experience with a generally-excellent German supplier where we actually ended up paying for part of the re-unification of Germany.  I am pretty sure that was not part of our plan.  The supplier originally sent much of our work to a less knowledgeable team in the former East Germany because of German government incentives, and, perhaps, because of the pressure we put on them to lower their NRE costs.  There are lots of ways to lose.  While we had folks actively involved, we simply trusted that the vendor would manage their resource to meet our requirements rather than satisfying ourselves that the right resource was assigned.  We also gave up too much of the system design.  If you don’t know the actual people doing the outsource or off-shore work, you are running a risk.    If you cannot distinguish between poor work, good work, and inspired work, then you have outsourced too much expertise.  I like the model where the person overseeing the work was originally a competent practitioner but has now moved further up the system design hierarchy or is perhaps responsible for the really hard parts while the outsource vendor is responsible for the easier parts. No one knows your problem domain like you do, right?  Another common mistake is to save money by not placing an engineer or technical manager at the vendor.  If you cannot afford the airfare you cannot afford to globalize.  I also hear, “We know what is going on—we visit often.”  If you are not there almost every day developing relationships deep in your vendor’s organization, you have no idea what is really going on.  Be sobered by reflecting on how hard it is to know what is really going on in your own organization.

And finally, always remember that even with collaboration, we should always be examining and improving our alternatives, whether the alternatives are in sourced or outsourced.

What are the common pitfalls?  I have mentioned a few.  Here are a few more:

Remember that an external party is just that, external. Implications include, first, if you are going to share confidential information, make sure you have a confidential non-disclosure agreement; if you are going to do things where IP will be generated based on joint activity or the disclosure of confidential information, make sure an IP agreement is in place.   There are many embarrassing examples where companies did not do that.   Second, communicating a total lack of alternatives to the supplier is, well, stupid.  We should always work to strengthen our choice of alternatives; even if we choose not to implement them.  Why do we need alternatives?  Because a supplier could go bankrupt, or change strategies such that we are not a fit with their business (I have been fired by a vendor before!), or get acquired, be razed in an earthquake, or, who knows?   In a recent case, about a year before the contract was set to expire, the supplier visited us and was informed by a number of folks that we NEED a long term agreement with him because we will need to service our machines for many years to come, and these are the only modules that exist.  The supplier then proceeded to take something that was costing us about $x a year, and make it $27x a year for 10 years, and x was not a small number.  In the end, there was, of course, an alternative; we began to redesign the component without using the supplier’s IP, but we unnecessarily incurred costs and pain better spent elsewhere.  If we had gone into this understanding that there really was an alternative and not acted so needy, perhaps we could have spent the engineering and management effort on developing new products instead of redesigning antediluvian ones.  Third, while one may not know the final price of something being collaborated on because the design is not final, that is no reason not to establish many of the commercial parameters up front.   Again, collaboration doesn’t have to just be with one party, and one can potentially make a collaboration that fits the best interests of both parties.  We have many examples of this in areas as simple as machining.  Years ago our engineers collaborated with a single machine shop, but didn’t get the spec’s really written down such that they could be taken to a third party, and had no framework in place for a commercial agreement, the predictable result was very high prices. We, of course, later worked on this by developing the specs and now competitively source or collaborate in a better way, but after flushing a lot of money.

It is critical to communicate on an ongoing basis the things the external party needs to know (not just for the obvious reasons, but remember, relationships affect output) and align on a single set of priorities.  Assuring communication back is equally important and more difficult.   Expecting the supplier to do everything without tradeoffs is an invalid assumption, just as it would be with us.   This can be within a project, or can cut across projects or divisions.   There are many examples where production forecasts weren’t communicated, later leading to shortages.   From engineering, engineering change orders (ECO’s) not clearly communicated can lead to either incorrect implementation or a misunderstanding in transitioning of different revisions.   Urgency often drives less communication when more is needed.

So perhaps we can indeed have it all.  In today’s globally competitive environment we need it all.

Thank you to Scott Paull for tutoring me on many of the ideas in this essay.