Thomas P. Hughes, "Creating Open Systems: From Thomas Edison to ARPANET/INTERNET” - MIT SDM Distinguished Lecture

[MUSIC PLAYING]

MAGNANTI: Welcome, everyone. Delighted to have you with us, those here at MIT and those at a distance. My name is Tom Magnanti. I'm one of the co-directors of the System Design and Management program.

And it's my pleasure to welcome you to our first distinguished lecture series in complex systems. We are very fortunate to have with us today and over this semester Professor Thomas Hughes, distinguished professor, and I think it's probably appropriate to say, dean of the history of technology in the United States and maybe in the world.

Professor Hughes is well known for his insightful look at technology, particularly look at large scale projects and of developing a framework for looking at these projects and for providing insight for all of us at technical institutions such as MIT and elsewhere. We're just delighted to have Professor Hughes with us on this occasion.

He's going to give two public addresses. The first address will be today, and the second address will be on October 30. And he will also be meeting with the System Design and Management students in a more intimate setting.

I'd just like to, for those who are not familiar with the System Design and Management program, it's an educational program at MIT, whose intent is to educate future technical leaders in architecting, engineering, and designing complex systems and complex products. The intellectual content of this program revolves around complexity, complex systems, and complex products.

There clearly are many ways to look at complexity. There's various modeling approaches to looking at it. There's engineering ways of looking at it. But certainly among those viable ways of looking at technology is a historical perspective of trying to understand lessons from history, what we've learned from the evolution of our understanding of complex systems, our understanding of technology. And Professor Hughes, I think, brings a rather unique perspective on that in terms of his understanding of particular large scale projects.

He has written many books and many articles. His most recent book is Rescuing Prometheus. It's a very notable book.

AUDIENCE: I hate to interrupt, but the audio is very poor.

MAGNANTI: We hope we'll improve it. I'd like for the control room to see if we can improve it.

His most recent book, Rescuing Prometheus, has gotten a great deal of attention. It was, I think, a month, a month and a half ago was reviewed in the New York Times. Two weeks ago, he was on National Public Radio to talk about this book and got quite a rousing responses, I understand from my conversation with him a few minutes ago.

He is also very much intertwined with the system--

AUDIENCE: We can barely hear.

MAGNANTI: Let me try another microphone then.

HUGHES: You want this?

MAGNANTI: I hope this is a little bit better. He's intimately involved, has been intimately involved with the System Design and Management program. I think about six years ago or so now, we had a committee at MIT that was convened by our previous dean of engineering provost Joel Moses and Dan Roos, our associate dean for engineering systems, that was looking at large scale systems. And we brought together, at that time, engineers, management people from MIT, anthropologists, historians to try to get our arms around this whole issue of large scale systems.

And I think that was a previous occasion in which Professor Hughes was visiting MIT. And he joined us in those deliberations. So I think it's fair to say that he's had a touch, from the beginning, on the overall direction and orientation of this program System Design and Management.

I think those of us involved with the program couldn't think of anyone better to inaugurate this distinguished lecture series on complex systems than Professor Hughes, who will tell us a little bit about, I think, some of the elements of his book and some of the projects that he's been involved with and provide us with his own unique perspective on these issues. Professor Hughes.

HUGHES: Thank you, Tom. This all right? Coming through all right? Very generous introduction.

I'm very happy to be here talking to the people about whom I write, that is engineers. Historians do not have this opportunity very often. I'm very fortunate to have it this afternoon and on other occasions.

Tom mentioned this National Public Radio. He said I got a good response. I'm not sure it was a good response. I got an interesting response. I'll tell you about it very briefly before I go into my prepared remarks.

The program is called the Public Issue, Public Concerns, Public Issue. It comes on every day in the week. And after the guest described is interviewed about a book or some other activity, then the audience out there in radio land has an opportunity to call in and ask questions.

And I was getting a rather expected, what I expected by way of questions, until somebody from Pennsylvania named Mike, I believe, called in and he said, professor, I don't want you to think that I'm a crock. But he said, when I was young, aliens abducted me. This is on National Public Radio. Aliens abducted me. I spent time with them.

And I know in your book, you write about intercontinental ballistic missiles and computer networks. And I happen to know from being with the aliens that all of this is reverse alien engineering. Well, he said, did you find any evidence to support this?

So the person who was interviewing me was rolling her eyes. And all I could think of saying was, I've only been able to interview earthlings. And I said, but you have these contacts. And if you can renew them and do some serious interviewing, then turn these over to historians, we can use this to revise our interpretation. So this is true. I mean, if he comes through with those interviews, we will revise our. Interpretations. So he seemed quite satisfied.

Today, my subject is systems, does creating systems, creating large complex systems, as Tom said. First, a word about the historical approach of which you will share with me today. I think what the historian can do can help engineers in several ways.

One way is to put an engineer's present work into some perspective. I hope today, when I describe the creation of several very large systems, that you will be, those of you who are into system design and management, will be drawing analogies on your own with what I'm describing historical cases with what you experience in your work today and yesterday and tomorrow.

And incidentally, if you find that my description of these two systems, the Edison electric light and power system and the ARPANET system, their creation, I should stress, don't hesitate to interrupt me and point out where you think I might have gone astray in my interpretations of the creation of these systems. I'll be giving, as Tom said, several lectures, so I have a few opening definitions. These definitions I wish to use initially are definitions of closed systems and open systems.

Now I've read the biographical sketches of a number of those of you who are now here in the open systems program or in the Systems Design Management program. And I know some of you are in product design, and others of you are in what I am talking about today, managing projects. But I assume that those of you in product design, often the activity you are engaged in is called a project.

And so I believe what I will say today, even though it's not about products, say, in the automobile industry or products in the photographic industry, it is about products. Now here is a product. I call this a closed system. It could be called a technical system. In a moment, when I give you a visual of an open system, you will see the distinction.

Now this diagram is from a technical journal around 1892, I believe, something in that period. It's an electric light and power systems, obviously. What I think you might note here is that, as early as 1982, engineers and managers were quite capable of combining heterogeneous components into a general system.

You will notice that some of the appliances here are run on very high voltage, like the industrial motors. Some on low voltage like the electric lights. Some have one frequency. Other appliances or components have another frequency.

But by 1895 or thereabouts, engineers had developed what I think you might call gateway devices, transformers, motor generator sets, and so forth that allowed heterogeneous components to be put on a single system. So it is a closed system in that it's a technical system. But it is complex.

And now I would like to show an open system. Now what I hope I can contribute to your program and through other talks that I shall give at MIT is opening your minds, if they're not already open, to the importance of open systems. Open systems, as you see from the diagram, include organizational components along with technical components.

And a number of system builders, engineers, and managers over history, over a long period of time in Germany and in the United States and elsewhere in the world, some of these people have been quite good in designing open systems and creating open systems. Now my impression is that in most engineering schools, I'm not sure about MIT, I'm fairly sure though, the emphasis is not put upon open systems. They are considered soft. The emphasis is on the closed technical systems.

But from my interviewing of a number of engineers in the large complex systems world, I find that a number of you, perhaps certainly they're compatriots, your compatriots, your peers, whom I have interviewed, are in fact designing, developing open systems. And as a matter of fact, they tell me they enjoy it very much.

They are messy. And some people consider their work soft. It's not eloquent and elegant and as quantitative as closed systems. But it is designing these is a challenge, which young engineers enjoy. I'm thinking especially of engineers I enjoyed-- I'm sorry, yes, I enjoyed. I interviewed on the Central Artery and Tunnel Project.

And I would ask them, how do you feel about this bringing into the design of the system, environmental controls, taking into account the neighborhood politics, actually rerouting the system because of community concerns? And generally, they said it makes the design project much more interesting. But they added, several of the people I interviewed, that some of the older persons did not find this congenial and would not continue the project.

Now let's take a look at this for just a moment. What I wish I had up here in this diagram was a consulting engineering firm and also a utility. A utility organization should certainly be there.

And if I'd had those two and I'd put those two into my chart, then I could say this is very much like the system that the head of German General Electric, which was called Allgemeine Elektricitats-Gesellschaft. The open system that Allgemeine Elektricitats-Gesellschaft, AEG, created in Germany around 1910, it was a system presided over by a man named Walter Rathenau, who was an open system builder and very good at it.

Now let me just spend a moment on this. The point here is let's look at the bank. A man like Rathenau, when he created the system and then later used it, and he was trained as a physicist and an engineer. He was the head of German General Electric, which was not related to American General Electric.

Rathenau wanted some control over the bank. He also wanted some control of the consulting engineering company. And let's take the bank, for example.

If his consulting engineering and construction company, which he owned stock in, or his company owned stock in, he have them stock in, if construction activity had fallen off, then if he had influence over the bank, he would urge the bank to lower its interest rates. And so that those considering construction projects would be more enticed by the money market. And so there was interaction, and Rathenau saw it, between a bank and a construction firm in the field.

And also in this diagram there should be a manufacturing company. And Rathenau, through sitting on a number of boards of directors, had influence in manufacturing companies and in utilities. And he brought about a symbiosis between what the utilities were needing by way of equipment and what the electrical manufacturers were producing or would produce.

So what we have here are functional interrelationships. And some persons have the vision, as we will see in a moment in our world today, to put together these various components into an interacting system. One thing driving these people who do this, and to me they're fascinating people, and I think, with all due respect, that Mr. Gates is one of these people, these people want control. And they want control not for nefarious reasons, but they want control in order to get the system to function in an optimal way so that they drive control.

Now if I can have the next visual. This is from The New Yorker magazine several months ago. And here, we have media companies. And you know one of the media companies is Microsoft.

And I think most of you are well aware of this, but maybe I should remind you of it, that Microsoft is creating these functional interrelationships. And perhaps one of the driving instincts of Bill Gates is to create these kinds of interactions to have this type of control. If you run down Microsoft, just Microsoft either through direct ownership, through stock ownership, or some other mode of influence, as you will see, is into cables, TV and film production, internet technology, internet content, and so forth. And you see these are all media engagements, media activities. And you can understand that he has a mode of distribution, say, the internet, it's an instinct to get control of the content that goes over the distribution, over the media, over the modes of distribution.

But if we went back to the other diagram, German General Electric in 1910, you had the same phenomenon. You had the distribution system that was also the generation of content, that is electrons, and then et cetera, et cetera, et cetera. And so these are open systems.

I have another very complex diagram here. We can show the next one Leon. This also is from The New Yorker. And the question being asked by the person writing the essay and doing the diagram is, are these media concerns, which I showed you a moment ago, are they competing? Are they collaborating?

And this diagram shows companies that are owned or companies in which control is influenced that connect the spiders, the bugs across the lines drawn between them. And you could study that. And you'll see a number of companies jointly owned, et cetera, et cetera, et cetera. So this is a very complex open system. And again, the reason it's an open system is because organizations are part of the system, I repeat, and there are technical components in the system. Now this is what's called a web of collaboration.

Now a word about projects. I would argue, and perhaps some of my friends here from the Sloan School would not accept my argument, have some in the audience who would not accept the argument, but it seems to me from reading the history of engineering management, my concern is with the management that has a engineering core. And often the people I interview and the companies I write about are managed by persons with engineering backgrounds. So that's the type of management I'm speaking of now.

It seems to me looking back over 100 years that projects are becoming increasingly the activity in which engineers are involved. Projects, and as I said, projects can certainly include product development. Let me spend a few more moments on this.

If one were an engineer, imagine yourself an engineer in 1920, and you'd accepted a job. This is my hypothesis. I'm happy to have it critiqued. And you accepted a job at the Ford Motor Company and went to Detroit in, say, 1925. Still making the Model T.

I think you would expect, as an engineer, that you would be asked to improve the functioning of the assembly lines at River Rouge and Highland Park. You would also be engaged in some improvement in the model, Model T. But you would expect these changes to be accumulative as an engineer.

I don't think you would expect to be involved in projects that would bring about radical changes in the assembly line or in the product. And also, you would not expect a need to go back to MIT or some other institution in order to keep abreast of the discipline in which you were working. That's what I believe a 1925 engineer would feel going to work he or she at the Ford Motor Company, mostly hes then, of course.

But today, one finds that you may become involved in a project. And the project might bring about a radical transformation in product, software, or hardware, or a radical transformation in the way the production line is functioning. And these projects remind me in many ways of the theater.

A friend of mine who is a director and a producer, when I told her about these projects and engineers are so often involved in she said, oh, what you're telling me about is open casting. And I asked her to elaborate upon that. She said, all right, we're doing a play.

We're not a repertory company. We're doing a play. We announce open casting. And I know that companies like Andersen and others do this. An announcement is made, such and such a project will be put into place. The project might engage you for two or three months or maybe even a year or more. And then after you come join this project, and then when the project fulfills its goal, then we will disperse. And you may become involved in another project.

In the case of the theater, open casting, you make an announcement. We are doing "The Iceman Cometh." People from all over the Manhattan area will come and try out for parts. You put these people together for a while. They rehearse for months. They put on a production. And after the run is complete, they disperse. Incidentally, that this open casting when you announce that you are going to do a play, that's a cattle call, incidentally.

Now they also, repertory companies, they do not have cattle calls and open casting. But they have the same people, as you know, doing different projects with the same people. And you'll find both of these forms in the industrial world, in the military world, and in the university world today. Virtual projects as you know they're sometimes called.

And I will describe in a matter of a few minutes, a project. One of the classic projects of history. I think most of you have heard of it. Perhaps some of you have read about it. I note that people in the Systems Design and Management, some of you are interested in history. Well, this is one of the great historical episodes. And that is the creation by Thomas Edison and his group during the period from about 1878 to 1882 of an electric light in and system.

Now what I hope I will be able to do in briefly describing this project is give you what I consider to be the essence of project, the project essence. And the projects you may be involved in differ in detail, of course. And projects done throughout history differ in many ways. But I am hoping to capture the essence of a project by going through this historical episode.

First, program management, I am contrasting program management and project management. I am drawing upon some NASA policies in this regard. NASA, in the past at least, and many of the things I say come from the past, NASA defined program management differently from project management.

Now first, program management in the case of the electric light and power system, program management, people involved in this are concerned about funding and are concerned about politics. And sometimes, they must become involved in organizational creation as well. Now in the case of this particular project, an organization had been formed.

And as I go through this, perhaps you'll be impressed, as I am every time I involve myself with the history of this project, how contemporary this Edison story is in its detail. Perhaps you will agree with me. Perhaps not.

But a company was formed 1878 called the Edison Electric Light Company. Now the Edison Electric Light Company was formed by the program manager types. One of these was a man named Grosvenor Lowrey, who was a very prominent New York City lawyer. And it's not unusual to find people from law and other disciplines involved with engineers in these open system creations.

Now Grosvenor Lowrey was the lawyer for the Western Union Telegraph company. So he was working in the world of technology. Lowrey said, I think we should create an electric light system. I'll explain why he chose that problem in a moment. He said this to Edison. He said, first, we must create this company. And this company will be an investment and patent holding company.

What's new? It will fund Edison's activities. It will take over his patents. It will get a return on the investment. This is venture capital in 1878. And the company was formed.

Another thing Lowrey did, and this is another requirement of open systems, as some of you here I know are familiar with this, the political stage has to be set for the project. And many engineers in projects are not aware of the political maneuvering that has gone on before the project comes into being. In this case, the councilmen in the city of New York in 1878 were very much under the influence of the gas lighting people.

And so the gas lighting people put a lot of pressure on the councilmen in the city of New York when the gas lighting people learned that there was to be an effort to create an electric lighting system. And the gas people said to the councilmen, don't let these people open up the streets, because the distribution lines would be put underground in New York City. So one way to block the project was not to give the Edison Electric Light Company permission to open the streets.

Well, Grosvenor Lowrey went to work lobbying and in other ways in bringing about a change in attitude on the part of the councilmen of New York City. And I think you can well imagine what he might have done to change their minds. So the political stage was set.

And very quickly, I don't want to dwell on this, but it's an anecdote. One thing Larry did, he invited all the councilmen out to see a test of the Edison electric light system in 1879. And he was taking the-- he brought them out in a handsome railway car, took them around and showed them a proto electric light system that Edison had put up at his Menlo Park laboratories. And these people were becoming very bored, the councilmen, with what they were seeing.

And then the councilmen were moved into Edison's laboratory. It was completely dark. Suddenly, the lights came on. The first display of indoor lighting for these people. And when the lights came on, what was displayed? A marvelous meal from Delmonico's with much liquid refreshment to go along with it. And incidentally, that banquet had to end within an hour and 35 minutes because Edison's electric lights would not burn for longer than an hour and 35 minutes.

Now this is program management. We have to respect it. It sets the stage. Now we go into Edison as the project manager.

Now let's forget the heroic Edison of the books we read when we were young. This man was not working alone in a garret. He had one of the best equipped laboratories in the United States.

He also had his team. His team included a physicist, who had studied in Berlin. It included marvelously talented machine tool people. There were also chemists in his team as well as glass blowers who were brought into it for this project. I could go on and name the craftsmen.

But the point to be made here that the historian wants to make, Edison had brought this group, this team together. And I know many of you have been involved in teams. Edison had brought this team together in earlier years to work on the telephone and to work on the phonograph. Now he had this team in place, so he had to choose a product. He had to choose a system that could utilize the resources in the personnel that he had at his disposal.

So I think we need to remind ourselves that we are constrained by the organizational concepts that come out of the past and in which we are working now. We are constrained. There are only certain projects we'll do. There are only certain projects that are suitable.

So Edison decided that electric lighting was suitable for the team that he had in place. Now once he had his team in place and he had his equipment in place, then there was the problem of conceptualizing the electric light system. And I think this is where Edison's brilliance along with the intelligence of some of his team comes into play.

And if I may have the other diagram. Yes. There we are. There's nothing in Edison's notebooks that gives me the evidence to feel confident in saying that what I'm telling you now is other than a hypothesis.

But from circumstantial evidence, this is the way that I believe Edison reasoned his way to his concept, his design concept. As you know in a project, a design concept comes before a preliminary design. Well, from this little exercise in following Edison's reasoning, I think you may better understand the man's so-called and I would say, yes, his genius.

You'll note the interdisciplinary character of the thought processes. He realized he had to analyze the market and with whom was he competing. He was competing with gas lighting.

And from gas lighting, he drew an analogy with regard to the overall architecture of the system that he would design. He had to be concerned about the economics of competing, but also this analogy with the architecture. It was very helpful to him. Gas lighting or the gas companies were then distributing from central plants. They were distributing through an entire city from one central plant.

And Edison decided that his architecture would be like that architecture. But let's go back to the economics of the system. He had a general concept of what the system would be like. He would have distribution lines of copper. It would have generators, of course. And it would have the electric lights.

And he reasoned with the help of some of probably with Upton, the man who'd studied in Berlin under Helmholtz, he reasoned that the reverse salient in the system, the bottleneck, if you prefer, the reverse salient in the system was the cost of copper. So here's a man who is into designing an electrical system but he realized that materials are his problem.

And Edison didn't hesitate to move from one area from materials area into the electrical area into the chemical area. Wherever the problem was, he would move. He wasn't bound by any disciplinary restraints. So he said, the problem is the cost of copper, the cost of copper in the distribution lines.

Then he turns from materials and cost to the science that he had at his disposal. Now remember this is 1878 and the science available to electricians is very limited. He had Joule's Law and he had Ohm's Law.

And from thinking with Joule's Law and thinking with Ohm's Law, he knew that the losses in distribution would be an equal to the square of the current times the resistance. Or to put it another way, the energy loss in the conductors would be proportional to the current squared times the length of the conductor divided by the cross sectional area. If one increased the cross sectional area of the distribution lines, then one would reduce the energy loss in the distribution lines.

But to increase the cross sectional area was to increase the use of copper. Therefore, this was not an option for him to continue to increase the cross sectional area until he lowered his energy lost in distribution. So assuming a fixed length and keeping the cross section area low, how was he to solve the problem of getting the required amount of energy into his electric lights?

Now he knew from Ohm's Law that the electric lights had to have a power on energy consumption which was equal to the current times the voltage. Now he knew from the energy loss in the distribution lines, he had to keep his current low, because the energy loss was current square. I'm going across into this in such detail, it may seem elementary, but this is the way I think the man's mind was working.

And so therefore, he has to keep the current low because current square. He'll raise the voltage, so he will have sufficient current times voltage to give him the energy he needs at his electric lamps. Now how does he raise the voltage and lower the current?

I went into an old Encyclopedia Britannica for that period. And I found that the way that resistance, Ohm's Law was stated in those days was that the resistance equals the ratio of voltage to current. And there's the obvious answer. I think that's the eureka moment for Edison was when he saw that by raising the resistance of the electric light element, he could increase the voltage that would be going through his transmission distribution lines and reduce the current. So that is why the man, and we go into popular stories now, spent months trying to find a light filament that gave a maximum of resistance.

And what he ended up with and that determines even today the standards of our electric lighting system, he found that he could get a filament that would take a current of one amp, that it would have a resistance of 100 ohms. And so that would give him 100 watts. And so there you have the standards that we have in our electric lights today because the highest resistance he could get was 100 ohms.

He needed one amp to get the wattage he needed. Why that wattage of 100 watts? Because 100 watts gave him the same lighting intensity as a gas light was giving at that particular time. So Edison's conceptual design.

I hope that you are as impressed by the man's thinking process as much as I am, even though the scientific laws are not esoteric. The quantitative activity is not remarkable. But putting together the various aspects of the problem is what I find extremely impressive.

Now let's go on to the open system. He now has the essence of his electric technical system, his closed system. Now we go into the organization of the Edison company.

I have interviewed a number of persons in the field of complex systems. And they have told me that it's necessary if the closed system is radical, if the technology is radical, it is advantageous to create a new organization to nurture the radical technology. They tell me, and I'm thinking about an interview with Simon Ramo, who worked on the Atlas missile, did systems engineering for the Atlas missile. And I'm also thinking about General Schriever, who presided over the Atlas missile. And I'm thinking about the people who presided over the Polaris missile.

And in both those cases, the Polaris and the Atlas and numerous other system designs, the system builders not only produce the new technology, but produce new organizations in order to get the radical technology outside of the bureaucratic structure. General Schriever told me, and I'll talk about Atlas next time, General Schriever said, I had to get out, away from those bastards at the Pentagon. He said, I was dealing with people who could say, no, and could not say, yes, the assistant secretaries. I had to get outside the system. So he forms a new organization, the Western Development Corporation, part of the Air Force, but outside of the Air Force and the Pentagon bureaucratic structure.

Well, look what Edison did. Edison and his advisors did not depend upon existing manufacturing companies. But they formed this consortium of companies in which the parent Edison company, the Edison Electric Light Company, the venture capital patent holding company had interests through stock, in most cases. So you had the Illuminating Company, which is a utility, the Edison Electric Illuminating Company in New York and Brooklyn, and other illuminating companies, the Thomas Edison Construction Company to construct the electric light and power systems, the Edison Machine Works that manufactured dynamos, the Edison Tube Company, underground distribution, lamp works obvious. Bergman was fixtures, and other manufacturing came from United Edison.

What it is worth noting here, this system builder, Edison and his team, they have control of the manufacturer, like the German General Electric I told you a moment ago, they're controlling the manufacturer. And they're controlling the market for the manufacturer. That is, they're controlling the utilities that buy the generators that are made by the Edison machine works.

What's new Mr. Gates? In this effort to get control not only of other production, but the content and distribution and so forth. And so we see this control at a very, very early day. Incidentally, most of the manufacturing companies here were combined in the early 1890s into the General Electric Company.

Now I want to turn to a more recent-- well, I should say that the system was deployed in New York, in Brooklyn, and elsewhere. And the company, the Consolidated Edison Company flourishes in New York. It was established by Edison those many years ago, et cetera, et cetera, et cetera. I don't think we need to go into the further development and deployment.

Let's now turn to the ARPANET, which I think you all know is the beginning or the predecessor of the internet. And this story is I think one of the remarkable accounts of system building in the last 30 years. So I would spend some time telling the story of ARPANET.

Again, I mean to say telling a story. Because I know most of you are involved in very elegant problem solving. Your reports are rigorous and quantitative. And I'm telling a story, which you usually do not do in your professional work.

The reason I'm telling a story is because stories can-- well, there are many reasons. I couldn't do the kind of work you're doing. But another reason is stories encompass messy complexity in a more embracing inclusive way than a more scientific elegant account can do. So a story is one way of conveying messiness.

And I'm arguing and I'm arguing with some of my friends at MIT that MIT students need to hear more stories of messy complexity. They may find it soft. And they may find it at first not congenial. But the people I've talked to out in the field often say to me, yes, yes, do tell messy stories because the mess is what many of the young engineers will soon be involved with.

All right, turning to the ARPANET. In following the pattern that I have described in the case of the classic Edison story, let's begin with program management of the ARPANET. Now the program manager of the ARPANET, this is my terminology, some people in the audience may disagree, the program management was the responsibility of DARPA, the Defense Advanced Research Projects Agency. And I trust most of you are familiar with it.

It has been a remarkably successful funder and nourisher of projects since 1958. It is still flourishing. It has changed in character, in policy, but it flourishes. It has been called at times Advanced Research Projects Agency, ARPA. At other times, the Defense Advanced Research Projects Agency. I refer to it as DARPA.

It was founded, established in 1958 in response to the Sputnik. If you don't remember, I do remember. You may have heard that after the Russians launched Sputnik, there was great anxiety in this country that our technology was falling behind and there were some measures had to be taken the Eisenhower administration felt in order to respond to this problem. And one of the responses was DARPA, which was to nourish and develop and fund radical technology. I'm using radical in a very general way, but highly innovative technology, if you prefer.

Now note that DARPA is a Pentagon agency. DARPA gives military funding. But I stress that because DARPA has funded a number of projects that in their impact and even in the process of being created seem rather distant from military needs.

But let me go on with the project management that DARPA was engaged in when the organization decided to do a computer network. All right, now first, what's momentarily distracting me, I see a quote I want to give you here. One of the major DARPA personalities, Licklider, said, what the military needs is what the business main needs is what the scientist needs. So what the military funds can be useful of advantage to businessmen and scientists.

And this statement can be made as long as the level of abstraction is high. Where the businessman and the scientist and the military find their needs differ is when one lowers the project down the ladder of abstraction to very practical, specific applications. But when working at a general level, a computer network, general, all of these contingencies, these clients can be responded to at this level.

Another person I interviewed told me that the military is a very big society. The United States is a very big society. This is a DARPA person. So is it any surprise when we fund a military society need we also funding a civil society needs? Both, for example, need communications. Both need calculations, et cetera, et cetera.

All right, another characteristic of this program manager, DARPA, besides its willingness to innovate on a rather abstract level and respond to a number of interest was that the people in the early days who came into DARPA to manage as program managers, they were often on leave for two or three years from industry, on leave from universities for two or three years. So what were they bringing? They were bringing with them a university style or an industry research style.

What else? Two or three years, and then they left. The project was complete for them. Their performance was over. They left and others came in.

It is difficult to argue that DARPA was a bureaucracy with hardening of the arteries when you have these people coming in for short periods with new ideas soon to be replaced by other people with new ideas. Another characteristic of DARPA, the program management, the staff was extremely lean, relatively few people compared to other agencies. And another characteristic was that DARPA preferred to fund very large expensive projects. And this meant that a small staff could manage, instead of having to manage 1,000 little projects. You had a small staff, five or six people in case of one of the branches of DARPA, that is IPTO, which I'll talk about in a minute. You have five or six people managing millions of dollars, but only a few projects.

Now I want to say something about a remarkable project manager. I'm sorry. I've been talking about program management. Now I want to talk about a project manager, a person who worked within the context of DARPA. And that is Joseph Carl Robnett Licklider, who is usually called Licklider. He set a pattern of project management that I think has had enormous influence in the world of project management and engineering to this very day.

He had a number of devoted followers who admired his style, saw him as a visionary, and put into place and deployed the kind of project management style for which he became noted. Let me say something about Licklider in the time I have. Note the man's pedigree.

This gives us insight into a very interesting period of his history and some fascinating people. Licklider was a psychologist by training. I should say here that he was the first head of the information processing techniques office, IPTO, which was that part of DARPA, ARPA, which presided over the creation of the ARPANET, IPTO. Licklider later from 1962 to 64 was the head of IPTO, information processing techniques office of DARPA. OK.

But what I want to stress, this man with a background in psychology had a remarkably rich career that gave him to experience from unusual capabilities. And maybe some of you have had similar experiences. During World War II, and many of the people who came to the fore in the period about which I'm speaking, the '60s and the '50s, had an interesting World War II experiences in the realm of science and technology. World War II for scientists and engineers was a remarkable learning experience.

Well, Licklider, during World War II, had been a part of a psycho-acoustics laboratory at Harvard University. Then after the war, he moves to MIT to head an acoustics laboratory. How does a man move from acoustics to computers? Well see.

Now while at MIT, he became involved in those organizations that were providing rich experiences for those who would take the risk of becoming part of these new and risk taking organizations. For example, he became a research associate in the MIT research laboratory of electronics. Now that laboratory was famous in the 1950s and '60s for an interdisciplinary approach. Interdisciplinary with something still fairly new in the engineering world.

So he becomes a part of MIT research laboratory of electronics. He also takes part in Project Charles. Project Charles was a summer study project. We don't have these projects anymore.

Summer studies were very popular at MIT in the '50s and '60s. What was a summer project? A summer project was funded by the military, generously funded. The project involved inviting a number of academics and industrial people and military people, maybe 30, maybe 40, that neighborhood number, to just take off from their responsibilities for an entire summer. Later, it became sometimes six months. And focus at a bucolic site, geographical site, somewhere up in the mountains, down to the seashore, these 40 or 60 people free from their responsibilities would concentrate upon one particular problem of interest to the military for six months or a summer.

And one of the major projects was called Project Charles, which dedicated the people who were members of Project Charles dedicated themselves to setting up the air defense system called SAGE. Well, Licklider took part in one of these summer projects. And I'm told by people whom I interviewed at the summer projects, that when you entered the door wherever the meeting was being held, that you were told to forget your discipline, to forget that you were an expert, and that just focus on the problem and go wherever the problem took you into whatever field of engineering or whatever field of science because there are no experts in this area we're exploring.

And incidentally, that was the same technique used at the Rand Corporation about the same time. Forget your expertise. Let the problem decide where you would do your thinking. So Licklider was a part of Project Charles.

Also, he heard about Norbert Wiener. I think all of you have heard about Norbert Wiener. And so he became a part of the group that would mix and meet with Norbert Wiener. So this man had a rich, rich MIT experience. And after MIT and in electrical engineering department and acoustics lab, he went to Lincoln Laboratory. That was another great learning experience in the '50s.

Lincoln Laboratory was established to do the research and development for the SAGE air defense project. But it was funded by the Air Force. It had some of the most advanced computers in the world. And so if one had an opportunity to go to Lincoln Laboratory, as you know which is still administered by MIT, then one had hands on with the most advanced technological and specialty computer equipment.

Then from there, he went to Bolt Beranek and Newman, a high technology firm founded in 1948. I think you're familiar with this firm today. It's a major player in the acoustics and the computing field. So he moves on to Bolt Beranek and Newman. Rich experiences which prepared him for his work at IPTO.

Now Licklider was visionary. And what was his vision? He had a vision in the mid 1950s, he had a vision of time sharing on a computer. And he also had the vision of interconnecting computers. And he often gathered together people in the Cambridge area, maybe over a few drinks, to talk about the future, the possibilities of time sharing, the possibilities of computer interconnection.

He spoke a man-computer symbiosis. Now Licklider, in this earlier period, the 1950s, was not moving towards the development of the computer as a calculating arithmetic device. He was one of the pioneers. He saw that a computer could be used for control and decision making and other purposes. So the man has vision. He has a number of followers.

And now I would like to show you the Licklider network. I hope you have it before you on one of the charts. To me, this is a remarkable network. Please note the movements of these people. These are people with, most of whom, Licklider is intimately associated.

And the majority of them have similar experiences to which he had, MIT, electrical engineering, Lincoln Lab. Some of them at Bolt Beranek and Newman. This was the context in which computer pioneers who made the ARPANET learned the trade. And note the movements of a relatively few people and the organizations with which they were associated.