The Technology Radar is a living document to assess the risks and rewards of existing and nascent technologies in an organization. It allows us to visualize the breadth of technology we use and to get opinionated on which technologies we should be either converging on, or moving away from.

Examples of companies with public Tech Radars:

Reasons to have a Technology Radar

  1. Balancing risk vs. adoption: each technology has an ideal location on the innovation curve of your organization, balancing risk vs. reward. The radar is a snapshot in time, showing where each technology lies on your adoption curve and helping you to manage risk.
  2. A platform for continual analysis: once you have a framework, it becomes easier to repeat the process. Technology never stands still, so you must re-evaluate it constantly or risk falling behind. A good cadence is to update the technology radar twice a year.
  3. Bottom-up alignment: most organizations have no feedback loop from the people who use technology to the people who choose it. A technology radar is a blame-free tool that allows all consumers of technology to reflect back their opinions. Having a public stance on the current and future state of technology in your organization creates alignment and allows for more intelligent decision making and planning.

What to include?

The radar acts as an overview of the technologies that everyone should know about in your organization. It can cover open-source, commercial and home-grown technologies.

Since it is impractical to include everything, you must agree on a number (typically 100) and pick the N most impactful technologies. Ask the following questions to consider the impact of each technology:

  • Is it likely to impact multiple teams? (Alignment)
  • Is it a significant commitment or investment? (Risk)
  • Is it something everybody should look into? (Reward)

Structure

Technologies in the radar are organized into four quadrants, and then into four rings. The quadrants represent different categories of technologies, while the rings reflect their stage of adoption.

Tech Radar Structure

Quadrants

  • Languages & Frameworks: programming languages and development frameworks.
  • Tools: components such as databases; development tools such as Webpack and Bazel.
  • Platforms & Services: infrastructure platforms and services, both external and internal.
  • Techniques: processes, methods and patterns concerning development and operations, such as mob programming, microservices, GitOps, canary releases, game days, etc.

Rings

  • ADOPT: We have experience and trust in this technology. There is no doubt that it is proven and mature for use. For a particular use case, we see this as the best choice.
  • TRIAL: Recommended for use on a trial basis. Not completely proven. More experience needed.
  • ASSESS: We see a lot of potential in this technology, but it needs more research and validation.
  • HOLD: Avoid if possible. Flawed or not mature enough. There are better alternatives now.

Creation Process

This process was designed for distributed teams. All steps can be done online and, for the most part, asynchronously. Only the workshop (step 5) requires everyone in a call at the same time.

Step 1: Advisory Board

The first step is to form the Advisory Board that will create the radar. This group should represent as wide a range as possible of technology leaders within your organization. Instead of selecting only your top people, give space for diversity; and, to keep things manageable, limit the size to 20 people.

Step 2: Survey

The next step is to ask all board members for input on which technologies should be included on the radar, where to place them and why. A good way to do this is by sharing a Google Sheets document with four columns:

  1. Technology
  2. Quadrant (Technique, Tools, Platforms & Services, Languages & Frameworks)
  3. Ring (Adopt, Trial, Assess, Hold)
  4. Reasons to include this / Rationale for ring choice / Comments

Consider sharing a single Google Sheets document between all board members—with a sheet named after each participant—so that everyone can see all suggestions in real time and have discussions. Give the group one or two weeks to provide their input and then move on to the next step.

Step 3: Aggregation

One person (the chair of the board) should be responsible for combining the results of the survey into a consistent whole. This means deduplicating entries, reviewing quadrants, and keeping note of rings, comments, and who nominated each technology, in preparation for the workshop.

If the survey ends up with more entries than can be discussed in the workshop, the chair is also responsible for coordinating with the group to trim down the list to a manageable size.

Step 4: Initial Votes

In steps 4 and 5, the board decides which technologies to exclude, which to include, and where to place them on the radar. Step 4 is an asynchronous prelude to the workshop: it helps everyone to prepare for the upcoming discussions and makes the workshop more efficient and pleasant.

Starting with the consolidated Google Sheets file created in step 3 (which should contain a row per technology), add a column for each board member to cast their votes. Each vote cell should contain a drop-down list with one of the following values selected:

  • Accept — yes, include it in the proposed ring.
  • Discuss — I have a question or suggestion to make.
  • Exclude — do not include this on the radar at all!
  • Abstain — I want to excuse myself from voting on this. (selected by default)

Give the group a week to review all entries and cast their votes. Unanimous decisions (not counting Abstain votes) can be considered final and taken out of the workshop.

Step 5: Workshop

The board meets online to decide the fate of the technologies for which unanimous decisions could not be reached. The process consists of going over the same Google Sheets from step 4, choosing a quadrant at a time and voting on each technology in order from least to most disputed (easier votes first). The easiest quadrant to start with is usually Techniques.

Each voting session can be broken down as follows:

  1. A proponent starts with an elevator pitch of why the technology should be included.
  2. All participants update their votes on Google Sheets: Accept, Discuss, Exclude or Abstain.
  3. If consensus is reached on either Accept or Exclude (not counting Abstain votes), the decision is final. Otherwise, each participant who voted Discuss is allowed to speak in turn, and then there is another round of votes (back to 2).
  4. All decisions must be made by consensus, or disagree and commit helped by a facilitator.
  5. The group should take notes of all discussions and decisions throughout the workshop.
  6. For each accepted technology, someone has to volunteer to write about it in step 6.

This kind of workshop can only work in an environment of deep respect. A facilitator is essential to ensure no one talks over each other, that everyone is heard, and that debates don’t go on indefinitely.

Step 6: Publishing

The last step is to publish the radar. It should contain a few paragraphs about each technology, explaining why it was included, the ring choice and the main points discussed in the workshop.

There are a handful of tools online that can help you publish a Tech Radar, including:

References

  1. https://www.thoughtworks.com/insights/blog/build-your-own-technology-radar
  2. https://www.thoughtworks.com/insights/blog/how-we-create-technology-radar