Technology strategy
Legacy modernization: Change before you have to
It’s been almost a decade since Thoughtworker Darren Smith came up with the idea of using a radar metaphor to track our thoughts on emerging and evolving trends in tech. Since then, it’s become the go-to report for anyone interested in what’s new and exciting in tech. We asked Darren to give us an insight into how the Tech Radar was born.
In 2008, I joined the Technology Advisory Board (TAB) in a newly created role of Technology Assistant to the CTO, Rebecca Parsons. Rebecca had established the TAB a year earlier to connect many of our technology leaders across the globe. Prior to me joining, the group held a couple of face to face meetings where among many other things they discussed the role the TAB planned to play within our business.
As I read these notes, I started to think about the stages of technology adoption for our business. How there could be different gates that a certain technology could pass through as it approached the mainstream for Thoughtworks; gates that would trigger different activities within Thoughtworks, leading to case studies, articles, or public talks. The image of a radar was what came immediately to mind.
The radar metaphor gave some simple components we could easily build upon. Each technology could be a blip, the concentric circles would mark the boundary for each of the gates, and the quadrants were something we could work out later. Before talking to anyone about this though, I felt it needed to be a little better defined for others to grasp what I was proposing. That meant naming the stages, Adopt, Trial, Assess, and Hold.
This is something that Neal Ford goes into further detail in his article, Build Your Own Technology Radar.
Presenting the idea to the TAB took a little bit of courage. This was a group of not only our internal technology leaders, but people that were recognized in the industry for their books, blogs, and open source software. I ran the idea past one of the TAB members who encouraged me to share it with everyone. Despite a small number of reservations about the visualization working at scale, everyone was willing to give it a try during our next face to face.
That first trial worked really well for the internal group; it provided a useful way to structure our conversations and sparked further discussions about how we could share the radar both internally and externally.
Of course, nothing worthwhile in life is ever straightforward. Just as we were building momentum for this idea of sharing our ideas externally, the global financial crisis hit. This impacted our ability to meet face to face regularly and limited the amount of investment we could place into the Radar at that time.
Over the next year or so, we still managed a face to face meeting where we tried the Radar again. A couple of us tried outside of these meetings to write some detailed analysis of one or two technologies to attach to the radar. Unfortunately, the research papers didn't make it that far. Still, the Radar continued to be shared across the organization in the form of a slide deck to help the TAB talk to their regions about what technologies were relevant to our business and our customers.
This is where the quadrants really became a key aspect of the Radar. As a group, we came up with a set of quadrants that seemed to cover everything we wanted to talk about. This is why it is important to recognize all of the members of the TAB at that time, and since, as being the creators of the Radar; everyone has had a hand in making the Radar what it is today.
The quadrants have only changed slightly over the years. We found in the early years that we put a lot of frameworks into the Tools quadrant along with a whole bunch of other stuff. By contrast, the Language quadrant was always a little sparse. I can’t remember who had the great idea, but someone suggested after a couple of years that we add 'framework' to languages because of the close relationship between the two things. It freed up some of the space in the Tools quadrant too.
Over a period of two to three weeks after the November 2009 face to face, I worked on a new prototype of a radar white paper. The idea of breaking out the quadrants into separate images gave me the ability to provide a write-up for each quadrant on a single page accompanied by the quadrant's graphic. The content was taken from my notes and memory of the TAB conversations for each of the technologies, which meant I had a lot of content to work with. Regardless, I still saw this as only a proof of concept, not something that we would release.
The first Radar missed a few things — it definitely wasn't perfect — but we’ve iterated on it since and continue to improve upon it. This is the most important thing I learned about the Radar in its first few versions; we got it out fast, we missed things, but we took on feedback, incorporated it into subsequent editions and built something better with the input of many people.
The key thing was that we tried something, no matter how rough it was — and people liked it. If they didn’t, I guess we would have just moved on to something else. Our approach was essentially releasing an MVP before we even knew MVPs were a thing. We weren’t paralyzed by trying to get something out the door that was perfect, we just got it out there and quickly found that we filled a gap that so many people in the industry have come to value highly.
Of course, at the time, I had no idea how this thing would grow! That first Radar had 38 blips, and we thought that was a lot. The last Radar we published had 105 blips — and that was after 75 had been culled during the Radar face-to-face.
I think people have come to value the Technology Radar because we’re opinionated about technology and clearly state this to our audience. We have a lot of experience with a lot of technology, but we don’t have the answers for everybody, or empirical data to say that one thing is better than another. Who does? Given the group that produces the Radar today — their diversity, their experience, and the information they collect from our colleagues around the world — those opinions are still widely relevant.
Without that group’s ability to build on top of a very simple concept, we wouldn’t have what we have today. Having had a chance to be a part of that for even a small amount of time is one of the biggest highlights of my career.
Tracking tech
In truth, the idea of using a radar metaphor to track technologies really didn't take a lot of effort. It did, however, take some time to find a format that was worth sharing.In 2008, I joined the Technology Advisory Board (TAB) in a newly created role of Technology Assistant to the CTO, Rebecca Parsons. Rebecca had established the TAB a year earlier to connect many of our technology leaders across the globe. Prior to me joining, the group held a couple of face to face meetings where among many other things they discussed the role the TAB planned to play within our business.
Tracking tech maturity
In preparing for my new role, I was given the notes from those first meetings, where the group discussed identifying technology trends and how we as a company could best respond. The group could see value in being able to communicate what technologies our consultants should be learning, what subjects we could focus on helping our salespeople understand, and what technologies our company leaders should be across.As I read these notes, I started to think about the stages of technology adoption for our business. How there could be different gates that a certain technology could pass through as it approached the mainstream for Thoughtworks; gates that would trigger different activities within Thoughtworks, leading to case studies, articles, or public talks. The image of a radar was what came immediately to mind.
The radar metaphor gave some simple components we could easily build upon. Each technology could be a blip, the concentric circles would mark the boundary for each of the gates, and the quadrants were something we could work out later. Before talking to anyone about this though, I felt it needed to be a little better defined for others to grasp what I was proposing. That meant naming the stages, Adopt, Trial, Assess, and Hold.
We would also come to realize that the Radar could be used by other organizations, giving them a way to assess technologies at different stages of the innovation lifecycle against their own risk profile for technology adoption.
This is something that Neal Ford goes into further detail in his article, Build Your Own Technology Radar.
Presenting the idea to the TAB took a little bit of courage. This was a group of not only our internal technology leaders, but people that were recognized in the industry for their books, blogs, and open source software. I ran the idea past one of the TAB members who encouraged me to share it with everyone. Despite a small number of reservations about the visualization working at scale, everyone was willing to give it a try during our next face to face.
That first trial worked really well for the internal group; it provided a useful way to structure our conversations and sparked further discussions about how we could share the radar both internally and externally.
Of course, nothing worthwhile in life is ever straightforward. Just as we were building momentum for this idea of sharing our ideas externally, the global financial crisis hit. This impacted our ability to meet face to face regularly and limited the amount of investment we could place into the Radar at that time.
Over the next year or so, we still managed a face to face meeting where we tried the Radar again. A couple of us tried outside of these meetings to write some detailed analysis of one or two technologies to attach to the radar. Unfortunately, the research papers didn't make it that far. Still, the Radar continued to be shared across the organization in the form of a slide deck to help the TAB talk to their regions about what technologies were relevant to our business and our customers.
How the quadrants emerged
Late in 2009, we got back together again for another TAB face to face. I remember most of us felt overwhelmed by the amount of technology that we were tracking. That there was no way that we could list out all the technologies and have their names alongside the blips. By that time we had started using the quadrants to break out different types of technology, so I suggested that we break it out into five graphics instead of one. This would mean having one collective Radar image and a graphic for each quadrant. There were some concerns with this making the Radar even more complicated. Regardless, I was resolved to try and make it work.This is where the quadrants really became a key aspect of the Radar. As a group, we came up with a set of quadrants that seemed to cover everything we wanted to talk about. This is why it is important to recognize all of the members of the TAB at that time, and since, as being the creators of the Radar; everyone has had a hand in making the Radar what it is today.
The quadrants have only changed slightly over the years. We found in the early years that we put a lot of frameworks into the Tools quadrant along with a whole bunch of other stuff. By contrast, the Language quadrant was always a little sparse. I can’t remember who had the great idea, but someone suggested after a couple of years that we add 'framework' to languages because of the close relationship between the two things. It freed up some of the space in the Tools quadrant too.
Over a period of two to three weeks after the November 2009 face to face, I worked on a new prototype of a radar white paper. The idea of breaking out the quadrants into separate images gave me the ability to provide a write-up for each quadrant on a single page accompanied by the quadrant's graphic. The content was taken from my notes and memory of the TAB conversations for each of the technologies, which meant I had a lot of content to work with. Regardless, I still saw this as only a proof of concept, not something that we would release.
An MVP — before MVPs were a thing
Upon showing the radar to some of the TAB members in the USA along with Rebecca, we made some basic changes to the text to mostly correct my passive tone. At that point, to my surprise, we decided to release what we had. So there it was: the first Technology Radar released in January 2010, with my terrible writing and my terrible design. But it was all the TAB's content and their ideas that created the Radar and what has continued to make it successful.
Figure 1: The first Technology Radar
The first Radar missed a few things — it definitely wasn't perfect — but we’ve iterated on it since and continue to improve upon it. This is the most important thing I learned about the Radar in its first few versions; we got it out fast, we missed things, but we took on feedback, incorporated it into subsequent editions and built something better with the input of many people.
The key thing was that we tried something, no matter how rough it was — and people liked it. If they didn’t, I guess we would have just moved on to something else. Our approach was essentially releasing an MVP before we even knew MVPs were a thing. We weren’t paralyzed by trying to get something out the door that was perfect, we just got it out there and quickly found that we filled a gap that so many people in the industry have come to value highly.
Of course, at the time, I had no idea how this thing would grow! That first Radar had 38 blips, and we thought that was a lot. The last Radar we published had 105 blips — and that was after 75 had been culled during the Radar face-to-face.
I think people have come to value the Technology Radar because we’re opinionated about technology and clearly state this to our audience. We have a lot of experience with a lot of technology, but we don’t have the answers for everybody, or empirical data to say that one thing is better than another. Who does? Given the group that produces the Radar today — their diversity, their experience, and the information they collect from our colleagues around the world — those opinions are still widely relevant.
Without that group’s ability to build on top of a very simple concept, we wouldn’t have what we have today. Having had a chance to be a part of that for even a small amount of time is one of the biggest highlights of my career.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
