How the Technology Radar embodies Thoughtworks' culture

This blog post was inspired by Perla’s presentation for the 2022 XConf North America. 

The Radar was originally established as a knowledge management solution. It was designed as a way of understanding Thoughtworker experiences across regions, clients, industries and technologies. And although Thoughtworks and the Radar’s readership has grown and evolved, we continue to create the Radar collaboratively with a global perspective — we do a company-wide call for “blip” recommendations and encourage representation from every country where we have an office. (A blip is the word we use for a single item on the Radar). We often receive similar recommendations regarding a technology from opposite ends of the world. 

Because the Radar is based on Thoughtworker experiences, it’s hard to deny that the Radar is an opinionated guide. But more than that, it also draws on Thoughtworks’ culture, too. Everyone in the organization is passionate about technology — strong views are always encouraged. This means that our perspectives, biases and beliefs are always on display in the Tech Radar. We take that to be a strength. In this post I’ll explore some of them, giving an insight into some of the most interesting aspects of the Radar over the last decade and what it demonstrates about the Radar.

Learning from our mistakes

A part of our culture is admitting that sometimes we get it wrong. The Radar dedicates the Hold ring for technologies we used but ultimately didn’t have a good experience with. By sharing our experience we hope others learn from it and hopefully avoid similar struggles or get a better understanding of existing constraints. 

For the Radar’s 10 year anniversary we reflected on some of the Radar's greatest misses. One of my favorites is Java's end of life. In 2011, Oracle’s purchase of Sun created considerable uncertainty in the industry; we wanted to make sure to warn the Radar readers that the end of life of Java was a possibility worth considering and preparing for. However, our fears didn’t come to pass: Java is not only still around, it also continues to be prevalent. It’s the object-oriented language I have the most professional experience with, and the first language I recommend to anyone I’m mentoring. Although the idea of Java’s end of life seems remote, at the time it was a risk worth thinking about. That’s an important reminder that while risks aren’t always realized, it’s still worth being prepared. 

In 2012, we also blipped Experience Design in Assess. Looking back, that seems quaint: experience design is today a huge part of software development and product design. The idea that it could be covered in a single short blip just seems strange. This actually led to some reflection on our part — we quickly realized the Radar should be discussed with more than just developers. After all, technologists ≠ developers. This is one of the reasons we now run an extensive feedback process before publishing the final volume.

It’s always interesting when we get it wrong — but I’d like to note that we also learn from our wins; sometimes we do get it right. The Adopt ring is dedicated to our positive experiences with technology. The blips in this ring always require production experience and are often referred to and used by our teams when making technology decisions.

There's no such thing as a silver bullet

On the theme of sometimes we get it right and sometimes we get it wrong, I’d like to introduce you to a technologist’s favorite answer to a question — “it depends.” 

In consulting and technology alike, the answer is often “it depends” — there’s no such thing as a silver bullet, a one-size-fits-all, universal solution. When I joined Thoughtworks I had the opportunity to be trained in our Thoughtworks University program; the trainers seemed to love answering questions with “it depends.” At the time it felt like a running joke, but soon I realized it wasn’t. It’s important and often critical to consider the intricacies of every scenario in detail before making a decision on how to move forward — after all, no two developers are the same, no two architectures are the same and no two enterprises are the same. There are always trade-offs to be considered.

We see this idea emphasized on the Radar through a handful of blips. Take Microservices. It’s today a leading architectural pattern, so popular that if you’re early enough in your career it might be one of the only architectural patterns you have seen in back-end systems. And truly, there isn’t anything fundamentally wrong with the approach; I’ve used microservices successfully in plenty of my client projects and many Thoughtworkers have written about and presented on the topic. 

However, microservices isn’t the right solution for every situation. We last blipped Microservice envy in 2018 to remind folks that “microservices trade development complexity for operational complexity and require a solid foundation of automated testing, continuous delivery and DevOps culture.” That same year, Thoughtworks CTO, Rebecca Parsons, described why microservices never made it to the Adopt ring on the Radar in a blog post. She highlighted that the need for nuance in such a recommendation — due to the cost-benefit trade offs microservices brings — meant it was too complex to properly address in a single blip.

There are other blips on the Radar that demonstrate a similar way of thinking. These include things like Big data envy, Web scale envy and, most recently, SPA by default. 

The importance of feedback and experimentation

So, if the lesson is that there’s no silver bullet, how do we get to a decision we are confident in? The answer is that we always experiment, gather feedback along the way and pivot when necessary 

This cultural highlight has to be my favorite, particularly because of the impact it has had on my career. As a software developer, I’ve had the privilege of growing in back-end development, front-end development and data engineering. More recently, I spent two years as the Technical Assistant for the CTO — a role which tested and strengthened my multi-tasking, facilitation and influencing skills. Along the way, I gathered feedback and learned plenty, from the things I enjoy to the things I don’t, and from the areas in which I’m strong to those I need to develop. 

The processes we adopt for software development and product design can all benefit from this mindset. Within the Radar we see the theme of experimentation in blips like Rethinking remote standups. We’ve been doing stand-ups for a long time, but in 2020 the way we work fundamentally changed and took a quick pivot into the remote world. With this change, we proposed experimenting with a different type of standup, one that’s actually longer and allows for discussion that would’ve otherwise taken place naturally by walking over to someone’s desk or walking to the coffee station together. Again, it’s an experiment — we don’t know if this will work for everyone. However, if you decide to give it a shot, it’s worth circling back with the team for feedback and working out how you can adjust it to make it work for your team. 

And that leads us to feedback, probably the most critical part of any experiment. At Thoughtworks we place a lot of emphasis on feedback. We particularly prioritize it from our peers and those working closely with us. In fact, it’s one of most significant elements in our performance reviews — it’s something we aim to practice daily and emphasize as fundamental to our learning and development. Feedback is what has helped me succeed during every career pivot. 

Similarly, during the creation of the Radar we take a bottom-up approach to understand the technology that’s worth writing about. It’s the feedback from the 12,000 people on the ground working with our clients that makes the Radar such a special publication. You also see the theme of feedback in the Radar through tools like Telepresence and Vite. Telepresence is about shifting testing left and enabling more effective local testing; it allows developers to plug a process that’s running locally to a remote Kubernetes cluster. This means they can get feedback faster for changes that would have otherwise required a deployment for testing. On a similar theme, Vite prioritizes feedback speed in front-end pipelines. 

The relationship between culture and technology

So, what does this tell us about the link between culture and technology? Consider Conway’s law; this concept speaks to the observed relationship between the architecture of software systems and the organization of the teams that build them. Similarly, the Tech Radar is a reflection of the Thoughtworkers that build it and the culture that we continue to evolve. 

During the discussion for volume 26 of the Radar, the Technology Advisory Board (TAB) discussed many other biases that exist in the Radar — my examples are by no means the only ones. From our support for open source software, to our belief in simplicity and collaboration, we’re well aware that the vision put forward in the Tech Radar is an opinionated one. Can you spot anything else in the latest Radar that reflects our cultural values?