I Trained as a Futurist for 5 Weeks. Technologists Should Steal This.

7 moves for the technology decisions that cost the most to get wrong.

Jun 16, 2026

Futurists do not predict the future. That is lesson one for technologists.

In 1876, Alexander Graham Bell’s financial backers offered his telephone patent to Western Union, the telegraph giant that then ran the dominant long‑distance communications network. The asking price was a reported price of $100,000. Western Union’s president, William Orton, turned it down. By one account he asked what use the company could possibly make of an electrical toy. Within a few years that patent became one of the most valuable ever granted, and the company that owned the wires had handed the future to a competitor.

The people closest to the technology were the worst placed to see where it would go. That distance, between knowing how something works today and seeing where it travels next, is what foresight is built to close. I spent 5 weeks learning how to close it, across 5 weekly sessions, on the University of Houston Professional Certificate in Foresight. I went in as a working enterprise architect with over 15 years in technology behind me, not a futurist by trade, and I came out with a different way of making the decisions that matter most in my work.

What follows are 7 of those moves. None of them needs a crystal ball. All of them change how a technologist decides, and they matter most on exactly the decisions technologists are trained for least: the long-horizon ones, where being wrong is expensive and slow to show up.

1. Foresight runs on evidence, not just imagination

The first thing that surprised me was how little of the work involved imagination.

Foresight is a research pipeline. On the Houston Framework Foresight method, a project starts by collecting hundreds of signals of change from the real world, narrows them into a smaller set of trends, then clusters those into several forces driving the domain, and only then builds around 4 scenarios on top of them. The modern scenario method was developed at the RAND Corporation in the 1950s by Herman Kahn, a physicist and systems theorist who used it to think through nuclear strategy. The discipline grew out of hard analysis, with no crystal ball anywhere in sight.

That matters for technologists because most of us dismiss futures work as guesswork and never adopt it. Treat it instead the way you would treat any evidence pipeline you already trust. The signals are sourced and dated. The drivers are defended. The scenarios trace back to the data that produced them. Once you see the method as research, the objection that it is fluffy stops holding.

2. Stop predicting 1 future. Build for 4.

The biggest shift the course asked of me was to stop backing a single story about what comes next.

Many technologists are trained to produce a single target state. We draw the 2030 architecture, write the roadmap that reaches it, and treat that as the plan. The Houston method builds 4 futures instead: a baseline where today’s trajectory continues, and 3 alternatives where the rules change, settle into a new balance, or break down entirely. My class project looked at the impact of automation on the workforce in Canada out to 2035. The same domain produced very different worlds. In the baseline, which we called The Augmented Workforce, AI mostly augments people and the friction is about reskilling and access. In the transformation scenario, The Intelligent Society, integration becomes irreversible and work shifts from routine tasks to creativity and judgment.

Building the 4 worlds taught me something a single forecast would have hidden. In every version, the force that decided how the world turned out was the same. Trust in the AI mattered more than how advanced the AI became. We had been calling it a technology question. The futures showed it was a trust question. That is the value of the exercise. It shows you what your roadmap is quietly betting on, before you commit.

3. Match your time horizon to how fast your field changes

Before you forecast anything, the course makes you decide how far out to look, and the answer depends on the thing itself.

A computer chip generation turns over in around 18 months. A car platform typically runs 5 to 7 years, with major updates about every 3 to 5. An oil platform lasts 30 years or more. Set the same time horizon for all 3 and you will plan badly for at least 2 of them. Foresight forces you to pick the horizon deliberately, then split it into 3 stages: the near term you can largely see, the middle-to-long term where most of the change happens, and the long term you are steering towards. For the automation project we set the present to 2030 as the near term, 2030 to 2035 as the middle, and 2035 onward as the horizon we were really designing for.

Most technology roadmaps skip this step. They default to a 3-year window because that is how the budget cycle runs, then apply it to decisions that live on a completely different clock. A 3-year horizon is wrong for a data platform you expect to run for 15 years, and it is wrong for an AI capability that may be unrecognisable in 18 months. Choose the horizon from the lifespan of what you are building. The planning calendar is the wrong place to start.

4. See the whole system, not the parts

Peter Bishop, one of the programme’s founders, has called systems thinking the lens through which futurists see the world. It became the most useful habit I took away.

Engineers are trained to break a problem into parts, fix each part, and assume the whole improves. Systems thinking works the other way. It looks at the whole first, at how the parts connect, and at the loops where one thing feeds another. Donella Meadows described a system as a set of things connected so they produce their own behaviour over time. The behaviour comes from the structure. As the quality-improvement pioneer Paul Batalden put it, every system is perfectly designed to get the results it gets. When you map the automation domain as a system, you stop seeing a list of technologies and start seeing why the outcomes keep happening: the feedback between reskilling, trust, and adoption that no single component controls.

For a technologist this is a direct warning. Optimise a single service, platform, or team in isolation and you can easily make the whole worse, because the parts are connected in ways the component view cannot see. Map the system and its loops before you redesign any piece of it. The map is what tells you which change actually moves the outcome and which one just moves the problem somewhere else.

5. Your expertise is hiding the future from you

The hardest discipline in the course was scanning for weak signals, and the hardest part of that was getting out of my own way.

A weak signal is an early, faint sign of change, and the course is blunt about where these come from. They almost always start outside mainstream expertise, in the work of people who are not the recognised authorities and not publishing in the respected journals. The instinct of an expert is to filter those out. The futurist’s discipline is to hold space for them. The signal that stayed with me from my own scanning came from outside enterprise architecture entirely: a product-management writer, Marty Cagan, describing how AI tools could act like a kind of personal coach for product teams. What made it sharp was that Cagan, long a champion of human mentoring, was openly reconsidering how far AI could go as a coaching tool. Even the expert was loosening his grip on his expertise.

There is a long history here. When Bell filed his telephone patent, his rival Elisha Gray lost the race partly because, as historian David Hounshell has argued, Gray’s deep expertise in telegraphy became a disadvantage. He was so deep in the telegraph business that he could not see what the telephone would become. The more you know about your field, the more your knowledge filters what you let yourself take seriously. Build your scanning to reach deliberately outside your discipline, because the signal that matters will rarely be wearing your job title.

6. Separate the adaptive problem from the technical one before you build

Late in the course we drew a line I now use on every brief: the line between a technical problem and an adaptive one.

Ron Heifetz and Marty Linsky set out the distinction. A technical problem can be solved with knowledge you already have, even when it is hard. An adaptive problem needs new learning, a change in how people think or behave, and no existing expertise will crack it. Their warning is that organisations have a strong bias to treat adaptive problems as technical ones, because technical problems are more comfortable to work on. Automation is the clearest example I came across in the whole course. Governments keep responding to it as a technical problem, mostly by funding reskilling platforms and tools. The harder, adaptive truth underneath is that automation forces a society to renegotiate what work is for, and how people find purpose and security in it. No platform solves that.

The same trap catches technologists constantly. We reach for a tool, a platform, or a re-architecture when the real challenge is that people need to learn something new or let something go. Diagnose the nature of the problem first. If it is technical, your expertise will handle it. If it is adaptive, the tool will not, and the work is to help people through the change instead. Spending a fortune building the wrong kind of solution is what happens when you skip the diagnosis.

7. Decide now what will tell you which future is arriving

The final move turns foresight from a one-off workshop into something that keeps earning its place. You decide in advance what would tell you which future is coming true.

For each scenario you built, you name a small set of indicators, the events or numbers that would signal this particular world is materialising. Then you watch them. If you built a future where trust in AI collapses, you decide today what the early evidence of that would look like, so you are not guessing about it in 2 years’ time. This is what stops a foresight exercise from going stale on a shelf. The scenarios stay live because you are tracking the signals that tell you which one is winning.

Technologists already understand this instinct from monitoring and alerting in production systems. The same idea applies to strategy. Attach indicators and trigger conditions to your big architecture bets, and review them on a regular cadence. When an indicator fires, you do not have to start the analysis from scratch, because you decided what it meant before the pressure was on. That is the difference between a roadmap you defend out of habit and one you can change on evidence.

What this adds up to

Put these together and foresight gives a technologist something our training mostly leaves out: a disciplined way to decide when you cannot be certain. We are taught to engineer answers where the requirements are known. Foresight is the method for the decisions where they are not, and those are the decisions that shape an enterprise for a decade and cost the most to get wrong.

William Orton had the better technology and the larger company. He ran the network the whole country depended on. He still handed the future to a competitor, because he had no method for seeing past the present, and he judged the telephone by what it was on the day rather than what it was becoming. The 7 moves above are, in the end, a method for not being Orton.

If you are making a long-horizon technology decision right now, which of the 7 is your team weakest at: treating foresight as guesswork, backing a single future, setting the wrong horizon, optimising in isolation, scanning only your own field, mistaking an adaptive problem for a technical one, or never deciding what would tell you the plan is wrong?

I write about foresight and enterprise design in my newsletter, The Foresight-Driven Enterprise. If this was useful, that is where I go deeper.

The Foresight-Driven Enterprise

Discussion about this post

Ready for more?