Developing Capabilities and Solving Problems
Talking Big Ideas.
This week’s guest columnist is Ben Reinhardt, the founder of Speculative Technologies.
A couple of years back, when Maryrose and I sat down to make a list of the people we most wanted to work with, Ben was at the top of our list. His projects are fascinating and fill a needed gap in the research world.
Today, I’m honored to call Ben a client and a friend.
Subscribe to Ben’s newsletter here.
At Speculative Technologies we’re trying to walk that narrow bridge over the valley of death: developing technology capabilities that can one day be incredibly powerful while avoiding creating something that will never be useful. These technologies are speculativein large part because many of them aren’t targeting a specific problem.
Creating capabilities that don’t address an immediate problem while still setting them on a trajectory to solve a problem is incredibly hard. Most organizations resolve this tension by only justifying work as the solution to clear problems. While valuable, thinking of technology creation only as a solution to problems is clearly incomplete and may be getting us stuck at local optima.
This piece will briefly unpack why thinking of technology as solutions to problems is limiting and how Speculative Technologies is focusing on creating capabilities with a serious context-of-use instead.
Many of us 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! Technology should be useful (in the broadest sense) and solving a problem is always useful. In order for a technology to be useful, people need to use it, but adopting new technologies is hard. The bigger the problem a new technology can solve, the more incentive people have to adopt it. But the framework is incomplete.
It feels strained to say that Henry Ford solved the problem that people couldn’t move over land faster than horses. Or that Apple solved the problem that people couldn’t carry the internet in their pockets. Or that telephones solved the problem that people couldn’t communicate in real time without being in the same room. The list of technologies that didn’t solve a problem except in retrospect is long.
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.
Capabilities are not just solutions in disguise: it is substantively different to make something that makes people not-sick and not-sad versus something that makes people healthy and happy. Solving problems implies some baseline that you’re trying to get to. Creating capabilities raises that baseline, often in ways unimaginable before they were created. It’s the difference between making people not-hungry and not-sick (which is important!) and giving people the capability to build things that do not yet exist at rock-bottom prices while having casual coffee with friends anywhere in the world (or on others)?
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.
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. Jensen Huang, the CEO of NVIDIA, has a quip that “every $1 trillion business starts in a $0 billion market.” 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 new battery chemistries. 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. 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 refueled. I suspect that 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 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.
Unlocking the future requires new capabilities for humanity. Creating those capabilities involves walking a narrow line between expansive uselessness and narrow problems. It’s tempting to only work on technologies that could clearly solve big problems if successful. That work is easy to justify and both supporters and technologists can feel good that they were tackling something important, even if it doesn’t work out. Tackling big problems is important, but we’ve overindexed on this problem-solution framework, limiting the possibilities we can explore. However, without a clear problem, it’s easy to waste time and resources pursuing useless garbage!
Our job at Speculative Technologies is to sit with that discomfort and continually refine our heuristics that should apply to doing work in that murky middle.
Thanks to Tim Hwang and Eli Dourado for feedback on this post!
If you’d like to read more from Ben, subscribe to his newsletter.
