Build Your Own Technology Radar

For most of the '90s and the beginning of the '00s, I was the CTO of a small training and consulting company. When I started there, the primary platform was Clipper, which was a rapid-application development tool for building DOS applications atop dBASE files. Clipper was object-based; we leveraged an extension library called Class(y) to make it fully object-oriented and promptly bludgeoned our competitors because we built an extensive object-oriented framework for cranking out applications. We were quite happy, with both a thriving training and consulting business.

Until one day it vanished. We had noticed the rise of Windows, and most of us had played with it, and even used some of its primitive tools to build things. But the business market was still DOS...until it abruptly wasn't. Seemingly overnight, all our business disappeared. We had to scramble to find equivalent tools and platforms in the Windows world. That lesson left a lasting impression: ignore the march of technology at your peril.

It also taught me an important lesson about technology bubbles. When heavily invested in a technology, you live in a memetic bubble, which also serves as an echo chamber. Bubbles created by vendors are particularly dangerous because you never hear honest appraisals from within the bubble. But the biggest danger of Bubble Living comes when it starts collapsing, which you never notice from the inside until it's too late. It happened to us with Clipper, and it can happen to you as well.

What we lacked was a technology radar: a living document to assess the risks and rewards of existing and nascent technologies. I've come to believe you need two radars: one for yourself, to help guide your career decisions, and one for your company, to help restore sanity to purchasing decisions and technology direction. I discuss building both kinds of radars, but first, I describe how this concept came to be.

You need two radars: one for yourself, to help guide your career decisions, and one for your company.
Tweet this

The Thoughtworks Technology Radar

The Thoughtworks TAB (Technology Advisory Board) is a group of senior technology leaders within Thoughtworks, created to assist the CTO, Rebecca Parsons, in deciding technology directions and strategies for us and our clients. Thoughtworks tries to be proactive in technology choices, to objectively assess technology uses for problems we see in the wild. For example, we were early proponents of Ruby on Rails in the enterprise because we understood the technical merits of Rails and when it was applicable. I am a member of the TAB, which meets via a horrifically timed international conference call every two weeks and face-to-face a few times a year.

One of the outcomes of the face to face meeting is the latest Technology Radar. It started as the output from what was (for many of us) the most fun part of the face to face meeting, the Cool Tech discussion. Because Thoughtworks is a complex entity, the TAB has a busy agenda when we meet in person. But, at heart, we're all geeks. From the beginning, we reserved a spot on the agenda to talk about the things we're currently passionate about. Over time, it gradually grew into the bi-annual Technology Radar, whose latest incarnation always lives at www.thoughtworks.com/radar.

It has become popular beyond our wildest imagination. We're not quite sure why, but perhaps it's because we are the rare consulting company that gives honest opinions about technology. We are passionate about technology, and we aren't afraid to speak our minds. It is also popular because it embodies a useful metaphorical framework for assessing technologies. While not a perfect metaphor, it is a metaphor, and sometimes all memes need to flourish is a framework to hang ideas upon.

The TAB gradually settled into our twice a year rhythm of radar production. Then, as often happens, unexpected side effects occurred. At some of the conferences I spoke at, attendees sought me out and thanked me for helping produce the radar, and said that their company had started producing their own radar. We had never considered recommending this exercise to others, but it's obvious in hindsight. Since then, we've undertaken this exercise with several of our clients, with resounding success.

I've also realized that this is the answer to a pervasive question on conference speaker panels everywhere: "How do you (the speakers) keep up with technology? How do you figure out what things to pursue next?" The answer of course is that we all have some form of internal radar. Using the tools presented here, you can formalize that process for yourself, helping you decide where you want to spend your precious research and development that may lead to a new career but steals from family time.

You need two radars: one for yourself, and one for your company. I'll cover how and why to create them, but first I should cover the details of the document itself.

Mechanics

The radar metaphor provides concentric circles as shown here:

The radar is split into four quadrants (being a consulting company, we feel strangely compelled to produce things with quadrants): Techniques, Tools, Platforms, and Languages & Frameworks.

Rings

The radar has four rings, from outer to inner: hold, assess, trial, and adopt.

Hold

The original intent of the hold ring was "hold off for now", to represent technologies that were too new to reasonably assess yet. We had in mind technologies that were getting lots of buzz but weren't yet proven. The hold ring has evolved into our way of saying "don't start anything new with this technology". There's no harm in using it on existing projects, but you should think twice about using this technology for new development. Hold is the closest we have to an avoid category, which Rebecca won't let us have. But we've come to see great wisdom in that decision: true to the metaphor, your radar should be about things you are looking towards, not recriminations about the past. 

Assess

The assess ring indicates that a technology is worth exploring with the goal of understanding how it will affect you. You should invest some effort (such as development spikes, research projects, attend conference sessions, etc.) to see if it will have an impact on your organization. For example, many large companies visibly went through this phase when formulating a mobile strategy.

Trial

The trial ring is for technologies you (and/or your peers) have decided are worth pursuing. It is important to understand how to build up this capability. Now is the time to pilot a low-risk project to "get dirty" with the technology so that you can really understand it. We wanted an objective criteria for Thoughtworks to move something from assess to trial, and we decided the litmus test is serious usage: we must have used this technology on project work. We firmly believe that you can't really fully assess technology unless you've used it to solve real problems, to help understand both its weaknesses and strengths. Often, the assess phase shows benefits but not limitations, whereas solving real problems provides a holistic view. After all, every technology is trying to entice you into using it, touting benefits but hiding deficiencies. It's up to you to uncover the weaknesses in new technologies.

Adopt

For technologies in the adopt ring, we feel strongly that the industry should be adopting these items. We use them where appropriate on our projects; as close to a "no brainer" as possible.

We were trying to come up with a good criteria for when something should plainly be in adopt, and my colleague Mike Mason developed what we call Mason's Razor: for any of the technologies in the adopt ring, I will make fun of you at the pub if you aren't using them. A recent addition is Mason's Second Law: suspect anything that you want to move directly into adopt -- do you really understand it well enough?

Icons

We use a simple set of icons. Triangles represent new or moved items, whereas circles indicate no change. We also show vectors illustrating movement on the individual quadrant views.

Once an icon has not moved for two radars (one year), we let if fade away, reducing clutter. If there is something interesting to say about an item, we'll resurrect (or "reblip") it.

How We Build It

For each quadrant:

• everyone uses Post-it notes to write their nominees and sticks them on the whiteboard within the 4 bands drawn there to represent rings (hold, assess, trial, adopt)
• the facilitator (some member of the TAB) groups like notes (there is inevitably some overlap in what we think is cool)
• as a group, we discuss each technology, whether it should remain on the radar, and where
• a passionate person is chosen to write the few sentence description contextualizing the decision (some of which appear as the write-ups in the white paper)

We also do this for existing radar entries, deciding if they should move, fade, or be "re-blipped". 

One beneficial driving force for our radar comes from my colleague and TAB member Erik Doernenburg, who always exerts pressure to encourage naming specific technologies. For example, rather than adopt a broad category (for example, log aggregation tools), use specific technology names: we recently called out logstash and Greylog2 in that space as exemplars of this new category of tools we hope people will adopt. Specificity adds concreteness to the radar.

Reaching Consensus

One of the remarkable things we've noticed only in hindsight is the rapidity with which the TAB reaches consensus. Senior technologists tend to be passionate, but we reach conclusions quickly, and it rarely comes down to a tie-breaking vote by Rebecca. Other similar groups both within and without Thoughtworks seem to take a frustratingly long time to eventually arrive at a consensus. One theory states that, as technologists, we're accustomed to making our case and submit it for approval, then respect the outcome and move forward without hard feelings. Once you have worked on software projects in big organizations, you hone acceptance skills. We unexpectedly benefit from our hard-won practice in this area; choosing what technologies appear on our radar is mostly a congenial affair.

Open Source Visualization Bits

By popular demand, Thoughtworks released in November 2016 a tool to assist technologists to build their own radar visualization. When we do this exercise for companies, we capture the output of the meeting in a spreadsheet, with a page for each quadrant. The Thoughtworks Build Your Own Radar tool uses a Google spreadsheet as input and generates the radar visualization using HTML 5 canvas. Thus, while the important part of the exercise is the conversations it generates, you can trivially generate the appropriate visualization using this tool.

The tech radar creation exercise invites you to have a conversation across all organizational levels.
Tweet this

Thoughtworks Radar

Many people misinterpret the purpose of Thoughtworks radar, so we created a FAQ to answer common questions. For us, it is a snapshot in time of what a group of opinionated technologists think is cool. It's not a technology lifecycle assessment tool—some technologies that we truly love, like GitHub faded long ago in our "no brainer" adopt category. The metaphor is apt: radar tracks near-term incoming objects.

While we never expected our metaphor to become popular, others started using it for both personal career development and to shore up a missing feedback loop in many companies.

Personal Radar

Once you started a career in software development, you signed a pact that promises you'll keep up with changes in that world. It's fun at first because there are always new things to discover and play with. But over time, the things you learn turn into a Career, where technologies have more value than their inherent coolness. It's wise to invest in learning your current technology stack thoroughly (and, the good part is, if it happens to also be cool, you can still call it "work").

But you can never rest on your laurels. The technology world changes at a dizzying pace. One of my former co-workers was a world-renowned expert in the Clipper. He lamented that he couldn't take the enormous body of (now useless) Clipper knowledge and replace it with something else. He also speculated (and this is still an open question): has any group in history learned and thrown away so much detailed knowledge within their lifetimes as software developers?

It is dangerous to adopt a Laissez-faire attitude towards your technology portfolio. Most technologists pick technologies on a more or less ad-hoc basis, based on what's cool or what your employer is driving. Creating a technology radar for yourself helps you formalize your thinking, and balance some technologies (more cool factor, less likely to get a new job versus huge job market, but not interesting work). You should treat your technology portfolio like a financial portfolio: in many ways, they are the same thing. What does your financial planner tell you? Diversify!

Choose some technologies and/or skills that are widely in demand and track that demand. But you might also want to try some high risk/high reward technology gambits, like open source or mobile development. I know several developers who freed themselves from cubicle dwelling servitude by working late at night on open source projects that became popular, purchasable, and eventually career destinations. Mobile development currently has the shiny garage-to-success aura, which is valid but also incredibly difficult.

Set aside some time, develop some litmus tests to help you choose technologies, and create a radar. You can use our quadrants or create your own. Realize that the exercise is as important as the outcome, so schedule time to re-visit it a couple of times a year. It's natural for me to revisit mine at the end of the year because that's when I'm thinking about new things, and also during the summer when I'm starting to think about talk ideas for the next year. Creating the physical pieces (a crude radar visualization + the write-ups) helps you formalize your thinking and contextualizes your decisions so that you understand them upon revisit.

Enterprise Radar

While the value of a personal radar is evident, an enterprise version seems less valuable but is actually immensely more so.

Reasons

Here are five reasons you need a technology radar for your company.

1. Balance risk vs. adoption

For any given technology, your company is somewhere on the diffusion of innovation curve:

​

But you don't have one technology, you have a host of them: every open source framework. commercial product, home-grown tools, etc. For each and every one, you can draw where you are on the adoption curve and where you think you should be, balancing risk versus reward. While a useful exercise, doing that work for each technology is cumbersome. Trying to create a comprehensive matrix that evaluates all the dimensions of technologies is doomed to failure. Instead, you need a coarse-grained categorization system, allowing broad buckets rather than fine-grained cubby-holes, like our radar rings.

For any given technology, your organization has an ideal location on the innovation curve, balancing risk versus reward. My colleague Darren Smith came up with the original radar metaphor by visualizing the host of technologies you use, along with your ideal adoption phase, and "flattening" them into a two-dimensional radar circle. The radar is a snapshot in time, showing where each technology lies on your adoption curve. Like many rich metaphors, "radar" works on several levels.

2. A platform for continual analysis

Once you have a framework, the exercise becomes easier to repeat. Thus, you build a platform to allow you to continuously gauge your reaction and appetite for technology. Technology never sits still; you must (re-)evaluate it constantly or risk drastically falling behind your competitors. Having a standard format helps you build a history of this exercise, using it to gain insight over time.

3. Unified message from the technical to the interested-but-non-technical

Your CTO/CIO/"Person who makes software buying decisions" probably wanders around and chats with people about technology on a regular basis, and may even ask individuals their opinions. But it's a rare CTO indeed that calls a meeting, allowing all his underlings to grade his decision process for the tools they use every day. Most C-level types get more advice from salespeople than their own employees. Why? First, no one wants feedback that they think may be negative, especially when they can make it optional. Second, when opportunities for feedback do appear, it's mostly negative, in the form of complaints. How often do you tell your CTO "Hey, good job on picking technology X?" or even "You know, our productivity is really up since we changed to Y". Effective technology is invisible but defective technology sticks out like a sore thumb to the people who use it. In most organizations, there is 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 to the decider about technology. In a couple of the companies where we've helped produce a radar, an infrastructure change that developers had been advocating for more than a year happened almost instantly when the Powers That Be realized near universal demand for it.

4. Excuse to have impassioned conversations about technology

I once had a project manager complain to me that the developers on a project argued too much. I corrected him that they merely had impassioned conversations, which feature excitement without anger. How often do you have a forum where interested technologists can get together and have impassioned conversations about the technologies you interact with every day? Creating a radar is just such an excuse, in a (hopefully) non-hostile environment. The group of technologists should come from all projects across all technology stacks. Frequently, programming language barriers have the same social impact as spoken language ones, isolating constituents into cliquey groups. The radar exercise excuses everyone to gather and talk about their similarities rather than differences, with often surprising results.

We've found that this aspect is the most beneficial part of the exercise because you have important conversations about technology that you could have any time, you just never get around to it. For example, most developers probably think they know the head of operations opinion on Puppet, but having the formal conversation always generates surprising outcomes.

5. Helps align business and IT views on technology

Having a radar helps you decide when to be more (or less) aggressive about rolling out a new technology, and provides a readable, condensed view that non-technologists can understand. Having a public stance on the current and future state of technology in your company allows more intelligent decision making and career planning.

Generally, you hope that the business and IT views on technology align, but often conflicting goals arise. For example, what if your company merges with another company with a wonderful business outcome but they bring along dysfunctional IT? Having a stated roadmap helps everyone (technical and non-technical) assess strategic thinking and make plans.

Mechanics

Each company will do this differently and should evolve their own style. Start with these suggestions and don't be afraid to change the details.

Quadrants

You may want to change the quadrants for your enterprise radar. When I perform this exercise for a company, I sometimes move languages alongside tools (because at most large companies, languages is, unfortunately, a foregone conclusion), adding a package software quadrant instead. This is a big deal to many companies, who have a monstrous Rube Goldberg contraption integrating COTS (Commercial Off The Shelf) software. You may have other quadrants as well, like partner companies or consultants, or something quite domain specific.

Who? What? When?

The who is split into producers (those who are producing the radar) and consumers. The producers should be a representative group of senior technologists (perhaps with nominations and insights from their coworkers), along with anyone else in the company with an interest in technology choices. If the group is larger than 30 people or geographically disperse, do multiple sessions and aggregate the results. The consumers should be anyone who is interested, but the output (documents, presentations, video screencasts) should assume a non-technical audience. One of the purposes of the radar is to enlighten interested parties about technology decisions, so they should be able to read it. While there's nothing wrong with C-level types attending the meeting, the technologists should drive the process.

What you produce might be a 10 page white paper like the Thoughtworks radar, or it could be a presentation that the Radar group authors and delivers to others. It could be as simple as a wiki page you update periodically. The exercise is more important than the artifact, so the output can be minimal. We start our process on a white board, with lines for quadrants and sticky notes that represent the current items on the radar. 

How you capture the results can be quite simple; we use a spreadsheet when we do this as a company exercise. The write-ups are the most cumbersome part but the most valuable after the fact because they contextualize the radar blips. While we are constrained by printing limitations to a few sentences for each technology, you should encourage a paragraph write-up on your Enterprise radar, to summarize the group conversation and consensus.

When you do this also depends on your company and its interaction with technology. I would recommend at least once a year and twice is better. Technology moves fast; the whole universe can change in a year.

Summary

When you chose a career in technology, you implicitly agreed to manage your technology portfolio. Formalizing that process using a metaphor like the technology radar allows you to make better decisions. Similarly, building a radar for your company provides a feedback loop that has been missing for far too long. Why not leverage the deep knowledge and experience of the people who touch your software every day?

Having both radars in hand is also a useful career tool. As you can see from the exercise above, the decision process about technology is different when you are the CTO. Remember, radar is used as a defensive tool...but it can also be used as an offensive weapon. Look at the difference between your radar and your company's, and see if this tool allows you to better align your career goals.

While this is a wild fantasy, wouldn't it be great if one of the formalities during job interviews became the trading of radars, personal, and company, as a way for each to assess the other? 

In this edition of the Beacon podcast, Neal shares tips on how to Build Your Own Radar. 

This article is an updated version from the 2013 original published on Neal Ford's blog.