Quick Navigation
- Start here — Why scanning matters
- What to scan
- The technology radar
- Separating hype from opportunity
- Connecting scanning to strategy
- Governance of emerging technology
- Building a scanning practice
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Technology moves faster than most organisations can absorb. Not everything new is relevant — the skill is filtering hype from genuine opportunity. I've seen organisations discover technology shifts only when a competitor has already adopted them or when a vendor announces EOL. By then, the response is rushed, expensive, and poorly designed.
Scanning = filtering signal from noise — structured process with sources, cadence, evaluation criteria, and decision outcomes. If scanning doesn't change decisions, stop doing it.
Scanning isn't reading tech blogs. It's a discipline — monitor what's coming, evaluate rigorously, place technologies on a radar, and connect every placement to an investment or governance decision.
Keep it in mind.
1. Why scanning matters — The cost of being surprised by technology shifts
Most organisations discover technology shifts only when a competitor has already adopted them or when a vendor announces EOL. By then, the response is rushed, expensive, and poorly designed. The cost of being surprised is always higher than the cost of scanning.
Without scanning, every technology shift becomes a crisis:
flowchart TD
SHIFT["⚡ Technology Shift"] --> NO_SCAN["❌ Without Scanning\nDiscover late\nPanic response\nRushed adoption"]
SHIFT --> WITH_SCAN["✅ With Scanning\nSee it early\nDeliberate response\nPlanned transition"]
NO_SCAN --> COST_H["High Cost\nPoor design\nCompetitive disadvantage\nForced migration"]
WITH_SCAN --> COST_L["Low Cost\nWell-designed\nCompetitive advantage\nSmooth transition"]
The cost of surprise:
| Scenario | Without scanning | With scanning |
|---|---|---|
| Competitor adopts new technology | Panic adoption — rushed, poorly designed | Already evaluated — deliberate response |
| Vendor announces EOL | Crisis migration — unplanned cost | Already planned — smooth transition |
| New paradigm emerges (e.g., AI agents) | Confusion — "what do we do?" | Already trialled — know what works |
| Regulation changes | Compliance gap — reactive | Already designed in — proactive |
The scanning value chain: Monitor — track sources systematically. Raw signal list. Filter — apply relevance criteria. Shortlist of technologies. Evaluate — assess against strategy and risk. Technology assessments. Decide — adopt, trial, assess, or hold. Radar placements. Act — fund pilots, update standards, plan migrations. Investment decisions.
Lead time economics: Without scanning — technology shift discovered at competitor launch. 0 months lead time → panic adoption → 18 months to catch up. Cost: 3x normal adoption cost (rushed, rework, poor design). With scanning — technology shift discovered 12 months early. 12 months lead time → deliberate evaluation → 6 months to adopt. Cost: 1x normal adoption cost (planned, well-designed).
The ROI of scanning isn't just cost avoidance — it's competitive positioning. The organisation that sees shifts first adapts first.
Scanning creates lead time — don't wait to be surprised.
Try it yourself — The surprise audit
When was the last time your organisation was surprised by a technology shift?
| Scenario | What happened | Cost | Could scanning have prevented it? |
|---|---|---|---|
If you can name two or more, you need a scanning practice.
2. What to scan — Sources, signals, and how to structure the horizon
Without a structure for what to scan, teams either scan randomly (whatever catches their eye) or not at all. Random scanning produces random results — a collection of interesting articles with no decision value.
Structure scanning across three horizons and five source types:
flowchart TD
SCAN["📡 What to Scan"] --> HORIZON["🗓️ Three Horizons"]
SCAN --> SOURCES["📚 Five Source Types"]
HORIZON --> H1["H1: Now\n0-6 months\nReady for adoption"]
HORIZON --> H2["H2: Next\n6-18 months\nMaturing rapidly"]
HORIZON --> H3["H3: Later\n18-36 months\nEarly signals"]
SOURCES --> S1["Industry analysts"]
SOURCES --> S2["Academic research"]
SOURCES --> S3["Vendor roadmaps"]
SOURCES --> S4["Community / OSS"]
SOURCES --> S5["Internal experiments"]
H1 --> DECIDE["Decisions\nNot just information"]
H2 --> DECIDE
H3 --> DECIDE
Three horizons:
| Horizon | Timeframe | What to look for | Action |
|---|---|---|---|
| H1: Now | 0-6 months | Technologies ready for adoption | Evaluate for standards |
| H2: Next | 6-18 months | Technologies maturing rapidly | Trial and assess |
| H3: Later | 18-36 months | Emerging signals, early-stage | Monitor and learn |
Five source types:
| Source type | Examples |
|---|---|
| Industry | Gartner, ThoughtWorks Technology Radar, InfoQ |
| Academic | arXiv, conference proceedings, research labs |
| Vendor | Vendor roadmaps, release notes, beta programmes |
| Community | Open source projects, developer forums, meetups |
| Internal | Team experiments, proof of concepts, hackathons |
Not all signals are equal. Evaluate signal quality before investing in evaluation: Strong signal — multiple independent sources, clear trajectory, major vendor backing. Evaluate now. Medium signal — some sources, emerging community, unclear trajectory. Monitor closely. Weak signal — single source, early-stage, speculative. Monitor passively. Noise — marketing hype, no substance, no independent validation. Ignore.
Use multiple sources — no single source is reliable alone.
Three horizons (Now, Next, Later) + five source types = structured scanning — not random blog reading.
Try it yourself — The source check
Which of these sources are you currently scanning?
| Source type | Currently scanning? | Gap |
|---|---|---|
| Industry analysts | ||
| Academic research | ||
| Vendor roadmaps | ||
| Community / OSS | ||
| Internal experiments |
If you're only using one or two, your scanning is incomplete.
3. The technology radar — Building, maintaining, and communicating one
Technology assessments that live in documents nobody reads have no impact. Teams need a shared vocabulary and a visual tool to communicate technology position — what to adopt, what to trial, what to watch, and what to avoid.
The technology radar (popularised by ThoughtWorks) is a visual tool for communicating technology position:
flowchart TD
RADAR["🎯 Technology Radar"] --> RINGS["💍 Four Rings\nAdopt · Trial · Assess · Hold"]
RADAR --> QUADS["📐 Four Quadrants\nTechniques · Platforms\nTools · Languages"]
RADAR --> VELOCITY["⚡ Adoption Velocity\nHow fast is it moving\nthrough the rings?"]
RINGS --> ADOPT["Adopt\nProven, recommended\nUse as standard"]
RINGS --> TRIAL["Trial\nWorth pursuing\nPilot in 1-2 teams"]
RINGS --> ASSESS["Assess\nWorth exploring\nResearch and experiment"]
RINGS --> HOLD["Hold\nProceed with caution\nDo not start new"]
VELOCITY --> FAST["Fast Velocity\nRapidly moving to Adopt\nHigh strategic urgency"]
VELOCITY --> SLOW["Slow Velocity\nStuck in Assess\nMay not be worth it"]
Rings (adoption readiness):
| Ring | Meaning | Action |
|---|---|---|
| Adopt | Proven, recommended for production use | Use as standard |
| Trial | Worth pursuing, limited production use | Pilot in 1-2 teams |
| Assess | Worth exploring, understand potential | Research and experiment |
| Hold | Proceed with caution, do not start new | Migrate away if possible |
Quadrants (technology categories):
| Quadrant | What it covers |
|---|---|
| Techniques | Architecture patterns, practices, methodologies |
| Platforms | Infrastructure, cloud, runtime platforms |
| Tools | Development tools, CI/CD, observability |
| Languages & Frameworks | Programming languages, frontend/backend frameworks |
Adoption Velocity — measuring momentum: Adoption Velocity measures how quickly technologies are moving from assess to trial to adopt. It's calculated by tracking ring changes over time.
| Velocity | What it means | Implication |
|---|---|---|
| Rapid | Moved 2+ rings in 2 quarters | High urgency — evaluate immediately |
| Steady | Moved 1 ring in 2 quarters | Normal cadence — follow the process |
| Stalled | No movement in 2+ quarters | Question relevance — why is it stuck? |
| Declining | Moved backwards (e.g., Adopt → Trial) | Risk signal — investigate why |
Building a radar: Gather — collect technologies from scanning sources. Evaluate — assess each against strategy, risk, and readiness. Place — assign to ring and quadrant. Measure velocity — track ring changes over time. Communicate — share with teams — quarterly update. Act — move technologies between rings as they mature or decline.
The radar = Adopt / Trial / Assess / Hold + Adoption Velocity — a shared vocabulary for technology position and momentum.
Try it yourself — The radar draft
Take three technologies your organisation uses or is evaluating. Where would you place them?
| Technology | Ring | Quadrant | Velocity |
|---|---|---|---|
If you can't place them, you don't have a radar. You have opinions.
4. Separating hype from opportunity — How to evaluate emerging technologies rigorously
Every new technology arrives with a wave of hype — conference talks, vendor marketing, social media excitement. Following hype leads to wasted investment. Ignoring everything leads to missed opportunities. The skill is evaluating rigorously at the right moment.
The Gartner Hype Cycle describes the typical trajectory of emerging technologies:
flowchart LR
TRIGGER["🚀 Innovation\nTrigger"] --> PEAK["📈 Peak of\nInflated\nExpectations"]
PEAK --> TROUGH["📉 Trough of\nDisillusionment"]
TROUGH --> SLOPE["📈 Slope of\nEnlightenment"]
SLOPE --> PLATEAU["✅ Plateau of\nProductivity"]
PEAK -.->|"Do NOT adopt\nhere — max hype"| DANGER["⚠️ Danger zone\nUnrealistic promises"]
TROUGH -.->|"Best time to\nEVALUATE"| OPPORTUNITY["💡 Opportunity\nHype gone, reality clear"]
PLATEAU -.->|"Safe to\nADOPT"| SAFE["✅ Safe zone\nProven, mainstream"]
Hype cycle stages:
| Stage | What happens | Architect's response |
|---|---|---|
| Innovation Trigger | New technology appears; excitement spikes | Monitor — don't adopt |
| Peak of Inflated Expectations | Maximum hype; unrealistic promises | Assess — evaluate critically |
| Trough of Disillusionment | Hype fades; real problems emerge | Best time to evaluate — hype is gone, reality is clear |
| Slope of Enlightenment | Real use cases emerge; practical value | Trial — pilot with real use cases |
| Plateau of Productivity | Mature, proven, mainstream | Adopt — if it fits strategy |
The evaluation criteria:
| Criterion | Question |
|---|---|
| Strategic fit | Does this support our business strategy? |
| Maturity | Is this production-ready or still experimental? |
| Community | Is there an active community and ecosystem? |
| Talent | Can we hire or develop skills for this? |
| Risk | What's the blast radius if it fails? |
| Alternative | Is there a proven alternative that works? |
Hype detection checklist — red flags: Vendor-only narrative — "Only our product does this." No failure stories — "Everyone who tries it succeeds." Buzzword density — every sentence has 3 buzzwords. No production references — "We have great demos" (no production deployments). Unrealistic timelines — "Adopt in 2 weeks, transform in 2 months."
Green flags: Multiple independent sources — different people, different contexts, same conclusion. Failure stories available — "Here's what went wrong and how we fixed it." Production references — "Running in production for 12 months at scale." Clear limitations — "Here's what it does NOT do well." Realistic timelines — "Expect 6 months to production maturity."
Evaluate at the Trough of Disillusionment — hype is gone, reality is clear.
Try it yourself — The hype check
Take a technology you're currently evaluating. Run it through the hype check:
| Red flag | Present? | Green flag | Present? |
|---|---|---|---|
| Vendor-only narrative | Multiple independent sources | ||
| No failure stories | Failure stories available | ||
| Buzzword density | Production references | ||
| No production references | Clear limitations | ||
| Unrealistic timelines | Realistic timelines |
If red flags outnumber green flags, you're evaluating hype, not opportunity.
5. Connecting scanning to strategy — How horizon intelligence becomes investment decisions
Many organisations run scanning exercises that produce reports nobody acts on. Scanning that doesn't change decisions is just reading. The gap between "interesting technology" and "funded initiative" is where scanning dies.
Scanning outcomes must connect to a decision chain that ends in investment or action:
flowchart LR
SCAN["📡 Scan\nSources + Signals"] --> EVAL["🧐 Evaluate\nCriteria + Scoring"]
EVAL --> PLACE["🎯 Place\nRing + Quadrant"]
PLACE --> DECIDE["⚖️ Decide\nAdopt / Trial\nAssess / Hold"]
DECIDE --> FUND["💰 Fund\nInvestment\nor Pilot budget"]
FUND --> MEASURE["📊 Measure\nOutcomes\n+ Velocity"]
BREAK1["❌ Chain breaks here\nNo evaluation"] -.-> SCAN
BREAK2["❌ Chain breaks here\nNo decision"] -.-> PLACE
BREAK3["❌ Chain breaks here\nNo funding"] -.-> DECIDE
Scanning-to-strategy mapping:
| Scanning output | Strategy action |
|---|---|
| "Technology X is ready for adoption" | Add to standards register |
| "Technology Y is worth trialling" | Fund a pilot |
| "Technology Z is emerging" | Monitor; assign to team for learning |
| "Technology W is declining" | Plan migration; deprecate |
The decision framework:
| Radar placement | Velocity | Decision | Funding |
|---|---|---|---|
| Adopt | Steady or Rapid | Standardise | Include in platform budget |
| Trial | Steady | Pilot | Pilot budget (3-6 months) |
| Trial | Rapid | Accelerate pilot | Increased pilot budget |
| Assess | Any | Learning budget | 10-20% time or hackathon |
| Hold | Declining | Migration budget | Deprecation planning |
The investment decision tree: Technology placed on radar → Adopt ring → Velocity: Steady → Standardise in next budget cycle. Velocity: Rapid → Accelerate — immediate budget reallocation. Trial ring → Strategic fit: High → Fund pilot (dedicated team, 3-6 months). Strategic fit: Low → Monitor only — no funding. Velocity: Rapid → Increase pilot scope. Assess ring → Multiple signals → Fund learning (hackathon, 20% time). Single signal → Monitor passively. Hold ring → Currently in use → Fund migration. Not in use → Document rationale, revisit in 6 months.
Track scanning investments as a portfolio, not individual bets: Adopt — standardisation — 60% of tech budget. Trial — pilots — 25% of tech budget. Assess — learning — 10% of tech budget. Hold — migration — 5% of tech budget. If >70% is in Adopt, the organisation isn't scanning enough. If >40% is in Assess, the organisation isn't deciding enough.
Scanning → Radar → Decision → Investment. If the chain breaks, scanning is wasted.
Try it yourself — The chain check
Where does your scanning chain break?
| Link in chain | Working? | If not, why? |
|---|---|---|
| Scanning → Evaluation | ||
| Evaluation → Radar placement | ||
| Radar placement → Decision | ||
| Decision → Investment |
If any link is broken, your scanning isn't changing decisions.
6. Governance of emerging technology adoption — How to experiment without creating chaos
If every new technology requires full governance review, teams stop experimenting. If no governance applies, teams adopt anything and create a fragmented landscape. The answer is tiered governance — match the rigour to the maturity.
Emerging technologies need different governance than established standards:
flowchart TD
GOV["🏛️ Tiered Governance"] --> EXP["🧪 Experiment\nH3 — Emerging\nNo governance\nLearn freely"]
GOV --> TRIAL["🔬 Trial\nH2 — Maturing\nLightweight\nPilot scope, review"]
GOV --> ADOPT_FULL["✅ Adopt\nH1 — Ready\nFull governance\nStandards, exceptions"]
EXP --> RULES_EXP["Rules:\nDefined scope + timeline\nNo production impact\nDocument learning"]
TRIAL --> RULES_TRIAL["Rules:\nPilot scope defined\nReview outcomes\nSuccess criteria set"]
ADOPT_FULL --> RULES_ADOPT["Rules:\nStandards register\nException process\nCompliance required"]
Governance tiers:
| Governance level | Technology maturity | What governance applies |
|---|---|---|
| Experiment | H3 — emerging | No governance — learn freely |
| Trial | H2 — maturing | Lightweight — pilot scope, review outcomes |
| Adopt | H1 — ready | Full governance — standards, exceptions |
Rules for experimentation: Defined scope and timeline — experiments end — they don't become permanent. No production impact — experiments are safe — no customer risk. Documented learning outcome — learning is preserved whether it succeeds or fails. Success → progress to trial — clear path from experiment to adoption. Failure → documented — failed experiments are valuable — don't lose the learning.
Rules for trials: Pilot scope defined — 1-2 teams, specific use case, not everything. Success criteria set — know what "success" means before starting. Review outcomes — formal review at end of pilot. Go/no-go decision — trial leads to Adopt or Hold — not indefinite.
The governance escalation model: Experiment (no governance) → Success → Trial (lightweight governance) → Success → Adopt (full governance) → Declining → Hold (migration governance). At each transition: increase documentation requirements, increase review frequency, increase compliance scope, decrease freedom to deviate.
Anti-patterns: Governance-free zone — "Experiments never end." Fix: define timeline; review at end. Governance creep — "Every experiment needs a committee." Fix: keep it lightweight — one sponsor, one objective. Orphan experiments — "Nobody documented what we learned." Fix: require learning documentation as exit criteria. Shadow adoption — "We experimented in production." Fix: experiments must not affect production.
Govern less for experiments, more for adoption. Let teams explore; govern what goes to production.
Try it yourself — The governance check
What governance applies to your current technology experiments?
| Experiment | Governance level | Rules in place? |
|---|---|---|
If everything is at the same level, you're not tiering governance.
7. Building a scanning practice — Who does it, how often, and what it produces
Scanning done as a one-time exercise produces a snapshot that's outdated within weeks. Scanning must be a practice — assigned to people, on a cadence, producing regular outputs that drive decisions.
A scanning practice has five elements — who, cadence, inputs, outputs, and communication:
flowchart TD
PRACTICE["🏗️ Scanning Practice"] --> WHO["👤 Who\n1-2 architects\n20% time allocation"]
PRACTICE --> CADENCE["📅 Cadence\nMonthly source review\nQuarterly radar update"]
PRACTICE --> INPUTS["📥 Inputs\nIndustry + Vendor\nCommunity + Internal"]
PRACTICE --> OUTPUTS["📤 Outputs\nRadar + Recommendations\nAction items"]
PRACTICE --> COMMS["📢 Communication\nShare with all teams\nQuarterly town hall"]
WHO --> HEALTH["✅ Healthy Practice\nDecisions change\nTeams consult radar\nBoard informed"]
CADENCE --> HEALTH
INPUTS --> HEALTH
OUTPUTS --> HEALTH
COMMS --> HEALTH
Practice elements:
| Element | What to establish |
|---|---|
| Who | 1-2 architects with scanning as part of their role |
| Cadence | Quarterly radar update; monthly source review |
| Inputs | Industry sources, vendor updates, team experiments |
| Outputs | Technology radar, recommendations, action items |
| Communication | Share radar with all teams — quarterly town hall |
The scanning health check:
| Dimension | Healthy | Unhealthy |
|---|---|---|
| Cadence | Quarterly update | Last update >6 months ago |
| Coverage | All four quadrants covered | Only one quadrant scanned |
| Action | Radar changes lead to decisions | Radar is published but ignored |
| Participation | Teams contribute observations | Only architects scan |
| Velocity tracking | Ring changes measured over time | No tracking of technology momentum |
Assign scanning to 1-2 people, quarterly cadence, radar as output, decisions as outcome — make it a practice, not a one-time exercise.
Try it yourself — The practice check
Do you have a scanning practice?
| Element | In place? | Gap |
|---|---|---|
| Who | ||
| Cadence | ||
| Inputs | ||
| Outputs | ||
| Communication |
If fewer than three are in place, you don't have a practice. You have an ad-hoc activity.
Putting it all together
Here's the complete picture in one diagram. This is the mental model worth internalising.
flowchart TD
PROBLEM["⚡ Technology Surprise\nOrganisations discover shifts\ntoo late — panic response"]
SOLUTION["🔍 Scanning Practice\nMonitor · Filter · Evaluate\nDecide · Act"]
TOOLS["🎯 Tools\nTechnology Radar\nAdoption Velocity\nHype Evaluation"]
GOVERN["🏛️ Governance\nTiered by maturity\nExperiment → Trial → Adopt"]
PROBLEM --> SOLUTION
SOLUTION --> TOOLS
SOLUTION --> GOVERN
TOOLS --> OUTCOME["✅ Outcome\nLead time gained\nDecisions informed\nCompetitive advantage"]
GOVERN --> OUTCOME
The foundation:
Scanning creates lead time — don't wait to be surprised by technology shifts. If you discover a shift when your competitor has already adopted it, you're too late. Evaluate at the Trough of Disillusionment — hype is gone, reality is clear. Don't adopt at the peak of hype. Wait for reality. Scanning is only valuable if it changes decisions. If scanning doesn't lead to Adopt/Trial/Assess/Hold decisions, stop doing it. Scanning = filter signal from noise — only valuable if it changes decisions.
Cheat Sheet — All the key terms
| Concept | One-Line Memory | Key Action |
|---|---|---|
| Scanning | Filter signal from noise | Structured process, not blog reading |
| Horizons | Now (0-6m), Next (6-18m), Later (18-36m) | Scan all three |
| Technology Radar | Adopt / Trial / Assess / Hold | Shared vocabulary for technology position |
| Adoption Velocity | Measures ring-change speed | Track momentum, not just position |
| Hype cycle | Evaluate at the Trough | Don't follow hype |
| Strategy connection | Scanning → Decision → Investment | Chain must not break |
| Governance | Light for experiments, full for production | Match governance to maturity |
| Practice | Quarterly cadence, assigned people | Make it ongoing |
How to know if this landed
You'll know this has landed when someone stops discovering technology shifts when competitors have already adopted them. Can explain the three horizons (H1, H2, H3) and what action each requires. Technology radar exists and is updated quarterly — not a one-time exercise. Adoption Velocity is tracked — know which technologies are accelerating. Evaluation criteria are defined — weighted scorecard, not gut feel. Scanning outputs connect to decisions — radar changes lead to investment or deprecation. Governance is tiered — experiments are lightweight, adoptions are full governance. And scanning practice is assigned — 1-2 architects with 20% time, quarterly cadence.
What changes when the mental model clicks
I've run this session with an insurance company where a competitor launched AI-powered claims processing — 10x faster. Company had no scanning practice — discovered the shift 18 months late. Rushed AI adoption — poor quality, no governance, expensive mistakes. The gap at the start is usually not about understanding scanning — it's about not having a structured practice.
What changes after this session:
Teams stop being surprised by technology shifts and start seeing them early. The technology radar exercise — "place your technologies in rings and quadrants" — is always the moment things click. People stop treating scanning as blog reading and start treating it as a decision-changing practice. Their results get better. They stop adopting at the peak of hype when the real problem was that they hadn't learned to evaluate at the Trough.
The scanning-to-strategy mapping exercise tends to immediately change how teams think about their scanning outputs. They start connecting radar placements to investment decisions. Their clarity goes up. They stop producing reports nobody acts on when the real problem was that the chain between scanning and investment was broken.
Book a Workshop
Ready to build a scanning practice that keeps you ahead of technology shifts?
or
Half-day workshop includes scanning practice design — who, what, when, how, technology radar creation — build your first radar with real technologies, Adoption Velocity measurement — track technology momentum through the radar, hype vs signal evaluation — apply criteria to current emerging technologies, strategy connection — link scanning outputs to investment decisions, governance tiers — design experiment, trial, and adoption governance, and technology radar template (including Adoption Velocity metric) + horizon scanning process + hype vs signal evaluation criteria.