The Thoughtworks Technology Radar started in 2010 as an exercise to keep our CTO informed of what was going on inside our organization. Back then we didn’t realize just how much the field of technology would explode. Our first edition of the Radar included only 37 ‘blips’ — a technology or technique that features somewhere in the software development landscape. This year, we struggled to narrow them down to around 100.
With this growth, our Technology Radar has become a critical tool helping not only our team but also many enterprises to navigate the evolution of technology. It supports them to objectively assess their tech portfolio.
An unapologetically opinionated take on tech
The Technology Radar is a snapshot in time of what a group of technologists at Thoughtworks think is worth talking about. It doesn’t try to be comprehensive, nor does it claim to describe all that is going on in the industry. It's strongly grounded in what we value about technology, how we approach it, what we’re using and what interests us.
It should not be confused with a technology lifecycle assessment tool — some technologies that we truly love and belong in the “no brainer” category, like GitHub, faded from our Radar long ago. Our visual metaphor of a radar tracks where new things come in. As they move towards the inside, they shift from ‘proceed with caution' to ‘a safe default choice’. Read more about the radar and its benefits in this article.
A lot of the value lies in the process of actually building a radar. It promotes open discussions about technology at every level of the organization and allows you to introduce innovation into your technology portfolio without an explosion of diversity and complexity. It also helps you prioritize and makes it possible to have some level of governance in place — while also allowing individuals to introduce new things when appropriate.
We honestly never expected the Technology Radar to become quite so popular. However, in the years since the very first edition, many organizations have benefitted from the visibility and feedback loop it provides.
Build your path to a simplified tech stack
Today, the organizations that can make the most of new technologies are the ones that thrive. But without an objective view of your entire tech stack, this can be difficult.
Building your own radar can give you that view and help you assess what’s working and what isn’t. It can open up invaluable conversations around the different levels of maturity of technology from your own organization’s perspective, helping you identify gaps and any additional tools or training you need to succeed in the future. It’s also an effective tool to talk to executives about technology and communicate decisions made around adopting new technologies or retiring old ones. And importantly, it helps you make sense of the increasing complexities of your technology – and simplify it.
Once you have identified the technology you want to include in your radar, the Thoughtworks Build Your Own Radar tool makes the visualization process easy. It uses a Google spreadsheet as the input and generates the radar visualization using a HTML5 canvas.
Over the last few years, we've helped companies like REA and MYOB build their own technology radars so they can think more deeply about technology choices and trends within their organization.
Getting started with your technology radar
While each organization will develop their own style and create their radar differently, here are some useful considerations to get you started.
Who is your radar for?
Your audience will include anyone who is interested, but the output (documents, presentations, video screencasts) should assume a non-technical audience. Some potential audience groups for an organization include:
The engineering department: It informs them about what is safe to use, what is a candidate for an experiment, what they should stop using.
Non-technical executives: A radar can show this group there is a methodical process behind technology selection and an intentional, controlled introduction of new technologies and retirement of old.
Prospective engineering candidates: It can also help applicants understand the technology landscape. It can be an effective recruiting tool if you are a forward-looking organization.
Who should produce your radar?
Building your own Technology Radar is an invitation to have a conversation about technology across all levels of your organization. The process should start with senior technology leaders proactively seeking out opinions and contributions from everyone in their teams. A bottom-up approach gives every engineer an opportunity to weigh in.
The people who put the radar together should include representatives from your senior technologists, along with anyone else in the company with an interest in technology choices. Ideally, try to keep the group to a maximum of 20 people. If the group is larger than 30, or geographically dispersed, you can do multiple sessions and aggregate the results.
While there's nothing wrong with including C-level executives in the meetings, technologists should drive the process.
How often should you create and update your radar?
This depends on your company and its interaction with technology. We recommend at least once a year, but given the accelerating pace of tech change twice a year would be even better.
How will you gather data to inform your radar?
At Thoughtworks, every person in the group is assigned countries or regions they need to gather data from. If you operate in a single region, consider gathering data from different areas of the business.` And if your business is organized by tech functions, make sure each of them are adequately represented.
The best way to do this is through running sessions with groups of people from your given region or department. Enlist the head of technology and other tech leaders to help you collate the information from these sessions.
How will you decide what goes into your radar?
The way we choose the technology and tools (or ‘blips’ as we call them) we include in our radar is through interactive sessions with the Technology Radar group. Over the course of a couple of days we come together (in person or virtually) and make our case for each technology. We then vote for what stays and what needs to go.
In our experience, technologists can be very passionate about different tools and technologies, so we find it useful to establish some ground rules to help guide these sessions.
At Thoughtworks, this includes expectations that we don’t talk out of turn, and we use a card system to communicate. A yellow card signals we’d like to say something, green signals a vote for a tech to be included, and red a vote against.
A strong facilitator — someone who can keep the group focused, respectful and moving forward – is also essential. We are fortunate to be led by Thoughtworks’ CTO Emerita, Rebecca Parsons. She helps us stay on track, makes sure everybody gets a chance to say their piece, and can disagree politely and respectfully.
How will you build your radar?
We start the process on a whiteboard, drawing four bands to represent the rings (hold, assess, trial, adopt). For each quadrant:
Participants write down their tech nominees on Post-it notes and stick them on the whiteboard within the relevant ring
The facilitator groups similar notes (there will inevitably be some overlap)
As a group, we discuss each technology
Once each person has had their say, the facilitator calls for a vote to decide whether or not it should stay on the radar
We assign someone to write a short description for each, contextualizing the decision
Every time we update our Technology Radar, we follow this same process for existing entries, deciding if they should move, fade, or be "re-blipped". We suggest capturing the results of the meeting in a spreadsheet. You should aim to write a paragraph that summarizes the group conversation and consensus for each blip.
How can you run the sessions remotely?
Though they may not be as efficient (or as much fun!), it’s just as easy to run sessions virtually. Rather than using Post-it notes, collect all the blips in a spreadsheet similar to the above and make your way down the list. Add people’s names across the top after the Description column where they can add their vote. Alternatively, you can also use online polls which help tally up the votes automatically.
It’s also important to have a scribe and notetaker when you're doing it either in-person or remotely. This is especially helpful when there are a lot of blips as it’s difficult to to keep track of the blips and decisions made if you aren't methodical and organized with the data. Sometimes you need to defer a decision and go away to research or "phone a friend." Sometimes you might need to mention a specific fact or remember to rename the item.
If you're doing it remotely, you need someone to operate the spreadsheet so that everyone can keep up and know where they are. There are probably other ways to do this, but it's harder to keep track when you're doing it remotely because there are no physical post-it notes.
How should you structure your radar?
Each organization will do this differently, and it may evolve over time. REA Group decided to tweak their technology radar to include five rings: adopt, consult, experiment, hold and retire. You can start with our format and change the details if you need to as you go along.
Concentric Circles
Our Technology Radar has four concentric circles or ‘rings’, from outer to inner: hold, assess, trial and adopt.
Hold: The original intent of the hold ring was "proceed with caution", to represent technologies that were too new to reasonably assess yet. But it has evolved into more of a "don't start anything new with this technology." You may be constrained to use it for existing projects because it is so deeply embedded into the tech portfolio, but you should think twice about using this technology for new development.
Assess: The assess ring includes technology worth exploring with the goal of understanding how it will affect you. You should invest some effort (such as development spikes, research projects or attend conference sessions) 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 includes technology that has been shown to be safe in certain circumstances — you would probably want to use them going forward. While the assess phase shows benefits and potential, it doesn’t touch on limitations. To be worthy of the trial ring, the technology should have been used on project work to solve real problems.
Adopt: Blips in the adopt ring should be safe default choices that your organization adopts. We use them where appropriate on our projects; they’re usually as close to a "no brainer" as possible. A good rule of thumb is to be cautious with anything you want to move into the adopt ring: do you really understand it well enough?
Quadrants
Our radar is split into the below four quadrants, but you may want to include different quadrants in your enterprise radar but the key consideration is you want it to be relatively stable over time so you can understand and visualize change.
Techniques: These include elements of a software development process, such as experience design; and ways of structuring software, such as microservices.
Tools: These can be components, such as databases, software development tools, such as version control systems; or more generic categories of tools, such as the notion of polyglot persistence.
Platforms: Things that we build software on top of such as mobile technologies like Android, virtual platforms like the JVM, or generic kinds of platforms like hybrid clouds.
Languages & Frameworks: This used to include just languages, but we rolled frameworks into this quadrant with the October 2012 Radar.
Icons
We use a simple set of icons:
Circles: represent new or moved items, and circles indicate no change
Ring: illustrate movement on individual quadrant views
If a blip has stayed put for two radars (one year), we let it fade away, reducing clutter. If there is something interesting to say about an item, we'll resurrect (or "re-blip") it.
Describing blips
Everyone in the group should share the burden of writing about the blips. It’s easy to express opinions or vote yes or no, but asking the participants to do the writeup forces accountability for the decision and the resulting artefact. In our radar, a couple blips inevitably get culled from the final document because in the end, nobody in the group felt comfortable or found it worthwhile to write it up.
The description about each blip should distill the essence of the item and should be no longer than a paragraph or two.
What output should you produce?
The output you product ultimately depends on your organization,and how you plan to use your radar. The final output might be a white paper like the Thoughtworks Radar, or it could be a presentation that the group authors deliver to others. It could even be something as simple as a wiki page you update periodically. The key consideration is to write why this particular item is relevant to your organization and put a unique lens on the subject. Don’t overthink it, but make sure the output is accessible to people who are interested.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
