How the Technology Radar came to be in Godel and Why we should be proud of it

In 2021, Godel’s Innovation feature came alive! This is an initiative brought together by a group of developers, testers, and designers that created a tool that brings together the competencies of all the company’s divisions. After 9 months of hard work, 11 divisions, 4 functions, more than 30 people and 300 added characteristics, Godel got its own Technology Radar. 

We spoke to Vitali Pukhalski, Head of our Innovations Function about how the idea came to be, who can use the platform and how Godel open-source can develop thanks to the technical solution. 

Vitali if someone doesn’t know what TechRadar is, how would you explain it to them? 

When the idea of the TechRadar came to light, our main specifications we wanted were to collect extensive information about the company’s competencies and present it in a convenient form that would suit people of different technical levels and various activities, so that everyone equally understands what we see in front of us. 

We also wanted it in a single tool that can display all the skills and experience that Godel has. It is also a set of tools, new knowledge and areas in which the company sees potential and plans to improve its position in the near future. Now all the information on the technical radar is really convenient for search and quick analysis. 


Who is using TechRadar right now? Who will find it useful? 

Our Sales and Presales teams were our target audience, but we also wanted our developers to use it as well. When you first encounter a new technology, you often need to assess whether this technology or framework is suitable for the project. This is where the information from the radar, where these frameworks are already described, will be useful. And it’s much better than just googling and learning everything yourself. Developers can use TechRadar just for the sake of interest, to see what we are actively using in the company, but what they might not have known before, for example. 

Our Talent Acquisition team are already using the technical gift. On the platform, they see what competencies are in demand for a specialist in a particular field, and during the interview they check how well a potential employee has them. 


Let’s imagine a person who wanted to use TechRadar. What features are available to them? 

In our process, we constantly asked ourselves: “How would I use this tool, to find the information I needed?” First of all, on our page, we tried to explain what the product is so that every person who first gets to it can understand what this tool is about. Our home page reveals the main targets of the radar and explains what you will see on it. 

We then also added an FAQ tab, where we tried to give answers to the questions that arose in our focus group before the official publication of the radar. Here you can read about how often the radar is updated, how the information is collected and the radar’s targets for the future.


 How did you determine which Subgroup (RINGS) the technology falls into? 

At first it was a rather subjective assessment, but then we decided to ask the team from .NET, JavaScript, QA, and Data divisions to see how many customers use a particular technology in production. If the number was greater than or equal to three, then we thought it was already a well-established technology for us – so it falls into the inner circle of Well-established. Plus, there are also things that have been used for years, so one or two customers can use them, but if they have been using them for a long time, then the technology is also considered well mastered. 

The Trial circle includes technologies that are already in production, that the team have already worked with, but their experience is not so extensive as to quickly assemble a team of specialists of the right nature to immediately make a project. Can we say that the technology is well mastered if we have only two people who work with it? Not really, but at the same time, we know that if a project comes for which this technology will be needed, we will at least be able to assess and look for the right people in the market. We already have a certain competence in the form of these two people. 

Assess includes things that are just being studied by the team. For example, new trends that are emerging in the market. At the same time, we already have an opinion about them, we understand what it is and how it works, albeit on a rather superficial level. Naturally, if we believe in this technology and believe that this is something that is worth following, then we continue to observe it and take steps in studying it. 

And then there’s Emerging, which is the outer circle. There’s a technology that we haven’t tried yet, but that we’ve heard of, and that’s our own to-do list. For example, one of our team went to a conference and heard about a new technology or read an interesting article, but a person does not have time to understand it, so they added it to their bookmarks. These are the bookmarks that make up the Emerging circle. 

A few months after adding the technology to this circle, we go back to it and see what happened to it in the end. If it didn’t pay off, then we’re not going to invest in that technology. 


If you click on a specific competency, a profile appears next to it, in which there is still a whole block of information. Did you collect all that information separately for each circle? 

Yes, we did, the idea was to have a quick reference at your fingertips. Let’s imagine that a person on the Sales team is talking to a customer, and the customer says, “We’d like to use fluent validation.” Most likely, a non-technical person who has never worked with this, does not even know what fluent validation is. And thanks to the technical radar, they will be able to quickly find this term, see that we really use this technology in our company, and understand its general idea with literally three or four sentences from the radar. 

How did we gather all this information? 

 First, we asked the members from each division to write out keywords on cards that would describe the main skills and competencies of their division. It took about 30 words to describe the basic set of things they know how to do for the client. Then other people, not necessarily out of this division, did the manual work: they took all these words, went to Google, searched for information and filled in data files, left links in cards and typed tags. After that, all the information was validated, proofread and uploaded to the radar. Now it has more than 300 such items. 

It is important to say that you can filter not only by keyword, if you are looking for a specific technology, but also by tags. For example, we can select .NET and see everything that this division decided to add to the radar. Mobile for example is a divisive division. As we know, Mobile is divided into Android and iOS. Therefore, if you are an android developer and you are interested in seeing what other android developers are doing, you can just choose the Android tag – and you will see only what applies to android. 


Please tell us who these people are, who did all this almost manually.  

It’s worth starting with how the radar appeared in Godel. From the very beginning, we had a ready-made radar engine from Thoughtworks – this is a popular open-source product that you can take and use for your needs. That’s how it all started. But we decided to go further and customise the workpiece, adding a few of our own features. For example, filtering by tags. Plus, because radar is a corporate platform, we wanted it to look in the style of our company. For that, we turned to Head of Design Aliaksandr Soryn and Sr. JavaScript developer Iryna Markovich. At the time, they were UI/UX enthusiasts. The guys did the design, which we showed CTO to Elena Polubochko and VP Engineering. NET Victor Nekrasov. When everyone approved among themselves the principle of operation and appearance of the radar, they began to work. 

Since the Thoughtworks engine was written in a mixture of Node.js, JavaScript, jQuery, and a couple of other old JS frameworks, I asked for help with JavaScript Consultancy. Head of Consultancy Function Iryna Schuppo and Sr. JavaScript Software Engineer Hanna Labushkina helped me a lot. They got involved quickly, and they helped with the new design. We also decided to completely abandon the old version of the radar code and set up a new version of it, which was already in open source at the time. It took a little longer than we had planned, but eventually with the help of these guys we got it done, and the radar became more like, which we even expected. 

Jr NET. Developer Pavel Radkevich then joined us. He unexpectedly fixed a lot of bugs in our beta version. Presales Consultant, Alina Halubinskaya also made an important contribution to the search for bugs and in general and did a lot for us as a representative of Presales. When we had the first version of the radar ready. I went to the heads of our divisions, enlisted their support, explained what we were doing, for whom, why, and asked them to form a list of these 30 descriptions of divisions for the radar. Then the manual entry of all the data began. 

I just want to reiterate the contribution of a huge number of people to our idea. More than 30 people took part in the development of the radar! And it really was a purposeful and productive work of all. Radar is one of those initiatives that bring our functions and divisions together, and I would even say that it is a company-wide level initiative. 


Everything you have described sounds and feels like a big system that needs to be constantly monitored and maintained. How many people are doing this now and how often? 

In Godel, the Innovations function is responsible for the radar, whose representatives in each division monitor the relevance of the information for this division on the radar. It is assumed that the work on updating the site will be carried out about once every six months. If suddenly I see that we have actively started using some framework, but it is not added to the radar, I will ask you to do this without waiting for the next update period. 

Will the radar be able to track completely different indicators in the company? Not from the point of view of development, but, for example, financial indicators. 

The basic framework is capable of showing data of any kind and it can be the same financial indicators. We can well imagine that if the information is presented correctly, described in a radar-friendly format, it will display it as it should. There is no reference to specific data. There are just certain fields that you must fill in that transform into the names of categories and rings. 


What plans do you have for the future regarding TechRadar? 

For me, the future of TechRadar is seen in the fact that it would be a product that the whole company would be proud of. To do this, it needs to include our javascript Innovations function. To include them I need to write “from scratch” my version of the technical software in React.js, one of the most popular UI frameworks, to make it a completely public open-source tool that our potential customers will also be able to see, use it and eventually learn better what Godel can do well.  

We ourselves will be able to further develop the radar in the way that we see, regardless of third-party developers. There is, of course, a small risk of showing that we do not know something, but I do not see this as a big problem. For me, it is more important to show that you are open to new knowledge and are able to understand everything, to make something your new skill. For us, this is only a plus. which suggests that the company is developing and does not stand still. 

I would like to see Godel open-source, the set of products that we distribute, be developed thanks to TechRadar. I want to lay out the source code of our modern radar, which people at their discretion could supplement and develop further. That is, to popularise both the company and the products that we at the company have made. This is, of course, a global plan, but I would like it to be implemented because I have already seen, how in a single rush we were able to make a product for which I am certainly not ashamed. 

Ready to talk to Godel

My Chatbot