It’s Radar season at Thoughtworks, which means we’re all working hard to get the next Technology Radar ready for release on November 30. During Radar season, sleeping is overrated.
Jokes apart, I’ve been involved in a couple of Radars now. One question I get asked frequently — and I used to ask myself before I got involved — is: “How is the Tech Radar created?”. In this article, I’ll give you under-the-hood insights into what goes on, how we prepare and how decisions are made. It all starts with a four-day meeting.
It’s an early start, and we’ve gathered Thoughtworkers from across the globe to create the next edition of the Technology Radar. Each time, we meet at one of our offices — this time it’s Barcelona, which only opened last year. If you thought the unfamiliarity of the place and jet lag would have meant a slow start, think again. As soon as the group gets together and reconnects and each member of the Technology Advisory Board (TAB) has their caffeine fix, we’re underway.
For anyone that doesn’t know the TAB, it’s made up of some of Thoughtworks’ senior technologists from across the globe, including our Chief Scientist, Martin Fowler. Our CTO, Rebecca Parsons, chairs this face-to-face meeting.
When we kick off on Day One, each TAB member has a collection of ideas that they’ll suggest for the next Radar — the blips. These blip proposals usually bubble up from conversations they’ve had in offices about what new and exciting things we’ve been using.
This time in Barcelona, the group has to vote on about 180 blips. That means a lot of debate to reach consensus.
The potential blips are organized into our Radar quadrants (techniques, tools, languages and frameworks, and platforms), and then into the rings (hold, assess, trial and adopt). It’s always handy to remind ourselves what we mean by each of those rings, as it helps us decide where a blip belongs.
Hold. This is for blips that we think clients should either phase out or wait to mature.
Assess. These are things we think hold promise and are worth exploring.
Trial. This is a pretty strong recommendation, and we only put blips here if we’ve successfully seen them deployed in production — exceptions to that rule are pretty rare.
Adopt. For a particular use case, we see this as the single best choice.
To get down to the 100-or so blips that appear in the final Radar, we take it a quadrant at a time, and within each, we work outwards, from adopt to hold. Whoever nominated the blip gets to explain it to the group, it’s then discussed and voted on. Everyone has three different colored cards: green for ‘yes, I want it on the Radar’; red for ‘no, no way will it make to the Radar’ and a yellow for when they have a question or comment. These cards get used a lot over the four-day meeting.
Well, when we are out of red cards, orange is the new red ;-)
This time around, we start with the Techniques quadrant — not just because it's my favorite, but because the discussions here tend to be nuanced. And with that, the next Tech Radar is out of the starting blocks.
By the start of Day Two, the Radar wall looks slightly less busy — although not by much. A team member assumes responsibility for walking the wall while I make sure to track all the decisions — it's quite impossible to remember everything later. When walking the wall, they identify which proposed blip we’ll discuss next and move the post-it note to wherever the group has voted for it to go. In some cases that means putting it in the ring it was nominated for — however, at a later point, may get moved into another ring or even quadrant, or it may get rejected entirely.
Occasionally, we have blips that spark intense debate to the extent that the group is unable to write a short paragraph about it due to its nuances. These are the issues we deem ‘too complex to blip’ — that doesn’t mean they’re forgotten about; indeed these items are important and noteworthy. It just means the Radar isn’t the right place to discuss them.
But with so many blips to discuss and vote on, it’s essential that the discussions keep moving. Rebecca keeps a careful eye on proceedings. As each blip is explained, she looks out for yellow cards going up and lets the group know who’s next in line to comment or question. No one talks over each other. You’ve got to wait your turn to make your point.
The first votes go through pretty quickly. An explanation, quick discussion and a ‘yes/no’ vote. Then we hit a tricky one. There have already been a few comments from different people, and still, lots in the group have yellow cards up. To keep us on track, Rebecca identifies who’s on the comment list and instructs us: "After Jonny, we vote.”
The votes are often close, so hands stay up until all the green/red have been counted. While we have a yellow up, the conversation continues. And once a decision is made, we move on. There’s nothing personal about this, and we move on quite quickly.
By Day three, we’ve mostly broken the back of the new blips. But we’re far from done. And in many ways, the hard work starts now.
Previously, each vote decides whether a new blip merits being on the Radar. Now, we have to look at the blips that were on the last Radar, which usually adds up to 100-ish blips. Are they still relevant? Which ones should move? Do any blips need rewriting? If our opinion on a blip hasn’t changed for two successive Radars, we ‘fade’ it. There's a lot of interesting stuff to talk about! And in some cases, to free up space on the Radar, we force-fade blips — removing them earlier than we otherwise would.
Even then, we still have too many blips. Now the discussions get intense. The Tech Radar emerges from ThoughtsWorks’ community of passionate technologists across the world. It is based on our experiences working for clients. We think that is one of its strengths. But whenever people are passionate about technology, there’s always likely to be disagreement. Our Radar debates are no different.
And then, we look at blips that everyone has agreed deserve to be on the Radar but maybe aren’t as deserving as others. The culling process is hard, and several times we have to stop and ask ourselves: what is the advice here? If the group doesn’t have clear advice or consensus on a particular blip, it isn’t on the Radar.
Three days of solid debating — and maybe the occasional after-work beer interacting with people from the office and fomenting technology conversations besides the Radar — takes its toll. Pretty much everyone in the room is now tired, but we still have the final touches to put in place.
To ensure that we can get this wrapped up in the time we’ve allocated, we use a number of techniques. For instance, Rebecca ensures that debates aren’t allowed to run on indefinitely. But we also know that there’ll be occasions where individuals disagree with the group. In these cases, there are also opportunities to change the group’s decisions — what we call the lifeboat. Once the Radar is almost in place, each TAB member can choose a single blip to bring back - but they have to convince the group that the blip deserves to be on the Radar. Or the majority, it doesn't have to be unanimous.
Ultimately, the meeting can only work if each of us respects the other’s opinions. The way Rebecca facilitates the sessions ensures that everyone has a voice and gets to express their thoughts, experiences, and concerns. It is a delight to see such high-quality discussion from passionate people with strong opinions in such a respectful way. So even when the group is split, and votes are close, we move on to the next discussion.
By the end of day four, we’ve reached a final decision on what will appear on the Radar. Each time I’m there, I’m blown away by the discussions — it’s a real privilege to be part of the meeting, and I’m always amazed at the considerations around technology, its history, how to assess it and different contexts that the group talks about.
But this is just the start of the Radar creation process. We’ve now got to go away and write up each blip, the themes which emerge from the discussions and the main report. Stay tuned — the new Radar will be with you shortly!
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.