Introducing Skai’s Tech Radar
At Skai, our Engineering group consists of over 40 teams across various domains: data platform, ops, fullstack/backend/frontend development, QA, data science, data analysts, testing infra, performance, and more. Naturally, such variance requires diverse tooling and skills.
Nevertheless, they share common values and universal practices: we want all our teams to excel, deliver quality, be innovative, be proficient and support each other.
So how can we encourage innovation, keep our technological edge, and communicate these expectations internally?
Thoughtworks Tech Radar
Thoughtworks is a software development consultancy company working with hundreds of firms across many industries. It provides them with a vantage point to which technologies & practices work well for different use cases and which should be avoided. Each quarter they share their insights in a model called Technology Radar.
The model consists of items spread across four rings that look like blips on a radar. Each ring indicates an adoption level from Adopt at the center, outwards to Trial, Assess and finally Hold as the outer-most ring. The association of an item to a ring visually indicates Thoughtworks’ recommendation regarding the adoption level of that item.
In addition, the Radar is divided into four quadrants, representing different subject domains (tools, platforms, programming languages & frameworks, techniques), making it easier to digest by grouping the items.
Our Adaptation
While searching for a model to create alignment and share a technology roadmap, we found the Radar suitable for our needs. As with maps, it clearly communicates plenty of information visually.
However, while Thoughtworks Technology Radar serves as a barometer of the general tech industry trends, it cannot be adopted as is. Instead, our perspective has a specific context and should be based on our product needs, engineering culture, and values.
Adopt & Hold Rings
In our adaptation, we use the “Adopt” & “Hold” rings for aligning company standards on our tech stack, internal & external tooling, best practices, and methodology. These rings must answer the question, “How do we do X in Skai?”.
Items on the “Adopt” ring must have some enablement to support a good developer experience and make them easier to use, be it clear documentation, project templates, tooling, workshops, etc.
For example, we have an internal service for provisioning and managing microservices called Kubiverse. You can see it on our Tech Radar on the Adopt ring, as it is the standard way of building microservices in Skai.
Another example is Clean Code, a best practice we promote in the company, starting with the onboarding of new members and in our constant code reviews. Again, stating it on the Tech Radar sets a clear expectation on what standards we’re aspiring to.
The “Hold” ring contains items that shouldn’t be used in new projects in Skai, and if they already exist, they should be kept in minimal maintenance mode or deprecated as soon as possible.
An example of a “Hold” item is Scala. We’ve been using it for years, but due to many reasons, we’ve decided to stop writing new code with it. Putting it on the “Hold” ring, along with the reasoning, drives alignment across our R&D.
Trial & Assess Rings
As opposed to the “Adopt” & “Hold” rings that state the company standards, we use the “Trial” & “Assess” rings to project the tech roadmap of our R&D.
On the “Trial” ring, we put items that we’re already experimenting with and might even have some usage in our production systems. However, it also means there is not enough support and enablement for it yet. So think of it as a way to invite teams to try these items according to appropriate risk assessment.
An example is encouraging teams to trial GraphQL, a technology we believe can be helpful, but we haven’t used enough and don’t provide any infra for it.
The “Assess” ring is the most obscure. It holds items with a high potential for being on the tech roadmap that we haven’t experimented with yet. So why bother having it on the Radar, you may ask? The simple answer is that we want to encourage teams to explore these items, on their terms, along with limited support from other peers interested in promoting them.
Ideally, items shouldn’t remain on the Trial & Assess rings forever. One year should be enough to understand whether an item should become our standard (i.e., “Adopt”) or disappear from the Radar.
The process, in short
The most challenging part is selecting the items and placing them on the correct ring.
To do so, we’ve established a committee of architects, principal engineers, and platform and QA group managers. The committee reviews the nominated items, votes, debates, comes to terms and publishes the Radar. It is a non-trivial process, but it creates a shared understanding and alignment across the stakeholders and, eventually, the whole engineering organization.
We plan to revisit and update the Radar every six months. As with real radars, blips will naturally move across the rings, reflecting and communicating the graduation or disregard of technologies and practices in our company.
A part of a whole
We hope and believe that having a Tech Radar, accompanied by the onboarding process, tech talks, workshops, peer forums, and many other rituals we exercise in our organization, will provide a holistic approach to driving our tech excellence in the company.
Our Tech Radar is public, so see it for yourself at https://tech.skai.io.
BTW, we’ve open-sourced the Tech Radar application, so you’re welcome to use to create your own Radar. Find it here: https://github.com/skai-oss/tech-radar
