Build Your Own Technology Radar
For most of the 90’s and the beginning of the 00s, I was the CTO of a small training and consulting company. When I went to work there, the primary platform was [Clipper](http://en.wikipedia.org/wiki/Clipper_(programming_language), 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 as happy as we could be, 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. But that lesson left a mark: 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 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.
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 saw the technical merits of Rails and when it was applicable. The TAB helps assess new technologies and gently steers ThoughtWorks where it can. 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 white paper, whose latest incarnation always lives at 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 settled into our twice a year rhythm of radar production. Then, as often happens, unexpected side effects occur. 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. We use our radar to help articulate our global technology strategy, and you should too. 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.
The radar metaphor provides concentric circles as shown here:
The radar is split into 4 quadrants (being a consulting company, we feel strangely compelled to produce things with quadrants): Techniques, Tools, Platforms, and Languages & Frameworks.
The radar has four rings, from outer to inner: hold, assess, trial, and adopt.
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 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.
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.
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 real project work. We firmly believe that you can’t really fully assess technology unless you’ve used it to solve real problems, and understand both its weaknesses and strengths. Often, the assess phase shows benefits but not limitations, whereas solving real problems provides a holistic view.
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?
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’t 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 & sticks them on the white board 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 Dörnenburg, 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.
One of the remarkable things we’ve noticed only in hindsight is the rapidity with which we reach 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 consensus. One theory states that, as technologists, we’re accustomed to make 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
To use his tool, you must fill in a JSON data structure with your technology and where it belongs. One little quirk is his use of polar coordinates, which allows exact placement within the circle but a bit of yak-shaving-inspired translation beforehand.
Many people misinterpret the purpose of ThoughtWorks radar. Martin Fowler, our chief scientist, has 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.
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 language](http://en.wikipedia.org/wiki/Clipper_(programming_language). 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.
While the value of a personal radar is evident, an enterprise version seems less valuable but is actually immensely more so.
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 are forced to use every day. Most C-level types get more advice from sales people 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 them produce a radar, an infrastructure change that they 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.
5. Helps Align Business & 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 & 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.
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.
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 that has 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 screen casts) should assume a non-technical audience. One of the purposes of the radar is 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. I described our process above, using Post-it notes, whiteboard, and a project tracking tool (Mingle in case anyone is interested) to store the results and the write-ups.
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.
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?
Download a copy of this white paper.