FAQ

The Radar captures the experiences and learnings from Thoughtworkers based on the work they do on behalf of our clients. As a result, it cuts across technologies, industries and geographies. As a large client services company, with a long history in custom software development, we believe it represents a reasonable sample but no attempt is made to be comprehensive or to survey the market at large.

We don’t publish the Radar to secure revenue, nor do we accept vendor requests to influence what we include. We share our opinions in the belief that winning in technology doesn’t mean having the right answer; it means being open and thoughtful about the options in a rapidly evolving ecosystem. 

The Radar is written by the Thoughtworks Technology Advisory Board (TAB).

The TAB is a group of 20 or so senior technologists at Thoughtworks who meet twice a year face-to-face and bi-weekly virtually. Its primary role is to be an advisory group for Rachel Laycock, Thoughtworks CTO. The TAB represents a wide range of technology leaders — from different countries, areas of expertise and tenure.

Rachel Laycock (CTO) • Martin Fowler (Chief Scientist) • Bharani Subramaniam • Birgitta Böckeler • Bryan Oliver • Camilla Falconi Crispim • Chris Chakrit Riddhagni • Effy Elden • Erik Doernenburg • James Lewis • Ken Mugrage • Maya Ormaza • Mike Mason • Neal Ford • Ni Wang • Nimisha Asthagiri • Pawan Shah • Selvakumar Natesan • Shangqi Liu • Vanya Seth • Will Amaral

The Radar is all about tracking technologies and techniques, which we refer to as blips. We organize blips using two categorizing elements: the quadrants and the rings. The quadrants represent different kinds of blips. The rings indicate our recommendation for using that technology or technique.

A blip is a technology or technique that plays a role in software development. Blips are ‘in motion’ — their position in the Radar often changes — usually indicating our increasing confidence in recommending them as they move through the rings.

The quadrants are a categorization of the type of blips:

• Techniques. These include elements of a software development process, such as experience design; and ways of structuring software, such as microservices.
  
  

   

• 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.
  
  

   

• Tools. These can be components, such as databases, software development tools, such as versions' control systems; or more generic categories of tools, such as the notion of polyglot persistence.
  
  

   

• Languages and Frameworks. These include programming languages like Java and Python but today primarily focus on frameworks like Gradle, Jetpack, and React.js.

We don't make a big deal out of the quadrants — they’re really just a way to break up the Radar into topic areas. We don't think it's important which quadrant a blip goes into, unlike the rings, which generate a lot of discussion.

Our Radar has four rings, which we'll describe starting from the center:

• The Adopt ring represents blips that we think you should seriously consider using. We don't say that you should use these for every project; any tool should only be used in an appropriate context. However we do think that a blip in the Adopt ring represents something where there's no doubt that it's proven and mature for use.

   

• The Trial ring is for blips that we think are ready for use, but not as completely proven as those in the Adopt ring. So for most organizations we think you should use these on a trial basis, to decide whether they should be part of your toolkit. We've used trial blips in production, but we realize that readers may be more cautious than us.

   

• The Assess ring are things to look at closely, but not necessarily trial yet — unless you think they would be a particularly good fit for you. Typically, blips in the Assess ring are things that we think are interesting and worth keeping an eye on.

   

• The Hold ring is for things that, even though they may be accepted in the industry, we haven't had a good experience with. Therefore we are calling them out to warn you that you may run into trouble with them as well. Sometimes it means we think they're irredeemably flawed; or just being misused. We do place things in the Hold ring that we wish the industry wouldn't use.

   

We have some quite passionate arguments about which ring a blip should go into. Over the course of making the Radar we've come up with some useful rules of thumb to help us put things into rings.

We can only put blips into the Trial ring when we have experience of using that blip for production software. This means we sometimes look behind the technology curve, because we may like the look of a technology but haven't yet persuaded a client to try it out — and until we do that, a blip cannot pass into Trial.

For the Adopt ring, we only include items when we think it would be a poor and potentially irresponsible choice not to use them given the appropriate project context.

Given that many blips could be in a couple of different quadrants, we don't worry too much about which quadrant a blip ends up in, and pay no heed to its angular position within the quadrant.

In contrast, we do pay attention to the radial position. If we place a blip in the Trial ring but close to the Adopt ring, this means that we’re increasingly confident in its potential.

There are various reasons why things are missing:

• No Thoughtworkers have recommended the blip.

   

• We put it on our initial list, but had to cull back the number of blips to let them fit on the Radar. This item was one of the victims — meaning we felt it was less important than the others.

   

• We've talked about it in a past Radar, and don't have anything new to say about it now. If a blip doesn't move, it fades from the Radar.

   

• We blipped something more generic, to talk about the wider concept. For example we didn't talk about specific NoSQL databases in our very first Radar edition, instead mentioning "non-relational databases". Later, we called out blips for specific NoSQL databases.

The Radar represents technologies that are currently on our mind. Given how fast technology is advancing, the default rule is that blips only appear on the Radar for one edition unless they move rings. However, members of the Thoughtworks Technology Advisory Board (TAB) can always make an argument to keep a blip, for example when something noteworthy has happened warranting a refresh of the writeup.

We think it’s important to keep older blips in the archive for completeness and visibility, but please be aware that we’re not updating them. In some cases, Thoughtworks teams may continue to work with and recommend these technologies; in others, the advice could be outdated. If you’re looking at a blip from our archive, do keep this in mind.

We've come up with various ways to show blips changing from one Radar to another. Firstly, we show new blips differently to blips that have appeared before. The most common change is blips moving between rings. A blip that covers a broad category may be split into narrower elements as that category matures.

Sometimes we move blips from one quadrant to another, which means our classification of the blip has changed. We don't view this change as important and thus don’t call it out anywhere.

All of the blips you see on the Radar are crowdsourced from our Thoughtworkers across the globe. Ahead of our Radar meetings, our teams nominate things they’ve discovered during their work on client projects. To get on the Radar, our colleagues must have been persuaded that they’ve seen something worth sharing.

We try to limit how many blips we have on the Radar, so if we think it's getting too crowded we'll discuss which blips should stay and which won't fit, often with a vote to help focus the advice.

No, but the Radar is used by Thoughtworkers as a knowledge sharing tool between projects and experiences. 

The Radar captures things that are moving — so we only blip things if we’re seeing a significant change in how we regard a technology across the rings. There are plenty of technologies that we like and use all the time that aren’t on the Radar because we think they’re settled and have long earned their place.

You'll find many of these technologies in past Radars, particularly those in the Adopt ring that have since faded. But even this is not a comprehensive list, since we’re always battling with space on the Radar.

We meet twice a year — ideally face-to-face — to discuss the Radar.

At the meeting, the members of the TAB spend several hours debating the nominated blips for the Radar. Our main aim during the meeting is to decide which blips to include, which rings they fall into and what we should say about them.

We begin by putting candidate blips up on the wall, each placed in their suggested quadrant and ring. Often different people suggest the same blips, sometimes in different rings. Once we have the candidates up on the board, we go through the long process of evaluating each blip. We take each blip one at a time and discuss whether we think it ought to be on the Radar, and if so, where. This discussion is always enjoyable — there are lots of opinions and experiences around the room, but there's also a friendliness and mutual respect that makes the arguments much less grating than these kinds of discussions sometimes become.

Note: Be sure to check out podcasts on how we build the Radar remotely and in-person.

Once blips are chosen and placed, we need to write the descriptions. Each blip gets one champion who is responsible for writing it up, which typically happens after the meeting. The TAB has a product owner who has the unenviable job of chasing us to get our blips written up. Once written, they kick off an internal feedback process across Thoughtworks and work with various region representatives to begin translations. All the while, a designer works on the graphic and PDF.

The Radar can be read in two versions: the interactive website and the PDF. The website allows you to explore, search and link to blips. Meanwhile, the PDF is great for reading all the blips in one place.

Yes, we encourage people to build their own Radars. It’s a great way to get an objective assessment across your entire technology portfolio and assess what’s working well and where you have opportunities for improvement. We have created an online tool that can help you get started.

To get on the Radar you need to get the attention of Thoughtworkers, particularly in the context of our project work. If you get a Thoughtworks team excited, that can get to the Assess ring, but we need actual experience to progress further.

We don't have a formal process for external people to nominate tech, or to arrange demonstrations. But Thoughtworkers are always looking for ways to improve the software creation process and we're active members of numerous tech communities.

We regularly host a sneak peek webinar with two TAB members a few weeks before launching a new volume.

In addition to that, we often give talks about the Radar across the various Thoughtworks regions. The content is left up to the individual speaker; most people like to focus on the blips they're particularly interested in, although they'll happily answer questions about all the items. Usually, Radar talks are given by a TAB member or two, perhaps with another Thoughtworker who's familiar with it.

If you're interested in getting someone to talk about the Radar, or for more information on these topics, contact your nearest Thoughtworks office.

Ajey Gore (2010-12) • Anne J Simmons (2015-16) • Badri Janakiraman (2011-17) • Bharani Subramaniam (2016-present) • Birgitta Boeckeler (2020-present) • Brain Leke (2014-16) • Brandon Byars (2020-24) • Bryan Oliver (2025-present) • Camilla Falconi Crispim (2016-2018,2020-present) • Cassie Shum (2020-22) • Chris Chakrit Riddhagni (2025-present) • Chris Stevenson (2010) • Claudia Melo (2013-15) • Cyndi Mitchell (2010-11) • Darren Smith (2010-14) • Dave Elliman (2015-16) • David Rice (2010-11) • Effy Elden (2025-present) • Erik Doernenburg (2010-present) • Evan Bottcher (2011-21) • Fausto de la Torre (2016-24) • Graham Brooks (2010-12) • Hao Xu (2010-24) • Ian Cartwright (2010-23) • Ian Robinson (2010-11) • James Fischer (2010-13) • James Lewis (2012-present) • Jiaxing Chen (2016) • Jeff Norris (2010-15) • Jim Webber (2010-11) • Jonny LeRoy (2014-20) • Ken Mugrage (2024-present) • Ketan Padegaonkar (2017-19) • Lakshminarasimhan Sudarshan (2017-22) • Marco Valtas (2016-19) • Marisa Hoenig (2022-24) • Martin Fowler (2010-present) • Maya Ormaza (2023-present) • Mike Mason (2010-present) • Neal Ford (2010-present) • Ni Wang (2018-20, 2025-present) • Nick Hines (2010-12) • Nimisha Asthagiri (2025-present) • Pawan Shah (2023-present) • Perla Villarreal (2020-22) • Pramod Sadalage (2010-12) • Rachel Laycock (2013-21, 2023-present) • Rebecca Parsons (2010-2024) • Ronaldo Ferraz (2012-13) • Sam Newman (2012-16) • Samir Seth (2010-11) • Scott Conley (2010) • Scott Shaw (2011-2024) • Selvakumar Natesan (2023-present) • Shangqi Liu (2018-present) • Sofia Tania (2023-2024) • Srihari Srinivasan (2012-17) • Thiyagu Palanisamy (2012-16) • Thomas Squeo (2024) • Vanya Seth (2023-present) • Wendy Istvanick (2010-12)  • Will Amaral (2024-present) • Zhamak Dehghani (2016-22)

Actually the purpose of the Radar is in part to help us keep up. It's an inevitability of our profession that there's constantly new stuff appearing, and we can't keep up with it all. You can look at the Radar as our opinion of how you should prioritize your investigations.

• Start by looking at the Adopt ring. Are you familiar (and using) all the blips here? If you're unfamiliar with a blip, look to see if it's relevant to what you do; if so you should be studying it now — and putting it into use as soon as you can. If an Adopt blip is relevant to your work and you're not using it, think hard about why.

   

• Pay careful attention to blips in the Hold Ring. We are pointing out things that could be more harmful than helpful, depending on the context. If you are making use of it, you should reflect on why that is and whether it makes sense to start planning to move away from it. Educating others around you could be a good idea as well. You may find the BYOR (Build Your Own Radar) tool useful to get started on these discussions.

   

• Once you're familiar and starting to use everything in the Adopt ring, move to the Trial ring. Here, you want to look at each blip and consider which ones are relevant to you. Make sure you familiarize yourself with these topics — do some research on the web, get a couple of books, build a prototype with the more promising items. You could also start thinking about what it would take to trial them in your organization.

• The Assess ring is the last priority, which you can start investigating once you know about what's in the Trial ring. Because of your circumstances it may be more important to get to know something in this ring than something deeper in. Just because we haven't used it yet doesn't mean it's less important. But in terms of prioritizing your learning, the rings are a good way to go.

Of course, this is just our opinion of your priorities. We don't expect everyone to agree with us, but at least it's a start.

Subscribe to the Technology Radar to receive emails every other month for tech insights from Thoughtworks and future Technology Radar releases.