We manage technologies in a company without those. radar
What’s wrong with big companies?
Above I spoke about large and fast-growing companies, in this place it is necessary to explain why we are talking about them. Such structures are characterized by:
- the presence of a large number of technologies at various stages of use;
- a large number of teams;
- a lot of legacy that you want to get rid of.
Now, in a little more detail, what problems there may be. Let’s start with the most obvious: this is a zoo of technology that needs to be supported. It is expensive for the company. It is difficult for a large number of teams to synchronize according to the technologies used and the patterns of their use, for example, which streaming platform to use and is there any experience of using it in the company? It is not clear how to manage legacy technologies and decommission them. And at the same time, with all this, it is necessary to remain transparent for candidates in the market.
Let’s figure out what to do with it. It is a good form when setting a task, and in our country it sounds like “managing technologies in a company”, is to ask a question – for what? We will ask it this time too and try to answer it.
- Ensure stack transparency for applicants.
Let’s place the stack on the portal, ask recruiters to send links to candidates. Applicants see what we work with every day, what stack we use.
The transparency of the technology stack for candidates helps to correctly decide whether I will really apply my skills in a new place and whether I will be able to learn new things. Visualization helps to understand how relevant the technologies used are. Few developers will agree to write front-end in JSP or integrate microservices via ESB.
And we will also make a cool banner with technologies, we will carry it around conferences. We will put it on the stand – let everyone see what we are working with.
- Make the stack transparent within the entire company.
The company is like a complex clockwork. Everything should work smoothly. Meet Konstantin, the new technical architect at the company. The management aims to select the appropriate technologies for the implementation of a new product. After several meetings with the management and enterprise architects, Kostya understands that the resource of internal developers may not be enough for such a product and some of the tasks will have to be transferred to the contractor. What technologies should you choose? What is it customary for the company to work with and what can our engineers then support and develop? Kostya addresses those. the stack of the company, makes a decision on the choice of technologies and on the basis of this, if necessary, helps the owner of the product find the right partner in the market.
- reduces the decision-making time for a company employee responsible for the choice of technologies for a specific task;
- reduces the cost of supporting the technology zoo;
- makes it possible to search for internal resources;
- makes it possible to reuse code within the company. You can read more about Innersource in one of our articles.
- Manage the technological development of the company.
And finally, last but not least, point. With proper stack management, complex strategic decisions, such as building a technology development strategy, implementing software, developing a recruiting strategy or choosing inhouse / outstaff / outsourcing, are made based on data. It is possible to decide how to develop a company in the technological direction only by knowing what is happening inside the company in terms of technology. We add to this knowledge about trend technologies, describe their life cycle, criteria for getting into those. stack, and now we are closer to the management of technology in the company. And, of course, do not forget that this is one of those management tools. debt. A legacy system based on non-stack technologies or a new system that bypasses the stack automatically write those. debt for alteration. Typically in large companies, this technology development management process is centralized and managed by the CTO.
What we want to achieve is now clear. We will select the right tool.
What approach did Leroy Merlin take?
In Leroy Merlin, they approached the stack formation 2 times. First time in winter 2018-2019. It was standard those. radar, of which you have already seen a great many. This approach seemed not very convenient: it is not clear in which case which technologies to use. Then we just recorded the technologies that we use and their level of maturity within the company, but did not describe how we work with them, what is the life cycle of the technology within the company and what to do if I want to try to solve a business problem using technology outside the stack. For these reasons, we refused to use radar as a visualization and technology management tool within the company.
The second approach to creating those. stack was different from the first. We tried to solve the problems we encountered the first time. To consistently manage those. stack, we created a technology committee that consists of CTOs, architects, technical team leaders, and infrastructure representatives. In the new paradigm, they began to use table technology instead of radar.
We liked this approach more because the technologies are divided according to the scope and method of use. For example, we need to make a simple service that simply accesses the database – we go to the Business Application Backend section, understand that CRUD is most suitable, and see what technology is recommended for such a pattern. Another example: when needed Bff, we look at the recommended technologies and immediately take the low-code platform. For each use case, a technology is selected: language, framework, tool or platform and our attitude to it.
- Research – we try to play, it is not clear yet.
- Trial – run in limited edition for sale.
- Best Choice – cool, you have to take it. Recommended for use in a new project or product.
- Hold – tried it, played enough, that’s enough. We also get into Hold if the technology is outdated, the technology is not supported by the vendor, or negative operating experience is obtained in the Trial and Research stages. Usually our Legacy is located here, which we systematically rewrite. We do not recommend using such technologies in new products.
All categories except Research can work in production.
A little about experiment management
The Research category is our absolute favorite, and here’s why. We have developed a rule: we enter new and interesting technologies for us in a separate trend table with a short justification of how this technology can be useful. Each team can take one of the technologies for research. Based on the results, fill in canvas an experiment made by our Engineering Manager Alexander Regner. Then the team comes to the next meeting of the technology committee and talks about how the research ended, and based on the results, we decide to move the technology to Trial or Hold.
The sophisticated reader will probably argue that we make it harder to work with innovation. My answer is that trying something new is just as easy, just this attempt needs to be described so that there is less chaos. And this description helps internal communities to understand how the experiment ended.
A few words about the internal communities, since we have already mentioned it. At Leroy Merlin, we develop in-house profile communities such as Java, QA, Node and others. We believe it is important that employees have a platform to discuss the specifics of applying technology in their teams and that they can put forward proposals for the further development of technologies in the company. Representatives of such communities are included in the technology committee. You can read more about the rules of the technology committee on our those. portal…
Just a week ago, I had a conversation with a colleague from France, who is faced with the task of putting together a technology stack for all companies in the ADEO group (Leroy Merlin is one of the companies in the group). He asked how we managed to reach an agreement, since it is not an easy task to compile a technology stack, and even such a detailed one. Well what can I say: we agreed for a week. Every day they broke their spears for an hour, loudly clapped the exit button from the zoom conference, but nevertheless they managed to reach an agreement. The main thing is that they answered the question for themselves why this particular technology is in this life stage.
A couple of days ago, we made an autumn review of the stack without unnecessary emotions, clearly and to the point, in an hour and a half.
What we finally got from the introduction of this technology management approach:
- visualization tool;
- decision-making assistant;
- the described rules for working with technologies and their life cycle in the company;
- HR branding tool: Candidates can always see what they have to work with. We haven’t made a banner yet, we look forward to offline conferences and you at our booth.
How does your company manage the technology stack?