A Note on the Changing Faces of (D)ARPA
by Eric Gilliam
Unlike the rest of the FreakTakes ARPA series, today’s piece does not have the usual narrative structure. It is, instead, a set of personal notes cleaned up and re-structured as a post. While the post is atypical, the ARPA series would be incomplete if I did not outline the factors that mark key regime changes at the agency over time. The piece is not an exhaustive account of every regime change in DARPA history, but details three major variables that mark regime changes and provide some illustrative examples. Most of the examples are drawn from the early history of computing at DARPA because it is both well-known and well-documented. Enjoy!
DARPA doesn’t exist in a vacuum. It is enmeshed in both the military ecosystem and the D.C. ecosystem. DARPA also has no labs; it is dependent on the community of performers (contractors) available to it — academic labs, companies, and others. Major changes in the politics, economics, incentives, or preferences of any of the above can substantially change what a DARPA office is at any given time.
It is a testament to DARPA’s resilience that it has been able to withstand so many changes throughout the decades, continuing to serve its mission in a less bureaucratic and more entrepreneurial fashion than the vast majority of the government R&D ecosystem. However, it is still essential that those seeking to understand historic DARPA successes understand the “regime” — a DARPA office’s political environment, performer ecosystem, etc. at a given moment — in which particular projects existed.
Through my research on DARPA history thus far, I have come across many small changes that have impacted what DARPA is at a given moment. But three factors have jumped off the page and proven salient enough that I will not sit down to write up a DARPA project from history without understanding them. They are:
The level of organizational oversight in a given period
The extent to which project “visions” came from office directors vs. PMs
The timeline in which projects were expected to pay off and how exactly a given office interpreted DARPA’s mandate that projects serve the military in some way
Today’s piece will not cover any specific project or contractor from DARPA history. Instead, I will detail how changes in these three factors alter how DARPA operates. I will provide examples from oral histories of long-time DARPA employees and performers as well as DARPA historians describing the specific effects of changes in these factors. Many of the specific examples will draw on DARPA computing history and the Information Processing Technology Office (IPTO) —responsible for many or ARPA’s now-famous early computing projects.
I’ll begin by exploring what might be the most substantial shift DARPA has ever experienced: the increase in bureaucracy and procurement rules following the Vietnam/Watergate era. These shifts fundamentally changed how DARPA PMs were allowed to operate.
1. From a Small World to a Bureaucratic One
The post-Vietnam and Watergate shifts in Washington D.C. mark a clear “before and after” in DARPA history. Regulatory crackdowns and increased oversight became typical in this period. Much of this oversight impacted the entire government or the entire DoD at once. Regardless of whether or not DARPA had done anything wrong in the public’s eye, the government had. The sweeping reforms left DARPA a very different agency — from the perspective of both its PMs and its performers. While DARPA remained a more fast-acting and less bureaucratic place than many other agencies in D.C., it became noticeably more bureaucratic than it once was.
Procedural Changes (e.g. 1984 Competition in Contracting Act)
This general change in political attitudes had begun to steadily impact DARPA operations throughout the 1970s, but among the years of steady changes there were also abrupt shifts. One example was the implementation of the 1984 Competition in Contracting Act. To DARPA PMs and longtime performers who served both before and after the changes, this shift is often seen as demarcating where an old DARPA stopped and a new DARPA began. While it is reasonable for one to believe that the ramping up of oversight in how government funds were spent was, in principle, good. It’s more difficult to argue that the changes did not substantially impact the speed and freedom with which DARPA PMs could source, iterate upon, and fund ideas.
Even the procedural changes that seemed, on the surface, very reasonable had a noticeable impact on the speed and fluidity of DARPA’s operations. One example of this was the new requirement that agencies publish a notice for all procurements above $10,000 in the Commerce Business Daily. Once published, PMs would only have to wait thirty days for bids to be solicited and could then begin negotiations. Roland and Shiman — who wrote the book on DARPA’s Strategic Computing initiative and extensively interviewed many of the major staff and performers of 1980s DARPA IPTO — wrote the following on the impacts of this change:
Paired with the Competition in Contracting Act, this legislation transformed the old IPTO-ARPA style of funding research.
In the salad days of IPTO during the 1960s and 1970s, program managers solicited proposals in the research community, often by direct contact with the researchers. An office director such as J.C.R. Licklider, or a program manager such as Larry Roberts, for example, might call up a researcher to ask if he or she would be interested in doing a project for ARPA. If there was a meeting of the minds, the researcher would submit a proposal that was essentially approved before it came through the door. Program managers achieved results by knowing what was going on in the research community and who could deliver. They also accepted unsolicited proposals coming over the transom if they were good and suited ARPA’s purposes. And they put some contracts up for competition, as they did the ARPAnet contract that BBN won with Robert Kahn’s help. The style, however, was still less formal than at agencies such as NASA or even elsewhere within the DoD.
With the implementation of the Competition in Contracting Act, far more DARPA contracts were now formally competed. As a result, a wave of new federal procurement laws now applied to these contracts. This particularly impacted an organization like DARPA because DARPA staff not only fund work on the technological frontier, but come up with plans to shape it. DARPA PMs had previously relied on their ability to work out what a contract might look like with the performer community before a formal contract was ever written. Now, all the performers were legally competitors; how DARPA PMs could interact with them once a bid was out had changed. Roland and Shiman describe how this change in the legal relationship between PMs and the performer community impacted project creation, writing:
Particularly crippling to DARPA was the requirement in the new law limiting contact between procurement officers and potential contractors. Such contact was the taproot of the PM’s success. It was by staying in touch with the community, by letting the community know what was needed at DARPA, by finding out what the community was capable of doing that the PM was able to map out a reasonable research agenda in his field and sign up the best workers to make it happen. In the new dispensation, such networking could be viewed as collusion. PMs in the future would simply have to be much more careful, much more circumspect, much more correct when dealing with researchers who were potential contractors. This did not make their jobs impossible, but it did make them harder and less enjoyable.
“Harder and less enjoyable” is a succinct way to describe the differences in the lives of a DARPA PM of the 1980s vs. a DARPA PM of the late-1960s. If it were truly critical, there were procurement levers DARPA directors, office directors, and PMs could pull to make DARPA work the way they needed it to work. As one example, directors could use an OTA-like authority to get around particular pieces of red tape if it was truly important. But directors were also aware that this should only be done sparingly. Also, if a technicality got in the way of common-sense project management — like the above regulation which negatively impacted PMs’ ability to brainstorm with performers when putting together contracts — entrepreneurial individuals at DARPA often found ways to at least approximate their old common-sense workflows in legal ways. In fact, this is how DARPA’s Broad Agency Announcements (BAAs) came to exist. To get around the aforementioned issue, Stephen Squires came up with a technique for soliciting proposals — once described as “a cross between an RFP and a fishing expedition” — which took hold at DARPA.1 It eventually evolved into what is now the BAA. While the BAA was a wonderful organizational innovation, it was only necessary because of the aforementioned changes in procedure.
There was now an added step to the game of being a DARPA PM. PMs and office directors could still be proactive and ambitious, but they often had to devise strategies to make their projects work within the confines of the new legal procedures and red tape. By the late 1980s, many longtime DARPA affiliates felt the PMs could no longer do precisely what they wanted exactly when they wanted to do it. These shifts in procurement laws and contract management contributed to DARPA becoming a place in which funding could easily be given to promising ideas in days or weeks, to one where months was increasingly becoming the norm.
Of course, there were also games to be played in the prior DARPA regime. In the case of IPTO, for example, many researchers at computer science departments that did not receive IPTO’s Centers of Excellence grants — which Licklider’s IPTO office had used to foster top-tier computing departments when the field was in its nascent stages — complained that they were unfairly overlooked. To overcome being outside of the network was also a game, to be sure. A researcher might need to go further out of their way to put themselves on a PM’s radar. But the new procedures ushered in a game that was quite different in nature. The following subsections detail some of the performers’ and PMs’ perspectives on this new game and how it had to be played.
The Performer’s Perspective On These Changes
In their oral histories, often recorded once they had retired, long-time DARPA performers often listed this change in procurement bureaucracy as the single factor that most threatened DARPA’s future effectiveness.
In a series of interviews with those who played major roles in BBN’s work on the famous ARPAnet contract, two separate BBNers used the free air the interviewer provided them to put on the record how bad they felt these changes were for DARPA. In his 1990 oral history interview, Frank Heart, BBN’s project leader for the ARPAnet contract, described what he believed to be the increasing silliness of the government’s approach to technology contracting:
[Interviewer]: Okay, that covers the questions I had, unless you have any general comments you would like to add to the record.
HEART: As I say, the only thing I would emphasize is that if people try to look at all the projects that this country does in the computer world, and all the failures there have been, all the large military computer systems that have fallen on their face, or had a factor of ten overruns in time or money...If you look at all those things, and then you ask, "Why do these few make it and be successful, and why do all those not be successful?" That's an important thing, if one could somehow get that lesson across to Congress and others, it would be kind of nice. It's very hard apparently because they keep doing it the wrong way, mostly. What happens is that people who know nothing about the technology write long lists of requirements. Then they go out to industry and ask industry to bid on these silly requirements, and they get back silly bids. Then they pick the low bidder of the silly bids, which often is the one who understands the technology least; and then ten years later they have a disaster. Instead of people who understand the technology very, very well in the government who are able to drive it to the groups that are the right groups, even if it isn't the low-price bid, and who take close control of it, who don't have an enormous list of specs, and then other people who never wrote the specs, but who have a participatory prototyping kind of relationship with the thing where it grows. If one could get across that lesson, it would be kind of nice. But I don't hold much hope for that.
[Interviewer]: Can you give me any examples of what you consider big failures, using this kind of method?
HEART: Well, gee, there are probably... No, I probably can't do that, just because I wouldn't want to be quoted. But, I mean, they're legion. The number of defense systems where they've tried to build computer systems, and they've been horrible, there are probably lists twenty or so long. I probably wouldn't want to be quoted on naming them, but it's many, many, many subsystems that have been ten years late at ten times the cost — things like that. The ARPANET went from a contract award to an installed operating system in nine months. It went from a contract award to equipment being delivered, on site and running, in nine months.
Heart also believed that working with DARPA, in 1990, was still quite a positive experience and not nearly the headache it had become to work with other pieces of the government that supported research. But the following quote from Alexander McKenzie’s 1990 oral history — Mackenzie was BBN’s so-called “ARPAnet generalist” — makes it clear that these procurement changes had pronounced negative effects on DARPA performers, compared to how things used to be. McKenzie’s interview reads:
[Interviewer]: We have covered what I wanted to ask you about. I want to open it up and ask if there's anything you want to add, any general comments you would like to make about the ARPANET, or your involvement in it, or ARPA in general.
MCKENZIE: I think that the example of the way ARPA worked in those days, in the 1970s — not only in communication but in a lot of other programs — was pretty effective in terms of cost and return on investment. That the model of some really bright people in the ARPA office, with some particular goal in mind, something they thought would help the country, or the DoD, being given the authority to go out and find the smartest people they could find who were interested in working on that problem, and then giving them relatively free rein to do some research or some development, produced pretty remarkable results. And I know that there has been fraud and abuse in government and in contracting and so forth, but it seems to me that the kind of rules and regulations that there are now, that are attempting to prevent that, really make it very difficult for the government to get the same kind of power out of its research dollars these days as it was able to then. I know it's hard to find a balance between accountability and free rein, and these days the government approach seems to be more on the side of accountability and less on the side of free rein. But I think that a lot is being lost.
Mckenzie continues by sharing a quite specific example that he felt characterized the kind of thing DARPA eventually began to worry about that it hadn’t in the 1960s:
I remember a discussion that I had with Jon Postel back in, I don't know, the early 1970s. We were talking about travel to a Network Working Group [which helped come up with the early internet protocols] meeting. And he was saying that he really would like it — maybe it was a subgroup meeting — if it would be some place rather than some other place, because the government accountants were getting university accountants to not want them to spend so much on travel. And his comment was, "I know that in my contract there's only a fixed amount of money. I want to use that money the most effective way possible. I don't know why they think that, when my salary is paid out of this, that I'm going to waste money on unnecessary travel. I want the money for my salary; I want to keep having a job, but sometimes the travel is necessary. They don't seem to understand that that's the case. They think it's just a boondoggle." I think there's a lot to that attitude. That, yes, we spent a lot of time in Network Working Group meetings hammering out ideas, but something really good came out of it.
Mckenzie closes by explaining how, in his eyes, the previous DARPA regime was ideally set up to keep costs down in its own way, while staying ruthlessly focused on outcomes and not process:
BBN wasn't required to file monthly fund expenditures reports and justify every decision on the basis of cost effectiveness. We could pick the Honeywell 516 because it was OK — it was an OK processor for this. It would do the job, and it wasn't, maybe, the most cost effective and we didn't have a subcontract bidding plan in effect to give everybody the opportunity to bid, and thereby put another three months of delay into the schedule - we could just decide. I think that was pretty valuable. If you're talking about multi-million dollar projects, it's probably more important to pay attention to those things than it is in tens-of-thousand or hundreds-of-thousand dollar projects. But, even there, there's probably things where better results would come to the government if they could find a way to shift back a little bit more towards accountability for the results, rather than accountability for the pennies. I think that DARPA in the 1970s did a really good job for the country in that way. It was a joy to be associated with the ARPANET project. It was fun. It was challenging. And I think it was good for the country. It's not so easy to find that mix now, and I think regulation is a big part of it.2
The negative opinions on these bureaucratic changes at DARPA were not limited to its performers.
The PM’s Perspective
As these procedural changes began to take effect, the life of a PM became “harder and less enjoyable” in many ways. Opinions varied on how annoying the changes were. Many PMs thought the changes were horrendous for the pace and cost-efficiency of projects. Some, such as IPTO’s Ronald Ohlander, expressed less polarizingly negative opinions. Ohlander — whose budget more than tripled from $14 million to $55 million as DARPA’s computing applications budget grew — felt this increase in resources granted him many more opportunities than the increased paperwork and bureaucracy took away. But even after taking moderate views like Ohlander’s into account, it is clear that the DARPA of the mid-1980s operated with the increased computing budget much differently than the DARPA of 1970 would have.
PM Paul Losleben’s thoughts on the new mix of resources and bureaucracy were clear:
I…had twice the budget that I had had before…and I was accomplishing less because I had lost the freedom to build the program, to interact, to define direction, to work with the community.3
Ohlander, on the other hand, merely complained that he had to hire more staff than he otherwise would have to keep up with his budget increase. But, with that being said, some of the difficulties he experienced managing the ill-fated Autonomous Land Vehicle (ALV) project may have been mitigated if he could operate more like a ~1970 ARPA PM. The original ALV project had to be scrapped largely because of the mismanaged expectations and misaligned incentives of both Martin Marietta and the university vision researchers. As I covered in a prior FreakTakes piece, Martin Marietta turned out to be a prime systems integration contractor with little interest in implementing cutting-edge component technology. Martin pressed DARPA to specifically define intermediate benchmarks for the technology. Martin would then find ways to hit these benchmarks using minimal cutting-edge technology, not trying to satisfy the spirit of the contract. Meanwhile, many of the university-based computer vision researchers cared more about developing algorithms that were interesting in a basic research sense than they did about developing algorithms to make the vehicle work. Their algorithms often did not perform when plugged directly into machines like the NavLab at CMU.
Whether or not these failures would have happened absent the new procedures, at the minimum the new regulations exacerbated these issues. Roland and Shiman describe how these procurement changes negatively impacted Ohlander’s ALV project:
The new methods of procurement…made Ohlander’s task doubly difficult. In a previous era, he would have held informal discussions with the researchers at an early stage in the planning process, so that contractors understood what was expected of them and what they would contribute. Such a casual approach was no longer possible. The potential contractors were all competitors now. Ohlander could gather the researchers together to help write the [project] plan, but he could not discuss specifics with them about who would do what. The researchers themselves would have been very reluctant to talk, especially with their potential competitors. Ohlander could not be certain that the successful competitors would work well together. He had never worked at all with some of them, especially those in industry, such as GE and ADS. All he could do was to specify in their contracts that they were required to participate in open discussions and exchange information freely with the other contractors. They [DARPA] would have to trust in his [Ohlander’s] ability, as the source of funds, to twist arms if necessary. Running SCVision in two phases made this easier, as it allowed DARPA to cut off recalcitrant or underperforming contractors after only two years.
The multi-phase structure of the project proved to be essential. At the end of the first phase, DARPA would have to fire the prime contractor, Martin Marietta. While many of the academics continued to receive their basic research funding, they gradually became only indirect contributors to DARPA’s main autonomous vehicle project. Their research was often not as applied as DARPA needed it to be. The spirit of the ALV project primarily lived on in the autonomous vehicle teams Chuck Thorpe and others were building at the CMU Robotics Institute. In the CMU Robotics Institute, Raj Reddy had built up a research operation that valued what DARPA wanted it to value: cutting-edge research alongside practical systems engineering work. In CMU, DARPA’s autonomous vehicle staff eventually found a one-stop shop that could manage the practical aspects of the project and many of the research portions. That was great. But more time and money likely had to be spent on the wrong performers than may have been necessary under DARPA’s old procedures.
In 1984, as the Competition in Contracting Act was being implemented, a Science reporter named Mitchell Waldrop — now of Dream Machine fame — wrote an article that characterized the feeling of DARPA PMs and their performers as “confusion and heated tempers.” One side was frustrated as they figured out how to write bids for government contracts while the other tried to figure out how to evaluate them in a legal and auditable fashion. ARPA’s office staff and performers had begun to spend far more time checking compliance boxes than they ever had before. Bureaucratic obstacles stood between the PMs and their beloved performer communities. Things had changed.
To learn from any project from ARPA history, it is crucial to understand whether the project took place before or after these procedural shift and how that affected a PM’s project management.
2. Office Director’s Visions vs. PM’s Visions
DARPA has become quite famous for the freedom of its PMs. Many advocates of the ARPA model believe a PM’s freedom to pursue their own unique vision is an emphasis that DARPA has always had. However, in DARPA’s early decades, in particular, the freedom to decide which project areas to pursue often fell to its office directors, not individual PMs. But even in cases when specific goals were dictated to PMs by office directors, the PMs still generally had the freedom to decide exactly how to go after those goals.
There are pros and cons to leaving the job of “visionary” to office directors vs. the distributed cohort of PMs. The former may provide an office with fewer unique opinions but ensure that the whole office is working in a coordinated fashion towards a few primary goals. The latter ensures that a given cohort of PMs is free to pursue as many unique ideas as possible. Many offices from DARPA history tend to fall somewhere in between the two extreme ends of the spectrum.
A prominent example of a relatively director-driven office was IPTO in its early decades. Early IPTO office directors were picked because they could both provide a strong vision for the office as well as effective leadership of the PMs. Roland and Shiman describe the different directions in which early IPTO directors steered the office, writing:
J. C. R. Licklider revolutionized computing by aggressively supporting his twin hobby horses of time-sharing and man-machine symbiosis, and by proselytizing for his vision of an “intergalactic computer network.” He recruited Ivan Sutherland to do the same with graphics. Strong successors such as Taylor and Roberts ensured that artificial intelligence (AI) received the support it needed well into the 1970s. The payoff from AI was slower to come than in time-sharing, graphics, and networking, but IPTO kept faith with the field nonetheless.
These IPTO directors often fostered beneath them a few academically-decorated PMs with visions of their own which they were green-lit to pursue. But, oftentimes, there were even more PMs stewarding the visions of others than were encouraged/expected to have visions of their own.
Three examples of projects that were dreamt up by someone other than the PMs who ran them were the Pilot’s Associate, Battle Management, and Autonomous Land Vehicle projects — all covered in a prior FreakTakes piece. Several individuals across IPTO, in consultation with the armed forces, had a hand in dreaming up these projects. The most important of these individuals was probably Clinton Kelly. Despite this, Kelly became the PM of none of them. He helped guide them, in a way, but was not the official PM. Despite the fact PMs like John Retelle (Pilot’s Associate), John Flynn (ship-level Battle Management), Al Brandensteein (fleet-level Battle Management), and William Isler (ALV) did not come up with the ideas themselves, they still had relatively long leashes to execute their projects as they saw fit. Despite not having the freedom to come up with projects from scratch, their freedom was more similar to that of a SEAL team commander who might not get to choose which objective to take, but often has the freedom to decide how to take the objective. In fact, PMs from the armed forces found themselves in the position of stewarding others’ visions relatively frequently.
A major upside of office directors coming up with a vision and several PMs being expected to execute that one vision is that PMs could be assigned to projects that they might not 100% believe in. This can be useful. There exist cases that might draw appropriate skepticism from all individual PMs, but which it is optimal for the office portfolio to pursue nonetheless. I’ll provide an example of a program which was roughly this shape — one in which the right course of action required PMs to pursue all possibilities, however unlikely.
In the early 1980s, IPTO director and chief visionary Robert Kahn thought that computers needed about a three order of magnitude increase in performance before they could truly approach AI-type applications. There were three paths that he felt could make this happen. To be thorough, he felt it made sense to fund all of them — even though some seemed far more likely to work than others. The goal was important enough that he felt no stone should be left unturned. Option 1 was to improve chip performance, funded through the VLSI program. Option 2 was to speculatively design new software approaches that could be run on later generations of machines more suited to the approaches than present machines. Option 3 was considered the most promising option. Option 3 was to design and build parallel architectures. With the office largely following the vision of one or a few people, and not every single PM, Kahn was easily able to ensure each of these approaches was pursued thoroughly — even if options like speculative software design felt risky and unlikely to pay off.4
In IPTOs early decades, such as in the 1980s, it was also not uncommon for PMs to be called in to manage projects that were the vision of another PM. PM Ronald Ohlander’s portfolio of AI projects was one example of this strategy. In the following excerpt, Roland and Shiman describe what was expected of the non-visionary PMs brought in to help Ohlander manage his then-swelling AI portfolio:
All three men were typical of the active-duty military officers who did one or more tours at DARPA on assignment from their services. They served beside civilian program managers who came to DARPA from industry or academia…The civilians usually came with more powerful credentials in their technical fields; this often meant that they had technical agendas of their own and attempted to shape the field while at DARPA. The military officers came with a better understanding of the clientele for DARPA’s products…They could translate service needs for the computer science community and translate technical capabilities to serving officers. Sears played the latter role. He took over programs for which he had little formal training, but he educated himself on the job and relied on his common sense and management experience to keep the programs on track. Most importantly, he had to recognize good excursions from the plan, to know when a project was making better-than-expected progress and needed more resources to exploit the opportunity. Just as importantly, he had to know when a project was failing and had to be invigorated, redirected, or abandoned.
While many seem to intuitively understand the pros of PMs’ freedom to have visions of their own throughout DARPA history, it’s important to understand that this is not something that has been true of every office throughout DARPA history. For example, DARPA’s golden goose, early IPTO, did not always work this way. The individual freedom of PMs has huge upsides, but so does the entirety of an office’s PMs working in a coordinated fashion to accomplish a few goals. There is room for both approaches in any ARPA-like organization; the state of a field, an office’s goals, the personnel available, and the set of institutional circumstances an office finds itself in will determine which approach is optimal.
3. Payoff Timelines and DARPA’s Military-Focused Mandate
The final section details a variable that heavily dictates which projects are in scope for a PM and how a project is pursued: a DARPA office's attitudes towards payoff timelines and dual-use technology. This is often dictated by things like the preferences of DARPA directors and the political moment an office finds itself in.
Changes in acceptable payoff timelines for a project can come about for a variety of reasons. For example, wartime or a change in political winds can lead administrations to push for more “fiscal responsibility.” A common response to this is for DARPA directors to emphasize project plans that can produce applications quickly. On the flip side, certain directors and presidential administrations have been known to openly embrace dual-use technologies and provide generous payoff timelines. DARPA’s exceptional track record often earns the agency a longer leash than is typical. There is also a lot of middle ground between these two extremes. It is not uncommon for certain offices within DARPA to maintain quite short leashes and keep a clear focus on military practicality while, simultaneously, other offices exercise long leashes and focus on more dual-use technology with unclear time horizons for payoffs. This was the case in the 1970s in which the applied Engineering Applications Office (EAO) coexisted with the risk-embracing IPTO.
Early IPTO’s Dual-Use Ethos, the Mansfield Amendment, and George Heilmeier
Obvious shifts in timelines and attitudes towards dual-use technology might abruptly follow a change in the President and/or DARPA director. One example of an abrupt shift in how military-centric DARPA was expected to be came in the early 1970s. In 1970, with the Vietnam War waging and amid a generally troubled political environment, the Mansfield Amendment was passed as an addendum to the Defense Appropriation Act of 1970. The amendment proposed that the DoD should not be allowed to conduct any basic research. While the amendment was repealed within the year, the point Congress intended to make was clear. In response, ARPA soon changed its name to DARPA. The D in DARPA was no longer silent.5
Throughout the 1960s, Licklider and prominent IPTO PMs, such as Larry Roberts, had openly funded the most promising and useful research they could find, often without too much thought to how military-focused it was. In general, the IPTO office visionaries were true believers in the technology and its eventual widespread usefulness in all areas of society. So, they were generally happy to grant funds to any researchers who would push the computing field forward. The general, dual-use ethos that drove these visionaries was something along the lines of, “What’s good for the country will be good for the military.”6
As we now know, this attitude proved to be spot on in the case of computing. When the field of computing was in its nascent stages and much still needed to be worked out, IPTO gave massive block grants to computing “centers of excellence” like MIT, Stanford, CMU, University of Utah, and others. While many somewhat applied projects and direct asks were made of the centers of excellence which were often funded by the block grants, there was a lot of excess funding from the grants which the departments were free to use to pursue their own interests. Notably, the ARPAnet contract itself was pursued by Larry Roberts largely with general use cases in mind. The driving force behind the project was not exactly a military-specific need, but the idea that a broader communication breakthrough like the ARPAnet must improve military operations somehow. Despite the success IPTO had with this approach, this style of operating soon became more difficult.
While the Mansfield Amendment was repealed, it succeeded in forcing changes on DARPA beyond making the D in the name no longer silent. At the minimum, it was now clear to DARPA PMs and office directors that they were being watched. They were now careful to justify projects with specific military applications in mind and find more development projects. Larry Roberts described some of the changes as follows:
The Mansfield Amendment…forced us to generate considerable paperwork and to have to defend things on a different basis. It made us have more development work compared to the research work in order to get a mix such that we could defend it…The formal submissions to Congress for AI were written so that the possible impact was emphasized, not the theoretical considerations.7
However, Roberts did note in his oral history that while the mix of funds did shift to become more applied, for his personal budget DARPA found additional money for applications and that his basic research budget was not cut. While this applied shift felt abrupt to PMs at the time, a modern PM would probably classify this era of DARPA history as relatively exploratory.
This applied shift, which came in the wake of the Masnfield Amendment, ratcheted up a level in 1975. This is when DARPA appointed its most well-known director: George Heilmeier. Heilmeier would become famous for exercising a very heavy hand in deciding which projects would be pursued at DARPA along with his famous Heilmeier Catechism. Office directors and PMs now needed to have satisfying answers to Heilmeier’s six questions related to things like current technological limitations, applications, and intermediate measures of success if they wanted funding for a project. While none of the principles in the Heilmeier Catechism were new to DARPA, the expectation that each of the six questions had a thorough answer was much stricter. Roland and Shiman attempted to describe many PMs’ views on the change, writing:
Heilmeier’s catechism was not unreasonable, but he reportedly applied it with a draconian enthusiasm that reflected a chilling political climate settling over Washington in the first half of the 1970s.
While Heilmeir’s DARPA may not look too strict to modern eyes, it felt very strict compared to prior ARPA regimes. Heilmeier believed DARPA should look much more like mission-driven agencies, such as NASA, than a basic research funder like the NSF. He thought DARPA had unreasonably broadened its scope. He even mocked what had come of DARPA, derisively calling it “NSF West.” Under Heilmeier, PMs were pushed harder to get their exploratory research out into the field as applications. Funding exploratory research with only a hazy idea of what the applications could look like became a taller task than before. For those in D.C. who felt DARPA could be perceived as spending recklessly, Heilmeier was just the man to rein it in.
But Heilmeier’s tenure at DARPA should not be viewed as an event that marked some monotonic decrease in DARPA’s embrace of exploratory, dual-use technology. While the federal government norm is often for things to grow only more onerous over time, in DARPA history it is quite common for operating rules mandating a certain level of strictness to abruptly become less onerous.8 The period coinciding with the departure of Heilmeier as DARPA director and the prospective appointment of Robert Kahn as IPTO Director brought about one of these shifts on an office level.
Under Heilmeier, basic research funding from DARPA had become insufficient by the standards of Kahn and the computing community. New DARPA Director Robert Fossum was sympathetic to this viewpoint and was happy to bring Kahn on as IPTO director and honor his one condition to take the job: that DARPA increase basic research funding in computing. Roland and Shiman described how this shift in how applications-focused IPTO was occurred, writing:
In congressional testimony in 1981, Fossum reported that DARPA funding in constant dollars had fallen steadily from 1970 to 1976; it had not yet recovered its 1970 level when Kahn became IPTO director in 1979. The post-Vietnam heat of the mid-1970s was abating, Fossum did not share Heilmeier’s catechism or his pessimism about artificial intelligence, and Fossum wanted Kahn to take the job. By 1982 the IPTO budget had climbed from its 1979 low back up to a respectable $82 million.
These changes in an office’s focus, which are often the result of non-technological factors, not only impact which projects enter the DARPA funnel and continue to receive funding, but also the life cycle that a given project takes. In the case of DARPA’s 1980 Strategic Computing Initiative and the underlying pressure to have clear applications for the program, this pressure likely had both positive and negative impacts. When assessing DARPA’s impact on the development of autonomous vehicles, the pressure may have been for the best. While the Autonomous Land Vehicle project did come up short, the push to get vision applications into the real vehicles quickly allowed CMU to prove itself to be DARPA’s great systems integration contractor in the field of autonomous vehicles. On the flip side, in the case of the Pilot’s Associate program, the PM in charge of the program thought the premature push for a mature prototype took a program that was making solid technological leaps and forced it to abruptly implement a system that was not as cutting-edge or intelligent as it could have been otherwise.
In very obvious ways, variations in DARPA’s attitudes towards dual-use technology and the pursuit of projects with long-run or unclear payoffs impact which projects get chosen and how they are pursued. But one would be incorrect to view some eras of DARPA as simply better or worse places for the most ambitious research. For example, while some (too crudely) might view Tony Tether’s wartime DARPA agency in the 2000s as a more difficult place to pursue ambitious programs — given its use of procedures like budget wedges and emphasis on programs that might pay off in the current war — an entrepreneurial PM like Geoff Ling proved this was an ideal time to pursue one of DARPA’s most ambitious programs ever: the Revolutionizing Prosthetics Program. Ling’s program made major breakthroughs in neurally integrated upper limb prosthetics and brain computer interfaces (BCIs) that helped lay the base for some of the ambitious BCI projects of today.
While the impact of an office’s attitude on dual-use technology and payoff timelines is somewhat intuitive, one important wrinkle to consider is whether the customer (the military) must actually agree an application is desirable before a project is funded. Whether or not an office can pursue a project despite the military being lukewarm or cold on an idea has a massive impact on what sorts of projects get pursued.
A military-focused office can often say “no” to the military
Military-focused project selection and listening to the military are not always the same thing. Different DARPA regimes and offices can have varying abilities to say “no” to the armed services. In the case of the Pilot’s Associate, the Air Force did want it and indicated they‘d be willing to actively participate in its development. In the case of the ALV, the Army did not express much desire for an autonomous recon vehicle — at least not strong enough to warrant DARPA’s spending on the vehicle — but IPTO staff had a strong belief that the Army would want the ALV once they saw it in action. So, DARPA was comfortable making the ALV application the centerpiece of its SCVision portfolio. This ability to say no to the army in the 1980s DARPA computing portfolio stands in stark contrast to the accounts of some PMs who worked under directors like Tether. Tether often mandated that PMs obtain a budget wedge — a formal promise by an armed service to continue funding a particular project if the R&D benchmarks reached a certain point — before beginning to fund many projects.
In Tether’s case, the recent 9/11 attacks and the country transitioning into wartime allegedly had a strong impact on this decision. Ling’s prosthetics program was the right kind of ambitious for the moment; meanwhile, overriding the no of the military to build seemingly futurist technology the Army said it did not want likely would not have been. One cannot truly understand and apply the lessons of any project’s success or failure without understanding the office’s attitudes towards dual-use technology, payoff timelines, and saying no to the customer in a given era.
Concluding Thoughts
DARPA is no longer a young government agency. In a difficult environment, it has managed to remain a place where bright minds take risks, act (relatively) nimbly, and get things done. The agency continues to specialize in pursuing projects that are big-if-true, fall through the cracks of the standard R&D ecosystem, or might succumb to the valley of death without DARPA’s intervention. The agency’s history is one we would be foolish not to learn from.
To adequately learn from this history, it’s crucial we understand what changes and what stays the same about the agency over time. Certain key factors have remained constant throughout (D)ARPA’s life. The twin constants that, to me, define the ARPA model over time are the use of a clear customer relationship as the agency’s North Star and the use visionary PMs (or office directors) with agency instead of passive funding panels. But it is possible that there are even more key variables across DARPA history than there are constants. Today’s piece outlines what I believe to be three of the most important ones those. Those looking to learn applied lessons from the agency’s history should keep them in mind.
Thanks for reading:) As always, I’d be eager to discuss/assist PMs or PM-like individuals in any way I can. Just reach out to me on Twitter (eric_is_weird) or via email (egillia3@alumni.stanford.edu) to chat.
Appendix: A Note on Other Headwinds In The 1980s
Regulations are not solely to blame for the initial negative results of the ALV project, and projects like it. In the mid-1980s, Ohlander was fighting against two other sweeping trends that surely made the life of a PM for a project like the ALV harder. Many groups that would once have been more aligned with DARPA’s incentives were gradually drifting in scope.
The first of these headwinds was the gradual drift of university labs away from applied research contracts. With post-war federal basic research funding continuing its explosion, universities were leaning more and more into basic research funding and further away from the applied research contracts that were a key source of funding in prior decades. University labs were gradually growing less well-suited to DARPA-style contracts that required a very applied technological component — like operating a working vehicle in which to plug academic vision algorithms.
The second headwind PMs like Ohlander were fighting against in the 1980s was an increasingly myopic sense of what projects corporate R&D should pursue. A 1970s recession, the 1980s “financialization” of management in engineering organizations, and likely other causes saw corporate research drift in its ambition. My prior FreakTakes piece on Lockheed’s Skunk Works provides an interesting case study of what these pressures looked like from within a defense prime. It was even difficult for Kelly Johnson and the famous Skunk Works to fight against them as the decades wore on.
Both of these trends happening simultaneously contributed to an organization like BBN’s ability to recruit top academic engineers from places like Lincoln Labs so convincingly. BBN’s recruits simultaneously felt that Lincoln Labs did not work on truly useful technology, but also that their minds would be wasted at standard corporate R&D departments like Honeywell’s. BBN was one of a small number of organizations that still existed to work on truly novel, truly useful applied research contracts. These two simultaneous trends likely had their own negative impacts on DARPA on top of the negative impacts brought on by the new procurement rules. But, at the minimum, the growing apart of industry and academic research made it even more vital that DARPA keep a strong hand in coordinating — and when needed, twisting the arms of — performers on an ongoing basis. The new procedures made this much more difficult.
General Links
Beyond the specific citations above, much of the general knowledge in the piece is indebted to the great books and oral histories on early IPTO conducted/written by Judy O’Neill, Arthur Norberg, William Aspray, Alex Roland, and Philip Shiman:
University of Minnesota IPTO oral histories can be found here
Transforming Computer Technology: Information Processing for the Pentagon, 1962-1986
Strategic Computing: DARPA and the Quest for Machine Intelligence, 1983-1993
Roland and Shiman wrote this, but it’s unclear if the quote came directly from a PM they interviewed or if it was their distilled explanation of BAA descriptions given to them.
Emphasis my own
I simply use this example to describe a shape of a situation from history where the office director as chief visionary could be advantageous. I do not know whether or not the PMs who pursued these projects were, in fact, working on their first choice of project or not.
This is a reference to a joke made by Robert Kahn in his oral history.
This is a general takeaway distilled by Roland and Shiman from the O’Neill, Aspray, Roland, and Shiman interviews.
Larry Roberts, “Expanding AI Research,” in Expert Systems and Artificial Intelligence: Applications and Management, ed. by Thomas C. Bartee (Indianapolis, IN: Howard W. Sams & Co., 1988), 229–230. I am indebted to Roland and Shiman for this citation, who are, in turn, indebted to the great David Hounshell for it.
This is, to me, one of the most impressive things about the agency.