The ARPA Model isn't what you think it is
Improve your ARPA with this one weird trick!
tl;dr – Almost everything about the ARPA model is window dressing on top of empowering program leaders
It’s mysterious when seemingly inconsistent processes lead to consistent outputs. Many people (including myself!) have lauded the success of the “ARPA model,” but when you dig into the stories behind those successes, almost every important feature that one might point to as part of the model actually varied wildly: program manager tenure, how programs start and whose ideas they are, the level of speculation or defense-relatedness of the technology, or the importance of the venerated Heilmeier Catechism. Even the structure of research programs and the job description of the program manager – two core pieces of the ARPA model – are inconsistent both over time and even in the same era. Despite a deeply inconsistent process, DARPA has unlocked impactful technology for more than half a century with shocking consistency.
Once you get past the cognitive dissonance of DARPA’s consistent results from inconsistent process, this paradox is impossible to unsee.1 As I’ve built a more granular understanding from designing programs at Spectech, running the Brains program, and doing more deep dives with former PMs, it started to feel like almost everything I had written about how DARPA works was just epicycles in astronomy – a complicated edifice of explanations that were being undermined by more detailed observations.
It’s vanishingly unlikely that pure luck led to impactful work across eras and generations – from computing in the 60s to internet in the 70s to RNA vaccines in the 2010s. Like gravity explaining the motion of the planets, there still must be an underlying principle to DARPA’s success. That principle is agency – ironically, actually part of the ARPA acronym; specially, the consistent thread through drastically different successes is that the program’s manager had the agency to lead the program as they saw fit.
The importance of agentic program managers to the success of the ARPA model isn’t surprising or new. The “aha” was that the only way to cut through the paradox of inconsistent process leading to consistent success was that the agentic program leader may be the only thing that’s important to get right; everything else may be cargo-culting.
As an illustration of the paradox, let’s zoom in on one of the most striking inconsistencies – the structure of a research program itself. The term “program” almost always refers to a bundle of different projects – discrete units of work with specific deliverables – or sub-programs.2 However, the relationships between those projects can differ drastically. The relationship between projects and the broader program fall on a spectrum: at one end, the projects form a loosely coordinated portfolio; at the other end, the program is a group of tightly coordinated pieces driving towards a specific result.
On the loosely coordinated end of the spectrum, the only relationship between the projects is the fact that they are all part of the same program (and probably share some rough theme). Perhaps the paradigmatic ARPA program on this end of the spectrum is JCR Licklider’s program around man-computer symbiosis that led to GUIs, mice, and basically all of modern computing. We could call these “expansive” programs because the projects explore very different parts of idea space.
On the tightly coordinated end of the spectrum, there are strong dependencies between the projects; each depends on the others to create a single cohesive whole. The paradigmatic ARPA program on this end of the spectrum is perhaps Lawrence Roberts’ work to create ARPAnet, the starting point for the internet. We could call these “focused” programs because the projects converge on a specific output.
Outside of ARPA examples, there have been successful programs of both the expansive and the focused varieties. All the activities in a professor’s lab comprise their research program — these projects could be focused on building a single system with near-startup-level coordination or be connected only because each project uses similar tools. Many foundations and government programs fund portfolios of work connected only by specific keywords – “molecular biology”, “nanotechnology”, etc.
The funny thing is that If you ask well-informed people “where on the expansive-focused spectrum do ARPA programs lie?” you will get many different opinions. Some former PMs and directors describe a program manager’s job as “find good people and give them money” and others describe it as “constantly running around between labs and making sure they’re working on the right thing and on the same page.”
The reality is that there have been successful ARPA programs all over the spectrum. JCR Licklider “just” spelled out an extraordinary vision, found people who were aligned with it, and gave them resources. Only a few years later, Lawrence Roberts ran the ARPAnet program almost like a CEO: giving different people and groups parts of a broader architecture he had designed and making sure they coordinated to deliver a single system. Many successful program managers didn’t actually manage the people in their program, but many successful program managers managed intensely!
The realization that finally cut through the mystery was focusing on the one truly consistent thing: every successful program I dug into had a program manager who had a lot of agency to lead the program in a way that would deliver results (within institutional constraints, of course.) And conversely, a big program failure point was when the program manager’s agency was constricted by excessive process.
This realization made several things click:
All program managers are program leaders but not all program leaders are managers. Licklider and many other PMs did not manage but they did lead (even if the ideas were not their own). (As such, I think the term “program leader” is much more accurate and I’ve started using it to describe the position when talking about the ARPA model in the abstract.)
There are many effective program leader archetypes for different contexts, technologies, and personalities.
The core inviolable thing that makes ARPA programs successful is that they give program leaders the agency to do the kind of leadership that is most appropriate for their personality/program combination. Everything else is second-order effects.
If I’m right, there are several important corollaries:
If you’re trying to replicate DARPA’s success, most of the structural bits are a distraction. They’re certainly useful, but if you don’t get the agentic program leader piece right, nothing else matters.
I worry that many of the attempts to replicate DARPA’s success don’t get the agentic program leader piece right. And this is why, despite all the trappings of DARPA, they will fail to deliver outsize results.
Examples of success all across the coordination/focus spectrum suggest that there is no context-free “best” way to run a program. Instead, where a program falls on the spectrum depends on the program’s goal and the state of the field that the program is trying to advance. It’s possible to execute on programs anywhere on the spectrum either well or poorly. (But a mismatch between the type of program and the state of the field it’s working with is almost guaranteed to result in frustration and wasted resources!)
Different types of programs need different skills and styles of leadership. As a result, there are many effective program leader archetypes. Expansive programs require the ability to find and filter people who will do good work when you let them rip; focused programs require the ability to create tight feedback loops and align incentives towards a concrete goal. Only the latter could really be called “management”; thus, while all “program managers” lead in one way or another, not all of them are actually managers. Perhaps program leader would be a more accurate term for the role.
The connection between program type, state of the field it’s striving to impact, and effective leadership style means that a program leader’s personality has a big effect on their ability to run an effective program. Different kinds of leadership require different personalities. As a result, not every person who has the requisite skills can be an effective leader for every program. You need program leader-program fit in the same way that you need founder-market fit.
For the people running an organization, hiring the program leaders you can trust is critical because the agency they need to succeed requires so much autonomy. There are many dimensions you need to trust in to be comfortable with someone going off and deploying millions of dollars: technical competence, prioritization, communication, clarity, the list goes on. This trust is easier said than done: it’s much more comfortable and common to pay lip service to agency but then prioritize process over trust.
In addition to leader-program fit, you need organization-program fit. Different organizations have different protocols and Institutional moves around running programs that make them more or less suited to different styles of programs. The powerful thing about ARPA programs is that they give program leaders the agency to do different kinds of leadership.
(An interesting aside: if you squint, these points about talent, trust, fit, and a leader’s agency resemble many truisms in the startup world. It’s not surprising that there are commonalities across power-law-dominated domains.)
At Spectech, we’re executing on these insights by doubling down on giving program leaders as much agency as possible by keeping process and bureaucracy to a bare minimum. This means not pre-specifying the structure of a program – external vs. internal vs. hybrid research – or targeting a specific kind of goal beyond “get the technology to a point where it can change the world.”
Finally, some shilling: If you or anyone you know wants to fund high-agency people to do what needs to be done (and won’t happen in other institutions) to turn the impossible into the inevitable, we’re fundraising! Please reach out on Twitter or info@spec.tech.
It took a friend basically shoving the inconsistency in front of my face repeatedly for me to actually see through the cognitive dissonance. Thanks for that!
See https://www.pmi.org/learning/library/understanding-difference-programs-versus-projects-6896 for more on the distinction between programs and projects.
It would be good to ask someone like Tony Tether to see if he agrees. I found DARPAs proximity to the customer (US National Security) very helpful. It brought very clear focus in contrast to other government research that augments research outside of a direct user base. Government is not for example the direct customer of healthcare.
Seems like an additional actionable takeaway is to help program leaders realistically look at whether their style has good leader/program fit. It's not usually realistic for a leader to significantly change their style, but partial changes in management style and significant changes in program type could be feasible. The absence of process constraints allows freedom here, but even great people can be significantly jumpstarted with good mentorship or collaborative ideation in areas where they aren't used to experimentation.