Chapter One: Introduction

It was roughly two years ago that I took my second course at the U of P. I detested it. The theories espoused by the experts in the field were weak and of limited scope, and the experiments they cited looked like rejects from aspirin commercials. Being of a rather analytical in nature and well-schooled in the rigors of traditional engineering by my course work at MIT, I could hardly keep a straight-face through most of the course. At one point I even made the mistake of asking the professor when the course was going to start. He was not amused, and I ended up with my lowest grade while attending the U of P.

However, after the dust of taking the course had settled, I kept thinking about what was supposed to have gone on in that course. I finally realized that just because the material was not well presented to my way of thinking didn't mean it wasn't important. It just meant the field was still new and there wasn't anything better to talk about.

The course was organizational behavior, and I decided that it was important enough for me to spend more time on, especially since the experts cited in our text still seemed to be groping with the very beginnings of establishing the field, and I felt cheated that this was the best they had to offer.

I felt this particularly strongly because the last two big companies I had worked for -- Novell and Beehive -- had undergone severe financial and leadership crises while I was working for them. In both cases the crisis escalated to organization-threatening proportions, and finally struck home (or should I say office) -- putting me out on the street. Having seen this happen twice, I am quite motivated to learn enough about organizations to see if I can prevent organizational weakness from clobbering me again--or at least let me see the signs in time to take precautions.

So, my dissertation will be built around the subject of organizational behavior. But, since I found the material in the field such a poor discussion of it, I have decided to spend little time reviewing traditional work in the area and draw instead upon my own experiences in business and computer work.

The paper will cover four areas I have investigated:

And finally, there is a discussion of employee compensation and how it affects motivation, and ways to improve motivation by changing ways people are compensated to match what they want rather than tie the compensation tightly to the job they are doing for the company.

The goal of this paper is to explain what these organizational structures are, and why they are the way they are. If we understand the underpinnings of our organizations well, then we can understand why some kinds of changes will work well, and others won't.

 

History -- Past observations that have lead to the questions

Over the past four years, in addition to changing jobs more often than I'd like, I have become aware of an interesting phenomenon in the dynamics of product development in the electronics industry. It seems that many, if not most, of the products introduced by the "big" electronics companies are not originally designed by them. Most have major components and major design features imported from the outside -- sort of the opposite of the NIH phenomenon.

The most curious aspect of this is that the products and concepts being purchased are being produced by engineers of the same quality and qualifications as those that currently work for the organization. In fact, many engineers for electronics firms moonlight designing for other electronics companies.

Here are some examples I know of:

CASE #1:

When Novell introduced their personal computer in 1981, they offered the WordStar word processing program with it. In addition they cast around for many months trying to find a word processing in package they could private label. In their casting about they finally decided upon a word processing package that was being developed by an outfit in Arizona.

CASE #2:

In two cases when Beehive decided they were going to pursue making more products for the IBM compatible market, they went outside. They purchased a protocol converter from one company, and a Coax A interface from another. In both cases Beehive is now looking at engineering out that part of the technology that was purchased from outside and replacing the components with in-house designs.

CASE #3:

When IBM decided to introduce a personal computer, they went outside to numerous small companies for quotes and specs on producing one. Since it's introduction, most of the components used in the IBM PC have been fabricated in Asia; only the final assembly has been done in the US.

Based on my ten years of experience in the electronics industry, these cases are not exceptions. It seems like Not Invented Here has been thrown out the window and replaced with a The Grass is Greener in the Other Guy's Engineering Field posture.

 

The Questions

 

Importance of the Problem to the Organization

Electronic companies and other manufacturers spend a great deal of money on Research and Development. They maintain large engineering staffs. In an electronics company today typically about 10% of gross sales will be expended on these areas. Since a lot of innovations are still being bought from outside, what are the companies getting for all this in-house expense? What is the purpose of these staffs? Are they serving an economically useful function? Does their organizational charter or structure need to be changed to reflect the reality that many of the company's innovative products will come from outside the organization?

The objective of discussing where product innovation comes from is to increase a company's effectiveness in dealing with innovation, whether it comes from inside or outside. For instance, if an organization plans on dealing with mostly outside innovation, should it expand by hiring more lawyers to negotiate contracts instead of engineers to do design work? Conversely, should a company that wants to make more use of in-house talent do so by broadening its product line to include lots of the "wild and crazy ideas" that in-house people spontaneously originate? Would that strategy encourage the "home team" engineers to devote more of their best efforts to producing products for the company instead of moonlighting? These are the kinds of questions I hope to shed some insight on in the course of this discussion.