# Building capabilities instead of solving problems We often think of technologies as solutions to problems. This framework is often explicit: investors, grantmakers, and journalists will ask “what problem does this solve?” Technologists will justify their work by declaring “we’re solving <climate change/education/cancer>.” The *implicit* assumption that good technologies should solve problems is everywhere. Technologies as solutions to problems is the dominant framework for thinking about them. The problem-solution framework has a lot going for it — [[The strongest argument for the problem framework is that adopting new things is hard for humans so if they are going to use your new thing, you need to be solving some unbearable pain]]. But it’s incomplete. [[Technology Solves Problems]]. However, [[The problem framework runs up against examples of important products and technologies that didn’t solve an obvious problem]]. Another framework for technology development is that *building new technologies creates new capabilities for humanity.* It makes a lot more sense to say that cars gave people the capability to move over land at dozens of kilometers per hour than to say that they solved the problem that people couldn’t move faster than a horse. Technologies can both reduce bad stuff *and* increase good stuff. “Not having enough good stuff” isn’t really a problem. ### Why does this frame-shift matter? At the most abstract, if we only focus on eliminating bad stuff, it creates a giant blind spot around ways to increase good stuff. Do you want people to simply be not-hungry and not-sick or do we want everybody to have the capability to build things that do not yet exist at rock-bottom prices and have casual coffee with friends anywhere in the world (or on others)? If we only develop technologies to solve problems, we’re in a sticky situation when the problems change. We have to hope that someone can repurpose a technology that solved a previous problem to address a new issue. mRNA vaccines almost died because they weren’t solving the problem of cancer particularly well before the COVID pandemic. [[Counterfactuals are hard]] but you have to wonder how many dead technologies that didn’t solve a past problem well enough to justify its existence could solve problems today. Framing technology creation in terms of capabilities can be more actionable. It’s hard but straightforward to say “in order to develop this capability, we need to do this work.” (Framing technologies in terms of capabilities is better for roadmapping.) Cancer or climate aren’t going to be *solved* by a single technology, but the problem framework puts technologists between a rock and a hard place — either they’re honest and note that they’re solving a small, obscure problem or they make grand claims that lead to hype and disappointment. Ideally, markets would price in the value of some future capability, but we often don’t know the value of a capability until we have it. If you asked McKinsey to value the capability to create coherent beams of light (ie. lasers) in 1940, they would have come up with a number close to zero. Today, everything from medical devices to the entire global communication system depends on that capability. Isn’t building capabilities what university engineering labs do? There are piles and piles of papers on technologies that never end up getting used — everything from swarm robotics to ==examples==. Most academic engineering *gestures* at capabilities, but usually doesn’t have the incentives to take the technology far enough to be a capability that other people can use.[^1] Obviously, “capabilities” is a nebulous term, but in the way that I’m using it here, a technology doesn’t count as a capability until it can be a component in a bigger system (or is a complete system itself) — this is where most academic work falls short. Of course, focusing on capabilities is the classic trap that many technologists fall into. There are many capabilities that nobody will ever want or aren’t worth the resources to build right now. Overfocusing on capabilities can be a giant waste of resources. The US Government (and especially the military) is one of the few places that focuses on capabilities without asking whether they’re what is really needed, creating a bloat and useless work. The right move is not to focus on capabilities to the exclusion of all else. One reason that Bell Labs and Xerox PARC may have been so exceptional is that they worked on both solving problems and building capabilities. The future value that AT&T expected to get from solar panels certainly didn’t justify their development costs. The public wouldn’t see climate change as a big problem that solar panels could help solve for decades. But they did know that solar panels could solve the problem that it was hard to power satellites that couldn’t be refuelled. I suspect that [Russell Ohl](https://en.wikipedia.org/wiki/Russell_Ohl) could imagine a world where the capability to create energy directly from the sun would be incredibly powerful on Earth, even though eye-wateringly expensive early solar panels weren’t solving any problems in the 1950s era of giant cars and cheap fossil fuels. At [[Speculative Technologies — Spectech]] we’re trying to walk that narrow bridge over the valley of death: developing capabilities that can *one day* be incredibly powerful but aren’t targeting a specific problem. At the same time, we attempt to avoid the failure mode of creating something truly useless by making sure work we do targets a [[Serious Context of Use]] so that our work doesn’t end up on a shelf. [^1]: There is a longer piece about why [[Invention does not belong in academia]] ### Snippets “Is this technology going to create problems?” Yes, As we push the frontier, we’re going to Capabilities give rise to problems that Thinking in terms of capabilities is perhaps a more down-to-earth framing of the fact that [[Technology gives superpowers]] Sometimes I like to think of us as building an “arsenal of humanity” — creating capabilities so that *On the margin* we need more capability development. But isn’t this what [[Phenomena-based cycles]] ### Related * [[Frame programs in terms of capabilities]] * [[What processes can be drastically changed with new manufacturing tools and capabilities?]] * [[‘Solving problems’ is an extremely cartesian paradigm]] * From [[mokyrLeverRichesTechnological1992]] `a problem was defined jointly by a perceived market need and by the state of the art as defined by previous inventions and accumulation of knowledge` in the context of simultaneous invention. * [[Technology push and technology pull]]